5 ms·

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 f

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.
  - danieldk 15y ago
    If this is true, can you point me to an elegant implementation of, say, the Either monad in a non-functional language? Bonus points if you can show me how to implement algabraic data structures plus pattern matching in your favorite non-functional language.
- danieldk 15y ago
  My experience is exactly the opposite: in number crunching it's often easier to parallelize processing in a low-level language such as C or C++. Current C compilers make loop parallelization via OpenMP. And since data is mutable, you do not have the overhead of allocating new chunks of memory (plus garbage collection). Functional languages will eventually be able to do most parallel computations on vectors and matrices nearly as fast as C. E.g. in Haskell a new project has started for adding support for SIMD intrinsics. Packages such as repa have been shown to be much slower (see the repa papers), where a program using repa with 8 cores (without SIMD) has about the same performance as a single-threaded C program (with SIMD). With SIMD support, Haskell plus repa will probably get a lot closer to the performance of C. Where functional programming with immutable data structures does help tremendously is in concurrency. Anyone who has written a fairly complex C++ program using concurrency, such as a GUI application, has probably run into complexity issues. There is a lot of mutable state, and no clearly defined model of interaction between threads. Anyway, in my opinion the real benefit of a pure functional language is that code written in a functional language is often more succinct and easier to reason about. There is no state outside a function (either global or within an object), side-effects are controlled and typing provides neat abstractions (monads, functors, etc.). The primary source of complexity in some functional languages is laziness.

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.
- danieldk 15y ago
  If this is true, can you point me to an elegant implementation of, say, the Either monad in a non-functional language? Bonus points if you can show me how to implement algabraic data structures plus pattern matching in your favorite non-functional language.
danieldk 15y ago
My experience is exactly the opposite: in number crunching it's often easier to parallelize processing in a low-level language such as C or C++. Current C compilers make loop parallelization via OpenMP. And since data is mutable, you do not have the overhead of allocating new chunks of memory (plus garbage collection). Functional languages will eventually be able to do most parallel computations on vectors and matrices nearly as fast as C. E.g. in Haskell a new project has started for adding support for SIMD intrinsics. Packages such as repa have been shown to be much slower (see the repa papers), where a program using repa with 8 cores (without SIMD) has about the same performance as a single-threaded C program (with SIMD). With SIMD support, Haskell plus repa will probably get a lot closer to the performance of C. Where functional programming with immutable data structures does help tremendously is in concurrency. Anyone who has written a fairly complex C++ program using concurrency, such as a GUI application, has probably run into complexity issues. There is a lot of mutable state, and no clearly defined model of interaction between threads. Anyway, in my opinion the real benefit of a pure functional language is that code written in a functional language is often more succinct and easier to reason about. There is no state outside a function (either global or within an object), side-effects are controlled and typing provides neat abstractions (monads, functors, etc.). The primary source of complexity in some functional languages is laziness.