At the University of Edinburgh, they teach first year undergraduates Haskell and Java (Haskell in semester one and Java in semester two).
But I bet that's only because Phil Wadler is there advocating functional programming and Haskell to bits.
Dijkstra on Haskell and Java (2001)
151–160 of 253 posts
Re: Dijkstra on Haskell and Java (2001)
#152Earlier quoted context omitted.
As Brian Beckman explained, as an aside, in "Don't fear the Monad" [1], these two differing views were born in the '70s and split two programmers into two camps: The bottom-up people, and the top-down people: - The bottom-up people start with the hardware and only add abstractions and trade performance where necessary (fortran, c, java) - The top-down people started with perfect abstraction/logic and reduced/removed…
> The bottom-up people [...] only add abstractions [later] I don't think bottom-up verses top-down are like political camps. I think it's more innate, like right-brained vs. left-brained. I can't understand abstractions till I first understand the lower level. I could never learn algebra without first learning arithmetic. (BTW, I'm old enough to have lived through the New Math philosophy which insisted that every gra…
As someone who's strongly in the "top down" camp by observation, I'm about to refute an interpretation of what that means.
Everyone who's learned Haskell really well understands exactly that you learn monads by example, not abstraction. Abstractions need both motivation and "point samples" which describe good reasons for their particular brand of abstract behavior to be meaningful. I don't think at all that the "top down" side actually must work top down, but instead simply values the tools you get when you reach the top, i.e. strong reasoning capabilities and metaphor connections to algebra.
I really want to change the Crockford Monad Curse to instead read that "Anyone who's just learned monads is suddenly incapable of explaining them". When they first "click" you become obsessed with the abstraction as a thing instead of using it as a tool to better leverage patterns which turn up in real examples. Until you shake that by just using monads so frequently that you're damn bored you cannot properly explain them.
Re: Dijkstra on Haskell and Java (2001)
#153Earlier quoted context omitted.
Well the C does stand for computer.
“Computer science is no more about computers than astronomy is about telescopes.” - Dijkstra It was just too relevant in this case...
How much weight would you give the opinion of an astronomer (today) who didn't know how to use a telescope?
Re: Dijkstra on Haskell and Java (2001)
#154I would guess Haskell would be perfect if the goal is to produce academics. But if most of your students are destined for industry, Haskell is in my opinion the absolute worst language. - You'll probably get a high drop out rate because of the complexity (recursion, pure / first class functions etc). - You rely that your students already have experience at high school with imperative languages - The industry by far s…
- The industry by far still don't use functional languages.
Flat-out wrong. The world's most popular language (in terms of lines of code, number of programmers and companies using it) is a functional language: JavaScript.
Re: Dijkstra on Haskell and Java (2001)
#155I would guess Haskell would be perfect if the goal is to produce academics. But if most of your students are destined for industry, Haskell is in my opinion the absolute worst language. - You'll probably get a high drop out rate because of the complexity (recursion, pure / first class functions etc). - You rely that your students already have experience at high school with imperative languages - The industry by far s…
I don't think I could disagree more.
To your first point, Haskell is less complex than imperative languages. You get to functional by removing things from imperative: mutable state, side effects, et al.
To your second point, case studies indicate that it is actually much easier for people who have no prior experience with programming to learn functional languages than to learn imperative ones. They also show that it is easier for novices to learn functional languages than it is for experienced imperative programmers to learn functional languages.
To your third point, the finance industry uses functional languages quite a bit, and almost every mainstream language has adopted some aspects of functional style (at the very least lambdas and map/filter/fold). Further, the historical trend for the past 50 years has consistently been that mainstream languages adopt new features from functional languages, which means that learning those languages will help prepare you for advancements in whatever language you end up using.
Laying a foundation in C is like teaching how to cut down trees in a first class on woodworking. Yes, the lower-level stuff is important to flesh out a thorough understanding of the subject, but it is absolutely not the correct foundation on which to build pedagogically. Following that notion through to its logical conclusion, rather than starting with C you would start with electrical engineering and only move on to programming after the student had built their own computer from scratch.
Re: Dijkstra on Haskell and Java (2001)
#156Ugh, is this a guy who learned his CS from reading Proggit? There's no way you can say Haskell is "orders of magnitude better than Java"; maybe it's better, but it's not that much better.
o_O
No. No he did not learn CS from reading Proggit. http://en.wikipedia.org/wiki/Edsger_W._Dijkstra#Life_and_wor...
Re: Dijkstra on Haskell and Java (2001)
#157My personal opinion - the best languages for learning are script-able, dynamically typed languages like Ruby or Python. You can build very basic programs in a procedural or functional style, and then get introduced very softly into the world of OO.
Haskell is great in some ways, terrible in others. Like the fact that you can't apply a normal function to a monad, and monads are hidden with do Lisp/Scheme are conceptually very simple and easy to learn, but the syntax is hard to follow, and some of the keywords make no sense to someone who's never done any programming.
I personally think Ruby -> Java/C++ would be a great progression, with maybe some SML/OCaml on the side somewhere along the way. I spent way too much time dabbling in various 'trendy' languages like Clojure, Haskell, various Lisps and other FPLs, Ruby and JS/Node, etc... Now I'm at the point where I just want to build things, so I'm using a very practical, OOP, statically-typed, compiled language that many people have already shipped many practical apps with.... Probably not going back to 'trendy' languages.
Re: Dijkstra on Haskell and Java (2001)
#158Earlier quoted context omitted.
Your idea about going from architecture to programming in the other way of traditional curricula, in my opinion, has a lot of merit. Other seem to agree. An Israeli professor, Noam Nisan, created a course specifically for this purpose, now branded even more popularly as Nand2Tetris course and book.[0] Why did he teach something obvious like this? From the site: "Why Bother? Because many CS students don't understand h…
Ironically, all of the software for From NAND to Tetris is written in Java.
It's not that Java is a bad language to write programs in per se (platform agnosticism can be a huge help for educational purposes). It's just a bad language to teach programming.
Re: Dijkstra on Haskell and Java (2001)
#159It's much better to pick something multi-typed and multi-paradigm like C# and be able to show the difference between static and dynamic, imperative and functional, AOP etc.
Re: Dijkstra on Haskell and Java (2001)
#160Earlier quoted context omitted.
It's trivially easy to write perfectly valid looking Haskell programs that are abysmally slow because of how they are actually executed, and since the reason for this can't be explained at a level of abstraction of such a course, people learn to treat the language as a closed black box, while you can't really competently use any language without understanding its execution model. Abstractions are fine, but you have t…
As Brian Beckman explained, as an aside, in "Don't fear the Monad" [1], these two differing views were born in the '70s and split two programmers into two camps: The bottom-up people, and the top-down people: - The bottom-up people start with the hardware and only add abstractions and trade performance where necessary (fortran, c, java) - The top-down people started with perfect abstraction/logic and reduced/removed…
I don't agree. There's many a programmer I know that can troubleshoot a tube radio, then go write some Lisp. Most are old school folks that grew up in the 8 bit days of solder and wirewrap.