The Rest of the Story (Yammer & Scala) • Hacker News Board

Re: The Rest of the Story (Yammer & Scala)

#41

Post by temphn » Wed, Nov 30, 2011, 9:07 AM UTC

socratic wrote: post #16

michaelochurch wrote: post #7

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 exec…

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 progra…

The 99th percentile C++ systems engineer uses C++ in their day job, likes it, and uses Haskell on the weekends for fun. They can also give you a detailed set of things Haskell needs to fix before it becomes more widely used (fast Mutable Maps among them).

Re: The Rest of the Story (Yammer & Scala)

#42

Post by microtonal » Wed, Nov 30, 2011, 9:30 AM UTC

harryh wrote: post #12

jmspring wrote: post #11

Earlier quoted context omitted.

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…

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.

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.

Re: The Rest of the Story (Yammer & Scala)

#43

Post by j_baker » Wed, Nov 30, 2011, 9:31 AM UTC

microtonal wrote: post #39

michaelochurch wrote: post #20

Earlier quoted context omitted.

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…

I think it's this: the best programmers generally want to learn new languages and approaches. This is true, however an inherent danger to Haskell/Lisp/ML-filtering is that this group has also a relatively high percentage of people who think every problem is a nail. So filter for people who know functional languages, but also have plenty of experience with, say, C or C++ projects.

You really believe functional programmers are more willing to treat their language choice as a golden hammer than C++ or Java programmers? You must have installed a different version of reality than I have.

Re: The Rest of the Story (Yammer & Scala)

#44

Post by microtonal » Wed, Nov 30, 2011, 9:35 AM UTC

jmspring wrote: post #24

harryh wrote: post #12

Earlier quoted context omitted.

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.

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 ", for instance, functional javascript brings up an interesting article on IBM developer works: http://www.ibm.com/developerworks/library/wa-javascript/inde…

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.

Re: The Rest of the Story (Yammer & Scala)

#45

Post by microtonal » Wed, Nov 30, 2011, 9:38 AM UTC

j_baker wrote: post #43

microtonal wrote: post #39

Earlier quoted context omitted.

I think it's this: the best programmers generally want to learn new languages and approaches. This is true, however an inherent danger to Haskell/Lisp/ML-filtering is that this group has also a relatively high percentage of people who think every problem is a nail. So filter for people who know functional languages, but also have plenty of experience with, say, C or C++ projects.

You really believe functional programmers are more willing to treat their language choice as a golden hammer than C++ or Java programmers? You must have installed a different version of reality than I have.

I didn't say filtering on Java was any better. Just that 'filter on Haskell or Lisp' is no golden rule. You will miss out on good candidates. There are great programmers out there who never really touched Scheme or Haskell outside a CS course.

Also, I think that a fairly large subset of C++ programmers who think that C++ is an ugly and complex language. But it's often practical, e.g. because it is used in legacy software, because it's fast (and provides more abstraction than C), or because many good cross-platform UI libraries use C++.

Re: The Rest of the Story (Yammer & Scala)

#46

Post by lancepantz » Wed, Nov 30, 2011, 9:51 AM UTC

michaelochurch wrote: post #7

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 exec…

Who mentioned clojure?

Re: The Rest of the Story (Yammer & Scala)

#47

Post by gtani » Wed, Nov 30, 2011, 10:06 AM UTC

michaelochurch wrote: post #7

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 exec…

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_lim...

http://www.reddit.com/r/haskell/comments/mm68o/ghc_74_branch...

Re: The Rest of the Story (Yammer & Scala)

#48

Post by sandofsky » Wed, Nov 30, 2011, 10:19 AM UTC

michaelochurch wrote: post #7

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 exec…

"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.

Re: The Rest of the Story (Yammer & Scala)

#49

Post by nivertech » Wed, Nov 30, 2011, 10:20 AM UTC

michaelochurch wrote: post #7

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 exec…

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.

Re: The Rest of the Story (Yammer & Scala)

#50

Post by lmkg » Wed, Nov 30, 2011, 10:25 AM UTC

brown9-2 wrote: post #8

michaelochurch wrote: post #7

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 exec…

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?

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.