7 ms·

Here's why I, personally, prefer to put all my investment into languages like Scala and Clojure. Scala and Clojure, for their problems (which are not severe, b

Here's why I, personally, prefer to put all my investment into languages like Scala and Clojure. Scala and Clojure, for their problems (which are not severe, but not to be ignored) have the advantage of being closer to the languages and approaches of the future, in which building comprehensible systems at very high levels of complexity/intellectual intricacy will be even more important relative to performance of executables. I expect that the problems of these languages (including performance) are going to become much less major over time, just as performance gaps between Java and C and between C and hand-written assembly have nearly disappeared. Spending another 5 years in Java means you're preparing yourself for a 1996 job in 2016. Why Scala and Clojure? Unfortunately, the 10-year forecasts for Haskell and Ocaml aren't great. I wish they were, because those are great languages. The reason: libraries and tooling matter, and they seem to be mattering more as the years pass (while differences in performance between languages narrow and matter less over time). Hiring and talent: It's true that you can't hire 50 Scala programmers per month. On the other hand, most startups are far away from being in a position to hire 50 programmers per month at all, much less 50 good ones. Choosing an "esoteric" language works both ways. On one hand, it reduces the total pool of ready developers. On the other hand, I know companies that use Haskell and Ocaml and are able to hire 60-75% of their in-office interviewers while remaining selective; this would be impossible for a Java shop-- there are just too many unqualified Java developers. Choosing a language like Scala or Clojure will do a lot of the filtering for you.

brown9-2 15y ago
I don't see how someone writing Java in 2016 would be stuck in a 1996 job. Is the same true of someone using C or C++ today?
- michaelochurch 15y ago
  It depends what the person's using the language for. I'd say "no" for C. C is still the leading language for a lot of purposes: operating systems, runtimes for higher-level languages, device drivers, and applications where tight control of memory use is important. In these domains, C hasn't been supplanted yet-- not even close. I don't know that C++ and Java have substantial domains in which they're superior to other choices. C++ is a badly-conceived cross between C and high-level languages and Java is the worst of the JVM languages.
  - tomjen3 15y ago
    C++ isn't a badly-concieved cross. It is a bucket with everything thrown in. That said I wouldn't want to write larger programs in C and would prefer C++ simply because it scales better (assuming the other programmers don't use all the features it has, but confusing code can be written in any language). Also RAII is awesome.
  - reissbaker 15y ago
    In AAA game development, it's C++ or go home. People can argue all day about the relative merits of Java, but C++ certainly has a domain in which it's superior to other choices.
    - nknight 15y ago
      C++ has a domain where it has a large foothold and extreme inertia. That says nothing about its fundamental merits. Your statement is also misleading for another reason. Core engine logic might be in C++, but actual "game" logic is increasingly being shoved into scripting languages like Lua.
      - reissbaker 15y ago
        Concern for and access to low-level implementation details is one of the fundamental features -- and in some cases merits -- of C++. In applications where program execution speed is important and you can't scale out by adding machines, C++ is a better option than dynamic languages. See: game engines. Yeah, you might add a scripting layer on top for some of the logic, but you can't write the engine in a dynamic language and get Battlefield 3. The other merit of C++ is that it's object-oriented, however awkward its implementation may be (insert Alan Kay quote here). The fact that it's both fast and natively object-oriented is why C++ for the most part replaced C in the game development community, which once had as much C-based inertia as it currently has C++-based. Is it a beautiful language? Noooooo way. But it has merits. Edit: before someone responds with "But computers will get faster and make C++ obsolete..." People's expectations for videogame graphics tend to increase as better graphics are made possible. It's a tough fight against an equilibrium, and the fact that the graphics of today will eventually be possible with dynamic languages in the future won't matter for as long as games are unable to reach perfect photorealism -- better-looking future games will come out, and Crysis-level graphics will look dated and shabby by comparison. For an example of previously-heralded graphics become obsolete even within a single console generation, when the first screenshots of Oblivion came out years ago there were people who truly couldn't believe that they were realtime and in-engine -- but dear God, look at Oblivion now. It's not hideous, yet, but it isn't pretty. And there's no way you could write that in pure Lua today -- not even at ten frames per second.
- lmkg 15y ago
  It's not so true for C and/or C++, because some of their niches are cutting-edge, like gaming and VMs. Where it is true is for languages like Visual Basic, or heaven forbid COBOL. If you are working with COBOL today, or even ten years ago, you're probably maintaining a 1980's mainframe for a 1980's company (VB is probably 90's). If I were to pull a prediction completely out of my ass, then my complete lack of experience or expertise in the matter says that Java is more likely to end up the VB of tomorrow than the C++ of tomorrow.
Harkins 15y ago
This post is not about Scala and/or Clojure vs. Java.
jmspring 15y ago
Languages are but a tool to build things. What specifically about Scala and Clojure, do you feel, make them closer to the languages and the approaches of the future? While one should keep abreast of current technologies (and languages), there is still plenty of work that requires knowledge of C from the system level to SAAS platform technologies and implementations. It is a 35+ year old language. If your argument was "learn these knew languages for the advantages the provide given the likely emergence of X, Y or Z", I would buy it. Saying a newer language is a path to the future? Lacking.
- harryh 15y ago
  Functional programming more easily fosters the parallelism that will be required to keep making performance gains as individual core speeds top out and CPUs only get faster by adding cores.
  - jmspring 15y ago
    There are functional programming languages (Erlang, for instance) and the concepts functional programming embraces. While the functional languages make these concepts explicit, people have adopted the concepts into their languages of choice. Search on "functional <X>", for instance, functional javascript brings up an interesting article on IBM developer works: http://www.ibm.com/developerworks/library/wa-javascript/index.html http://www.ibm.com/developerworks/library/wa-javascript/inde... For, myself, I am open to the concepts, but I don't need to be necessarily locked into a given language in this case.
    - jerf 15y ago
      Some of the functional advantages don't really work until fully adopted and supported by language runtime and syntax explicitly. Immutability in particular I consider really an all-or-nothing proposition. Either you can count on the language using value-only-based semantics, or you can't. Any attempt at middle ground will fail when you're someday dealing with a library built on a library built on a library that, whoops, turns out to use the mutable variables your language supports after all, and then the mutability seeps out from there. Or your junior devs come in and spray mutability around 'cause that's what they know and before you're right back in the morass. (One I've grown sensistive to, since it's the one I work professionally in.) (Also just declaring the semantics of how mutable variables and immutable variables relate in one language turns out to be really tricky problem. Not impossibly tricky; it's been done, after all. But I suspect trying to mix the two in any sort of deep way means that you have unavoidably created a cognitively "large" language.) If Haskell is going to "win", it'll be on the strength of properties like these, that either you go all in, or you don't get the benefits of them, just the costs. I think instead of 90-10, "90% of the benefits for 10% of the work", it's rather closer to 10-90.
socratic 15y ago
Do people think the hiring and talent argument holds water? The more I hear this argument (e.g., from the "Python Paradox"), the less I buy it. Is the theory that true "hackers" care more about the programming language syntax and semantics than whether it has the right libraries for the subject domain of the startup? Is the theory that true "hackers" care more about whether the startup uses a new and un-tested programming language than traction, likelihood of success, money, or the actual problems being solved? Do the best "hackers" come in by searching job sites for niche programming languages, rather than referrals? Even ignoring the huge disadvantages in library support, tooling, community sizes, and so on, are the hiring and talent advantages believable? Are the sort of people who learn Haskell also the sort of people who would be 99th percentile C++ systems engineers for some reason?
- jmspring 15y ago
  There are all sorts of people those that get their kicks on language selection and semantics, there are those that love to discuss process (agile, scrum, TDD, whatever), others that want to focus solely on delivery. Reality is, the best people are somewhere in the middle. An engineer worth hiring is one that is bright, curious, and learns quickly. That said, they should also have an interest in some aspect of what you are producing. I, personally, have searched for jobs on the basis of esoteric / niche items, mainly hoping for something different. The most rewarding experiences have been where I've worked with/brought in good people and built cool things. One of those involved Windows Server and WinCE work, and I personally dislike working on Windows. But the overall project was interesting. Technologies, languages, approach, and product. A good engineer who is interested will likely have deeper interests and help contribute in one of those four areas.
- michaelochurch 15y ago
  I think it's this: the best programmers generally want to learn new languages and approaches. This means that by mid-career, they've been exposed to at least 5 languages and seriously used two or more. They've at least tried functional programming. Rarely is the general-case favorite, for such a person, C++ or Java. Finding great programmers who know C++ and Java is not very hard. Finding great programmers who prefer those languages is quite difficult.
lancepantz 15y ago
Who mentioned clojure?
gtani 15y ago
You may be missing a lot of what's happening with GHC: stacktraces, fixing GHCi and cabal, polymorphic kinds http://www.reddit.com/r/haskell/comments/k4lc4/yesod_the_limitations_of_haskell/ http://www.reddit.com/r/haskell/comments/k4lc4/yesod_the_lim... http://www.reddit.com/r/haskell/comments/mm68o/ghc_74_branched_whats_in_for_christmas/ http://www.reddit.com/r/haskell/comments/mm68o/ghc_74_branch...
sandofsky 15y ago
"Spending another 5 years in Java means you're preparing yourself for a 1996 job in 2016." In the type of environments where I work, five years experience shipping successful software will advance your career further than five years experience in one particular language. If you choose a bleeding edge language, what is the risk you will spend time solving edge cases with the language instead of delivering great software? Given everyone's lack of experience in a language, what is the risk you will write something unmaintainable? If your bleeding edge runtime is slower, what is the risk that it will fall apart under load? It's possible these are acceptable risks for the gains in programmer productivity. That risk to gain ratio would have to be massive to persuade me. Yes, picking bleeding edge technology will filter out bozos during hiring. You'll also filter out engineers who are more passionate about shipping than new technology. You're left with an high concentration of engineers who have never seen bleeding edge technology blow up in their face.
nivertech 15y ago
I agree about Clojure, not so much about Scala. Clojure built on solid proven foundations of LISP and JVM. While Scala is also built on JVM, it's semantics are completely new and unproven. And b/c Scala's semantics are complex (unlike LISP), it will be very hard to prove and make it mature. My other choice is Erlang/OTP, which is 20+ y/o dinosaur, controlled by Ericsson, not a modern language, but very stable and mature.

brown9-2 15y ago

I don't see how someone writing Java in 2016 would be stuck in a 1996 job. Is the same true of someone using C or C++ today?

michaelochurch 15y ago
It depends what the person's using the language for. I'd say "no" for C. C is still the leading language for a lot of purposes: operating systems, runtimes for higher-level languages, device drivers, and applications where tight control of memory use is important. In these domains, C hasn't been supplanted yet-- not even close. I don't know that C++ and Java have substantial domains in which they're superior to other choices. C++ is a badly-conceived cross between C and high-level languages and Java is the worst of the JVM languages.
- tomjen3 15y ago
  C++ isn't a badly-concieved cross. It is a bucket with everything thrown in. That said I wouldn't want to write larger programs in C and would prefer C++ simply because it scales better (assuming the other programmers don't use all the features it has, but confusing code can be written in any language). Also RAII is awesome.
- reissbaker 15y ago
  In AAA game development, it's C++ or go home. People can argue all day about the relative merits of Java, but C++ certainly has a domain in which it's superior to other choices.
  - nknight 15y ago
    C++ has a domain where it has a large foothold and extreme inertia. That says nothing about its fundamental merits. Your statement is also misleading for another reason. Core engine logic might be in C++, but actual "game" logic is increasingly being shoved into scripting languages like Lua.
    - reissbaker 15y ago
      Concern for and access to low-level implementation details is one of the fundamental features -- and in some cases merits -- of C++. In applications where program execution speed is important and you can't scale out by adding machines, C++ is a better option than dynamic languages. See: game engines. Yeah, you might add a scripting layer on top for some of the logic, but you can't write the engine in a dynamic language and get Battlefield 3. The other merit of C++ is that it's object-oriented, however awkward its implementation may be (insert Alan Kay quote here). The fact that it's both fast and natively object-oriented is why C++ for the most part replaced C in the game development community, which once had as much C-based inertia as it currently has C++-based. Is it a beautiful language? Noooooo way. But it has merits. Edit: before someone responds with "But computers will get faster and make C++ obsolete..." People's expectations for videogame graphics tend to increase as better graphics are made possible. It's a tough fight against an equilibrium, and the fact that the graphics of today will eventually be possible with dynamic languages in the future won't matter for as long as games are unable to reach perfect photorealism -- better-looking future games will come out, and Crysis-level graphics will look dated and shabby by comparison. For an example of previously-heralded graphics become obsolete even within a single console generation, when the first screenshots of Oblivion came out years ago there were people who truly couldn't believe that they were realtime and in-engine -- but dear God, look at Oblivion now. It's not hideous, yet, but it isn't pretty. And there's no way you could write that in pure Lua today -- not even at ten frames per second.
lmkg 15y ago
It's not so true for C and/or C++, because some of their niches are cutting-edge, like gaming and VMs. Where it is true is for languages like Visual Basic, or heaven forbid COBOL. If you are working with COBOL today, or even ten years ago, you're probably maintaining a 1980's mainframe for a 1980's company (VB is probably 90's). If I were to pull a prediction completely out of my ass, then my complete lack of experience or expertise in the matter says that Java is more likely to end up the VB of tomorrow than the C++ of tomorrow.

Harkins 15y ago

This post is not about Scala and/or Clojure vs. Java.

jmspring 15y ago

Languages are but a tool to build things. What specifically about Scala and Clojure, do you feel, make them closer to the languages and the approaches of the future? While one should keep abreast of current technologies (and languages), there is still plenty of work that requires knowledge of C from the system level to SAAS platform technologies and implementations. It is a 35+ year old language. If your argument was "learn these knew languages for the advantages the provide given the likely emergence of X, Y or Z", I would buy it. Saying a newer language is a path to the future? Lacking.

harryh 15y ago
Functional programming more easily fosters the parallelism that will be required to keep making performance gains as individual core speeds top out and CPUs only get faster by adding cores.
- jmspring 15y ago
  There are functional programming languages (Erlang, for instance) and the concepts functional programming embraces. While the functional languages make these concepts explicit, people have adopted the concepts into their languages of choice. Search on "functional <X>", for instance, functional javascript brings up an interesting article on IBM developer works: http://www.ibm.com/developerworks/library/wa-javascript/index.html http://www.ibm.com/developerworks/library/wa-javascript/inde... For, myself, I am open to the concepts, but I don't need to be necessarily locked into a given language in this case.
  - jerf 15y ago
    Some of the functional advantages don't really work until fully adopted and supported by language runtime and syntax explicitly. Immutability in particular I consider really an all-or-nothing proposition. Either you can count on the language using value-only-based semantics, or you can't. Any attempt at middle ground will fail when you're someday dealing with a library built on a library built on a library that, whoops, turns out to use the mutable variables your language supports after all, and then the mutability seeps out from there. Or your junior devs come in and spray mutability around 'cause that's what they know and before you're right back in the morass. (One I've grown sensistive to, since it's the one I work professionally in.) (Also just declaring the semantics of how mutable variables and immutable variables relate in one language turns out to be really tricky problem. Not impossibly tricky; it's been done, after all. But I suspect trying to mix the two in any sort of deep way means that you have unavoidably created a cognitively "large" language.) If Haskell is going to "win", it'll be on the strength of properties like these, that either you go all in, or you don't get the benefits of them, just the costs. I think instead of 90-10, "90% of the benefits for 10% of the work", it's rather closer to 10-90.

socratic 15y ago

Do people think the hiring and talent argument holds water? The more I hear this argument (e.g., from the "Python Paradox"), the less I buy it. Is the theory that true "hackers" care more about the programming language syntax and semantics than whether it has the right libraries for the subject domain of the startup? Is the theory that true "hackers" care more about whether the startup uses a new and un-tested programming language than traction, likelihood of success, money, or the actual problems being solved? Do the best "hackers" come in by searching job sites for niche programming languages, rather than referrals? Even ignoring the huge disadvantages in library support, tooling, community sizes, and so on, are the hiring and talent advantages believable? Are the sort of people who learn Haskell also the sort of people who would be 99th percentile C++ systems engineers for some reason?

jmspring 15y ago
There are all sorts of people those that get their kicks on language selection and semantics, there are those that love to discuss process (agile, scrum, TDD, whatever), others that want to focus solely on delivery. Reality is, the best people are somewhere in the middle. An engineer worth hiring is one that is bright, curious, and learns quickly. That said, they should also have an interest in some aspect of what you are producing. I, personally, have searched for jobs on the basis of esoteric / niche items, mainly hoping for something different. The most rewarding experiences have been where I've worked with/brought in good people and built cool things. One of those involved Windows Server and WinCE work, and I personally dislike working on Windows. But the overall project was interesting. Technologies, languages, approach, and product. A good engineer who is interested will likely have deeper interests and help contribute in one of those four areas.
michaelochurch 15y ago
I think it's this: the best programmers generally want to learn new languages and approaches. This means that by mid-career, they've been exposed to at least 5 languages and seriously used two or more. They've at least tried functional programming. Rarely is the general-case favorite, for such a person, C++ or Java. Finding great programmers who know C++ and Java is not very hard. Finding great programmers who prefer those languages is quite difficult.

lancepantz 15y ago

Who mentioned clojure?

gtani 15y ago

You may be missing a lot of what's happening with GHC: stacktraces, fixing GHCi and cabal, polymorphic kinds http://www.reddit.com/r/haskell/comments/k4lc4/yesod_the_limitations_of_haskell/ http://www.reddit.com/r/haskell/comments/k4lc4/yesod_the_lim... http://www.reddit.com/r/haskell/comments/mm68o/ghc_74_branched_whats_in_for_christmas/ http://www.reddit.com/r/haskell/comments/mm68o/ghc_74_branch...

sandofsky 15y ago

"Spending another 5 years in Java means you're preparing yourself for a 1996 job in 2016." In the type of environments where I work, five years experience shipping successful software will advance your career further than five years experience in one particular language. If you choose a bleeding edge language, what is the risk you will spend time solving edge cases with the language instead of delivering great software? Given everyone's lack of experience in a language, what is the risk you will write something unmaintainable? If your bleeding edge runtime is slower, what is the risk that it will fall apart under load? It's possible these are acceptable risks for the gains in programmer productivity. That risk to gain ratio would have to be massive to persuade me. Yes, picking bleeding edge technology will filter out bozos during hiring. You'll also filter out engineers who are more passionate about shipping than new technology. You're left with an high concentration of engineers who have never seen bleeding edge technology blow up in their face.

nivertech 15y ago

I agree about Clojure, not so much about Scala. Clojure built on solid proven foundations of LISP and JVM. While Scala is also built on JVM, it's semantics are completely new and unproven. And b/c Scala's semantics are complex (unlike LISP), it will be very hard to prove and make it mature. My other choice is Erlang/OTP, which is 20+ y/o dinosaur, controlled by Ericsson, not a modern language, but very stable and mature.