The Myth of the Lone Hacker | Hacker News Reader

The Myth of the Lone Hacker

ashtonkemerling.com

51 pointsGarbage18 comments

Common Lisp isn't the only option. There are other communities that are geared more towards practical development, with large and growing user and library bases. Aside from the obvious example of Clojure, I'm thinking specifically of Racket [1] and Chicken Scheme [2]. I use the latter personally, and it's a pleasant experience on any project scale, with the heavy emphasis on extensibility and package management. It also compiles to C.

[1]: http://racket-lang.org/ [2]: http://www.call-cc.org/

Lone hackers are not a myth. There are definitely people out there who do incredible things entirely or mostly by themselves.

It seems to me that question is orthogonal to the value of community for a language. If anything, a strong language ecosystem empowers lone hackers, and I suspect most good ecosystems benefit greatly from the contributions of lone hackers.

In this case I meant myth in the "tradition or legendary story" sense, not the "this is completely false" sense.

Ashton, I appreciate your thoughts on this subject - I've been meaning to write about it for a while, and just posted my response here: http://startupframework.tumblr.com/post/36816740387/power

Not to side-track from programming language semantics, but I hope to engage in a discussion on the sole entrepreneur as you mentioned.

Edit: I think the bottom line of your post and mine is that: No one does it alone. At least, that's my (perhaps more philosophical than technical) take on it. So for hackers and entrepreneurs to reach critical mass with their products/offerings, they need the input/help/support from those around them (family, friends, clients, etc).

I do wonder why such a powerful language such as Lisp has such a small community and number of libraries. There may exist some trade off between the level abstraction and number of users for languages. You may have to 'hang around' long enough before the penny drops and you're a proper Lisper that can use the language productively. What other languages have for them, in my small experience at least, is that you can grasp all the essentials and get a general feel for the language very early on- allowing you to 'hit the ground running'. With Lisp, it takes a while (I started learning a few months ago) to grasp concepts such as macros, closures, and continuations, which really give Lisp its power, and then effectively implement them on the fly. A few bloggers out there write about the 'moment of clarity' that they get once they understand Lisp macros, etc.

There was an article posted here a while ago that made the case that Lisp is so powerful that it makes it feasible to do much more yourself rather than relying on libraries, and thus it attracts a higher level of hacker that wants to do things their own way and is more intolerant of compromises made in the name of standardization. Sort of the opposite of the lowest common denominator approach of successful enterprise languages like Java. The failure to thrive of Common Lisp is strong evidence of the worse-is-better phenomenon.

I would say this is also highly driven by non-hackers. Many schools are nothing more than Java certification shops and many companies select technologies pushed through salespeople.

I'm fairly sure languages such as Lisp and SmallTalk would be much more widespread today if the industry wasn't told what to use by clueless people driven by profits.

Couldn't agree more on that one. When given a task, people who take programming just as a job will look for a open source project to hack around and taylor it to do a job, instead of doing the hard implementation by themselves.

Interestingly, looking within the Lisp hacker community, individual hackers seem to be doing quite well. It seems as though the language is geared towards empowering the individual. Even though Lisp is hard to learn, once you 'get it' the pay-off seems to be rather large.

Proportional to its number of users, Common Lisp probably has more libraries than any other language in history. The problem is described in the article: all of the libraries are half-baked "trivial" implementations that cover the author's use case. Very few, if any, CL libraries are continuously maintained. Even fewer have usable documentation. Fewer still are feature complete.

Check out the list of EIGHT GTK+ bindings for Common Lisp: http://www.cliki.net/GTK%20binding

And yet, the last time I attempted to write a trivial GUI application using GTK and CL, I could not find a single usable library. I tried four and they were all unusably broken on my platform. (This was some years ago. Clearly at least four more implementations have come around since then.)

There has been a call from within the Common Lisp community to work toward consolidating libraries. http://fare.livejournal.com/169346.html

I think this is a step in the right direction. If the XKCD comic is true that every generation produces a handful of lisp hackers, I hope this is the generation that looks to Quicklisp as a foundation to build a modern, consolidated set of batteries.

Nevertheless, it was Richard Stallman who wrote a hell lot of GNU as a lone hacker.

So the empowered individual is a myth, and to the extent it is not a myth, these reckless individuals harm the community. Individualism bad, got it?

I neither use, nor have used Clojure, but I keep hearing about it, which says something for the community aspect. Curious how this maps to that.

cl != clojure each has it's own unique community, paradigms and tools (aside from slime).

Clojure can draw on the whole Java ecosystem, so it's immediately useful, which gives it a great entry point.

Yes but it also has a package manager and library repository with over 5000 idiomatic Clojure libraries. A lot of projects would not even have to use Java libraries.

For someone already familiar with the Java ecosystem, this can be a huge boon. For someone unfamiliar with Java and the Java ecosystem it can be a little bit daunting.

Case in point, I recently had an experience where I was trying to read some binary data with nio. This meant I was reading java docs related to nio trying to figure out a java implementation of what I needed to do. Then I needed to translate this into clojure. As a new clojure user who didn't have quite the grasp of the java interop idioms, my code looked pretty ugly, and with a lot of (. foo (. bar (. baz))) looking stuff.

That said, if you're going to have a "problem," a preponderance of usable, high-quality libraries isn't exactly the worst I can think of...

Reply on news.ycombinator.com