Carmack's aside about his 7 year old son learning to program brings up an interesting idea: What would happen if you taught a 7 year old to program with Haskell. I don't have any children, but I started programming at 7 so at the very least I can conduct a thought experiment about what it would mean if Haskell was the tool I had at my disposal instead of opaque C manuals and a hex editor I used to hack the Mech Warrior 2 binary when I couldn't beat a scenario.
My thoughts:
I probably would have intuitively grasped algebraic datatypes. It often frustrated me that I could not define new things like True and False to suit the game worlds I wanted to create.
I would have had little to know interest in math or recursion for its own sake. I'm pretty sure I would not have done well with those.
I would have probably written almost all of my code in the IO monad, with game rules defined outside.
Graphics programming in Haskell would have been no better than with any of the other languages.
Overall, I don't think Haskell would have stuck. I think I would have been easily frustrated, despite being able to structure programs better than I was able to in Basic. For proof of this, I look to my early abandonment of C/C++ for game development (even if the manuals were pretty much terrible). On the other hand, if I was presented a game written in Haskell (with source), maybe the outcome would have been different. I certainly managed to use a hex editor at that age, so if I had some goal I wanted to accomplish (like modifying the AI of a game), I think maybe anything would have been possible.
I tried learn programming since I was 11. First I played around with graphical programming in Game Maker, Construct and RPG Maker. Later I tried out VBasic but quickly felt it was boring. After that I bought K&R and tried learn C, which was way too hard to program games above simple parsers and text adventure. After that I played around a little bit with Python and Scheme. It never got too interesting since I wasen't able to write any "real" programs. Later, when I was 15, I got invited to a private IRC network of cool and friendly programmers. One guy did a Haskell course and sent the slides from the lecture to me. I did some exercises with it and everything I didn't understood I looked up in LYAH and RWH. After I was able to complete all exercises, which by the way was very simple ones, I started reading Write Yourself a Scheme in 48 Hours. It told me how more about the practical use of monads, I learned how to use external libraries (Parsec in this case), and basically how you design a program from scratch. After that I tried to implement macros for it but failed, I wrote a simple IRC bot that used my Scheme implementation to evaluate expressions, I wrote a simple blog powered by Scotty and Blaze-HTML. Now I'm contributing to a recently released game engine which utilizes FRP, written some really small games with it and have contributed a little bit of code.
What I think made Haskell stick was that it was fun and easy to start write "real" programs with. :-)
I don't consider simple mathematical algorithms as "real" programs, nor do I consider simple text adventure games real programs either. I donno if anything got in the way with Python and Scheme, I just wasen't able to write anything useful or fun so it got very boring. In fact, learning Racket using "How to Design Programs" might have got me started much quicker, but it was already too basic I needed some more challenging while not being too difficult.
When I think about it, Scheme is probably a great option for beginners. It's simple and functional, got a great development environment for beginners (Dr. Racket) and two great beginner books(SICP, HTDP2). Also, since it's not purely functional the user who learn it won't need to learn abstract concepts like monads to do useful stuff in it. :-)
It sounds like the docs you had focused on functions and console I/O and never got to graphics/mouse/web.
The lessons of How to Design Programs are really well done, in the sense of reliably taking people from beginner to real programmer, yet everyone who's offered on opinion to me found it kind of tedious. I get the impression it's great for classrooms and there's a need for a resource like it aimed more at the self-motivated. Maybe that's http://realmofracket.com/
I don't think the tools available really limit a beginning programmer. They'll hack away in Visual Basic or using a hexeditor on their favorite programs.
What they really need is a mentor, learning materials, and the drive to create something. The smartest kid in the world isn't going to build anything useful or interesting if he doesn't care about it. He'll be assisted big time if he has someone to give him a sense of direction. It's amazing how much a 'dumb' but determined kid can get done, even if underneath it's a horrible jumble of spaghetti code.
I'm far from being a professional programmer, and until the last year of my life I'd never written anything work-quality. However, you've pretty much nailed it on the tools needed for a beginning programmer: They'll learn anything to do whatever it takes, if it's for a game or something else they're equally passionate about.
That's exactly how I started programming, with QBASIC gorillas, savegame hex editing, and Robot Battle AI programming. I eventually muddled my way through QuakeC, because it was for fun. It was only really at this point that I was ready for proper training materials.
When you're that age you're entirely goal oriented. You don't care about structure, you don't care about speed. You wanted to hack Mech Warrior 2. You had a very specific goal, so whatever language helped you do that the easiest would be the right one for you. Whatever language and toolset is the easiest to get to the point where programming is fun is the right language for a kid.
Actionscript was actually great for me. I wanted to make flash games, and back in the AS2 days you could add code to frame 0 of movieclip objects. It was ugly, but it was the easiest way to get something to happen. It also tricked me into learning a form of object oriented programming.
There exists at least one UK university which uses Haskell as a teaching language in its CS department. Not quite 7 year olds, but certainly a good percentage of fresh programmers.
Does it result in better programmers? Perhaps. It certainly forces you to understand recursion.
My university used Haskell as the intro language for the math department. People who where already good at programming and people who had never programmed before picked it up quite quickly, but people in the middle who knew a bit of programming coming in had a terrible time with it.
However people who'd never programmed before the Haskell course had a very hard time transitioning that knowledge to Java and similar languages, which was used in some other courses.
I remember learning Haskell at Imperial College London - a very nice language. I had never tried a functional language before and just loved how "natural" if felt after getting familiar with it.
I would love to re-learn it but I am thinking that from a career point of view I am better off learning Scala/Clojure than Haskell.
I started coding when I was 10. I think what made the difference for me was that I started out in QBASIC and it had excellent documentation within its help menus.
I didn't have any books or anyone knowledgeable to learn from at the time, but I was able to constantly look through that documentation to try to figure out what I wanted to do.
I had to make meticulous notes on everything, and make sure I really understood something in order to use it to solve a problem I was getting stuck on.
I think that hard-won knowledge was excellent, and it really taught me the value of API documentation and being able to find the answers myself just by reading that documentation.
I don't know. That is kind of like asking what if you try to teach a 7 year old calculus? Should you teach them calculus with math? Or try to just explain it through word problems? It makes no sense.
Sure you can take short cuts by skipping discrete math and teaching the "act" of programming without the understanding. But in the end the seven year old isn't really learning programming then, is he/she?
If you don't teach a seven year old calculus, are you really teaching them math?
I understand you can't teach everything upfront; that's not my point. I remember my 5th grade class, where several people said they wanted to be mathematicians when they grew up. The reality usually sets in by college, that all the 'math' we learned in the classrooms was just a tiny, tiny corner of a vast field of study. So similarly, I thought the 'programming' I was learning as a beginner was the real deal. When you're starting out, you never see the invisible, the unknown unknowns, the hidden complexity; you only see what's in front of you, and it has to make sense all on its own.
So there's this huge, intangible mess of complexity that is 'math' or that is 'programming', and you can't explain it all at once. They won't have any of the prerequisite knowledge, and you can't waste time covering all that. So you have to choose 1 concept out of the 7000, and you have to try to teach it.
There could be C programmers that know nothing about monads, so it stands to reason you could teach lots-of-C before you teach anything about monads. Is the opposite true? Are there Haskell programmers that know nothing about pointer arithmetic?
Good point regarding the math analogy, I feel it was a rather poor one now.
But I feel that the difference is between knowing and understanding. You can know how to get the browser to display a rectangle with the right copy/pasted html.
But without discrete math there really is no foundation to understand the underlying algorithms. Without understanding it is impossible to know how to extrapolate those examples to solve different but similar problems, probably the most important skill a programmer can have.
Teaching C before discrete math is like teaching english without a vocabulary. Sure you can understand the syntax. But without understanding algorithms or data structures you are going to be lost very quickly. You might not need monads for C - since it is such a primitive language. But try writing C without iteration or recursion.
You're right. What I was trying to say by Haskell programmer was more like an industry veteran. 10+ years experience in Haskell/etc, zero knowledge of pointer arithmetic.
There seems to be this ineffable force tilting the scales to create more C veterans that don't know monads (I could find you one) than there are Haskell veterans that don't know pointer arithmetic. Age, popularity, libraries, etc all tie into this, but I still think there's significance amidst the noise.
My thoughts:
I probably would have intuitively grasped algebraic datatypes. It often frustrated me that I could not define new things like True and False to suit the game worlds I wanted to create.
I would have had little to know interest in math or recursion for its own sake. I'm pretty sure I would not have done well with those.
I would have probably written almost all of my code in the IO monad, with game rules defined outside.
Graphics programming in Haskell would have been no better than with any of the other languages.
Overall, I don't think Haskell would have stuck. I think I would have been easily frustrated, despite being able to structure programs better than I was able to in Basic. For proof of this, I look to my early abandonment of C/C++ for game development (even if the manuals were pretty much terrible). On the other hand, if I was presented a game written in Haskell (with source), maybe the outcome would have been different. I certainly managed to use a hex editor at that age, so if I had some goal I wanted to accomplish (like modifying the AI of a game), I think maybe anything would have been possible.