Hacker News Reader

Comment by megaman22 | Hacker News Reader

No. It's a great way to turn people off from the whole idea.

I suffered through a course in Haskell and functional programming in college, and the course material was so up its own butt about monads and type classes and algebraic data types and such, that I essentially wrote the whole thing off as academic flubbery. It didn't help that whatever version of GHC we had then gave off error messages more cryptic than C++ template metaprogramming, and it was such a cluster to have to bounce into the IO monad to just to do some intermediate printf debugging.

It wasn't until years later and exposure to .NET LINQ that it started to click and the motivations for why you would want to use functional programming became apparent.

View on HN

I studied Haskell in college (with the Gofer variant), and it was GREAT for learning practical functional programming.

We didn't use monads though (they weren't in widespread use back then), so we had to learn the accumulator-parameter pattern and tail recursion the hard way.

Learning my foldr's and foldl's and zipwith's gave me confidence that almost any imperative programming can be equally represented as a recursive function, which is an important lesson for someone who had only learned about traditional imperative programming and OOP up to that point.

Of course, a proper course should center around algorithms and recursive data structures where functional programming shines; it should not begin with building business application logic, for which a classic language may have a gentler ramp-up.

If your course didn't cover monads, it was a very introductory one which would have probably benefited from choosing a nicer and simpler language, like antiquated LISP or maybe Scheme.

> antiquated LISP

By that do you mean "Lisp, which is antiquated", or "a LISP which is antiquated"?

Lisp certainly isn't antiquated, but as the second oldest high level language after FORTRAN, there are antiquated versions of it (e.g. LISP 1.5).

Wadler's introductory Haskell course at Edinburgh doesn't cover monads, but it's great. I don't want to use scheme because I want students exposed to a decent static type system. There's an argument to be made for using standard ml, maybe.

I think the fact that strings are linked lists is great for beginners. One of their assignments is on web scraping, where they can reuse all their list based functions to solve the problem.

I am not too keen on Haskell's polymorphism for teaching beginners, and error messages are mostly useless for them. If I were teaching again, I would be recommending custom preludes with simpler types.

It was introductory, yes, although it also covered relational programming in PROLOG.

I benefited from the type inference/type declarations, and learning about generics explained in a non-duck-typing way, though, which I wouldn't have had in LISP.

Hey, can you point to or do you have any of the relational/Prolog programming materials? I dabbled in this years ago, mostly experimenting on my own, would love to see some materials designed for guided exploration.

I'm afraid the material is some handwritten notes in Spanish, interleaved with some code examples in PROLOG. They were quite systematic IIRC, covering basic logic, data structures, proper use of the !bang for performance, etc.

I no longer have the exercises in code, just paper. I've yet to scan my handwritten notes and bring them to the digital era :-) This may prompt me to finally do it.

If you still want them, I can send you the scanned pdf to your mail. However, I think you'd better off with some free online course. On a cursory examination, this one seems similar to the content in my notes:

[1] http://www.learnprolognow.org/lpnpage.php?pageid=online

There were courses using haskell before monads were the smash hit they are now. In particular haskell didn't have monadic IO then. On the other hand, variants such as gofer were pretty simple.

> antiquated LISP

That's debatable. True, Lisp is Old. Hardly antiquated.

I agree, but over the decades LISP developed significant complications, such as object oriented features; I think the most appropriate LISP for an introductory FP course would be a very antiquated and very simple and pure one, without advanced features (and the accompanying syntactic pollution) that might be of interest as advanced theory, useful in advanced practice, but a source of confusion and a major waste of time for beginners.

Fancy LISP variants would still be vastly easier to learn than Haskell, but a straightforward computer adaptation of lambda calculus would minimize the distance between theory and running programs.

I'm not familiar enough with Scheme or Clojure to tell whether they are too complex for an introductory course.

>I agree, but over the decades LISP developed significant complications, such as object oriented features

How can this be a complication? On Common Lisp, you can just choose not to use object oriented features (the CLOS system).

There are many CL libraries that do not use OOP code at all.

And if you want to use them, in CLOS a method is called exactly the same as a function; they are called "generic functions", so the syntax is just the same.

>without advanced features (and the accompanying syntactic pollution)

I don't think there is any syntactic pollution. Again, in Common Lisp the syntax is totally uniform for all the features, in fact for a beginners' Functional Programming course, he/she would only need to learn:

    () parentheses for opening and closing an s-expression
    ; for comments
    ' for quoting an s-expression so it is not evaluated
    #' for indicating that the following symbol 
       is a function name
       (not needed on Lisp-1 languages like Scheme)
    "" for delimiting a string

... and that's it!!

"Advanced" features don't introduce too much syntax either:

    `  for quoting an s-expression in a "template" way
       (i.e. for use in macros)
    ,  for escaping the ` operator
    ,@ for escaping the ` operator, "splicing" the
       contents of a list; for example when passing a code
       block to a macro.

For a language that is really extensive in features, the amount of syntax introduced is minimal, really.

Compare with Haskell.

Of eight special delimiter character you list, three are used for macros. While the syntax of the highly evolved Common Lisp you have in mind remains extremely frugal, macros are only one of many relatively large unnecessary luxury feature.

Teaching fancy language features in an introductory course steals time and attention from fundamental functional programming principles. CLOS, unless thoroughly dissected as an advanced example of how far can you go with LISP, would be an even worse gratuitous distraction than macros.

Of course, "complex" LISP isn't going to be comparable with Haskell, and in a sufficiently long introductory course advanced language features might be worth teaching to increase student productivity.

> I'm not familiar enough with Scheme or Clojure to tell whether they are too complex for an introductory course.

Simple Scheme has been used for decades for introductory courses, both in schools and university.

An even simpler Lisp called Logo has been used with early programming education for kids.

Lots of educational material based on Scheme or Logo exists.

I tried learning Haskell by reading LYAH and doing some of the cis194 course, it was alright, but I was struggling. Then I bought Haskellbook (Haskell Programming from first principles). Took me a while to finish it, but I had a great time doing it. I learned Haskell and was able to jump right into writing my first library with it. And I come from a non-CS background with only a bit of Ruby prior to that. The quality of your learning materials matters a lot.

I'm about ~300 pages into it and it's been really enjoyable. "Pure functional programming without fear or frustration" is so right. I've started to look forward to the couple pages I get through each day after work, it's legitimately relaxing.

It's great but also 1300 pages (and $60, well-deserved).

I enjoyed learning Haskell in an optional advanced course at our uni. The things which I like the most are higher order functions, playing with pointfree, combinator libraries, typeclasses, pattern matching and higher order types.

Only later did I click with monads and some other patterns like phantom types and such.

I think the sad part about learning Haskell is that everyone gets so up about monads while they definitely aren't the most important part but only one of many beautiful and magical parts of Haskell. Maybe if people stopped talking about monads so much and more about other parts of the language would people be way better at learning the language.

> they definitely aren't the most important part

They are that small piece that makes everything fit together and work. If you ignore it, you will have many problems down the line.

Yet, you are right, they aren't all that interesting by themselves.

While I agree that many courses on Haskell are no good ...

>> "up its own butt about monads and type classes and algebraic data types"

Well, those are some of the best things about doing functional programming in languages that can afford them.

>> "I essentially wrote the whole thing off as academic flubbery"

And maybe it was your attitude to the whole thing.

>> "It wasn't until years later and exposure to .NET LINQ that it started to click..."

So seriously, can't you find anything else that changed "years later"? Haven't you changed? Aren't we talking about years of accumulated experience?

Also, .NET LINQ might be a cool example of what you can do with FP, there are elements of FP in it, certainly that's a monadic interface that makes it tick. But filtering an IEnumerable or an IQueryable is as interesting as executing an SQL query.

What have you learned about FP from executing SQL queries? Probably nothing.

Just saying.

Functional languages and strongly typed languages are not the same set. Most functional languages focus on typing (e.g. Haskell, Scala), but there are functional languages that do not (e.g. Clojure, Common LISP). You can easily do functional programming in clojure without using any monad concepts directly (though obviously it’s easy to say “that’s just a monad” in a lot of cases).

IMO the biggest win from functional programming is referential transparency. Automated verification (i.e. type checking) can definitely be useful on larger projects with bigger teams since it’s self documenting. That’s just my personal take on it though - there’s plenty for everyone to like.

You're mentioning Clojure.

Clojure has protocols which are probably inspired by type classes. Just like Clojure's protocols, type classes are a mechanism for ad hoc polymorphism that allows decoupling between data and the functions operating on that data.

Clojure indeed doesn't have monads, but this has to do with Clojure's culture (like all LISPs) of using macros for describing APIs for composing stuff. But those APIs aren't unified and some of the DSLs I've seen do not have a theoretical foundation, which really means they aren't reusable and some of them are flawed.

Due to its evolution and backwards compatibility concerns, some of its design shows its age as well. You can't make operations like "map" work on your own data types because it doesn't have a protocol defined for it.

Don't get me wrong, I actually like Clojure, but that the community is not using types like monads to drive their design is a flaw.

What do you mean by "doesn't have monads?" You just write monads in Clojure. They are only a structural formalism. [1]

If you meant doesn't have the Maybe monad built in... why would you want that tangled up in your data? [2]

  [1] https://github.com/khinsen/monads-in-clojure/blob/master/PART1.md

  [2] https://youtu.be/2V1FtfBDsLU?t=2381

There are two important functional programming concepts absent from most Lisps: currying and lazy evaluation, so if a Lisp is used they'd need to be explained separately. Implementing them in Lisp would be a good way of understanding them.

If you want a more typical functional language without type declarations or monads, there's SASL. It's an ancestor of Haskell, but I don't know of any implementation which runs on modern hardware. Interestingly, SASL was once used to write an operating system.

I would hardly identify lazy evaluation as a core feature of functional programming. It definitely forced Haskell not to compromise on purity but, as SPJ himself has pointed out, that may be the only strong thing it has going for it[0]. Currying is also nice, but I'm still not sure that is _core_ to FP.

What Lisp is really missing from an FP perspective is purity. In fact, maybe a pure variant of Lisp would be perfect for teaching.

[0]: https://www.microsoft.com/en-us/research/publication/wearing...

Purity isn't missing. It's what you have until/unless you introduce/allow impurity into your code.

How can you even teach what purity is, if it is enforced?

"Bad things could happen, take my word for it?"

Isn't Scheme pretty darn close to a pure and clean version of Lisp? Which is why it was chosen as the language of SICP?

Hey hey and what do you know, you can do both in scheme!

ML-style FP (including Haskell) is probably the most blogged-about, although I'm not sure it's the common used style of FP.

Lisps, Erlangs, and APLs all have distinct takes on what it means to be "functional".

For example, J is dynamically typed, permits mutable state, and doesn't really have first-class functions in any meaningful way. But it definitely has a functional "feel" to it (easy to compose functions, almost all operations are side-effect free, etc).

Your arrogant dismissal of a beginners' genuine troubles with a certain programming style is exactly why programmers in general but especially the FP crowd have such a bad rep.

After having my fair share of attempts to teach people and hearing the same flawed arguments repeated online ad nauseam, including the "too academic" classification which ends all reasonable dialog, to be frank, I couldn't give a shit.

If you want to point fingers, I would be more worried about the rampant "anti-intellectualism" going on in this industry, accumulated along with other social problems (other -isms) we are experiencing, like sexism or ageism.

Look, it's fine if you don't understand, it's fine if something is out of reach relative to your current knowledge. And most often than not, the teacher is the one doing a poor job at teaching. There's a big difference in results between good teachers and bad teachers, between good books and bad books, etc. And maybe you don't need the subject in question, maybe you're fine with writing dirty Python scripts, whatever.

But dismissing work of other people as "academic flubbery" is mean and counterproductive and you can't teach people good manners — they should have learned those in their first 7 years of their life.

I'm also not inclined to fight for every beginner, I'm only fighting for those with good manners and if you'd know me, you'd know that I have open source libraries released and that I'm helping users in my free time and at great personal sacrifice. I'm actually putting my time and money where my mouth is and I've never berated anybody for not knowing something, only for being disrespectful.

The disrespectful ones can go somewhere else. I'm fine with having small and focused communities btw, instead of a big and toxic one, because life is too short to take abuse from random folks on the Internet.

I suspect that the complaints of "anti-intellectualism" are too general. Critical-theorists make the same set of complaints. There's a big difference between anti-intellectual and anti-bullshit sentiment.

When bad ideas are dressed up in academic authority, well they often have a hard time outside of academia. That's what "too academic" means. That this could be another bad idea dressed in academic authority and we'd have no way to tell.

> What have you learned about FP from executing SQL queries? Probably nothing.

I would really like to know why you conclude this, because it seems almost certainly wrong. SQL is a great example of a mainstream non-imperative, no-implicit-side-effect language, which is really the essence of functional programming.

Agree. Functional programming made no sense to me until I came back to it after years of writing complex data warehousing SQL.

I am writing SQL/PLSQL for my living and I like how learning Elixir changed the way I accomplish my daily work.

Hmm, I'd argue the essence of functional programming is composability of which SQL has very little.

I would argue that you probably haven't written any SQL of significant complexity in which to observe its composability if that is your assertion. Subqueries, table-valued functions, SProcs that return tables, and more allow you to compose operations into your desired final query.

That said, it is largely used in a giant procedural way most of the time, and is certainly not an ideal functional language, but the fundamentals of things like, map, filter, reduce, sort, etc. are there.

I have written quite a bit of SQL including all of the items you mentioned including common table expressions, subqueries, views, etc..

This is a very limited form of composition. It's very difficult to break a query down into a bunch of subcomponents that can be reused among groups of queries. CTEs are close, but it's really hard to achieve re-usability of a CTE unless you are stitching together strings at runtime.

Probably the closest you could get is a view, but even then if you have many views stitched together to form a query this can impact performance in ugly ways.

Generally in order to achieve the best performance and to get the most of out of the DB engine it seems like producing unique SQL for each query which is optimized for that query is generally the optimal approach.

In summary: Just because SQL is based on a few composable operations (map, filter), does not mean it is composable itself.

This is a slightly snarky but mostly serious response: isn't hidden runtime complexity of elegant operations also a property of functional programming languages? :-)

There are a few that are good at optimization (and in my limited experience, Haskell is one of them), but in general if you use lots of conceptually clean maps and filters, you will occasionally see cases where your performance is very bad because you don't have full control over exactly what is evaluated when, won't you? That seems like basically the same problem that you have with using views and not trusting your query planner to do things efficiently.

I can largely agree with that from a practical perspective - I was speaking more in the theoretical. At any kind of practical scale, everything does seem to end up being fairly bespoke.

With unsafePerformIO you can do printf anywhere. There's also Debug.Trace.

I had the opposite experience, but I used Chris Allen's book instead of a university course. A lot of concepts I had been using in Elixir and even JS did not click until I worked through Mr Allen's book.

Chris Allen's and Julie Moronuki's book, to be precise.

Thanks. Wish I could edit my comment!

I agree. Functional programming should not be viewed as a tuxedo that we dust off and use when we want to be "fancy programmers." It's simply a tool in the toolbox.

The best language for learning functional programming is the one that de-mystifies it. And since you can use many (most?) popular languages to code in a functional style, I'd say, take whatever language the students have been using, and teach them a few functional programming techniques with it.

Totally. A couple books that I've really enjoyed (being somebody that lives in DotNetLand)

https://www.manning.com/books/functional-programming-in-c-sh...

https://www.manning.com/books/real-world-functional-programm...

1000000 times this! I learned FP (Functors, Monads, Applicatives etc. )through Javascript (Dr. Booleans adequate guide) and it was an eye-opener. Still no love for Haskell!

Typeclasses and parametric types are there to leverage the typesystem. It's hard to see how you can benefit from these abstractions if all you have is ducktyping.

Not a genuine answer, but JavaScript has a great ability to inspire respect for type systems, due to that duck typing.

I suppose the GP enforced it manually?

Javascript doesn't support duck typing. It doesn't support any typing actually: it's dynamically typed.

If Javascript can inspire respect for type systems, it's by making you realize that not having type annotations leads to terrible, unmaintainable code.

> Javascript doesn't support duck typing. It doesn't support any typing actually: it's dynamically typed.

Dynamically typed doesn't mean untyped; you still have types in JavaScript. Most dynamic languages are strongly typed, not untyped. You're conflating a few unrelated things. JavaScript is duck typed, as virtually all dynamic languages are.

Dynamic typing isn't lack of typing.

The fact that types cannot be statically checked doesn't mean you don't have any.

Bash only has one type, the string, and is thus statically typed.

Is Bash's type system better than say, Python's ?

Yes, that was my point.

Dynamic typing is a typing. Also, duck typing is used more in the dynamic sense than the static sense, where in the latter it is instead called structural typing.

Those abstractions are about static typing, not functional programming. Functional programming doesn't require static types.

dingdingding! we have a winner

)))

At least you had documentation, books and a community to ask questions from. We had SML which had none of that. I wish we used Ocaml, that at least had something of an active community. Haskell would of been even better.

Reply on news.ycombinator.com