Hey language snobs: don't pinch pennies | Hacker News Reader

Hey language snobs: don't pinch pennies

pchristensen.com

43 pointsmixmax29 comments

I wonder if personality has something to do with it. My guess is that language snobs are INTP, whereas Blub programmers are more INTJ. From the descriptions at http://www.personalitypage.com/portraits.html:

"INTPs value knowledge above all else. ... They hate to work on routine things - they would much prefer to build complex theoretical solutions, and leave the implementation of the system to others."

By contrast, "[an INTJ's] primary interest is not understanding a concept, but rather applying that concept in a useful way. Unlike the INTP, they do not follow an idea as far as they possibly can, seeking only to understand it fully. INTJs are driven to come to conclusions about ideas. Their need for closure and organization usually requires that they take some action."

Since INTPs are less motivated to action and "hate to work on routine things," they are driven to higher-level languages, because those languages help them focus on concepts instead of implementation details. But this means that the people using these languages get little done -- precisely because they are more interested in concepts than in implementation.

You didn't cary the abstraction far enough: programming languages are an implementation detail. An INTJ tends to find it Very Important That Things Are Done The Right Way Using The Correct Programming Language and would be more than happy to give you their reasons why. A stereotypical INTP doesn't care so much about the how, and in general tend to be less polarized on specific technologies.

"... My guess is that language snobs are INTP, whereas Blub programmers are more INTJ ..."

Do you really believe in the "psycho-babble" Myers-Briggs claims it tests? If you can show me any peer reviewed scientific studies that back the claims made by these tests I'd be more than happy to read them and judge for myself. Until then MBTI theories are as believable as any other pseudoscience.

I think a lot of people put too much faith in Meyer-Briggs, but I think psychologists tend to use it more than anything as an estimation tool just to get an idea of where to start with someone they're not familiar with. They can also be useful for describing some common personality memes, but a lot of times people mistake the categorizations as being predictive rather than descriptive and that's where they tend to quickly get into psycho-babble territory.

"Snobs" sparked off this chain of reasoning for me:

- Snobs have overly critical attitudes (by definition).

- Overly critical attitudes cause perfectionism.

- Perfectionism causes procrastination, because if you haven't actually done anything, you can't be criticized (especially not by yourself).

So it seems inevitable that language snobs would not produce much work (note: there any plenty people using the languages listed who do created finished work - one could claim that these people, in general, are noted for not having overly critical attitudes, and hence are not language snobs).

It's possible you're right in general, but as a counterexample note that the working code you and I are using to post these comments was written by someone whose attitude toward existing Lisp dialects was critical enough to make him want to write his own.

Did he spend his energy being critical of them, or on working on a dialect that he found valuable?

I don't know how much energy he spent implementing Arc, but the energy he spent before Arc's release writing critically of existing dialects was at least as much as you might see "language snobs" expend. My point is, you can't deduce from someone's highly critical attitude that they won't produce useful code.

You could well be right (that a highly critical attitude does not prevent writing of useful code).

But relating it back to "snobbery" - which I think is a highly critical attitude and "therefore I'm better than you" - I don't think PG was damning the other dialects, but was criticizing specific aspects while appreciating other aspects (maybe: "this is really cool, but the syntax is annoying", "they had a great idea here, but implemented it stupidly").

I haven't read the essays in question, so it would be an interesting test to have a look...[time passes]... I just scanned the articles under under "lisp" on PG's site, and didn't see any criticism of lisp - only praise. While I'm sure that his criticism of Lisp exists, praise also does, so I think his highly critical attitude towards lisp dialects was not in order to claim that Arc is fundamentally superior, but to improve on some specific aspects.

"Perfectionism causes procrastination, because if you haven't actually done anything, you can't be criticized (especially not by yourself)."

What about criticizing yourself for not doing anything?

In your experience, is criticizing yourself for not doing anything as effective as focusing on what encourages and inspires, and energizes you?

I think he's pinned down the groups wrong; here's how I see the poles of language snobbery:

- Language snobs come in a couple of sorts; hard core programming language wonks, and tinkerers. Tinkerers play with every technology and get excited enough about a new technology coming out that they have to get their hands on it. They know and use lots of programming languages because programming languages are neat. The downside is the depth of knowledge is often somewhat limited and they tend to get distracted by the next thing.

- Luddites who code. Luddites consider new technologies, aside from the ones that they're making, largely annoying and quite possibly evil. They tend to stay behind the technology curve, but tend to know their tools quite well. They like to get things finished, since that was the point, right?

It might be an unpopular position to take here, but I really think that what I think of as "language snob languages" (Lisp, Haskell, Erlang, OCaml . . . not Ruby or Python, though) can't ever be mainstream because the barrier to entry is just too high even for competent programmers. There's a network effect problem to be sure, where people don't use it because the docs/frameworks/examples/toolkits aren't there, but part of the reason those things aren't there is that the language doesn't appeal in the same way to people who want to build those things and the languages themselves have enough of an impedance mismatch with how people think about things to keep a lot of otherwise-competent engineers from investing their time in them.

In other words, it's not just about tools or marketing or docs: some languages, while certainly more useful in the hands of a skilled expert, are so complicated and require so much dedication to perfecting their use that they can't possibly ever become mainstream.

The high barrier to entry for those languages is not just because of docs, tools, lack of standards, etc. It's just an inherent part of those languages, and what makes them so powerful is exactly what makes them difficult to get started with and what keeps them marginalized.

C is more difficult than Lisp or OCaml, but it's extremely popular.

I'm not sure I agree . . . pointers in C throw people for a lot of loops, but aside from that the types are as simple as you'll let them be and I'm pretty convinced that most people have an easier time thinking in an imperative fashion than a functional fashion. The functional nature of Lisp just throws most people for a loop at first, because it doesn't match the naive breakdown of most simple programming problems. Likewise, the type system in OCaml throws a lot of people for a loop.

Mastering pointers, worrying about memory leaks, dealing with the loose typing, etc. are all things you need to do to write code well in C, but you can kind of muddle through as a beginner without those. You can't even get started with Lisp until you figure out the right way to break down your problem, and that's a huge barrier for most people. To put that another way, it's easier to mentally model what your algorithm should be in C than in Lisp (for most people), even if the actual implementation is a pain to get right, and its the mental model that's a barrier to entry for more "advanced" languages.

That said, C is certainly a harder language to learn than Python or Ruby.

If we were talking about purely functional languages, then I would agree. But Lisp isn't purely functional; it has assignment and loops and arrays and all the rest. You can program in the subset of Lisp that allows the same "mental model" as C and get the same results without worrying about pointers or buffer overflows. So I think Lisp is strictly easier.

The fact that you only have one way of programming in C, 'the C way', can actually be a blessing. I've found that I've been paralyzed by the flexibility of Lisp. There are so many different ways to do the same thing that it is hard to choose between them.

The key point is, you can download Python and be doing useful work with it very quickly. If you are a complete novice, you could still probably have something actually useful done within a day. This is in part due to the library you get with it. The path into Python is very smooth too. I look back on my own code; at first I used it as a sort of glorified shell script, and now my code is all list comprehensions and lambdas. Python (the technology and the culture) caters to all levels. There's very rapid positive feedback, everything you learn immediately has a reward in power/productivity.

OCaml for example is a language I'm into at the moment, but it's a good thing I knew C first because sorting out it talking to my Oracle databases has been a complete shag (and, crucially, not something that the language developers, being academic researchers, give a stuff about). And my experience is, you have to be a relatively good OCaml programmer before you can start to be productive; there's a lot less opportunity to learn by doing, you have to study first. The point at which the positive feedback kicks in is a lot later.

The message:

* BASIC (LSL, Java, C#, VB, PHP, Perl, etc) programmers win when it comes down to getting projects finished (versus Lisp, SmallTalk, Python, Ruby, Scala, Haskell, etc).

* using inferior tools has a cost associated with it, so does not using those tools.

Conclusion: find a balance and get things done.

BASIC (LSL, Java, C#, VB, PHP, Perl, etc)

One of these things is not like the others.

Which one?

I'll give you a hint:

It is a dynamic language with closures, higher order functions (lambda), map, join, the option to work in an expression-oriented manner, and the ability to modify the language to suit the task.

It's worth noting that a couple of the languages in the other list (the not "inferior" languages) lack one or more of those capabilities. What's trendy is not always the whole picture.

I've just summarized the article.

Language Snobs stress the superiority of one programming language over others. Some languages are extremely guilty of this (Lisp, SmallTalk, Python, Ruby, Scala, Haskell, etc) while others aren’t (Java, C#, VB, BASIC, PHP, Perl, C, etc). The snob languages talk about why they’re so great, and the other languages just point to what has been written in them as proof that they’re great (or at least good enough). </quote>

Yes, and then you used the term "inferior tools" to refer to the first set of languages, which wasn't in the article.

I'm saying the classifications don't make sense:

If the point is "people who use the languages get things done", then Ruby and Python clearly belong in the first list, as there's plenty of code in those languages doing work in all sorts of fields.

If the point of the second list is the superiority of the languages due to purity (Smalltalk, Scala and Haskell, I guess, but not Lisp) then Python and Ruby don't belong in the second list. If the point is capability (where "dynamic" is a capability along with all of the other goodies, shared by almost all of the second list languages), then Perl belongs in the second list and Scala probably doesn't, since Scala is the language that has the least in common with the others in the list (which is not to say it has significantly more in common with the first list).

The point of the article is probably valid, but the lists are flawed. No matter how you classify the languages, at least a couple of the languages are out of place in the lists they've been put in. Leaving Perl, Python, and Ruby out of the picture altogether would have left a gaping hole in the argument (as they are quite good and powerful tools, with which lots of people have written useful code), but cramming them into the wrong slots also makes the argument weaker. So, I guess what I'm saying is that the argument turns out to somewhat weak...huh! It seemed so compelling to start with.

1. I agree on your point about classification. Moreover the whole topic of language capabilities is overrated. There are many many decisions one should make during a work on software project and the choice of language is just one of them (maybe even it is not the most important one).

2. But life, business, and software are full of trade-offs. If you can accept a little imperfection here, some cruft there, and sloppy duplication there, they you can hire from a bigger pool of employees, deploy to a wider range of platforms, hit more markets more frequently. The key point that the penny pinchers miss is that while using inferior tools has a cost associated with it, so does not using those tools. The important thing is to Always Be Shipping. </quote> (press C-f, type inferior tools)

The article does not reflect my opinion (EDIT: but accidentally I agree with the above fragment). I was trying to make a short version (summary) of the article and as Joel (joelonsoftware.com) said:

the trouble is if you put something up without writing a long enough post to actually make your full case, uhmm, you just get misunderstood, was sort of what I concluded. </quote>

Life's hard that way, aint it? Everybody always misunderstanding everybody else.

Thankfully at hacker news it doesn't get ugly (yet !), unlike programming.reddit.com has become.

Does it start with a 'P'?

Err, there is an awful lot of real, working, production code being written in Python and Ruby.

Reply on news.ycombinator.com