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.
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).
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.
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.
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:
That's debatable. True, Lisp is Old. Hardly antiquated.
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.
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
"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.
Compare with Haskell.
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.
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.
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 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.
>> "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.
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.
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.
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=2381If 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.
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...
How can you even teach what purity is, if it is enforced?
"Bad things could happen, take my word for it?"
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).
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.
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.
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.
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.
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.
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.
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.
https://www.manning.com/books/functional-programming-in-c-sh...
https://www.manning.com/books/real-world-functional-programm...
I suppose the GP enforced it manually?
If Javascript can inspire respect for type systems, it's by making you realize that not having type annotations leads to terrible, unmaintainable code.
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.
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 ?
)))
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.