I couldn't articulate why I wanted to release software under an Open license to my boss, but ESR's writing helped them understand as far as they were able.
At least Terry Davis could write code.
https://geekz.co.uk/lovesraymond/archive/show-them-the-code
https://geekz.co.uk/lovesraymond/archive/moral-compassed
https://news.ycombinator.com/item?id=13147038
tptacek on Dec 10, 2016 [-]
I think we're all pretty sure ESR is not in fact a god, and that nothing could have occurred with ESR or his magic flute to have demonstrated to him that he was. Rather, the story is more broadly illustrative of a pretty extreme narcissism and --- challenging --- variant of self-awareness. For a more down to earth example, consider how many of us would non-ironically write the following passage:
I’m wondering about this because my wife Cathy asked me a simple question last night, and I realized I didn’t have an answer to it. “Are you” she asked “the most famous programmer in the world?”
This was a question which I had, believe it or not, never thought about before. But it’s a reasonable one to ask, given recent evidence – notably, the unexpected success of my Patreon page. This is relevant because Patreon is mainly an arts-funding site – it’s clearly not designed for or by techies.
It goes on in this vein. Here, by the way, is a link to his Patreon page:
[link redacted]
Apparently we value "the code that makes our digital world work" a bit less than we value the person who fries our french fries at McDonalds. If that sounds mean, well, it is, but it was also Eric Raymond who put forward the idea that his Patreon page may indicate that he's among the most famous programmers in the world.
For a nerdier take on ESR's merits, hunt down Terry Lambert's take on fetchmail. (You should know who Terry Lambert is, if you don't already).
[link provided to "A tangential diatribe on the unsuitability of fetchmail"]
https://markmail.org/thread/pmoqk6tuybncu2is
armitron on Dec 10, 2016 [-]
Not to mention that ESR was, at some point, a multi-millionaire. Pretty sure he still is, in which case that Patreon page of his would be nothing but a con.
This raises an interesting question: who actually is the most famous programmer?
(Obviously it's a fuzzy standard, but I'd broadly want to say "famous largely for coding work". I don't think Brin or Page were household names until they were in executive roles. Whether Zuckerberg counts, or rather when his fame stopped counting, is tricky. Snowden, Assange, Swartz, etc. I'd discount for the same reason.)
Offhand, the same-generation names that I think beat esr are Richard Stallman, Linus Torvalds, and maybe Knuth. The overall winner might be Sir Berners-Lee, who regularly gets mainstream press coverage - unless we're including Turing.
He has such clarity of thought and mastery of diverse languages (some of which he invented and implemented). He saw exactly what was wrong with XML Schemas, and addressed it practically and elegantly with TREX, which he and others refined through humble constructive collaboration into Relax/NG. And he's a big proponent and creator (not just a talker like ESR) of free open source software.
Here's a fascinating insightful DDJ interview of James Clark, "A Triumph of Simplicity: James Clark on Markup Languages and XML":
http://www.drdobbs.com/a-triumph-of-simplicity-james-clark-o...
>A Triumph of Simplicity: James Clark on Markup Languages and XML
>If you peek under the hood of high-profile open-source projects such as Mozilla, Apache, Perl, and Python, you'll find a little program called "expat" handling the XML parsing. If you've ever used the man command on your GNU/Linux distribution, then you've also used groff, the GNU version of the UNIX text formatting application, troff. If you've ever done any work with SGML, from generating documentation from DocBook to building your own SGML applications, you've undoubtedly come across sgmls, SP, and Jade.
>Whether you've heard of him or not (and mostly likely, you haven't), James Clark (below right) has made your life easier. In addition to authoring these and other widely used open-source tools (see http://www.jclark.com/ for a complete list), Clark served as the technical lead of the original W3C XML Working Group and as the editor of the XSLT and XPath recommendations. He recently founded Thai Open Source Software Center (http://www.thaiopensource.com/). His latest project is TREX, an XML schema language. Clark sat down with Eugene Eric Kim to discuss markup languages, the standardization process, and the importance of simplicity.
[...]
>DDJ: You're well known for writing very good reference implementations for SGML and XML Standards. How important is it for these reference implementations to be good implementations as opposed to just something that works?
>JC: Having a reference implementation that's too good can actually be a negative in some ways.
>DDJ: Why is that?
>JC: Well, because it discourages other people from implementing it. If you've got a standard, and you have only one real implementation, then you might as well not have bothered having a standard. You could have just defined the language by its implementation. The point of standards is that you can have multiple implementations, and they can all interoperate.
>You want to make the standard sufficiently easy to implement so that it's not so much work to do an implementation that people are discouraged by the presence of a good reference implementation from doing their own implementation.
>DDJ: Is that necessarily a bad thing? If you have a single implementation that's good enough so that other people don't feel like they have to write another implementation, don't you achieve what you want with a standard in that all implementations — in this case, there's only one of them — work the same?
>JC: For any standard that's really useful, there are different kinds of usage scenarios and different classes of users, and you can't have one implementation that fits all. Take SGML, for example. Sometimes you want a really heavy-weight implementation that does validation and provides lots of information about a document. Sometimes you'd like a much lighter weight implementation that just runs as fast as possible, doesn't validate, and doesn't provide much information about a document apart from elements and attributes and data. But because it's so much work to write an SGML parser, you end up having one SGML parser that supports everything needed for a huge variety of applications, which makes it a lot more complicated. It would be much nicer if you had one SGML parser that is perfect for this application, and another SGML parser that is perfect for this other application. To make that possible, the standard has to be sufficiently simple that it makes sense to have multiple implementations.