Live data from Hacker News

Learning Curves for Different Programming Languages

github.com

101–110 of 221 posts

Re: Learning Curves for Different Programming Languages

#101
post #26

I am increasingly convinced that Haskell only exists so that people who know it can pat themselves on the back for being wonderful.

Yeah, I've got a similar impression. The only 2 things I care about are 1) productivity (time to finish a task) 2) how pleasurable is it to use a language. And I just don't find Haskell (or Lisp) to be as productive as many would suggest, even if you adjust for matureness of the ecosystem. (Note: I have a moderate experience with Lisp, very little experience with Haskell and these days mostly program in Java, Julia a…

I wrote the core of our system in Clojure a couple of years ago, which is pretty high in productivity and actually quite pleasant to work with. Unfortunately as the scale goes up (hundreds of web application routes, sharing code among multiple projects etc) it doesn't feel nearly as nice anymore, and having static typing turns out to be pretty handy.

Haskell to me felt exactly like what you described: I could get stuff done fast because of how few head-scratchers I'd experience. This is mostly due to type mismatches, and how much more well thought our my design needed to be upfront. I also really enjoyed the language because I could express fairly complex thoughts in a very succinct, and yet very readable fashion, mostly thanks to types being explicit and enforced at compile time. Code reuse and sharing across multiple applications is also a breeze, which is absolutely key once you get past the "single Rails app" stage and you start getting into two digits worth of tools, services and applications.

Re: Learning Curves for Different Programming Languages

#102
post #82
post #75

Earlier quoted context omitted.

Actually, right in these comments PHP programmers proclaim how productive they are, how PHP powers half the web and how Haskellers haven't done anything practical. So it seems your sarcastic rant completely misses the mark. Disclaimer: not a haskell, nor a php programmer.

Which language do you use this days?

I've discovered elixir several weeks ago and fell in love. Dynamic functional language with great concurrency support and ruby syntax. Wow. Lots of other goodies, too.

Started a complete rewrite of my data analysis project in elixir and it is going great. I am nearly sure that my chemistry with elixir will stick for a long time.

Due to practical reasons javascript is my primary choice for small, short-term projects. As an example, meteor is really interesting. I consider JS to be a safe-ish investment of my time due to its momentum and huge ecosystem. It doesn't make me happy, though.

So, to answer your question my languages of choice are JS + Elixir.

Before elixir I've tried python, ruby, go, r, javascript, haskell and c. Btw, I consider programming in haskell to be a good learning exercise for understanding advanced CS concepts.

Re: Learning Curves for Different Programming Languages

#104
I am working on a commercial SAAS application written in Haskell. I have been programming computers since 1980, with solid experience in at least a couple dozen programming languages. I chose Haskell for this project because of its programmer productivity and runtime performance. I have not been disappointed. I am always amazed at how little code it takes to get things done. The Achilles Heel of too many languages and their implementations is concurrency support. Haskell had that problem licked ten years ago. Once my code compiles, I know it has few remaining bugs. It runs fast and there are enough good third party libraries to meet my needs.

So what's not to like about Haskell? It has a brutal learning curve. Not so much because it is hard, but because it is different.

Re: Learning Curves for Different Programming Languages

#105
post #95

Earlier quoted context omitted.

PHP is full of problems that lead directly to security vulnerabilities if you aren't constantly aware of them and very careful when writing your code. So when someone who doesn't know those problems (most people) "hacks together" something that "just works", it is almost always providing a backdoor into that server. Once you do learn a little, you find that every scripting language is just as easy to work with as PHP…

Does Perl, Python or Ruby have built-in automatic escaping and sanitization? I would not call PHP less safe than any of these languages. On top of that all three of those languages require additional setup. (Especially Ruby with RoR shudder )

Generally speaking, tutorials in those languages recommend using the paramatized versions of the queries rather than string concatenation and manual escaping. The official docs from these more well-designed languages would have copious warnings against attempting to escape user input yourself, rather than having numerous functions baked into the language to help you do just that (e.g. `mysql_escape_string`, `mysql_real_escape_string`).

Re: Learning Curves for Different Programming Languages

#106

Earlier quoted context omitted.

Yeah, I've got a similar impression. The only 2 things I care about are 1) productivity (time to finish a task) 2) how pleasurable is it to use a language. And I just don't find Haskell (or Lisp) to be as productive as many would suggest, even if you adjust for matureness of the ecosystem. (Note: I have a moderate experience with Lisp, very little experience with Haskell and these days mostly program in Java, Julia a…

>I just don't find Haskell ... to be as productive as many would suggest >I have ... very little experience with Haskell So, how would you know?

I don't know with 100% certainity, but it's a moderately confident conclusion from my little experience.

Re: Learning Curves for Different Programming Languages

#108
post #10

He wanted to make a cheap joke, but PHP should be the opposite: productivity is rather high, while self-assesment is low.

PHP is the standard bearer for the expert beginner. People write something that seems to be working quite quickly, so they feel they "get it" and know what they are doing. And then they stagnate and stay like that for 5, 10, 15 years even and never learn more. And then when presented with things they don't know, they resort to anti-intellectual rhetoric and trying to convince themselves that those things are "just a different way of doing it but no better than how I do it" and stay there in their rut forever thinking themselves an expert.

http://www.daedtech.com/tag/expert-beginner

Re: Learning Curves for Different Programming Languages

#109
post #80

Earlier quoted context omitted.

Yeah, I've got a similar impression. The only 2 things I care about are 1) productivity (time to finish a task) 2) how pleasurable is it to use a language. And I just don't find Haskell (or Lisp) to be as productive as many would suggest, even if you adjust for matureness of the ecosystem. (Note: I have a moderate experience with Lisp, very little experience with Haskell and these days mostly program in Java, Julia a…

"I have a moderate experience with Lisp, very little experience with Haskell and these days mostly program in Java, Julia and Python" I despise that people give their 2 cents for something they haven't experienced much.

Why? You assume that little experience with Haskell is not enough to make conclusions about its productivity. I disagree with this assumption, I think you can sometimes make a moderately confident conclusions from little experience. And I understand I can be wrong of course.

Re: Learning Curves for Different Programming Languages

#110
The stigma around Haskell is quite unfortunate. Most complaints that I've heard leveled at Haskell are variations of "it's too academic". Given that those complaints usually come up when one is tackling abstractions like Functors, Applicatives and Monads, it would seem that the true sentiment is that "Haskell is too abstract".

Interestingly, I have yet to hear someone complain about abstractions like Collection, Stack, Dictionary, or looking at the ever popular OOP abstractions Class and Method.

Why is it that OOP is widely accepted[1], and yet Haskell-like FP has yet to take off? Well, I think I have an explanation for why this is.

The abstractions commonly used in Haskell are perhaps a bit "more abstract" than those seen in most OOP programming. Most people can intuit the value of collections/classes/etc., and those that can't are pushed in the right direction by the majority of the industry.

Compare the situation of popular imperative languages to that of Haskell: the utility of the former is easily acknowledged and has the support of the industry, whereas the latter is harder to fully appreciate without investing some time and has the industry actively suggesting that the abstractions are useless.

Haskell-like FP is, unfortunately, where OOP probably was when it was still "the new thing". "Why would anyone use this? Classes, interfaces, methods, messages... Too academic!"

And then OOP picked up momentum as people discovered the utility of encapsulated state, programming to an interface (instead of an implementation), the ability to isolate the System Under Test via mock objects... And then those that tasted the benefits worked really, really hard to shift the mindshare of the industry to accept these abstractions as "good things".

I hope Haskell et al will get there some day. The thing is, ideas like Monads are incredibly useful - just as useful as any of the more popular abstractions. They're just one more tool in the toolbox - if you don't know them, you might be missing out.

In an attempt to dispel the myth that abstractions common in Haskell are academic and useless for professional programming, I would ask one thing of you: please, please, please watch Tom Stuart's talk "Refactoring Ruby with Monads" (given at Barcelona Ruby Conference 2014): https://www.youtube.com/watch?v=J1jYlPtkrqQ

The abstractions are useful. Yes, just like any of the abstractions that you may have already mastered, they do take time to learn. It's an investment. I know the payoff might not be immediately obvious, but I promise that it's right around the corner. There's a practical, pragmatic reason Haskell is being used to great effect at places like ThoughtBot, Facebook, Skedge.me, and more.

[1] This is almost a given now: recruiters have often quizzed along the lines of "why is OOP a superior paradigm?"

Post reply on HN