https://github.com/joearms?tab=activity

He is also a regular at the Erlang mailing list:

http://erlang.org/pipermail/erlang-questions/

http://www.infoq.com/presentations/ECC-Fun-Writing-Compilers

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.

(http://paulgraham.com/identity.html talks about this some, I'm sure there are other better references I can't find right now.)

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.

(What do programming languages, operating systems, and text editors all have in common? They're big parts of people's identities...)

The boundary of our self is constantly spreading outwards onto the things around us. Seems to be part of human nature.

By itself, self-complexity is neither good nor bad, but it does have consequences. High self-complexity buffers you against negative events or negative appraisals of those aspects you identify with. Someone who's devoted their life to low-level kernel hacking is going to take it more personally when you say C is obsolete and only a fool would be involved in OS design in 2013. Someone who also sees themselves as a husband and a father and a good friend and a church leader and not all that bad at Javascript web programming either is probably going to let it roll off them; they may think you're wrong, but they'll just shrug and say "Whatever; you're entitled to your opinion" and not bother to argue the point.

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".)

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."

http://www.paulgraham.com/notnot.html

http://www.paulgraham.com/start.html

"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."

It used to be of course that you were a Ford man or a Chrysler man. But nowadays it's become much rarer.

I agree that it's natural, but I think that the targets for identification shift over time and I don't think it's random.

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.

Now, that said, given the choice, I'd choose coffescript. It gives many of the same benefits in a more concise format. It has its warts as well, though, reflecting its desire to stay as close to a concise-javascript as possible.

example:

  (function(a, b) { return a * b; })(1) //valid javascript (NaN)
  (function(a, b) return a * b end)(1) //valid lua (runtime error)

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"

The wanna-be makers project their own failings more readily.

1. A clear and succinct citicism directed at the failings of a language in technical terms

2. Attacking a maker and telling them not to make stuff.

However.

Like Stallman, we take the rough with the smooth with Torvalds. Some people earn it.

The voice over explains that police had reviewed the footage, and whilst commonly prosecuting bouncers for ABH, this time declined to press charges.

Its probably not at all the same :-)

And that's a woefully terrible thing to be good at.

But do not program in COBOL if you can avoid it.

The Tao Of Programming verse 1.3

That is the TAO of COBOL - the mother of us all.

Book looks interesting, will check it out.

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.

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.

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.

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.

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.

"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."

Well said

We should be encouraging people to learn stuff before they attempt building it.

http://ycombinator.com/newsguidelines.html