Hacker Newsnew | comments | show | ask | jobs | submit login

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.

Does it really help our profession/hobby at all if we engage in language-elitism and snark? Even on Hacker News I've seen vitriol directed at Ruby, Python, Javascript, Haskell, to name a few recent targets. All languages have their place, even if that place is only as a lesson for future language designers.

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.

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

He is also a regular at the Erlang mailing list:

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

-----


A must watch talk, on joearms thinking and humour. talk is about on writing C compiler.

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

-----


I found it revealing that he appeared to not only like Javascript, but liked it better than Python and Ruby. Interesting. I personally have grown to love coding in Javascript, but I'm a dumbass who doesn't know Lua, Erlang, Haskell, etc. It would be interesting to hear his perspective on JS.

-----


I know quite a few languages, and I like Javascript. It has a nice mix of functional, procedural, and object oriented aspects. Once upon a time, it was a horrible language to work in (with browser differences making it infinitely worse); but now, I find I like it.

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.

-----


I feel like coffeescript largely exists because of early mistakes in javascript, like no heredoc and places where they weakened the language to make it more convenient, like this one I just discovered today (with workarounds) http://stackoverflow.com/a/14510952/539149 and js has a ton of problems because it separated Array and Object, but overall I think it's still probably my favorite language right now. I like lua too but it's less pure, so aspects of it remind me of older languages like pascal.

-----


just a note: Lua is basically a very cleaned up version of Javascript. if their APIs were the same you could practically do a literal transcription between them and most programs would run with little alteration. that includes things like object literals (lua tables).

example:

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

-----


I love Lua because of it's reluctance to use symbols (such as braces). It's mostly an aesthetic thing. I think it looks great.

-----


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

-----


I've yet to see anyone who 'slut-shames' based on language produce anything of value.

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

-----


Either you don't consider linux to be 'anything of value' or you haven't read Linus Torvalds' take on c++ http://harmful.cat-v.org/software/c++/linus

-----


This is amazingly both of the above points

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.

-----


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.

Its probably not at all the same :-)

-----


Finding one edge case doesn't refute the original point. Most /r/programming-esque lingual slut-shaming is by people who seem to be very good at being Right On The Internet, and not much else.

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

-----


What evidence do you have that a propensity to "slut-shame" isn't distributed evenly between people who are and aren't good at things?

-----


Purely anecdotal. I'm just highly suspicious of individuals who feel the need to slut-shame anonymous people on the Internet rather than actually make things.

-----


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.

-----


i hope it was a girl who downvoted me.

-----


I read this more as memoir than as present-day judgement.

-----


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

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

-----


I think you are bang on about this.

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.

-----


But why do programming languages become part of people's identity so readily, whereas many other things do not?

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

-----


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

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

-----


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

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

-----


I was thinking of a different essay:

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

-----


Almost everything is part of someone's identity. But I would venture for most people on this forum, they have a car but don't identify with a car brand.

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.

-----


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.

-----


Because you think in programming languages. They're not just a tool to get from X to Y, they're part of your thought process and literally a significant part of your life experience.

-----


Maybe because we used to differentiate people based on the language they speak? Sort of nationality thing? Just my guess.

-----


Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.

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

The Tao Of Programming verse 1.3

-----


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.

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

-----


It is also important to remember that COBOL was the result of design by committee in the attempt to please all parties and not her opus. This is an incredible book about her life and contribution: http://www.amazon.com/Invention-Information-Lemelson-Studies...

-----


I know - I was simplyfing a bit for dramatic effect.

Book looks interesting, will check it out.

-----


Often that purpose is to say "don't do it this way".

-----


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.

-----


Makes sense.

-----


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.

-----


Most sensible comment I have seen on HN for some while.

"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

-----


There's a reason engineering students flunk out in high numbers: if they don't know their stuff they'll build buildings that kill people.

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

-----


Ironically, he takes a swipe at PHP. And the swipe is a bit silly since PHP does have a strlen function.

-----


His point is that "Learn X in 10 minute" type books are so superficial as to miss even basic string functions.

-----


Except strlen does not give you the length of a string, but the size of a string (in bytes), unless ofcourse mbstring's func_overload directive is enabled.

-----


I thought this site was for the betterment of startup entrepreneurs, not hacking.

-----


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.

http://ycombinator.com/newsguidelines.html

-----




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: