Just for a moment, consider who this man is and what he has done. We would all do well to take a step back and consider his manner of response. Notice that he continued learning new languages after creating Erlang (instead of just evangelizing it at the one true language). He did not immediately say "choose these three languages" as if they were the only ones you could possibly learn.
Encouraging people to build stuff, whatever the language, whatever the library, whatever the framework; that is what we should be doing. IF someone wants suggestions, or help deciding what to use, that is fine, but criticizing someone for the language or framework they use has become all too common and a stain on the character of our community.
That's not to say honest criticism is unwelcome: All languages/libraries/frameworks/software can improve. But to belittle people for the choices they make, or to segregate ourselves into voluntary language-ghettos we are compelled to stay in by the force of public opinion...that goes against the spirit of what people like Armstrong worked hard to build. Maybe it started with "Worse is Better", maybe it started with alt.religion.emacs being taken a little too seriously, but it has been perpetuated by all of us, even Paul Graham (in Beating the Averages).
At some point, this has to stop. We, as a community, must grow to support the betterment of hacking by creating and encouraging creation; not by petty vitriol and conformism based on fashion.
Now, I've strayed pretty far from the point of the post itself, but Armstrong closed with such a salient point: If we stopped bickering so much about what is the "right language", "right framework", "right library" and instead encouraged particular protocols and documentation standards we'd all be better off for it.
This man is a legend. Not just being the father of Erlang (and that's probably enough to make him a legend). But it really is his attitude and his desire to never stop learning, never settle. He is still working and tinkering.
(function(a, b) return a * b end)(1) //valid lua (runtime error)
> Even on Hacker News I've seen vitriol directed at [...]
To be fair, the author himself is pretty vitriolic about C++:
"I saw C++ coming and read the book - or at least tried to read the book -
there's a dent
in the wall behind my piano, where the book hit the wall - Improvements to
C should make things
easier not more complicated, I thought"
You are absolutely correct, of course. But he was sharing his personal frustrations with C++, not engaging in the programming equivalent of "slut-shaming" someone for using C++. That's an important distinction that I think has been lost with the HN community. Without criticism, nothing would get better, but if you criticize someone for making something or making a choice, you might just encourage them to stop being a maker. And that's sad for all of us.
Given Dmitry instigated that incident by attempting himself to "slut-shame" C, I'd say he had that one coming! I think Linus was fed-up there with the nth polite suggestion he re-implement either git or the kernel in C++.
There was a "police camera action" footage of a UK nightclub and a man leaping up and slapping the bouncer 6 or 7 times because he was not allowed in - on the eighth leap the bouncer simply punches him once to the ground.
The voice over explains that police had reviewed the footage, and whilst commonly prosecuting bouncers for ABH, this time declined to press charges.
not being a girl myself, I suspect that a girl who has been "slut shamed" would probably take offense at someone referring to our circle jerks about one's favorite tool(s) to be considered "slut shaming". Lets keep things in perspective here.
> If we stopped bickering so much about what is the "right language", "right framework", "right library"
Programmers are sometimes maximizers rather than satisficers for this kind of thing. We don't want to know if something is ok and will get the job done, we want the best one.
I think people argue for their language out of some sense of the network effects involved: if I can get more people using my language, there will be more libraries, more people to ask about problems, more people to hire/to hire me, more books, and so on and so forth.
So I think there is some economic rationality to it.
I don't think it's anywhere near that complicated. People argue about languages because languages become part of their identity: It's common to think of oneself as for example a "Lisp Programmer". And if a language is part of your identity than people saying less than amazing things about that language feels like an attack on you personally, and very quickly the discussion devolves into an argument that has nothing in particular to do with the actual languages as such.
The problem is one of identity. We will protect anything that we attach to our identity because we perceive any attack on it as an attack on us. To have intelligent, unemotional conversations that has to be decoupled.
In general it can lead to problems if we map our identity externally - whether to a programming language, or something else - of course this is easier to preach than to practice.
Can you point out some things that don't become part of people's identity? My experience is that anything that someone spends more than a tiny amount of time with immediately starts becoming part of who they are.
The boundary of our self is constantly spreading outwards onto the things around us. Seems to be part of human nature.
Psychologists have a concept known as "self-complexity" (wiki it). Basically, it's our view of ourselves, in terms of the many attributes, relationships, skills, deficiencies, etc. we possess. Someone who thinks of themselves in broad terms, filling many roles and with many aspects, is said to have a high self-complexity. Someone who thinks of themselves in terms of only a single aspect has low self-complexity. Think of "I'm a world-class kernel C hacker" vs. "I'm an awesome C programmer" vs. "I'm a good programmer" vs. "I'm a decent human being".
So no, it's not bad for new activities to become part of your identity. It can be bad for them to become your whole identity, because it leaves you really vulnerable to outside attacks on your self-conception.
(On a side note, it seems to me that a lot of the Silicon Valley startup mythology is focused on encouraging low self-complexity and an obsessive focus on external success. Now that I re-read some of PG's early essays, several of them seem actively harmful to one's mental health. The YC application used to ask you "How are you an 'animal'?", in reference to an early essay where he suggested that successful startup founders often act like caged animals - as if denying your humanity is "success".)
Generally really like your post, but I have to correct you about PG's essay.
It's people who work at normal jobs that he calls caged animals, and founders are the wild animals.
"In fact, getting a normal job may actually make you less able to start a startup, by turning you into a tame animal who thinks he needs an office to work in and a product manager to tell him what software to write."
"One of the best tricks I learned during our startup was a rule for deciding who to hire. Could you describe the person as an animal? It might be hard to translate that into another language, but I think everyone in the US knows what it means. It means someone who takes their work a little too seriously; someone who does what they do so well that they pass right through professional and cross over into obsessive."
I think it's because we invest so much time and energy working with them. Most humans can't do that without becoming attached.
Once you identify with something it becomes difficult to be objective about it. So discourse about technical tools is mostly emotion, however rational it pretends to be. That's why the core debates never end.
By the way, you can add version control systems to your list.
In order to write invent COBOL Rear Admiral Grace Hopper had to invent programming languages, compilers, linkers and the entire modern IT industry - and then she had to implement them, without a programming language or a compiler or a linker.
I'm just (re)learning to code after doing a bit in college (c/c++), currently learning Ruby (and Rails). As a regular reader of HN, I see posts about how great Erlang is, Scala, Haskell, Python, etc. And they do seem to be great languages. And I want to learn them. But as the author points out (and as I have come to realize), regardless of my desire to learn all these things (right now!), it would almost seem fruitless to quit on Ruby/Rails after about 6 months.
The large point is, regarding langugage/framework bashing, people put in so much time into a particular language. You almost have to buy into it. I guess some people just become zealots.
The advantage of programming long enough is that your 'primary' language changes several times, and each time you get less zealoty about it.
Having learned a bunch of languages myself i would recommend beginners to learn a language thoroughly before moving on. Otherwise you don't assimilate the style of a language and end up writing fortran in c, or c in c++. The qualitative differences between languages don't become obvious until you understand why their common style is what it is.
I don't share your strong focus on "encouraging creation." I think it is more important that we encourage cooperation and sharing then creation. We have no shortage of software being created the problem is we still are extremely bad at fitting things together.
Fitting things together is important, but it exists entirely for the purpose of creating things, which is ultimately in service of end users. Fitting things together is mostly an implementation detail.
Creating things is just fitting together new things. Rather then fitting together many new things that may overlap already existing things we should focus on fitting together an efficient unified system that use resource sharing to ensure a minimum of bloat.
In death of the desktop, interface expert Aza Raskin mentioned that his computer has seven copies of the spellcheck program with seven slightly different implementations of the English language. Building a user interface based upon command sharing rather then bloated applications will ultimately benefit end users.
Obviously better interop is a Good Thing, but we're talking about relative weights of good things. My point is that it's nonsensical to ascribe "fitting together" a higher weight than "creation", because "fitting together" is a subset of "creation".
Now as to the manner of creation: you're reacting against the "just hack it together" philosophy of ghc. But the alternative in ghc's mind, I think, was people not creating anything for fear of not getting it right, or not knowing that building something for themselves is even a possibility. Sub-optimal creation is usually better than nothing, especially when nobody else has to use it.
Fitting stuff together is hard, especially now when we don't have good protocols. While we're working on those, telling people who just need to get stuff done to "wait until we figure some stuff out" is not acceptable. Those people (who may not even be "Programmers") and their products will still benefit from "fitting things together" to some degree that depends on the application (OS or fart app?), but that needs to be balanced against the need to actually finish at some point, all of which is in the service of some non-software need. They just need to get it done with whatever works, whether it's Haskell, PHP, or a spreadsheet. That, I think, is the point ghc was getting at.
You got it backwards when you said "fitting together" is a subset of "creation." Creation is fitting existing unused materials together into a more usable form. I believe we should encourage people to fit together existing programs rather then encouraging people to build stuff "whatever the language, whatever the library, whatever the framework".
If everybody uses whatever framework without concern for compatibility it will inevitably lead to enormous bloat. I have no problem with getting things done quickly to fulfill non-software needs. However, when it comes to software one of our most important needs is to reduce bloat by encouraging sharing.
On-Topic: Anything that good hackers would find interesting. That includes more than hacking and startups. If you had to reduce it to a sentence, the answer might be: anything that gratifies one's intellectual curiosity.