4 ms·
I find it interesting to hear people say 'language doesn't matter' (and similar, 'it's not important'), in general (because often the same people then, when ask
by lostcolony 12y ago
I find it interesting to hear people say 'language doesn't matter' (and similar, 'it's not important'), in general (because often the same people then, when asked what language they develop in, turn around and say that they 'use multiple; we always use the right tool for the job'), but in this article it's especially interesting given it's right after "and here are the things I learned, and the things that I have not grokked yet in this language".
While there is a certain truth to there being no inherent reason why you can't use an idiom or practice learned from one language in another, it's incredibly disingenuous to then say the language isn't important (and that it's only the concepts learned). The language is what encourages you to think in certain ways, and it helps you code along those ways, while making it difficult to code in others.
I recently went from having coded in Erlang almost exclusively for two years, to coding something small in Java, and I can't even express how irritating I found the experience. A part of it was writing a combination function (i.e., given a collection, generate every combination of elements). In Erlang it was the work of but a moment, and resulted in 3-4 lines, that were incredibly readable. I then attempted to convert it back to Java...and what do you -mean- collections are all destructive?! Ugh, I have to manually copy them out for this to work?! Etc. So much pain. Java got in the way of writing it cleanly, and when I looked for solutions online written in an idiomatically Java way, I found even more verbose solutions, that tended not to be as reusable (involving explicit nested loops rather than recursion, or recursion rewritten with a while loops; i.e., a collection of 5 items would have 5 loops and not be reusable for a collection of 6 items).
Quite simply, using a language with idioms from another language, while possible, is often times intensely painful, with a whole new slew of not well known caveats (since most developers in that language aren't using it that way), to where if you know you are going to develop a specific way, you will be far better served to use a language that supports it naturally.
And his takeaway at the end isn't in any way relevant to the title of "Language Is Not Important".
- drcomputer 12y agoThere is often the desire to formalize all concepts under a single, over-arching, unifying language, of which everyone learns from and adds their discoveries to, and it is perfect in clarity, unchanging in form, and eternal in elegance. But I think that desire often stems from the fact that learning stuff is hard. It doesn't matter what you are learning, if it is foreign enough to your brain, then it's hard. It makes everything seem in vain, that there is always more to do. But, everything is interesting, because there is always more to do. Also, creativity. We don't have to be dictators or communists over our programming languages. We can be artists, scientists, mathematicians, and poets.
- NhanH 12y agoThe note with Java is spot on. Even with the new language constructs in Java 8 (map, stream, lambda etc). More than one time I've to stop and decide whether to just use for loop rather than any of those higher level constructs. There are several cases where the use of map/ lambda looks worse than a for loop (when you have to chain them together, and the function to be used is not a class function etc.). And ugh, I have to "collect" after a map, what is that? If a for loop is 3 line, and you have to write 3 line with a whole bunch of "." for a map statement, it's probably of no help in term of expressiveness.
- Retra 12y agoEven those higher-level constructs in Java are ugly verbose hacks... I was excited to have those, but when they came out all I could think was "this is more work than doing it the old way..."
- klibertp 12y agoLanguages, and even syntaxes, do matter. In a lot of ways and not all of them are immediately obvious. Personally I went from "languages matter" to opposite and back again during the years. At the beginning I used C and then I started learning C++. At that point I had some experience with Pascal and BASIC and by comparison C++ looked like the undisputed winner. At this time I assumed that "languages matter" (or rather "C++ matters", but close enough). In the following years I learned a couple more languages. Ada, PHP, Python, Java. This is where I started believing that languages don't matter - they of course differ from one another, but the differences are minimal. But I didn't stop there. I started learning more and more languages, some really, really different. I first learned OCaml, then Erlang, then Prolog, then Scheme. Then more than a dozen of other languages, including Clean, Smalltalk, J, Forth and other such "esoteric" ones. I don't remember exactly when it happened, but somewhere along the road I realized, again, that languages do matter. There are two parts to this realization actually. One is that I started doing programming professionally - this caused me to interact with other programmers, to read their code, to explain things to them. I realized that language design has to accommodate large variety of people's habits, projects and circumstances and that not everything is completely rational when it comes to language usage "in the wild". That language design has non-trivial impact on language community (and language syntax on idioms/best practices) and that community matters very, very much. And the second part was that, as mentioned, I finally learned some languages which really were different. There are many notable differences between Pascal and C, for example, but they are not that great. On the other hand C, Smalltalk and J don't have almost anything in common and they all have specific niche where using one of them is clearly a win. In the end I concluded what I said at the beginning of this comment: that languages do matter and in many different ways at that. Some make thinking about certain problems easier, some make writing certain kind of software easier, some make learning particular concepts easier and some make earning money easier. Some differ more, some less, but - outside of purely theoretical discussions - you can't pretend that they don't. Or that the differences are negligible.