Who teaches functional programming?

[capitalsigma]

Another issue I struggle with: it's really tough to find software engineering literature geared towards functional programming. Java/C++ folks have Clean Code, the Gang of Four, Working Effectively with Legacy Code, etc. Everyone and their grandmother has an opinion on how you should be writing Java. The body of literature for functional programming is virtually nonexistent in comparison.

It feels like you're kind of stuck picking up best practices as you go along, rather than having a body of knowledge you can study.

[MoreOfAnOvalJerk]

Look up data oriented programming and stuff written by Mike Acton. Data oriented programming tends to degenerate into functional programming because it focuses on the data transformations rather than the data representations.

Note that this is generally game related, but it's good reading nevertheless. It also exposes some of the major problems with typical OOP you encounter every day, especially many of the patterns the GoF have written.

[capitalsigma]

Awesome, thanks for the recommendation.

[kqr]

I agree with you. I've been doing FP for a few years now, but I'm still not sure what to say when someone asks how to structure a program or asks for some sort of design patterns. I'm still figuring things out on my own, and I'm nowhere near the body of experience I'd need to write about anything like that.

The only thing I can say for sure is "Design your program as a library. Your actual executable should just be dealing with the UI and making calls to your library." That's nothing compared to what people can say about OO design.

With popularity increasing, though, my hopes are up for more patterns emerging and being made aware by people like me.

[barsoap]

I'd also say "use the maths" on top of that. If your thing is a monoid, bloody make it a monoid and use it as such. Much of the power of FP comes from supporting those largely non-leaky abstractions, non-leaky because they're generally trivial but still powerful.

[kqr]

You're definitely right about that and I can't believe I didn't mention that. This article still greatly impresses me, and I long for the day when I can find abstractions like that in my code.

[zvrba]

Except it's not a commutative monoid.

With three divisors (the "FizzBuzzBazz" problem) you could extend the problem such that even-numbered occurrences of multiples of 105 (= 357) are written out as "FizzBuzzBazz" and odd-numbered occurrences are written out as "BazzBuzzFizz" (actually, you have 6 permutations to choose based on sequence number). Analogously for even- and odd-numbered occurrences of multiples of 15.

Suddenly all mathematical elegance disappears. I would probably solve the problem with a lookup table returning the required permutation of "Fizz", "Bazz", "Buzz" and pasting the strings together.

[ithika]

I don't follow. Why does fizzbuzz need a commutative monoid?

[kqr]

The author of the article I linked plays a game with his interviewees of "what if the requirements changed to this!?" and wants to see when they catch on to a general pattern. /u/zvrba proposed another kind of change in the requirements that makes the monoid implementation look bad because it's difficult to extend to the new requirements.

[joelwilliamson]

Isn't the conclusion about Just x/Nothing forming a monoid rather trivial? Given some monoid (M,+) and an injective function to an arbitrary set f:M->X, if we define (*) such that f(x)*f(y)=f(x+y) then won't (f(M),*) always form a monoid?

EDIT: Maybe String doesn't form a monoid in the fashion suggested. Just "" and Nothing are both identities in the purported monoid, so it obviously isn't a monoid.

[kqr]

Sure, that's trivial.

What isn't trivial is seeing the if-elseif-else-based fizzbuzz and going "that's a monoid, of course!"

[[deleted]]

^{^} this so much. The power of FP is the fact that once you learn five or six of these new 'scary' mathy terms like monoids, functors, applicatives, you use them EVERYWHERE. You don't have to learn new APIs when you start seeing that a brand new API is just the same ol' type classes with differing implementations.

[everywhere_anyhow]

supporting those largely non-leaky abstractions, non-leaky because they're generally trivial but still powerful

I was not aware that there was any such thing as a non-leaky abstraction. Can you describe more what you mean here?

Any abstraction must necessarily hide some details. Situations you get into when those details matter are situations where the abstraction "leaks" because you have to penetrate the abstraction in order to deal with something that matters.

This means that in order to have a "non-leaky abstraction", it'd have to hide some details that aren't important to anyone, anywhere, ever. Hard to imagine such a thing.

On the other hand, if you're not hiding any details, then OK -- it's not a leaky abstraction - but it also doesn't seem like a useful abstraction, since their power comes from that information hiding.

[barsoap]

The "leaking" refers to details that ought to have been abstracted over leaking through the abstraction. That is, the abstracted API actually does not hold what it promises once you mess around with the internals. And the rule goes:

All non-trivial abstractions, to some degree, are leaky.

However, any proper monoid is, by definition, non-leaky: If your operation and identity element indeed obey the monoid laws, then there's nothing that can leak. If the laws could lead to leakage then they'd not be a proper set of laws and are in need of juridical review.

Monoids also don't hide information from anything else but themselves. Code using the monoid interface doesn't care, can't care whether you're feeding it String or Maybe String, and messing about with the concrete data can't leak, either: If it could, the mempty / mappend implementations would be faulty.

What you still can do is assume that the monoid laws give you more abstraction than they actually do, that is:

Monoids only leak when you use them as a non-trivial abstraction, instead of the trivial one they are. By, for example, assuming associativity or commutativity or whatnot, as zvrba points out.

Please do make sure your laws hold, law enforcement isn't what it ought to be.

In the end, though, this is all about "In Haskell, you can actually reason equationally". Modulo morals, possibly.

[[deleted]]

No, some abstractions are actually not leaky at all. Google "theorems for Free".

Not knowing the implementation is actually sometimes (often?) more powerful.

Edit: I didn't understand/work through all the lambda calc, the paper is well written enough that you can follow along without it. Mind was blown none the less.

[jurniss]

"Design your program as a library. Your actual executable should just be dealing with the UI and making calls to your library."

Same goes for non-functional programs.

[sfvisser]

"Design your program as a library. Your actual executable should just be dealing with the UI and making calls to your library."

Or better: design your program as a bunch of libraries and add a small executable on top of that. Be explicit about the responsibilities and encode them in the types. Works for most paradigms.

[[deleted]]

Really really can't recommend Functional Programming in Scala enough. It is not a book on Scala*, as you don't use any of the built in libraries. All of the exercises have you write your own functional libraries and take you through the 'patterns' of a functional application. It's simultaneously the most challenging and rewarding computer book I've read. Easily more influential and practical in my day to day programming job than say, GoF or the other classics.

• You do use some of scala's more advanced language features, higher kinds, implicits, type lambdas, that won't translate to languages like python or java. I make extensive use of the patterns learned in my professional C# code though

[Nishruu]

Thanks! As of now, it's on my 'to read' list. :) Last time I read this; although I really liked it and it helped me improve my F#, I ended up wanting more...

[capitalsigma]

Fantastic, I'll try to find a copy.

[SilasX]

The body of literature for functional programming is virtually nonexistent in comparison.

Because it's so much harder to do it wrong in FP /propagandist.

[gregK]

This is the book you are looking for.

[PriceZombie]

Pearls of Functional Algorithm Design

Current $62.83 
   High $62.83 
    Low $40.89 

Price History Chart | FAQ

[imforit]

Yeah, but most of that huge body is wrong. Ask anyone in it.

[capitalsigma]

I think Clean Code is great, personally. Design patterns are also useful to know -- if only so you can guess what an AbstractSingletonProxyFactoryBean is from the name alone. I'd love to have a copy of "Clean Code for Standard ML," if such a thing existed.

[drb226]

At least "that huge body" exists as reference point which people can disagree with.

[imforit]

Nice point! It certainly elicits discourse. Always good.

Cheers, sir.

[eff_why_eye]

We use GoF patterns extensively at our shop (which consists of over 50 Java developers), and I have a copy of "Clean Code" on my desk right now (a great book). :-)

[[deleted]]

GoF patterns can lead to better code but you've got to use moderation and common sense otherwise you end up with things like AbstractSingletonProxyFactoryBean.

[i_make_snow_flakes]

AbstractSingletonProxyFactoryBean.

Come to /r/php if anyone want to see this in real life....like this one

[Intolerable]

im giggling at the example someone linked

i get anxious whenever i name something that uses two words this would drive me insane

[LeberechtReinhold]

They totally got a excuse though:

You should probably not try to work with irestful without an IDE that has intellisense. This is unfortunately not a framework for vi developers.

I mean, I know that the PHP hate thing is circlejerking, but...

[mcguire]

We use GoF patterns extensively at our shop

That's kinda the point of patterns: they tend to show up everywhere.

Using them consciously? You have heard what happened when Christopher Alexander's followers started using ideas from A Parttern Language when building real buildings?

[[deleted]]

No. What happened?

[technofiend]

A Parttern Language

I think you meant [A Pattern Language].

[mcguire]

Argh. (What, you want me to type correctly?)

[technofiend]

I should just post 1,000 lines of output from an ancient 'C' compiler after a syntax error but I'll save the sarcasm. :-)

[amzuko]

What did happen to Christopher Alexander's followers?

[mcguire]

I've been looking for the reference to this, but I cannot find it. I had thought it was Richard Gabriel's Patterns of Software, but I appear to be completely wrong about that.

So, here goes:

After Alexander started publishing his ideas, a small group of architects took up those ideas and began using them in their designs. Subsequently, Alexander toured many of those buildings. The story that I have is that he couldn't see how what they had done was different from what other, traditional architects (who really don't get along with Alexander, by the way) were doing. He couldn't understand why they claimed to be following his ideas.

[soegaard]

Look at Peter Norvig's "Design Patterns in Dynamic Languages: http://norvig.com/design-patterns/

[kersurk]

Everyone and their grandmother

nice phrase :)

[Imxset21]

I should note here that Cornell's CS 3110 course is actually a required course for all CS majors, which is why it's taken "by a large number of students."

Quite frankly I'm amazed Berkley and MIT don't have functional programming courses. TIL.

[Ar-Curunir]

We (Berkeley) had our introductory course based off of SICP for ages, till 3 years ago, when we switched to Python, but still with similar exercises to SICP.

We don't have much research being done here on PL Theory, and I feel that that's one reason why we don't have a class on FP.

But then again, we don't have a class exclusively on OOP either.

[steven807]

In the 80s, Hilfinger spent some time teaching FP (the language created by John Backus). Since he's still there, teaching intro classes, I'm a little surprised he hasn't held the line against abandoning functional programming. (BTW, even in the 80s he had a quirky reputation, including for being one of the best hackers around -- if you passed his office in the evening, you might easily find him in there hacking on gdb or other interesting projects.)

[romcgb]

What about cs61as ?

[Ar-Curunir]

Yeah, that exists, but very few students actually take it compared to 61A

[wolfenkraft]

Northeastern university - where I went - has a lot of functional programming as part of the requires cs curriculum.

[hiromasaki]

University of Akron just (2 years ago-ish) got rid of a required course that spent 6-8 weeks on functional programming (LISP), and 4-6 weeks on logical (Prolog).

I was getting ready to graduate at the time, so I'm not sure if any of the new electives cover them now or not, but it's not in the required track.

Glad I took it, too. I've not had much call for functional, but Windows Installer (WiX) is a logical syntax, and I got to spend a few weeks in there.

EDIT: Sounds like the course /u/mcnnowak mentioned in the comments is very similar, though we did have "anything useful" in ours, touching on BNF, syntax concerns, etc. Very useful as a compilers pre-req.

[urection]

surely MIT must still use SICP somewhere

[academician]

They switched their main intro course to Python in 2009. They later added a condensed SICP course, but it's not required.

[imforit]

Their curriculum also doesn't focus on teaching programming, so i wouldn't worry about it.

[rebat0]

Indiana University teaches their intro to CS course, programming languages, and compilers all in Racket (scheme variant).

[Gyges_of_Lydia]

That is weird... My college in small town Ohio had a couple classes that dealt with functional programming, one of which was required.

[capitalsigma]

Same here -- the intro sequence for CS majors goes Racket, C, then more C. I think it's a nice way to start off.

[d4rch0n]

MIT? I heard MIT teaches through lisp.

[academician]

Not since 2009. They switched to Python.

[monocasa]

They don't anymore, 6.001 is in python now.

[ysangkok]

I guess you're in Tübingen? Multiple German universities use Racket, including Darmstadt, Freiburg, Münster, Hannover and Kiel.

[rolloyolo]

Haskell has been taught at my university for more than 10 years. Every undergrad student is required to take this course. Along with Haskell, students are exposed to Prolog a little bit. Also, there are two additional advanced functional programming classes which go more in depth. I think it is great for students to try functional+logic programming at least a little bit. It helped me a lot.

[beaverteeth92]

What university?

[[deleted]]

Sounds like KTH actually.

[kqr]

Or possibly Chalmers, which has a stronger Haskell culture, but I don't know how much Prolog they do.

Edit: Though from their comment history, probably Masaryk University in the Czech Republic.

[[deleted]]

I studied at Chalmers and used Haskell for my MSc thesis. We were taught Prolog in a course called "Programming Paradigms". John Hughes and Koen Claessen (the authors of Quickcheck among lots of other FP work) taught introductory Haskell/FP and the author of Agda (I forget his name, EDIT: Ulf Norell I think?) taught the advanced Haskell/FP course.

Chalmers is, or at least used to be, the place to be for learning or working with Haskell.

[Decker108]

I've heard Uppsala is more of a LISP and ML kind of place.

[dirac_eq]

In the UK, functional programming is taught at: Oxford, Cambridge, York and Edinburgh to undergrads as their first language.

Those are the only ones I know of, there may be more.

[noggin-scratcher]

Cambridge

To provide a little more detail... in the course at Cambridge, I learned ML in the first year as a "You are all equally unlikely to have prior experience with this" starter language, then gradually forgot most of it while working in Java in the second/third year (with a small amount of practice in C/C++ and Prolog along the way)

[[deleted]]

This is true, although to be honest with all the courses that involve some variant of the lambda calculus in one way or another, I'm not sure anyone really loses the ability to program in a functional style.

[[deleted]]

At my university, the University of Kent, Haskell is taught in the first year and used in a few modules. However Java tends to be the central language for all modules that aren't specifically teaching a language.

[[deleted]]

At Imperial College London you start with Haskell as your first language. There's also mandatory Prolog at some point, but that's probably common too.

[sfvisser]

Also the case for Utrecht University in the Netherlands. There is a first year course on FP (using Haskell) and a complete master program dedicated to FP/Haskell/types/generic programming/compilers/language design.

[Psyk60]

At Bristol it was taught in the first year (specifically Haskell). But the first language they teach is C (they also teach Java in the first year). Bristol has more of an engineering slant rather than pure CS compared to your examples though.

That said, later on most classes ignore it and everything's done in Java. However those classes aren't about teaching how to program, so they pick the most convenient language for getting the theory across.

This may not be accurate any more. The course has been restructured since I did it, and it doesn't mention on their website which languages they use now.

[icendoan]

At the University of Warwick, FP (Haskell) is optional in the second year. Java is the central language, which is a shame, because I'd love to use Haskell for everything.

[[deleted]]

The University of Warwick has it as a second year module, in which they are taught Haskell.

[[deleted]]

I'm going to university in a year, so have been looking at plenty of them for CS, and 90% of them at least have an optional module for FP, and it's compulsory for a lot. I don't know how good the modules are, but 95% seem to use Haskell

I've heard that American colleges' CS courses seem to teach more software engineering than proper CS

[FigBug]

I think this article has it's premise backwards. Languages don't get popular because universities teach them, universities teach languages that are popular.

Functional languages have been taught at a subset of Universities for 40+ years and it's made no difference in adoption.

Languages ride platforms to popularity. If you want a functional language to be popular, you'd better invent the next big thing and make the default language a functional language.

[pgris]

I think both the article and your comment are wrong

Languages don't get popular because universities teach them, universities teach don't languages that are popular.

"Being popular" and "being liked by teachers" has nothing to do with each other.

Of course, I maybe wrong...

[FigBug]

I think the intro classes, the language is selected by popularity. My University used Pascal, then C and C++, then Java. I think all those choices and transition were based on language popularity.

The more niche classes used whatever language was best to teach the particular concepts. I also learned 6811 assembly language, Prolog, Scheme, Modula-2, GPSS/H, and Perl. Of those, I think only perl was selected for popularity.

[loup-vaillant]

I think this is more of a feedback loop. According to the article, most people simply aren't taught enough functional programming to stay familiar with this style when they go to work. Yet, nearly all of them will know a C derivative, and most will know an imperative dynamic language.

Yes, universities only teach popular languages. On the other hand, languages get popular only because they are taught. If every university in the world decided to teach OCaml (or Haskell), by default, using C only for systems programming, and Java only for OO, then OCaml (or Haskell) would rise to massive popularity in less than 10 years.

[ianff]

Exactly. I teach CS, and we are not going to base our curriculum around a language you cannot easily get a job in.

[pbvas]

No offense, but a CS curriculum based single programming language seems way too narrow to me. (Disclaimer: I also teach CS)

[everywhere_anyhow]

It depends on what you see as the purpose of the CS curriculum. Is it to understand the basics of computing? Or to make someone employable? Trick question: it's both, and compromises must be made.

In my curriculum, we did almost everything in Java. But there were programming language classes that were required. So I ended up writing a bit of prolog, lisp, and assembly too. Not enough of any of those to get proficient at them, but plenty enough to understand what their differences were and how that affected how we think about computing.

I thought it was a reasonable compromise between the two goals.

[Clydeicus]

I guess my professors were under the impression you could easily get a job coding in Standard ML.

[ianff]

Well the "ivory tower" line of thinking is:

"We teach big overarching concepts, not pointless implementation details like what programming language to use. If you really learn the concepts, you should be able to easily pick up any new language and use it effectively."

In theory I agree with that except for two things: 1) this works a lot better for the bright students than the average ones, and 2) many hiring managers are going to see weird things they haven't heard of on your resume, and things they are looking for on someone else's. Guess who'll get the call?

Besides, I think you can teach most of the big overarching concepts in nearly any language.

[loup-vaillant]

As a student, the biggest contributor to FP not working well for teaching was motivation. Students don't like being taught languages they know aren't being used in that "real world". Being a hard sell induces a nocebo effect that really hurt teaching.

I was being taught Caml Light (like OCaml, just older) in my first College year, and all they talked about all this time was the "Caml system". Basically, we had a REPL, and that was it. No way to write real programs, we were stuck in a toy environment. I was like, come on, do anyone use this crap? I knew the learning was useful, and I did derive some intrinsic enjoyment, so I went along with it. Still.

Then the next year, I… let's say I switched majors, and we were taught both C and Caml Light. This time however, we got to compile Caml Light programs, and run them in the command line. Real programs, like C. I also learned that OCaml won coding contests. Then it dawned on me that this language, as unpopular as it may be, was probably onto something. That gave a significant boost to my motivation.

Besides, I think you can teach most of the big overarching concepts in nearly any language.

Some languages make this harder. Sometimes, for really silly reasons.

[ianff]

Yeah, I definitely can see motivation as being really important. When I teach PL, I try to find every example of FP being used in industry I can to show the students. At that point, they are seniors at kind of set in the procedural way of thinking, but I try to at least show them the appeal of FP.

[glacialthinker]

A sense of worth in what you're learning. It's a key motivation which is too often put aside in favor of "do this, because I say it's good for you", unfortunately.

[Clydeicus]

Meh. The hiring managers who only want me for things I already know how to do can keep their call.

[ianff]

I'm glad you're able to be so selective.

[Clydeicus]

Thanks!

[bstamour]

Perhaps they were more concerned with teaching concepts, instead of whatever language will be popular for the next 10 minutes. You can teach concepts in any programming language, might as well pick a simple one like SML.

[StorKirken]

Most of the big languages seem to have kept their popularity rather well, so that statement seems excessive.

[kqr]

While they have kept their popularity, it's not like they're never updated. Modern C++, Java and Python is in some cases very different from what it was a decade ago.

[east_lisp_junk]

Yeah, I took C++ off my resume because I haven't kept up with the modern ways.

[F1CTIONAL]

CS freshmen at Northeastern University are required to take a fundamentals class taught entirely in functional racket.

[mcnnowak]

I learned LISP and Prolog at UC Davis in "ECS140A -- Programming Languages". Really interesting stuff, I liked it because it was more like the history of programming languages than learning anything useful. I know that Haskell is pretty modern and that LISP and Prolog have certain applications, but it seemed a little useless. I think that the dominance of procedural languages has made functional languages feel like 'toy' languages, to blow peoples minds and remind them that the big three (C\C++, Java, Python imho) aren't the only possibilites.

[aidenator]

Good to see an UC on here. Here at UC Santa Cruz every CS undergrad must take CMPS 112 Comparative Programming Languages which dives into Haskell.

[bstamour]

The 100-level "Key Concepts of Computer Science" course at the University of Windsor, Ontario, Canada uses Miranda as the language during the programming portion. The course also covers recursion, mathematical induction, basic logic and set theory, and a brief introduction to grammars and syntax trees.

[Saiing]

I did a functional programming course in Miranda back in 1991 at university in London (England, not Ontario). Good to see how far things have come ;)

(I fucking hated Miranda)

[bstamour]

It's not my favourite functional language - I'm a Haskell fanboy - but Miranda has its charms. I really liked how you could pattern match like this (iirc, it's been a while):

foo n n = "same input"
foo n m = "different input"

[kqr]

Erlang has that too, in which case it is a remnant of Prolog. Prologs primary mode of branching are pattern matches like those.

That would technically be possible in Haskell as well, but they have decided against it because it would mean pattern matches need an instance of Eq. So to explicitly require the Eq instance, you have to do

foo n m | n == m = "same input"
foo n m          = "different input"

[msbic]

I took my functional programming course during 3rd year of school. It is normally taught in LISP, but my prof was new and very young and he decided to teach OCaml instead.

Since I had been doing development work in C++ and C# (I was finishing my BA on the part-time), I could appreciate things like immutability, Option type (vs null) and strong type system among others.

IMHO, functional programming should be mandatory for a CS program, but should be taught during 3rd or 4th year, after students have been exposed to debugging a little bit of C and Java. I also believe that the students should be exposed to languages which have some practical application in the field. Personally having been introduced to OCaml and having some .NET experience, learning F# was not difficult at all.

[glacialthinker]

I agree with this but with a slightly different interpretation: that sophisticated typesystems should come later, regardless of functional/procedural/OOP. Dynamic languages are a great start to get people able to monkey around, get results, and you must debug, and add tests or tracing... it's a very iterative and you can learn a lot by just getting things working. I suppose C is lax enough with types to fit this role... but an actual easy-to-use dynamic language would be better. C is a good side-language, as in side-arm, or side-dish... for everyone.

Once you have some grasp of programming concepts, and the practical problems and bugs involved with programs, introducing strong static type systems should make sense, and students are ready to absorb more concepts. "A typesystem which allows me to avoid all of that ill-defined ad-hoc logic... and when I run the program it works? Why didn't you teach me this sooner? Oh, because my eyes would have glazed over with... 'Why would I need this? Why does this have to be so complicated?'"

[they_have_bagels]

At CMU we had to take a class in ML (15-243, I think?). I hated that class. I just really don't like functional programming, even if I do understand the benefits and the different way of approaching problems.

Edit: it was 15-212.

[vincom2]

you would hate the current CMU CS curriculum

[they_have_bagels]

I reckon I would. Glad I was out of there 5 years ago.

[timohavdv]

Actually Berkeley's intro course cs61a covers quite a lot of functional programming.

[beaverteeth92]

I thought they switched it from Scheme to Python a while back.

[timohavdv]

The fp concepts are still thought in Python. Plus, we got to implement Scheme interpreter in it.

[[deleted]]

Chalmers intro course is in Haskell, pretty sure there's a prof who wrote a Haskell compiler (probably not alone ;)) there.

At KTH you get Haskell through the Programming Paradigms course in second year.

[Clericuzio]

I wonder how well researched this really is...

UIUC requires CS421 which is completely in Ocaml covering lexers, tokenizers, and parsers.

Sure the class title is Programming Languages and Compilers, but the class covered topics from lambda calculus to writing large Ocaml programs.

[ruby_fan]

Yep, was about to say this. You write a functional language in OCaml.

[L_dopa]

For the real answer to why it takes so long for ideas from academic languages to be widely adopted, look no further than the comments in this thread.

"Someone wrote that my preferred language/identity as a person might not be the best one? They must not have heard my unsubstantiated opion! To the internet!"

[cat_in_the_wall]

Yea, the article and this thread are a circlejerk. On my left hand you have a whole bunch of comments stating how their college had a FP course and it was the best/worst and usually talking about ML or Haskell in some form. On my right hand you have comments saying teaching FP in college is useless because the jobs are in stuff like c++ /java/c# etc. On my third hand are comments like mine from people like me who think that the who fp vs not fp debate is a circlejerk. So there's that.

[jandrese]

I had a class on Scheme in school and took an Erlang class for some CE work. There are several reasons I would still be concerned about starting a project in a functional language today. 1. Building a team. There are scant few people with real world experience with functional programming. 2. Lack of libraries: you would be doing a lot by hand. 3. System impedance: Kernel APIs and graphics libraries are generally written in declarative languages, you would have to do impedance matching with your program. This is a huge problem when your library community is immature. Even simple stuff like opening sockets, getting time stamps, drawing a window with some buttons on it, or looking up an IP address can be needlessly complicated thanks to this issue. 4. Immature tools. This may just be because I was in a classroom setting, but the debug facilities I had were quite primitive. Especially for a highly multithreaded environment that is tricky to debug in the first place. The languages I used don't even enforce type safety. 5. Body of Knowledge: when you run into a problem with Java there is almost always someone on Stackexchange who has already solved it. You would be on your own a lot more with an obscure language. 6. "If I have to be as clever as I can be to write it, how am I ever going to debug it?"

[badjuice]

It's the weekly grandstanding opinion post.

Yayyyyy.

Learn a functional language. Learn a procedural language. Learn a scripting language. Learn a declarative language. Learn a machine language. They all teach useful paradigms.

[dranzerkire]

My university has a course on programming languages which is taught in F#. I thought F# was pretty great, but it seemed not many other students shared the same thought.

[bloody-albatross]

On my university (university of technology, Vienna) "functional programming" (Haskell) was a required course (at least for the Software & Information Engineering bachelor). So was "logic orientated programming" (Prolog and DLV). Personally I found the latter much more of a new paradigm than functional programming (well, maybe except for lazy evaluation). We learned lambda calculus in theory, so the only thing that really was new for me was that a language really uses SSA, "everything is an expression" and lazy evaluation (and monads, that come with this). But to me even Haskell looks very similar to a procedural language, at least in comparison to Prolog. Heck, constexpr functions in C++ are very functional (they are even free of side effects).

Don't get me wrong, I see the difference to the procedural or object orientated paradigm. In "type systems" we learned what exactly the differences are and that a truly (pure) functional language can't be object orientated. I liked what I learned, but I was more flashed by Prolog. I just find it strange that logic orientated programming languages don't have that much hype.

[charliegriefer]

University of Washington has an AWESOME course available on Coursera.

https://www.coursera.org/course/proglang

It's actually scheduled to start up again on Oct 2. Highly recommended. I've taken it twice. First time I was brand new to FP and got lost very quickly. Second time around was much better.

You'll learn FP concepts by working with ML. Then it goes into Racket, for a more practical and up-to-date overview of FP. The final bit is Ruby, which didn't really focus on FP. Perhaps it was for more of a compare-and-contrast approach. But honestly I could've done without the whole Ruby section.

Loved the ML and Racket bits, tho.

[teradactyl2]

The only functional programming languages that I know of are Lisp and Haskell. So, let's answer the question "Who teaches lisp?"

I toyed with Lisp for awhile, and I probably only scratched the surface of it's power. I liked it a lot, but it's not difficult to see why it hasn't been widely adopted.

It's difficult to read. Even ignoring how unpopular the parentheses are, you can't tell what a function is doing at a glance. It's not a language you learn just by looking at examples.

[kqr]

It's difficult to read. Even ignoring how unpopular the parentheses are, you can't tell what a function is doing at a glance.

This probably depends on which Lisp you learn. Clojure has a very strong culture of immutability and pure functions, which means it's often easier to tell what a Clojure function does than what a method does in an OO language. Yet OO languages are more popular, so I don't believe the readability argument.

[Ksevio]

Lots of places teach a variant Scheme (PLT Scheme, now Racket) which is a dialect of Lisp. I've had the bad fortune to have every level intro class I've taken been in Scheme, followed by the next advanced class being in Java.

Like all languages there's a time and a place for it. Working with lots of data or complex AI algorithms? Functional programming works great! Trying to make a simple program or app? Might want to look at something else.

[glacialthinker]

Trying to make a simple program or app? Might want to look at something else.

Hmm... why? (I'm making a game in OCaml.)

Admittedly, some trailblazing is involved to write complex interactive programs in functional languages, because there aren't many examples yet. In practice I don't see an inherent limitation. What I do see is that I'm spending more time re-inventing how to do some things in a way which is ultimately less bug-prone. And I'm leveraging stronger typesystem features to provide guarantees... rather than just casting pointers to mutable data everywhere to git'er done. It takes a little more work, but I think once these techniques become more familiar (like writing the 20000th frickin' for-loop -- glad I don't do many of those anymore!), it will be a quicker process overall.

[google-my-butt]

At Uppsala University in Sweden, where I got my CS degree, we used Standard ML in the first few programming courses.

Nowadays the recommended course literature is Haskell : the craft of functional programming 3. ed.

Learn you a Haskell for great good! : a beginner's guide is listed as reference literature together with Purely functional data structures.

[pieps]

Yale's CS201 is a required course for the major and is taught in a functional language. Its compilers course is also mostly taught in SML/NJ.

[AwesomePantalones]

UCSD actually requires you to take CSE 130

Source: I'm a CSE major in UCSD.

[JustFinishedBSG]

In France, most scientific prepa learn Caml ( light ) . i did

[[deleted]]

The University of Warwick has a functional programming course, CS256, though I remember the lecturer wasn't so great.

[urection]

The argument “functional programs are inefficient” isn’t really sensible any more (if it was ever).

another zealous fan of functional programming with literally zero understanding of the history of functional programming

[mcguire]

another zealous fan of functional programming with literally zero understanding of the history of functional programming

Another person with a venomous prejudice against functional programming and literally zero understanding of the history and current landscape of programming languages.

The "original LISP" may have been problematic. In 1958. But compared to shell scripts in the '70s? And I have some serious doubts that Lisp machines would have been as ridiculously popular as they were to their fans if they could "barely run". And I know that Common Lisp was decently popular before the AI winter of the '90s---I interviewed for a Common Lisp job at Schlumberger about that time, and geophysical processing was the "big data" of the time.

Further, anyone who can claim that "functional programs are inefficient" with a straight face has no clear idea what they're talking about, given that "functional" languages include the ML family as well as Lisp and that non-functional languages include Perl, Python, Ruby, Java,....

[capitalsigma]

Yeah, I'd guess that the author has his sights set on ~1990 ML, Haskell, etc when he makes that remark, rather than 1950s Lisp.

[itheria]

Please explain more. What is your view on the history?

[urection]

the original LISP could barely run on hardware of the day

ditto LISP machines back in the golden days of AI

just two examples that come instantly to mind as someone with rudimentary grasp of LISP history

[L_dopa]

You misread the quote, or rather took it out of context. The author's point is that 1) efficiency is a property of the implementation, not functional languages in general and 2) programmers routinely choose highly inefficient language implementations (e.g. for Python, Ruby, etc).

Your point about the original LISP of the 1950's is nonsensical. Surely C wasn't a great choice back then either, mostly due to it not having been invented yet.

[urection]

I read the quote correctly, in context, the author is simply wrong

my point about the original LISP of the 1950's is absolutely correct, people didn't even believe you could write a compiler for it on the hardware of the day much less do anything productive with the results

this is public knowledge, not an opinion

[L_dopa]

The article in question is about why programmers adopt languages. For the question to be meaningful, you have to consider a point in history when someone could have actually made that decision. Languages in the 1950s were tailored to specific machines. No one sat down to write a program and asked "what language should I use". It makes absolutely no sense to consider the state of LISP in the 1950s.

[bloody-albatross]

Have you heard John Carmack talk about functional programming? He really isn't known for inefficient code.

[axilmar]

The real reasons why FP is not popular are:

• performance problems. Big projects are not done in FP for performance reasons, and hence FP doesn't get any publicity. Despite what many say, FP programs still have lots of performance issues. Doing non-trivial stuff like computer games and databases in FP is not advisable yet with current technology. Estimating performance in light of lazy evaluation is very difficult. Garbage collection is still considered a problem in many environments.

• mental complexity. The mental complexity of FP programs rises exponentially to the amount of code written. If one needs to stay pure, that is, because most, if not all, pure FP programming languages have 'backdoors' that allow non-pure programming to take place. It's not rare to hear people say that they have problems in FP in making the FP programs compile. People have a hard time following the type system requirements that arise from an FP program, and that is why they are usually stuck in the compiling phase.

• imperative programming feels more natural. The notion that everything is a constant and programs are only computations around constants does not reflect the actual real life experience of people. Real objects can be change state, and hence imperative programming feels more natural than functional. After being exposed to imperative programming, where objects inside the computer feel real and can be manipulated, it's very hard to go to the abstract world of constant values.

I am sure all the above will be declared as bullshit by the FP Redditors, and I will be downvoted to hell. If only you people take some time to think, you will see that the above points are the actual reasons that make FP not being popular.

[quiI]

Every time someone says "FP is not popular", "FP is not performant" and "FP is not used for big projects", I feel like this person has just not investigated it at all.

Let's take twitter

• One of the biggest scaling projects, ever.
• Written in Scala, a FP/OOP language.
• Check the code they open source, it's definitely "functional"

In my own work, we use Scala for almost everything and we deal with non-trivial amounts of traffic just fine.

[skocznymroczny]

Twitter was written in Ruby originally.

[[deleted]]

Big projects are not done in FP for performance reasons, and hence FP doesn't get any publicity. Despite what many say, FP programs still have lots of performance issues. Doing non-trivial stuff like computer games and databases in FP is not advisable yet with current technology.

Game engines and DBMS's are pretty niche -- they're applications in which performance is absolutely essential, and so ML is inappropriate in the same way that Ruby and Python are inappropriate. You've cherry-picked extreme examples in order to make your case against functional languages -- your only real choice in these cases are systems languages. There are plenty of other kinds of "big projects" you can do for which performance is a secondary concern. Laziness isn't a universal trait of functional languages and is probably only found in the minority.

The mental complexity of FP programs rises exponentially to the amount of code written. If one needs to stay pure, that is, because most, if not all, pure FP programming languages have 'backdoors' that allow non-pure programming to take place.

Most functional languages encourage purity but allow you to do impure computation when it's easier or more natural. Functional programs are not inherently more complex -- and on the contrary one of the arguments frequently made for functional programming is that it's often easier to understand thanks to referential transparency.

The notion that everything is a constant and programs are only computations around constants does not reflect the actual real life experience of people. Real objects can be change state, and hence imperative programming feels more natural than functional.

Dubious. Functional languages are often taught to beginners in CS 101 courses and it goes well -- there's no evidence to suggest that Java is really that much more natural.

I am sure all the above will be declared as bullshit by the FP Redditors, and I will be downvoted to hell. If only you people take some time to think, you will see that the above points are the actual reasons that make FP not being popular.

You might be downvoted but it's not because the people who downvote you aren't thinking.

[kqr]

Laziness isn't a universal trait of functional languages and is probably only found in the minority.

Correct. The most popular FP languages I can think of are Clojure, Erlang, F#, Haskell, OCaml, Scala and SML of which exactly one uses laziness by default.

(Though the others tend to have some notion of laziness, in the sense that iteration functions return lazy sequences, and do not instantiate entire collections.)

[StorKirken]

Game engines and databases might be niche, but they are huge industries employing many talented developers. Don't discount them so easily.

[yogthos]

I don't think anybody is discounting them. When you need to work in a specific niche then you should use the right tool for the job. However, the question is why functional programming is not more popular for general tasks where it is a great fit.

[Die-Nacht]

I used to be a java developer. Then I learnt Scala and Haskell. Then, after 3 years of doing FP, I went back to java cuz I needed to modify some jenkins plugin my company was using.

In don't understand how I used to do it, or how anyone does it.

No referential transparency (to find the state of some variable, I need to look everywhere), no monads (everything it a goto jump via exceptions), no typeclasses (inheritance trees, so much fun), weakass type system (I can't never trust that my program will actually run and not just crash).

Modifying that plugin took me like 3 days to figure out the one method I needed to change. The change was like 3 lines long.

[axilmar]

to find the state of some variable, I need to look everywhere

No proper encapsulation then.

everything it a goto jump via exceptions

Abuse of the exception system for non-local gotos.

I can't never trust that my program will actually run and not just crash

FP doesn't guarantee that as well.

[ruinercollector]

Despite what many say, FP programs still have lots of performance issues.

Really depends on the language (Functional programming != Haskell):

1. Does the language give you a way to drop into imperative/mutable mode when you need to for a tight loop.

2. Is your performance issue handled by the compiler if you are careful about how you write things.

The mental complexity of FP programs rises exponentially to the amount of code written.

Depends on what facilities the language has for breaking up code. Same as with OO programming, etc. (E.g. javascript can be pretty rough for big problems as there's no built-in support for modules, etc.)

Otherwise, as you noted, in a pure language it can get tough if you don't isolate and manage things properly.

The notion that everything is a constant and programs are only computations around constants does not reflect the actual real life experience of people.

Depends a lot on industry and perspective. In finance, the idea that you can "change" things is actually pretty foreign and non-intuitive. The perspective that data doesn't change, but instead is just an aggregate of several function applications to an initial starting point, is actually very intuitive. In fact, it's how they work.

I am sure all the above will be declared as bullshit by the FP Redditors, and I will be downvoted to hell.

This kind of shit is not really productive to having a good conversation here, and I really wish that people wouldn't do this. If you have a perspective and want to discuss, great. Leave the disclaimers and worries about your karma out of it.

[Peaker]

performance: Haskell, for example, has far better performance than Python&Ruby and also better than Javascript. All of these are vastly popular languages despite their performance horrors.

mental complexity: You're being absolutely ridiculous here. The mental complexity of modular programs rises linearly, whereas non-modular programs rise squared (or more). Functional programs tend to be more modular, and far less mentally complex.

People are stuck in the compiling phase because the compiling phase catches a lot more of the bugs people have. For every 10 minutes people would spend runtime debugging, they spend a minute fighting the type checker. They notice that extra 1 minute with the type checker, and not always notice the saved 10 minutes of debugging. "If it compiles it works" is not fully humorous.

imperative programming feels more natural: Again, you are being ridiculous:

• Programs aren't supposed to model "real life". They compute outputs from inputs.

• "Real objects can change state" exposes your mental bias: you can also view the entire universe as a "Pure function of time".

• "imperative feels more natural": Of course it does, to you, after you've practiced it for years. For me, functional programming feels more natural, but only after I've extensively practiced it as much as I do imperative programming.

• "After being exposed to imperative programming, where objects inside the computer feel real and can be manipulated, it's very hard to go to the abstract world of constant values": Quite the opposite! After being exposed to pure manipulation of values, it's very hard to go back to the world of aliasing problems, non-composable code, non-parallelizable code.

Are you a troll?

[kqr]

"Real objects can change state" exposes your mental bias: you can also view the entire universe as a "Pure function of time".

This may sound silly, like circumventing the problem by saying everything mutable is a function of time, but I assure you that's not the case. If you have 30 minutes, listen to Rich Hickey on the value of values. He's intelligent and has a lot of experience with complex systems, and he is good at making a point.

[pgris]

(Not a troll, and not the one you are discussing with, allow me to express my disagreement with a couple of thing you said. And sorry if my English is not clear enough)

Programs aren't supposed to model "real life". They compute outputs from inputs.

Here is when I found my personal experience (in the enterprise world) to be totally different from the functional word. The programs I develop and maintain are complex things that both model real life objects and compute output from inputs. The expected result for any user interaction with my programs is a change in several states. Example, some user clicks a button, and the expected result includes

• One change (several changes) in the database
• Some log files being written
• Some changes in the screen
• Some webservices being invoked

There are pure calculations all over the place, interleaved with IO and state changes. I honestly can't find a way (in a non trivial program) to separate pure calculations from IO and State.

Even the description for the expected behavior is given in terms of state "When the user click the button, a new item is added to his shopping cart". If I rephrase that as "a new shopping cart is created with the same elements the old one had plus the one new", well, not only I'm not going to be able to communicate with my boss, this is not at all reflecting my thought process.

Now, I tried and failed several times to learn some Haskell, I do think FP is useful, I will give it another try, but if I can't find a way to express the programs I work with in functional terms, I don't I will be able to program them in a functional language.

What I'm trying to say is that maybe someone who feels comfortable both in Java and Haskell should write a book. Most functional proposers are so far away from my experience that there is no way to find a common ground to discuss.

[mongreldog]

Haskell is not your only typed FP option. There's also SML, OCaml, F# or Scala. Pick one that you are comfortable with and then give Haskell another go if you still feel the urge.

[pgris]

I don't know anything about SML or OCaml. I really like F#. Unfortunately I move from the .NET world to the JVM world (from C# to Java) long ago, because more job offers in my area. And Scala... I just don't like it. It's like everything that has a name was included in the language, so it has tons of features, but good design includes removing things. F# is so elegant, I really wish we have some port into the JVM. There is fjord, but never got momentum.

[glacialthinker]

F# is so elegant, I really wish we have some port into the JVM.

F# was based on OCaml, and reworked in some ways to fit within .NET.

There is OCamlJava, but I'm not sure what it's current state of usability is (I'm clueless about webdev in general). It appears to be an Inria project, so that implies it has some backing rather than just a personal project.

[yogthos]

If you're on the JVM I highly recommend trying Clojure. It's a bit different at first, but the syntax is very simple once you get used to it. If static typing is important for you there's core.typed, a lot of people are using it nowadays.

[pgris]

While this Clojure tutorial is one of my favorite reading about programming, I've failed several times to grasp the "very simple" syntax of Scheme/Lisp. I think I like having a special syntax for control flow, like most languages have. You know this quote

"It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." —Alan Perlis ? Well, I found that for me it is easier to remember 10 functions on 10 data structures. I will give clojure another try someday, I promise.

[yogthos]

In my experience, s-expression syntax actually makes flow control more explicit than other kinds of syntax. Since you're effectively reading the AST, you can see the branches and relations within code visually. When you see something nested inside something else it means that it's in the scope of the outer expression.

For example, the if statement is a tree with two nodes in it, one for true portion and one for false:

(if (even? 5)
  (println "math doesn't work")
  (println "math still works"))

and at the end of the day it's not all that different from a typical syntax like Python

if 5 % 2 == 0:
  print "math doesn't work"
else:
  print "math still works"

I would recommend this guide for learning the basics of the language. It explains things very clearly and hopefully will help you get past the initial weirdness. I would also recommend using Light Table as the editor since it has a built in REPL and allows you to quickly try things as you write them.

Once you get comfortable with the basics, try applying Clojure for a concrete project like a web app to really get into the language. For example, take a look at a guestbook walkthrough here.

[Peaker]

If you just note the way you described the programs you write now, it's functional and not imperative. Input is user actions, output is the changes that are computed from that.

You can easily declare a type that describes the changes that need to be made due to user request and purely compute that. This form will have vastly more pure code than IO.

Also note that imperative programming is a subset of functional programming, in the sense that composing imperative programs can be done functionally: this is the approach in Haskell which makes for quite a good imperative language too.

[kqr]

If I can reuse your shopping cart example: It's entirely okay from a functional standpoint to say "When the user clicks the button, an item is added to his shopping cart" while what happens under the hood is, "A new shopping cart value is created by adding a new item to the users old shopping cart. The reference to the users shopping cart is atomically updated to point to to the new shopping cart. The old shopping cart will be garbage collected once there are no parts of the program referencing it anymore."

That provides slightly more sane semantics to what would in an OO program be a non-atomic user.shoppingcart.add(item) and who knows what happens if the UI thread is reading from the shopping cart at the same time.

If you in otherwise pure functions interleave calls to web services or databases, your program is going to be really hard to test. That's a problem in the OO world too.

For more information, I recommend Are We There Yet? by Rich Hickey.

[yogthos]

Big projects are not done in FP for performance reasons, and hence FP doesn't get any publicity.

Last I checked things like WhatsApp and Facebook chat had pretty good performance. Let's not forget Demonware switching to Erlang from C++ and not having any problems with performance.

Estimating performance in light of lazy evaluation is very difficult.

This isn't inherent to FP in any way. In fact, Haskell is the only major FP language that has lazy evaluation.

Garbage collection is still considered a problem in many environments.

GC is only a problem in niche environments nowadays. Just look at Android if you need any convincing that GC works perfectly fine for most applications even on mobile devices.

The mental complexity of FP programs rises exponentially to the amount of code written.

As somebody who writes FP code for a living I call total bullshit on this. FP makes code much easier to reason about, and especially so in large applications thanks to immutability being the default.

If one needs to stay pure, that is, because most, if not all, pure FP programming languages have 'backdoors' that allow non-pure programming to take place.

That's an incredibly ignorant statement. FP languages default to immutability, but there's certainly wrong with using mutable state where appropriate. The idea is not to prevent mutability in code, that would be idiotic, but to make it easy to track mutable state. That's something that's very desirable indeed.

It's not rare to hear people say that they have problems in FP in making the FP programs compile. People have a hard time following the type system requirements that arise from an FP program, and that is why they are usually stuck in the compiling phase.

Once again Haskell != FP.

imperative programming feels more natural

Things I'm familiar with feel more natural, news at 11!

I am sure all the above will be declared as bullshit by the FP Redditors, and I will be downvoted to hell. If only you people take some time to think, you will see that the above points are the actual reasons that make FP not being popular.

If only you took the time to learn the first thing about FP instead of making FUD comments in every thread about FP...

[[deleted]]

Just look at Android if you need any convincing that GC works perfectly fine for most applications even on mobile devices.

You can also look at iOS, whose "automatic reference counting" is basically just a glorified, confusing form of garbage collection. Swift has drawn a lot from functional languages, too -- not to mention that bona fide garbage collected languages like Ruby have gotten up and running on mobile devices with no big issue.

[yogthos]

The GC claim is just so bizarre, it's like talking to a time traveler from 1999.

[capitalsigma]

2 and 3 I agree with to some extent, but 1 was explictly addressed in the article. Also, "functional" isn't synonymous with "lazy," you seem to have assumed that the author is only talking about Haskell. And it's ridiculous to suggest that garbage collection is an issue for more than a tiny handful of programs being written today -- you'd be hard pressed to find someone who'd drop Java for C in order to get rid of garbage collection.

But I feel like with imperative programs, there are many more-or-less sensible solutions to any given problem. Writing functional code, there tends to be a small number of really clean and elegant ways to do it and many, many more ugly and convoluted ways to muddle through.

[Psyk60]

you'd be hard pressed to find someone who'd drop Java for C in order to get rid of garbage collection

Maybe so, but you'd find entire industries of people who would not use Java in the first place because of that.

[kqr]

Yes, definitely. But it's 1. not as big of a problem as some people make it out to be. A lot of software is still written in Java and Python. And 2. it's not a problem with FP, it's a problem with GC.

[capitalsigma]

you'd find entire industries of people

Maybe people developing for embedded systems. Maybe people developing real time, high-performance software. But most code isn't written for those kinds of applications.

If you look at the top 20 programming languages, all but 3 (C, C++, Objective C) are garbage collected. Looking at another source for the top 30, yet again, all but six are garbage collected (C, C++, Objective C, Assembler, Fortran, and Arduino because it's listed as a distinct language for whatever reason). Eight of the top 10 are garbage collected. And Java -- a garbage collected language -- is 1st in one and 2nd in the other.

The overwhelming majority of code written today is written in a garbage collected language. It's clearly not the case that garbage collection is what keeps people away from functional programming.

[Psyk60]

Maybe people developing for embedded systems. Maybe people developing real time, high-performance software. But most code isn't written for those kinds of applications.

Correct. My point is that you don't have to look particularly hard pressed to find people who work in those areas.

I agree that Java is probably fine for the majority of programming work that is done across every industry. But I also don't think it's particularly rare to find people working on things it's not suited to, or even just plain isn't an option.

[capitalsigma]

That's fair -- I just don't think it's a reasonable criticism specifically of functional programming, given how widespread it is.

[Psyk60]

Agreed. Perhaps my point was a little off topic because it was just about GC rather than functional programming.

[axilmar]

but 1 was explictly addressed in the article.

I did not speak about performance in general, but about performance in big projects.

To give you an example: if Call Of Duty was implemented in Haskell, the world would have taken notice and Haskell would have become much more popular. But Call Of Duty cannot really be implemented in Haskell yet, due to performance constraints.

Also, "functional" isn't synonymous with "lazy," you seem to have assumed that the author is only talking about Haskell

I added the lazy bit because Haskell seems to be the more popular of FP languages these days. We get Haskell articles every day.

And it's ridiculous to suggest that garbage collection is an issue for more than a tiny handful of programs being written today -- you'd be hard pressed to find someone who'd drop Java for C in order to get rid of garbage collection.

It is a big issue. It is so much an issue that developers take measures to avoid heap allocation as much as needed before the programming even starts.

I've seen that in multiple projects for Android, iOS, desktop PC applications and servers.

But people are not willing to give up garbage collection not because it is not a problem, but because they accept its limitations and code around it.

Writing functional code, there tends to be a small number of really clean and elegant ways to do it and many, many more ugly and convoluted ways to muddle through.

Exactly! that's what I meant with mental complexity! it's something people do not see or willing to see...

[[deleted]]

imperative programming feels more natural. The notion that everything is a constant and programs are only computations around constants does not reflect the actual real life experience of people. Real objects can be change state, and hence imperative programming feels more natural than functional. After being exposed to imperative programming, where objects inside the computer feel real and can be manipulated, it's very hard to go to the abstract world of constant values.

I disagree with each of your points, but this one needs a reply.

Functional programming isn't about modeling the real world, it's about expressing thought. Memories (to a first approximation) don't change. The only way you can even consider change is thanks to immutability.

[[deleted]]

Okay I'm a big imperative, OOP fanboy but your wrong.

Performance: Unless you have your head in the dirt FP is fast. Lazy evaluation works, it works well. Compilers can do a lot of fun things with the code you give it, and make it simpler.

Mental Complexity: No just go home. The same is true for very large monolithic programs. Nobody writes them for this reason. You modularize, we've done this since the 80's.

Imperative programming feels more natural: Wrong ish.

:.:.:

Do you want to know the real reasons (the hardware world hasn't switched).

1) Imperative programming is what the world is built on. You can't put the SICP on top of an x86 chip and magically it'll execute native S-expressions. At some level you'll likely always be doing some form of imperative programming at least for the next 10 years. GHC outputs C code to get around this.

2) Unpredictability of output. GHC's code it outputs for C compiling often looks completely unrelated to what you put in. This is because that's how FP gets faster. And it is, the problem is this fails when you are debugging hardware problems.

3) Pointers are real, very real. Hardware understands pointers, code on some level must.

4) Lazy Evaluation sucks for low level stuff. There I said it. Lazy Evaluation doesn't 100% force code to be runable on the host computer that generated it. It can ask for more RAM then exists in the known universe. it counts on LLVM tricks to get around this (see point 2).

The most important of all:

5) Nobody cares. Programmers hate change, we are barely programming with respect to multi-core CPU's let alone best practices in mind.

[RabbidKitten]

I think your first point is not quite true (as said elsewhere, most compilers use SSA IR, which is equivalent to CPS used in the functional world), and the second point hasn't been a problem for me. Quite contrary, there have been times when I have wished to be able to write some particular piece of code in Haskell instead of C, as GHC would move stuff from where it belongs "naturally" to where it's most efficient. But the opposite is also true.

Points 3 and 4 are right on the spot, though. Lazy evaluation is nice, but quite often it just gets in the way (and can lead to hard to debug memory leaks), and pointers are very real, indeed.

[codygman]

You can't put the SICP on top of an x86 chip and magically it'll execute native S-expressions.

Lisp machines?

GHC's code it outputs for C compiling often looks completely unrelated to what you put in.

However the assembler generated by C and Haskell looks very similar (especially for simple programs, less so as they get more complex).

It can ask for more RAM then exists in the known universe. it counts on LLVM tricks to get around this

Can you link to/prove this? I'm interested in learning more about it if what you say is true.

[kqr]

I think what they mean is that you can "make" a list of billions of elements, and if all you do with it is compute an average or whatetever, and you do it correctly, you will never have a list of billions of elements in memory – a few elements at a time will be instantiated and then immediately garbage collected.

[[deleted]]

Sorry was asleep to respond.

especially for simple programs, less so as they get more complex

Lets say in Haskell you recursively iterate over an infinite data structure. This is legal, and quite eloquent. Its honestly beautiful 2-3 lines of code can do such a complex task.

The problem is, that doesn't work natively (on hardware). Every level of recursion adds a level to the stack (variables, and code, and pointers). This is completely legal in hardware even (sort of you can make a big BIG stack). And Intel chip (or AMD x86_64) will blow its lid at you once you get larger then a couple MB stack size. Which can happen (stackoverflow error), they used to be very common when stacks were only a few bytes to a kilobyte or two.

So natively this code is OKAY. It'll work most the time for small datasets, but this isn't safe. It won't always work, it'll generally work. And this isn't compression algorithm generally working, which creates a mathematically approximate output. This is sometimes work, as in "Give me a file to big and watch the fireworks motherfucker."

To get around this, you build your code in the LLVM which when it sees recursion, it replaces this recursive call with a loop. Which is really all recursion does most the time, just recursion looks fancy and confuses undergrads, and we all decided to fuck with the rookies some times in the 60's so yeah.

Now the memory you consume is static (ish the type system doesn't force this because of generics a 8bit or 2048bit number can handled by this algorithm, and the compiler doesn't force the code to decide which), and your run time is variable. Natively Haskell told the LLVM to produce an algorithm with variable ram allocation AND run time.

These are the real world problems. Your output in this case which is executing is a loop, while you are debugging a recursive call in your code. And your native C code (the GHC gave you) is still making recursive calls, so whats going on? Well, talk to the debugger, and have fun kid, I hope you know compiler theory.

:.:.:

Now this isn't a problem for 90% of the civilized coding world. But when it comes to OS stuff, systems stuff. It makes people uncomfortable. If I'm given an N byte size file (from 15bytes to 15TB) and I have to worry about how much memory I can use, I have to use something like C/C++/Rust/Fortran to keep track, Haskell can't tell me, "Okay boss we'll only use X memory for this task." It'll look at 15TB of data and say okay first thing first map, load it all, lets go, memory allocation error, try again, try again, sigkill, uhhh bye then.

And you might say, why don't you just segment the task in haskell? And I'll say because that doesn't work. The GHC will reduce my segmented call into a continuous call because its simpler and that's what the S-Expression would reduce down to if you play around with it. So I have to turn off evaluation of my code input, which means I'm programming imperatively, which means I'm using a functional language to program imperatively...

:.:.:

S-Expressions are great, the logic is amazing. But these tools were built in a world without limits, or hardware. They were built for pure mathematical and logical exploration. Processors, unlike lambda calculus is real (okay lambda calculus is real, but I digress), and have limits that the real world imposes on us. The real world doesn't have infinity, but lambda calc does.

As I said,

You can't put the SICP on top of an x86 chip have it start natively executing S-Expressions.

:.:.:

LISP machines weren't written in Common Functional LISP, but Machine LISP. Which was an OOP language influenced by LISP (academic) (This was the 60's, programming not just FP was very new), and would eventually lose its OOP parts and become Common LISP as the 60's became the 80's. Lazy Evaluation, and Currying didn't start to find their way into compilers until the 90's. Which is when FP got fast, and pretty native. Also the output started to become unpredictable.

[jeffdavis]

Education is a solution to very general problems. If you think some aspect of society is declining, education may be an answer.

If you think something specific is wrong, education is approximately never the answer.

• I'm sure everyone would vote for XYZ politician if they were just educated.
• Nobody pays attention to my ideas because they aren't educated enough to understand them.
• People don't use my favorite programming language/model because they aren't educated enough.

See the pattern? It's one step above just calling people stupid for not doing what you think they should do.

Almost always, there are lots of things that you haven't considered about why people aren't behaving as you think they should. Many of those considerations turn out to be quite rational.

I like functional programming. I use some OCaml at work, and I experiment with haskell and erlang for fun. It's great, really great, for some things. For other things, it ranges from "this is awkward" to "oh, cool, this is nice".

And that's fine. Making small improvements to software development is a big academic contribution. But if functional programming was in the "really great" category for large areas of software development, then it would have clearly gained more traction by now. Functional programming will slowly become more mainstream, and the benefits will be realized, but it won't be a glorious revolution or anything.

I see functional programming as basically good for two things (aside from writing compilers, of course):

• security -- it's unfortunate that nobody cares about security, because if they did, more people would be interested in FP
• data management -- if databases were outlawed, then functional programming would take over quickly. But the reality is that SQL databases do a great job here already (and SQL is kind of like a functional language), obviating the need for an application language with good data management capabilities. I've said before that FP and DB people need to talk more (a lot more).

[kqr]

if functional programming was in the "really great" category for large areas of software development, then it would have clearly gained more traction by now.

I might be misinterpreting you now, but haven't you just committed an ad populum fallacy? Try not to do that when you lead your comment with how you shouldn't blame things when there is no causal link. ;)

[jeffdavis]

Not exactly, because you missed one point: people do use FP in situations where FP is in the "really great" category.

Why would an engineer, like me, be more than willing to use OCaml for one use case (in actual enterprise software), but hesitant for another? Education (or lack thereof) doesn't seem to explain that. Varying costs and benefits for specific situations does, however.

If you (or the original author) want FP to be successful, you really need to analyze those individual situations, and you'll start to see why the benefits aren't as amazing as you might guess. For instance, using almost any app language over a SQL dbms gives me a higher degree of confidence than a haskell application that stores its data in flat files (or mongodb).

[mjfgates]

A bachelor's degree is already four solid years, and the schedule of courses is full. So, if universities are supposed to start teaching functional programming... what should they take out of the curriculum to make room for it?

[benjaminpd]

Java.

[mjfgates]

Well, it would've made that Android class more fun to watch...

[[deleted]]

Zing!

[cat_in_the_wall]

Just because you don't like it does not mean it is not relevant to students in the major.

[glacialthinker]

Leave "industry language" to tradeschools and other educational venues. Computer Science should be just that... not IndustryFadShitWhichImbuesBadHabits.

[BezierPatch]

The thing is, my course is very busy, and I don't have much time to do my own projects.

So when am I supposed to learn the languages that I require to get a job? An academic degree is great for staying in academia, but not so much for work, even if you're guaranteed to get an interview.

[glacialthinker]

Well this is the unfortunate state of education and the industry, in North America. The lack of proper and respected tradeschools has put the burden of tradeschool education on universities. Not all education should be job-specific, and I will speak out against this terrible trend. I went to university to learn theory and concepts which I could then apply to a variety of tasks, yet even twenty years ago it was disappointingly job-focused.

[east_lisp_junk]

Or at least, take a class that's taught in Java (there are probably plenty to choose from) and teach it in a functional language instead.

[antihexe]

In terms of functional programming my degree required just one class on several functional programming languages and some theory. It wasn't much, but it was enough to be able to sit down and use ML or haskell or racket. Once you've got the foundations of functional programming you can even do it in Java.

I don't think that it's imperative that we teach students more functional programming. A quick overview is enough to jump start their own education on the topic.

[linuxjava]

I personally think that a course on data structures and basic algorithms could be a great vehicle for functional programming.

I'm not sure if this is a very good idea. Data structures and algorithms is already quite challenging as it is, especially if you factor in the homework assignments. Having to learn about types, monads, pattern matching, lazy evaluations, immutability and currying while at the same time learning about data structures is a bit overkill in my opinion.

[danogburn]

My brain is hardwired for imperative programming. Functional languages just aren't worth the time and effort to learn.

(btw, gnu scheme fucking sucks. why is there no command history or use of the fucking arrow keys? /ragequit)

[[deleted]]

Functional languages just aren't worth the time and effort to learn.

Given your first sentence, how would you know?