Live data from Hacker News

Dijkstra on Haskell and Java (2001)

chrisdone.com

21–30 of 124 posts

Re: Dijkstra on Haskell and Java (2001)

#21
post #8

I don't see why they don't just teach C, x86, and Haskell everywhere. If you know the concepts behind these, you can quickly grok any other programming language. Also I never got the whole hype behind OOP. IMHO its self explanatory, nothing you need an entire course on to be effective and understand OOP programs. Memory layout and management, advanced pointer concepts and monads are a slightly different matter. If I…

They actually do this at the University of Chicago. That's exactly the introductory sequence.

The first class in the major is in Racket (Standard) or Haskell (Honors).

The second class in the major is in C, and also covers basic UNIX tools.

The third class is in x86 assembly and C, focused on understanding low-level systems.

Re: Dijkstra on Haskell and Java (2001)

#22
Indeed, my first CS class in 1999 at UT was in Haskell. Wow! What a change it was from high school AP Computer Science in Texas, which was (in those days) C++.

Seeing QuickSort in just one line was what hit it home.

I remember thinking at the time that this was really incredible, but that Haskell had no future. This was at the time of Hugs 98, although I remember hearing about GHC. I'm glad to be wrong about this.

Re: Dijkstra on Haskell and Java (2001)

#23

Earlier quoted context omitted.

I am looking forward to the day the notion that functional languages are not suitable for developing software will die. It is not only that functional languages are more succinct, easier to reason about and are more readable, they also often come with significantly better type systems. Some have type systems sophisticated enough to specify nearly all the legal states and guarantee these are the only states the progra…

Neither Erlang nor OCaml bring with themselves the burdens of purely functional programming and the sophisticated type systems that you talk about. You also mentioned Scala and that one too is extremely pragmatic and lets you mix and match both OOP and functional concepts instead of sticking to purely one paradigm. Erlang is dynamically typed and OCaml does not mark side-effects with types and force you into the mona…

> Purely functional programming still remains a purely academic exercise

This is false.

Also, as far as I can see, only you mentioned pure functional programming. Sophisticated type systems do not mandate purity; see Scala for example.

Re: Dijkstra on Haskell and Java (2001)

#25
post #18
post #8

I don't see why they don't just teach C, x86, and Haskell everywhere. If you know the concepts behind these, you can quickly grok any other programming language. Also I never got the whole hype behind OOP. IMHO its self explanatory, nothing you need an entire course on to be effective and understand OOP programs. Memory layout and management, advanced pointer concepts and monads are a slightly different matter. If I…

The problem is, people finish their CS study, and do not have such level of knowledge that they could start working right away. So Haskell might be nice, but is hardly a sought for skill. Sure if students would learn different stuff by themselves, they could learn useful skills too, but most of the students are lazy, and only learn what they have to.

This is the worst attitude. University is not supposed to be vocational school.

Re: Dijkstra on Haskell and Java (2001)

#26

Earlier quoted context omitted.

I am looking forward to the day the notion that functional languages are not suitable for developing software will die. It is not only that functional languages are more succinct, easier to reason about and are more readable, they also often come with significantly better type systems. Some have type systems sophisticated enough to specify nearly all the legal states and guarantee these are the only states the progra…

Neither Erlang nor OCaml bring with themselves the burdens of purely functional programming and the sophisticated type systems that you talk about. You also mentioned Scala and that one too is extremely pragmatic and lets you mix and match both OOP and functional concepts instead of sticking to purely one paradigm. Erlang is dynamically typed and OCaml does not mark side-effects with types and force you into the mona…

There's nothing unfunctional about OOP. The two are not at odds. It's just frustrating when people confuse OOP with imperative programming and concludes that for sophisticated type systems to exist, all the lessons from OOP has to be thrown out. Imperative programming needs, to some degree, to be thrown out if you want programs that are easy for the compiler to reason about, but OOP doesn't.

Re: Dijkstra on Haskell and Java (2001)

#27
I've never formally studied CS, but I can definitely see the benefit. I can divide my own (amateur) programming experience into pre-Haskell and post-Haskell. Before I started learning Haskell, I thought I knew how to use a good half a dozen or more programming languages. After I started learning Haskell, I realised I'd really only known how to use one all along, and that they were all fundamentally the same. I wish I'd had the experience sooner (plus, learning Haskell is just plain fun).

Re: Dijkstra on Haskell and Java (2001)

#28
post #8

I don't see why they don't just teach C, x86, and Haskell everywhere. If you know the concepts behind these, you can quickly grok any other programming language. Also I never got the whole hype behind OOP. IMHO its self explanatory, nothing you need an entire course on to be effective and understand OOP programs. Memory layout and management, advanced pointer concepts and monads are a slightly different matter. If I…

> I don't see why they don't just teach C, x86, and Haskell everywhere

On my university in Portugal back in the mid-90's, we had:

Pascal, C, C++, Caml Light, Smalltalk, Prolog, Java, PL/SQL, x86 and MIPS Assembly

Additionally we also got lots of CS stuff like lambda calculus, relational algebra, language semantics and so on.

It always feels strange so to me that there are universities out there focusing on single languages, or paradigms.

Re: Dijkstra on Haskell and Java (2001)

#29
As much as I love Haskell, one problem with the intro to CS courses is that many of the students are not CS majors, but students from other disciplines that need to learn a little bit of programming. It makes sense here to teach Java and Python, as imperative languages are more useful to real world programming than functional languages.

Perhaps it would be better to create a separate intro course for CS majors. On the other hand, most curriculum in CS demand that students learn about languages like prolog and Haskell, so it's not like students will never be exposed to it.

Re: Dijkstra on Haskell and Java (2001)

#30
post #26

Earlier quoted context omitted.

Neither Erlang nor OCaml bring with themselves the burdens of purely functional programming and the sophisticated type systems that you talk about. You also mentioned Scala and that one too is extremely pragmatic and lets you mix and match both OOP and functional concepts instead of sticking to purely one paradigm. Erlang is dynamically typed and OCaml does not mark side-effects with types and force you into the mona…

There's nothing unfunctional about OOP. The two are not at odds. It's just frustrating when people confuse OOP with imperative programming and concludes that for sophisticated type systems to exist, all the lessons from OOP has to be thrown out. Imperative programming needs, to some degree, to be thrown out if you want programs that are easy for the compiler to reason about, but OOP doesn't.

Well there is something unfunctional about OOP, encapsulation of state and some implicit assumptions about mutability. Although I do agree that neither paradigm is at odds with the other. Scala demonstrates that there can be a fruitful interplay between both.

As for the existence of sophisticated type systems I again don't disagree with you. I'm having a lot of fun playing with TypeScript and mixing and matching dynamically and statically typed portions of my code. I'm looking forward to see where that line of work leads because it is an extremely pragmatic approach to type systems and helps me program instead of adding unnecessary cognitive overhead.

Post reply on HN