3 ms·

My somewhat biased stance: functional programming languages make you progress as a programmer quickly. Becoming great requires deliberate practice and intrinsic

My somewhat biased stance: functional programming languages make you progress as a programmer quickly. Becoming great requires deliberate practice and intrinsically hard problems. So you learn programming and CS about 5-10 times as fast in a functional language. This is part of why enterprise Java/C++ devs plateau at a skill level of 1.2 (even into their gray-haired years) while ML and Haskell programmers can reach 1.5 in a few years and generally cross 2.0 if they make a career out of software. (For reference, here's where I explain that scale: http://michaelochurch.wordpress.com/2012/01/26/the-trajectory-of-a-software-engineer-and-where-it-all-goes-wrong/ http://michaelochurch.wordpress.com/2012/01/26/the-trajector... ; it's a 0.0-to-3.0 scale and 1.5 is what most of us would consider a seriously good programmer.) So if you want to grow as an engineer and computer scientist, learn these languages. You'll learn a lot fast, and not just about one programming paradigm (FP) but about complexity and how to manage it. You'll just learn a lot more about software because the way to learn software is to write it and one person can actually accomplish significant things in these languages. Java and C++ demote the individual contributor: "commodity" developers crank out classes and a more senior "architect" figures out how to bolt them together. That said, these languages won't improve your performance in typical Java and C++ jobs. Six months of practice for exposure might give you some new ideas and make your code and performance better. Beyond that, they might diminish it. Why? Because you start hating these languages (Java and C++) and the accidental complexity they throw at you, which starts to look foreign and unnecessary. You get to a point where your own code (if you use the idioms of these languages, and you probably should, because it's not just about you) starts to look like someone else's. When you start hating your own code, disengagement sets in and it gets ugly fast. I can "hack" Java and C++ but I certainly wouldn't do a major project in them at this point. My Java and C++ are uninspired now that I know better languages. Often, the only way I can write decent Java is to write it first in Scala (which I like, a lot) and transliterate the solution. Whether this produces "good" Java I don't even know. Also, I really believe that C++ is the 21st-century COBOL. Java was gunning for that distinction, but Scala and Clojure gave it an assembly-like status, as the lowest-level language on the JVM (which will remain important for at least 15 years because of Scala and Clojure).

CJefferson 15y ago
I agree with one side of your message. There are very few people who have just learnt functional programming. I have met a few in academia, and they tend to be as "bad" as the pure Java/C++ programmers, but in a different way. They have trouble understanding how their code will boil down to CPU instructions, and so have trouble with performance, particularly (unsuprisingly) mutating algorithms, which are vital for performance in some situations. After I have defined a high-performance algorithm, they often want to modify it to make it "more beautiful" (which means functional) and in the process destroy the performance. Also, I had quite a lot of exposure to Haskell, and I haven't found C++ hate. I got some Haskell hate, because doing some things (mutating algorithms and bit fiddling) were really, really hard, while I found most of the things I loved from Haskell I could do in C++, with care. I work on low-level algorithm design in A.I., where performance is everything and there are many interlocking, low-level and complex algorithms and data structures. I know that other problems might well have very different characteristics. For example, I have no real ideal how Haskell vs C++ would compare for the average web app for example (or of course, something like Ruby/Python which seem to be much more popular).
- michaelochurch 15y ago
  To make it clear, I don't mean to rag on C, which is a great mid-level language. It's the ++ that I hate. Assembly is infantry: can do a lot of fine-grained work, but limited to about 5 mph with equipment. C is a tank-- a pretty powerful and impressive machine. It can shoot on the run and do 50 mph off-road. High-level languages are airplanes, perfect at 500 mph but coarse-grained from an operational standpoint. C++ exists because someone saw a tank and a plane and said, "I'm going to put wings on a fucking tank and see what happens." Thus, the tank-plane was born. The wings destroy its maneuverability on the ground and the weight of the tank makes it a shitty plane, and it looks fucking ridiculous, but there you go. Java exists because someone else concluded that the problem with tank-planes was that people were trying to fly them too fast and built an equally ridiculous invention-- the tank-icopter. After I have defined a high-performance algorithm, they often want to modify it to make it "more beautiful" (which means functional) and in the process destroy the performance. That's annoying. They should understand the concept of interface as separate from implementation. Implementations are allowed to be (and sometimes should be) ugly if performance concerns merit it. Besides, mutable state, intelligently used, isn't "ugly". A lot of programs are simpler and more attractive when mutable state is used. Mutable state just needs to be used with taste. What really pisses me off about that behavior pattern is when the tinkering is unnecessary. If it's working code, then who cares? I'm a hard-core FP advocate but I write stateful programs all the time. I try to wrap them behind interfaces that are as functional as possible. I will use state in controlled ways when appropriate; I just don't want to impose it on other people. I work on low-level algorithm design in A.I., where performance is everything and there are many interlocking, low-level and complex algorithms and data structures. I think what makes C++ appropriate for your purposes is that once code is written to spec, it doesn't need to be maintained (except for performance optimizations). I'm guessing that (except possibly for some STL usage) you're actually C. Where C++ and Java really drop the ball (legacy disasters) is when code has to be read more times than it is written. If your goal is to write fast software one time and, once it's working code, never need to look at it again, C++ is probably appropriate.

CJefferson 15y ago

I agree with one side of your message. There are very few people who have just learnt functional programming. I have met a few in academia, and they tend to be as "bad" as the pure Java/C++ programmers, but in a different way. They have trouble understanding how their code will boil down to CPU instructions, and so have trouble with performance, particularly (unsuprisingly) mutating algorithms, which are vital for performance in some situations. After I have defined a high-performance algorithm, they often want to modify it to make it "more beautiful" (which means functional) and in the process destroy the performance. Also, I had quite a lot of exposure to Haskell, and I haven't found C++ hate. I got some Haskell hate, because doing some things (mutating algorithms and bit fiddling) were really, really hard, while I found most of the things I loved from Haskell I could do in C++, with care. I work on low-level algorithm design in A.I., where performance is everything and there are many interlocking, low-level and complex algorithms and data structures. I know that other problems might well have very different characteristics. For example, I have no real ideal how Haskell vs C++ would compare for the average web app for example (or of course, something like Ruby/Python which seem to be much more popular).

michaelochurch 15y ago
To make it clear, I don't mean to rag on C, which is a great mid-level language. It's the ++ that I hate. Assembly is infantry: can do a lot of fine-grained work, but limited to about 5 mph with equipment. C is a tank-- a pretty powerful and impressive machine. It can shoot on the run and do 50 mph off-road. High-level languages are airplanes, perfect at 500 mph but coarse-grained from an operational standpoint. C++ exists because someone saw a tank and a plane and said, "I'm going to put wings on a fucking tank and see what happens." Thus, the tank-plane was born. The wings destroy its maneuverability on the ground and the weight of the tank makes it a shitty plane, and it looks fucking ridiculous, but there you go. Java exists because someone else concluded that the problem with tank-planes was that people were trying to fly them too fast and built an equally ridiculous invention-- the tank-icopter. After I have defined a high-performance algorithm, they often want to modify it to make it "more beautiful" (which means functional) and in the process destroy the performance. That's annoying. They should understand the concept of interface as separate from implementation. Implementations are allowed to be (and sometimes should be) ugly if performance concerns merit it. Besides, mutable state, intelligently used, isn't "ugly". A lot of programs are simpler and more attractive when mutable state is used. Mutable state just needs to be used with taste. What really pisses me off about that behavior pattern is when the tinkering is unnecessary. If it's working code, then who cares? I'm a hard-core FP advocate but I write stateful programs all the time. I try to wrap them behind interfaces that are as functional as possible. I will use state in controlled ways when appropriate; I just don't want to impose it on other people. I work on low-level algorithm design in A.I., where performance is everything and there are many interlocking, low-level and complex algorithms and data structures. I think what makes C++ appropriate for your purposes is that once code is written to spec, it doesn't need to be maintained (except for performance optimizations). I'm guessing that (except possibly for some STL usage) you're actually C. Where C++ and Java really drop the ball (legacy disasters) is when code has to be read more times than it is written. If your goal is to write fast software one time and, once it's working code, never need to look at it again, C++ is probably appropriate.