I really like that analogy. I think emacs succeeds because of three things mainly:
* It's so vitally important to people for their day to day work that it simply can't fail. I would far sooner trawl through, and modify, the worst elisp in the project than switch editors - I expect I'm not the only one.
* A (relatively) big, chatty and friendly community of smart hackers.
This is the really fucked up thing about object-oriented, case-based, "rational," or whatever is now fashionable fads. The snake-oil pushers sell them as the way to write maintainable software, with absolutely no evidence as to whether any of it works. And people believe them.
If you actually study long-lived, maintainable software that continues to evolve, you find it doesn't have modules or even namespaces (everything written in C, all of the old Lisp code), uses the simplest possible patterns of control, and is largely datastructure driven.
But no one actually looks at software that works because it has "poor design." Everyone would rather waste time on the latest modularization masturbation (OO, patterns, and now actors and persistent datastructures).
If I may take the conversation up to an academic level here, I always like Conway's Law:
"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." (cf. http://en.wikipedia.org/wiki/Conways_Law)
Most software is built in institutional organizations (banks, universities) or by commercial software vendors or otherwise hierarchical, departmental organizations. Therefore, almost all investment in software practice result in software designs and control structures that support hierarchical, departmental organizations.
Emacs and TeX are very different human organizations. Decentralized, ad hoc, stigmergic [1], meritocratic. Very few projects are organized this way and so very few people look at software design patterns that support these kinds of projects.
[1] Stigmergy is self-organized coordination and collaboration managed indirectly through the object being worked on. cf http://en.wikipedia.org/wiki/Stigmergy
I've flagged this post, mainly because the entire "article" contains absolutely nothing of substance. It is a fluff blog post that doesn't have anything new to say, doesn't provide anything for hackers to think about.
"Please don't submit comments complaining that a submission is inappropriate for the site. If you think something is spam or offtopic, flag it by going to its page and clicking on the "flag" link. (Not all users will see this; there is a karma threshold.) If you flag something, please don't also comment that you did."
One even flouts the guidelines to tell us they've flagged the item. And to be honest, I'm rather glad they have, because now I can see a different perspective than mine, and I have the chance to learn something.
I don't understand why these people think this doesn't belong here. It's about software design, and the suggestion that modern opinions, dogma, even, might not be as definitely true as we claim. If Emacs can survive, even thrive, without being designed in a "modern" way, doesn't that give cause for pause?
... because the software is so light on
bureaucracy, it is easy to customize and
to contribute to.
Would someone care to refute this? More than once I've attempted to contribute to a project, knowing that I can improve some aspect, and been thwarted by the sheer magnitude of the task in coming up to speed with all the nuances of the existing design.
Rather than simply saying that it doesn't belong, can you actually refute the claims? I'd like to see a reasoned discussion - that's why I thought it was interesting.
OP isn't much but a 'emacs is successful despite being bad software engineering in these ways', which isn't all that interesting. What would be more interesting is a discussion why those ways aren't bad for emacs or how emacs overcomes those handicaps.
But even though the OP doesn't have that, I was hoping the discussion here could, in effect, "crowd-source" such a contribution. So often in the past on HN I've seen relatively content-poor posts lead to serious discussions that pull together expertise and experience from a wide range of people, and the discussion has been a great reference.
EDIT: Don't mind the down-vote(s) - don't really care about karma - but I'd love to know why people disagree with my comment. Thx in advance.
> I don't understand why these people think this doesn't belong here.
Sorry, I wasn't trying to be rude. I just feel like its a couple of paragraphs long and doesn't have any substance. Like the other guy said, its a fluff piece. And the one thing you specifically pointed out of the article is actually incorrect.
>> because the software is so light on
>> bureaucracy, it is easy to customize and
>> to contribute to.
> Would someone care to refute this?
I would. Emacs was specifically NOT light on bureaucracy. That is specifically why xemacs created.
10 comments
[ 18.2 ms ] story [ 759 ms ] thread* It's so vitally important to people for their day to day work that it simply can't fail. I would far sooner trawl through, and modify, the worst elisp in the project than switch editors - I expect I'm not the only one.
* A (relatively) big, chatty and friendly community of smart hackers.
* It's simply fun to hack.
If you actually study long-lived, maintainable software that continues to evolve, you find it doesn't have modules or even namespaces (everything written in C, all of the old Lisp code), uses the simplest possible patterns of control, and is largely datastructure driven.
But no one actually looks at software that works because it has "poor design." Everyone would rather waste time on the latest modularization masturbation (OO, patterns, and now actors and persistent datastructures).
"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." (cf. http://en.wikipedia.org/wiki/Conways_Law)
Most software is built in institutional organizations (banks, universities) or by commercial software vendors or otherwise hierarchical, departmental organizations. Therefore, almost all investment in software practice result in software designs and control structures that support hierarchical, departmental organizations.
Emacs and TeX are very different human organizations. Decentralized, ad hoc, stigmergic [1], meritocratic. Very few projects are organized this way and so very few people look at software design patterns that support these kinds of projects.
[1] Stigmergy is self-organized coordination and collaboration managed indirectly through the object being worked on. cf http://en.wikipedia.org/wiki/Stigmergy
The most popular discussions of this I've seen are Eric Raymond's Cathedral and the Bazaar (http://www.catb.org/~esr/writings/homesteading/cathedral-baz...) and Coase's Penguin (http://www.benkler.org/CoasesPenguin.html).
"Please don't submit comments complaining that a submission is inappropriate for the site. If you think something is spam or offtopic, flag it by going to its page and clicking on the "flag" link. (Not all users will see this; there is a karma threshold.) If you flag something, please don't also comment that you did."
http://ycombinator.com/newsguidelines.html
http://news.ycombinator.com/item?id=2552857
http://news.ycombinator.com/item?id=2552812
One even flouts the guidelines to tell us they've flagged the item. And to be honest, I'm rather glad they have, because now I can see a different perspective than mine, and I have the chance to learn something.
I don't understand why these people think this doesn't belong here. It's about software design, and the suggestion that modern opinions, dogma, even, might not be as definitely true as we claim. If Emacs can survive, even thrive, without being designed in a "modern" way, doesn't that give cause for pause?
Would someone care to refute this? More than once I've attempted to contribute to a project, knowing that I can improve some aspect, and been thwarted by the sheer magnitude of the task in coming up to speed with all the nuances of the existing design.Rather than simply saying that it doesn't belong, can you actually refute the claims? I'd like to see a reasoned discussion - that's why I thought it was interesting.
For example, in an earlier Cook post on Unix philosophy, I linked http://www.johndcook.com/blog/2010/06/30/where-the-unix-phil... to ESR's discussion of Emacs http://www.catb.org/~esr/writings/taoup/html/ch13s03.html#id... and the followup discussion about the interesting idea of contexts/frameworks http://www.catb.org/~esr/writings/taoup/html/ch13s04.html
That could be more than a blog post, it could be a real contribution.
EDIT: Don't mind the down-vote(s) - don't really care about karma - but I'd love to know why people disagree with my comment. Thx in advance.
Sorry, I wasn't trying to be rude. I just feel like its a couple of paragraphs long and doesn't have any substance. Like the other guy said, its a fluff piece. And the one thing you specifically pointed out of the article is actually incorrect.
>> because the software is so light on >> bureaucracy, it is easy to customize and >> to contribute to.
> Would someone care to refute this?
I would. Emacs was specifically NOT light on bureaucracy. That is specifically why xemacs created.
Anyway, hope you have a good day.