
On Sat, Aug 29, 2015 at 01:41:52AM -0700, Alexey Muranov wrote:
IMO, what attracts a big part of kids to programming is the possibility to program side effects.
What attracts them are the effects. Implementing them as side effects is largely a choice the designers of their language have made for them.
It seems to me that Haskell takes a big care to "seal off" the side effects and does it in a nontrivial way. This may complicate introduction to programming.
Haskell simply refuses to allow side effects at all (aside from loopholes like unsafePerformIO). Making effects explicit complicates some things and simplifies others.
Telling the kids to "just use the IO monad and don't worry want a 'monad' is, it is just a magic word, it comes from Category Theory, don't try to understand, just follow me" might not be a good way to teach.
IO being a monad and IO being the type we use to describe real-world effects are orthogonal concerns. What we should teach people is that: - IO is the type we use to describe real-world actions - IO actions can be combines to construct complex effectful programs from simple building blocks - Many of the ways in which we can combine IO actions follow the Monad pattern, just like we can combine Strings in ways that follow the Monoid pattern. - You don't need to fully grasp the Monad pattern in order to use it with IO; just get used to how monad operations work for IO and go from there. The more general intuitions will follow in due time.
I've seen assembly language mentioned here, and what attracted me to it, when i was a kid, was the possibility to program "side effects" explicitly. Even if i could not observe those side effects, like change of a register value, directly, they could be tested indirectly.
The value of teaching assembly language is that it's close to the metal, and thus suitable for a learning trajectory that roughly follows the way programming language design has unraveled over the past 60 years or so. Assembly language is, in fact, an abstraction already: by mapping mnemoics to machine instructions, we make them more palatable for humans. The observation that instead of looking up the bit patterns for machine instructions in a printed manual ourselves, we could have the computer do it for us, is what I consider the spark that bootstrapped the entire field of programming language design. That doesn't mean, however, that this is the only possible trajectory - it's a thorough one, and a very suitable one for people like me who want to understand it all before moving to the next level of abstraction, but most people, I realize, aren't like me.
Alexey.
On Saturday, August 29, 2015 at 8:10:58 AM UTC+2, Donn Cave wrote:
quoth M Farkas-Dyck
javascript:> ... I see much praise of Python, while Haskell mostly performs better, is less verbose, and catches type errors. Worse yet, I see counsel to learn it as a first language.
Sure - "Programming for Everybody" is practically a Python trademark!
It is kind of embarrassing when Haskell enthusiasts see Python as a better language for beginners. But in either case I think we'd expect only a fairly superficial treatment of the language, right? I mean, for example, back in the day, one of my colleagues picked up Python for random minor utilitarian purposes, and when I talked to him he hadn't used classes for anything, so for him it was only incidentally OOP inasmuch as some of the built in functions were addressed as object member functions. A beginning student doesn't need to learn OOP in any kind of depth. He or she would need to learn about the IO monad, but maybe not monads in general. I suppose that might somewhat limit one's potential appreciation of Haskell's beauty, if we're still talking about that.
Donn _______________________________________________ Haskell-Cafe mailing list Haskel...@haskell.org javascript: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
-- Tobias Dammers - tdammers@gmail.com