Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I agree a lot with Dijkstra as well, especially when he denounces how childish it is to compare computational processes with physical ones instead of understanding them for what they are (i.e. 'the radical novelty'), but to play the devil's advocate, formal thinking is not how we learn.

I personally find it hard to understand a concept, even in pure math, if I don't understand the motivations that lead to that concept being formulated (not necessarily practical applications, I'm fine with purely theoretical concepts, just why that definition solves a problem, I guess); it's simply too much to ask someone to "get" programming without an intuition of what types of problems it solves.

The fact that more and more people get into programming, even professionally, without proper mathematical fundamentals is another topic entirely.



I cannot imagine a mathematics lecturer telling his students "a monad is like a burrito". Sometimes I think the analogies can actually hurt our understanding of something very abstract or novel, as is the case with the bad burrito analogy.


I completely agree with that but my angle was slightly different. Burrito monads are the prime example of what not to do, but my university course on category theory didn't start with the lecturer throwing out definitions, it started with an explanation in plain English (well, it wasn't English but you get the point :)) of what the theory is trying to accomplish. I'm completely behind the Dijkstrian viewpoint that computing is a radical novelty in itself, but I don't see why trying to explain the purpose of what you are doing is bad. To make a more low-level example, pretty much every explanation ever of the concept of R-module started with 'we are trying to generalize the concept of a vector space to sets that have a ring structure but not a field structure', not 'here, have a bunch of axioms'.


I completely agree. There should be motivating problems and examples. But I don't think that's at odds with Dijkstra's viewpoint?


> I cannot imagine a mathematics lecturer telling his students "a monad is like a burrito".

Well of course that's fatuous-- a math teacher's job in this case is to explain category theory. It would be professional malpractice for them to use an analogy to justify not teaching category in the interest of teaching practical programming techniques.


If one wants to learn what the Monad abstraction is, then one by definition will have to learn some category theory! I don't think there is any need to understand what a monad is in order to use any practical programming language. My point was that the burrito analogy does more harm than good (as predicted by Dijkstra).


> If one wants to learn what the Monad abstraction is, then one by definition will have to learn some category theory!

Actually, I always thought people were referring to Doug Crockford's talk about monads where he makes an offhand analogy to burritos at the beginning. In that talk the analogy has absolutely nothing to do with the 45 minutes of slides he presents, so it always struck me as weird. I had no idea bloggers had actually used a burrito analogy to explain monads-- I now realize he was making an allusion to that.

At any rate, in his talk he explicitly avoids both category theory and type theory in an attempt to explain monads to Javascript programmers for practical programming purposes.


We can certainly dispense with analogies that only serve as memory aids.


Maybe if they did more than a few 0.x% of students would succeed at maths.


> formal thinking is not how we learn.

The way I've thought about it is that we cannot understand a problem until we've faced it ourselves.

And too often we try to teach each other by going straight to the answer, and then it just doesn't stick.

I recall this happened to me when reading about 'soft' skills (such as collaboration methodologies), it wasn't until I was working with a team of people at a job and was faced with the problems these methodologies attempt to solve that I was able to read about them without immediately thinking "this sounds like bullshit"


I think this is part of why the "Learn X the hard way" method of teaching can be so effective. It's forces you to solve a problem with foundational tools.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: