Ask HN: Programming language power and 10 years to mastery

Haskell changed the way I program because laziness can allow you to express your code in much clearer and simpler ways - this encouraged me to use more memoization.

Functional programming is definitely where we want to be in theory, so if practice permits, use it!

Also consider learning a dynamic 'scripting' language like Ruby or Python. They have some functional aspects, and will teach you programming style and idioms that you probably haven't picked up from Java and C.

My personal history goes something like QBasic -> Visual Basic -> PHP -> Java -> C# -> Haskell.

Since Haskell is a purely functional language there's no cheating like you could in, say, OCaml. This forces you to learn how to work with immutability, which I have become a big fan of. When working with C# I try to avoid mutability as much as possible (naturally this is quite a bit uglier than in Haskell, but it does avoid some problems). Most of my C# projects now acquire a Haskell.cs file fairly quickly, containing things like a Tuple class, zip, >>=, etc.

In the time I've spent learning it, Haskell has quickly become my favourite language. It's not perfect (my current main wishes are existential types and an extensible record system), but it is considerably less painful than the other languages I know.

As for speeding up the transition, I can't offer anything other than just diving in. At some point it will just click and you will wonder what all the commotion is about (another monad tutorial? why?). Granted, I still don't have the slightest idea about why I would want to use a hylomorphism or what to do with a comonad, but perhaps I will some day. Fortunately you don't need them in everyday Haskell programming :)

afaik hn doesn't use sql/rdbms either, i guess it's because threaded forum is better suited using a tree-like data structure instead of simple table

i stopped using sql (after reading pcl and seeing the fact of hn) and just having a lisp process running, writing to disk every 5 mins

i'm now experimenting with nginx's proxy_pass and upstream to many lisp unix sockets (weighted round robin)

virgin territory for me, it's quite fun so far ... foolish and hungry :D

Why is this figure being bandied about as though it were an actual scientific fact?

A second excellent book is "Higher Order Perl", which shows how Perl, also, shares a lot more in common with Lisp than most developers realize. I'm on my 13th year as a professional developer and 27th as a hacker, and I still find some of the concepts in HoP challenging.

I would also recommend learning XSLT. It's pure declarative, side-effect-free programming. If you're used to procedural code (including OOP), or even functional code, you'll still have to reattach your head sideways to learn to use XSLT effectively. It's well worth the challenge; there are problems that would be very difficult to handle in other languages which XSLT handles with ease; it's a powerful tool for your toolchest.

As for improving my skills, that's an unequivocal yes. I think the biggest eureka moment came when I understood the idea of first class functions. That opened many doors to better code.

Before, I used functions primarily like a writer uses paragraphs: to break up the narrative into chunks. After SICP, I saw functions more like (for lack of a better term) filters. They transform their input into output. The transformation is well defined, and the natural boundaries between functions become clear rather than arbitrary.

Actually that is the power of Lisp. In Lisp, batch or stream data processing is not only straightforward, but the way to think and program.

For me, I need to be able to create something tangible. Having access to all the Java libraries gives me a lot of cool things to import, then play around with in functional ways.

Both are very worthy goals, but I don't know if using Lisp, Haskell or erlang to write a web app is really a great idea right now. (Sorry PG). I think that is was true that writing web apps in Lisp probably gave you a huge leg up against the competitors in the mid 90's. I don't really know if that's the case now.

Languages like Python and Ruby have tons of libraries, frameworks and documentation that really help you get productive making web apps. That's a huge plus in my book.

Then again, maybe you're interested in rolling your own libraries and framework ala arc. If that's your thing go for it. I'm sure you'll learn a lot along the way.

I also found learning OCaml to be a real eye-opener, both for learning FP techniques (it emphasizes a different set of them than Lisp) and how to work with, rather than against, static typing. (_The Little MLer_ helped, as well, and is at least as good for learning types as _The Little Schemer_ is for recursion, IMHO. Highly recommended.)

There's not a whole lot of material published in English on OCaml (the Joshua Smith book is terrible!), but there's a translation of a French O'Reilly book online (http://caml.inria.fr/pub/docs/oreilly-book/), and it's quite good for learning the main ideas. The first few chapters are on functional programming, imperative programming, and then their relative strengths & when to use each. (Their emphasis on using FP when appropriate, rather than treating it as the new best thing ever, suggests more insight to me than the blind enthusiasm for languages that tends to cycle through here and reddit.)

Also: OCaml is not without its flaws. In particular, its errors can be cryptic, and it's standard library has some infuriating omissions. The language is fantastic for some kinds of problems (ML's forte is anything involving complex data structures), though, and it's a great way to learn some very useful techniques.

With web app backends, for example, most of the problems somehow relate to difficulty maintaining state over widespread, always-on networked systems - things like authentication, sessions, concurrency, large-scale, flexible datastores. So the systems architected gradually get more and more tuned towards serving this particular goal with little programmer effort. And because those problems are a good match to functional programming - because it eliminates state - functional has become popular.

But if you were building an embedded system, statefulness is less of a problem: there's usually only one thread, and all memory can be mapped in an orderly way. Your performance constraints are reliant on a single fixed platform, so the methods of inspecting and debugging code change.

So to get back to the original question, think about reframing your familiar problems in a way that would simplify the solution with a functional technique. Preferably, look for simplifications that are really big changes and throw out traditional assumptions - the use of relational databases in webapps is one common target for this. Even if you get it wrong you'll get a better understanding of where the functional solution can and can't work.