[jfaucett]

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 had to teach someone OOP I'd say, OOP is like the real world if it were made of puppets and every puppet could pull another puppets strings, pull a string and a dog barks and wags its tail causing a cat to meow, the key is just not tangling up your strings.

[dkersten]

and monads

I really don't understand why people have such issues with monads. I don't have a haskell background and originally built up most of my functional programming skill in Python (going somewhat against the grain) and I find monads to be a fancy scary term for an extremely simple concept. I think if they were named something friendlier perhaps people's eyes wouldn't immediately glaze over and they could realise that, actually, monads are just a simple strategy for controlling how things are executed/computed. Computational or execution strategies, if you will. Lets just call them strategies and see if they are less confusing and scary?

[ddellacosta]

I don't know if I can agree with this. I've invested a significant amount of time in learning about monads (and functors, applicatives, monoids, and more from the bestiary of commonly used category theoretic structures in Haskell) and I find them quite challenging to grasp in their full generality. While specific use-cases are readily understood, getting to the heart of what a monad "is" has taken me time, and I honestly don't believe I've properly grasped it yet.

So I think there's a spectrum of understanding and effective use when it comes to monads and other algebraic structures like these, and I'm skeptical when people say, "oh yeah, a monad is just X, it's simple." I've said that myself in the past and I was wrong, and so were most of the people I've heard say that.

To put it another way: when I hear people who know what they're talking about say it's simple, they are talking about its structure, not about understanding what it is and how it is used. In that sense it is quite simple. But as Euclid said, there's no royal road to geometry (er, or monads...).

[dkersten]

Absolutely there's a spectrum and I certainly don't fully understand the full set of category theoretic structures (I'm slowly trying to learn, but.. its slow going). I just think that monads as programming constructs are quite simple. I don't doubt that in a full mathematical context there is a hell of a lot more to them and the mathematical reasoning behind how they work is surely beyond my understanding, but from a how they work, how to use them, how they interact with the language and what they enable you to do point of view, they aren't difficult at all.

[ddellacosta]

...but from a how they work, how to use them, how they interact with the language and what they enable you to do point of view, they aren't difficult at all.

I guess we'll have to agree to disagree here: I have found it challenging to grasp all of these things (even simply within the context of programming language usage). I guess that is, in the end, rather subjective.

[lostcolony]

For me the block for a long time for monads was understanding how they made IO possible.

That is, the basic ideas for things like a Maybe or similar were obvious and intuitive to me, and everyone software dev for long has done such things, even if they never think about what parts they could refactor out into something reusable.

But the leap from that to how it makes IO possible without side effects I just did not grok. It really only clicked reading something or other that described (admitting it was lying a little bit) the IO monad as something that threaded the state of the world through the program; that is, that world state becomes both an (invisible) input and output for functions, and so effects on it are fully encapsulated by the param(s) and return type of the function.

[dkersten]

That's a fair observation and I admit I didn't consider that when I wrote my comment. It is pretty difficult to visualise and leads to a lot of "but you still interact with the outside world so how can it be pure" kinds of confusion. Its very hard to visaulise how the program essentially gets wound up and then at runtime as IO occurs gets unwound. Some of the other monads are definitely simpler to understand!

[runT1ME]

> controlling how things are executed/computed.

No...see...you understand a monad. That is not the same thing as groking "Monads" in the abstract sense.

For instance, I don't think the State monad really has anything to do with how things are 'executed/computed'

[dkersten]

Sure it does - you execute code in the context of a monad. In the case of the State monad, your code executes in the context of a stateful environment.

[nbouscal]

I really don't understand why people think monad is a "fancy scary term". It's a five-letter easily-pronounceable word. What makes it fancy or scary? I think people assume that they're scary, and then confirmation bias themselves into making them hard to learn, despite them being a reasonably simple concept overall.

As for calling them strategies… if we called them that it would make learning and understanding the intermediate and advanced concepts significantly less accessible and more difficult. We should call things what they are.

[jfaucett]

hmm, if we called them what they are we'd call them "type wrapper functions" and talk about "type wrapper function chains", monads carries zero metaphorical/associative meaning. I think thats the problem with the name and a large reason people find them so unapproachable, most other terms in computer science carry significant associative meaning that helps in learning them, pointers have to do with pointing at things, functions carry the mathematical meaning of a set of inputs mapping to a set of outputs, etc.

[nbouscal]

You're demonstrating that you don't know what monads are. "Type wrapper function" could mean any number of things (lack of specificity is a bad trait in naming), but it couldn't mean a monad: monads consist of three things, whereas "type wrapper function" implies one thing.

Names don't need to be metaphorical. The purpose of a name is not to teach you what the thing is. For that, you should have a proper explanation from someone who knows. Names have a different, very important purpose: uniquely specifying the thing being named. "Monad" does that very effectively.

[amelius]

> I really don't understand why people think monad is a "fancy scary term".

The reason could be that the term "monad" comes from category theory, and that is a topic not everybody is too familiar with...

[nbouscal]

Lack of familiarity doesn't make it fancy, and for a software engineer it shouldn't make it scary either. One of the largest parts of our job is learning unfamiliar things.

[dkersten]

We should call things what they are.

Sure - I wasn't seriously suggesting we rename them, just that in my personal experience, newcomers get scared off seemingly by the name alone before ever actually finding anything out about them. A friendlier name may avoid this for newcomers. It definitely wouldn't be worth it for more advanced practitioners where referring to them exactly and in the context of their category theory roots is much more useful than friendliness.

[nbouscal]

I'm not sure how worried I am about the class of newcomers that will be scared off by a word that they don't know. PHP is friendly to newcomers, and the result is thousands of insecure websites built by people who think they know what they're doing but don't. Software engineering is a professional discipline. I don't understand the desire to pander to the lowest common denominator. When's the last time you saw a physics practitioner propose renaming vector spaces to be friendlier to the students?

(For what it's worth, you may not have been serious about renaming monads, but many others have seriously proposed it. In most languages other than Haskell they've been successful.)

[dkersten]

I don't understand the desire to pander to the lowest common denominator.

If people want to learn about monads is up to them and I don't have any skin in the game, but I hear a lot of people complaining that monads are so difficult to understand or use and I guess I was really just observing, in a roundabout way, that I feel a lot of that is down to monads appearing more complicated or scary than they are and that people are put off by it, kind of how people are put off Lisp's due to the parentheses.

[nbouscal]

Yep, on that point I agree with you completely. I don't at all understand why people find their appearance complicated or scary, but I agree that it's more appearance than reality.

[ufo]

> What makes it fancy or scary?

Its an abstraction and abstractions are hard. In away, its similar to why beginners tend to have trouble with recursion (if you try to understand a recursive program by stepping through without using abstractions like preconditions and postconditions)

[hornd]

Why would calling them anything different have any effect on learning other concepts?

[nbouscal]

Because the associated concepts, for example Kleisli categories, are easy to find if your search is seeded with the word "monad", but very hard to find if it's seeded with the word "strategy".

[arjie]

How about F#'s Computation Expressions? Not exactly the same, I'm told, but they're close, if so.

[louthy]

They're called computation expressions in F# and not monads because they're not exclusively used to implement monads. The term is more generalised to capture the much larger scope of the feature.

Here's a breakdown of the difference:

http://tomasp.net/blog/2013/computation-zoo-padl/index.html

[arjie]

Excellent! Thank you!

[dkersten]

I was kinda thinking of F#'s Computation Expressions when I posted my comment.

[johnloeber]

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.

[jagger27]

I wish I was there. My curriculum at Carleton University is

  1. Intro to CS in Python ending with a taste of Java
  2. Java
  3. C (intro to UNIX)
  4. C++ (design first, implement after, waterfall, etc.)

Along with 3 there is data structures taught in Java [0] and with 4 there is web dev taught in Node.js.

0: Following this text: http://opendatastructures.org/ Taught by its author, Dr. Pat Morin.

[cdelahousse]

Actually, the first class is now Java and C++. Morin isn't teaching Python any more.

"Functional" programming is taught in third year (COMP 3007), but you don't get too deep into it.

My issue with the listed classes isn't the chosen languages. A commenter mentioned that you can learn a lot of functional (and other) concepts in a procedural or object oriented language. My issue is that I basically learned the same concepts over and over again, just using different programming languages. You learn to iterate over a multidimensional array in Java, and then you do so again with C, but you have to deallocate and reallocate, and then you do it in C++, but you create an object for the array. It's all the same stuff.

[fakeanon]

Aha. Do you have an outline of a better way?

[dkarapetyan]

In that sense imperative programming is equally hyped. It too is like the real world, first you do this then you do that. Similarly there is nothing fancy about functional programming since algebra and calculus already introduce the ideas of composing smaller things to get bigger things.

What I'm getting at is that computation exists on several planes of abstraction and maybe covering C, x86, and Haskell might give you a good overview it will still leave things hidden because there is also Prolog and the branch of computation that Prolog leads to. Most schools settle for teaching their students the theory and some marketable skills by sticking to well-known languages like Java and Python.

[pron]

> If you know the concepts behind these, you can quickly grok any other programming language.

"Grokking" a programming languages is just a means to an end, and far from being the most important means (well, for interesting problems, at least). Most (though not all) of important concepts in CS have absolutely nothing to do with the choice of language.

At my university they taught Scheme (SICP) in Intro to Comp Sci, and C -- both in the first year -- and all the rest was just data structures, algorithms, computational complexity, operating systems, numerical algebra, compilation, and electives in vision/graphics/PLs/DSP/whatever. We could do the exercises in whatever language we chose (usually C). In short they taught us just theory and one practical PL (maybe Java, too, for concurrency problems) so that we could actually do the exercises, and boy did we have a lot of good programmers who came out of that school. I owe to my university the realization that the programming language is one of the least important things in CS and software engineering.

[pjmlp]

> 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.

[hnriot]

I'm not sure pointer concepts are very difficult, pointers might confuse people that didn't grow up with assembly language, but they really aren't very hard to understand and they are also less and less relevant. Over the years the abstraction level increases, it's far better to teach people to continue computer science to the next 21st century level, not go over stuff from the 70's again that they will likely never use. The breakthroughs in CS coming very likely won't be written in C (or assembly for that matter).

[GeneralMayhem]

You cannot write effective code in Java, Python, or C++ without understanding the difference between references and values. You can certainly stick to higher levels of abstractions - most functional languages do a good job of that, especially ones like Haskell that emphasize immutability and value-only semantics - but pointer concepts are absolutely relevant to the industry-standard languages.

[sbov]

I kind of feel like as long as we have imperative programming languages, pointer concepts will be useful. I mean, that's basically what references are.

[kyllo]

Add a Lisp or Scheme dialect to your list and I'm sold. Homoiconicity, macros, s-expressions and such are too powerful and novel not to cover in a college CS curriculum.

[Arwill]

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.

[sbov]

So, what would you cut out of CS so they can learn things that makes them employable right away, by a wide variety of companies, and not just yours?

Keep in mind it should be stuff that will have staying power, and not the latest fad, because you tend to go to school for at least 4 years.

[aidos]

The pursuit of knowledge shouldn't be dampened by silly things like getting a job. It's computer science after all.

Aside from that, learning Haskell at university has eventually made me a better programmer. It gives you a whole other world outlook and that's useful once you finally start figuring out how to build reasonable software.

[martin1975]

"The pursuit of knowledge shouldn't be dampened by silly things like getting a job."

Here's how I just read this: "The pursuit of what makes me look good shouldn't be dampened by silly things like serving people other than myself".

And than just to dampen that statement, you added "Haskell made me a better programmer", which clearly implies you got a job, serving the needs of others.

Would it be fair to say you are more concerned with looking good than serving others, based solely off what you said? Correct me if I'm wrong please.

[GeneralMayhem]

I'm not the person you're addressing, but - yes, you're wrong. (And an asshole to boot, but that's another issue.)

"Getting a job" has absolutely nothing to do with "serving others," except maybe in the slavery sense of "serving," depending on your politics. The point is that universities are supposed to be dedicated to knowledge and understanding for their own sakes. It's not about "looking good," and I have absolutely no idea where you got that from. It's about learning, in whatever way best expands your understanding of the world, yourself, and the absract.

[aidos]

That's exactly the spirit in which I was meaning it and there's not much more to add really.

[martin1975]

You clearly have no idea what I'm talking about. Thanks for the compliments.

[weeksie]

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

[wwweston]

It is de facto vocational school, though, since the demand for jobs generally outstrips the demand for labor and employers decided university credentials were indicative of what they were looking for.

[Arwill]

No, the worst is when you get to talk with people fresh out of college, and you can't give them a job, because they are useless. Sober up people.

[dkersten]

No, the worst is when you get to talk with people fresh out of college who "know" all the latest industry hype but still can't put basic programs together, lack basic problem solving skill and basic algorithmic thinking.

Sure, teach them some practical get-a-job stuff, but also teach them how to learn, how to solve problems, the different tools (functional, OO, logic, low-level etc) available and make sure they can solve real problems on their own.

[pacala]

> I never got the whole hype behind OOP.

It's really not much to it. Get value records right. Get method records right. Sadly, none of C, x86 or Haskell does this.

[fishnchips]

I love the analogy. I'll use it with my freshman students.