Rethinking Programming Language Tutorials
prog21.dadgum.com
prog21.dadgum.com
For this kind of people it would be a waste of space to bring lots of "practical" examples, if this doesn't show a unique feature of the language, since people often know the algorithms quite well. If you want to learn about that you better get a tutorial/book about algorithms.
What they don't know is the topics that are specific to the programming language. IMHO it is right that many tutorials concentrate on this.
This article seems to suggest that programming language tutorials should always be targeted at people with zero knowledge about programming or computer science. And he also seems to suggest that all readers are assumed idiots.
In the OP's view, the description of associative arrays as a primary data structure in Lua is not important. This depends a lot on the audience. For me the description about associative arrays was very important, since I want to know how the Lua interpreter works (esp. important for Lua since it's often used as an embedded language).
Same thing goes for the OP's complaint about Haskell and laziness. Laziness is a very central concept to Haskell so it makes sense to introduce it early on.
The OP says: "Programming language tutorials shouldn't be about learning languages. They should be about something interesting, and you learn the language in the process." I really disagree on this one. I don't want to spend time going through yet another badly written beginner tutorial if I want to learn a new language.
However, the paragraph from the Lua manual still shows sloppy technical writing. Terms should be defined before they are used. Using another technical term is not a good description. For example, coming from Python an "associative array" would have to be called a "dictionary". For the Java and C++ programmers it would be a Map. Better:
The table type provides storage of values under certain keys. Lua uses tables to represent ordinary arrays, sets, records, queues, and other data structures, in a uniform way. For example, a table can be used as an array, since it can store arbitrary data under index numbers as keys.
That may be true, but we just have to live with it. We can't expect every piece of software to be documented properly (or even at all).
> For example, coming from Python an "associative array" would have to be called a "dictionary". For the Java and C++ programmers it would be a Map.
I think the term "associative array" is used here (as well as in PHP docs) because it's distinct from Python-style "dictionaries" or Java/C++ "maps" in that it's the only data structure used in Lua. There's no lists or sets like in Python. I think this is the intent that the manual wanted to portray.
When I was learning to program for the first time, however, all that I wanted was a bunch of short programs that I could type in and make small changes to. It's hard to learn about a language's philosophy when you're spending so much time hunting for missing punctuation. At that point, you're just hoping that your program is going to do something.
With this in mind, I think there's a lot of room for improvement in both camps.
If you are teaching programming to someone who has never written a line of code, you need to do away with the programming language all together. When you start out, you are learning two distinctly different things at once:
* General programming principles; abstract thought patterns.
* The language it is being taught in, along with all of its oddities and quirks.
I'm fairly confident that you can effectively teach someone to /think like a programmer/ without ever showing them a single line of code.
I learned to program, not because I wanted to program in the abstract, but because my friend's dad showed him how to make a little car drive across the screen, and I wanted to do the same.
I spent hours typing programs in from books, not because I wanted to program, but because I wanted to get 3d shapes moving around.
When I taught programming classes, I'd often digress to talk about some interesting abstract concept -- and immediately lose 90% of the class. Start practical, and enrich from there, as the material becomes relevant.
I spent hours on Sitepoint, printing out articles and just reading them over and over, and trying them out. (I still have the huge stack of printouts in a section of my home office as a reminder of all the work I put it ... you know ... when I start to doubt myself). I had learned OOP in college but I really didn't get it ... one day I went to Barnes and Noble and spent the whole day reading a Head Start OOP book ... and I 'got' it. I felt like Neo in the Matrix (I know Kung Fu!!!)
The point of the story is ... keep all the boring crap out of the way at first, get beginners excited about building things, that will give them the passion that will carry them through the (necessary) minutae later.
You just have to avoid the mistakes the article talks about. Which is assuming the reader knows what you're talking about and introduce too many topics at once, forcing him to run in circles trying to understand each one. I think that's the n1 mistake in teaching in general.
But in fact, you have to figure out what will bring people to an understanding (and it differs depending on what type of thinkers they are), not what their understanding will bring them to. Or at least, you can't just do those overarching explanations.
* The language it is being taught in, along with all of its oddities and quirks.
That's why some people swear by Scheme for teaching. Simple language that exposes principals, concepts, abstract thought patterns with minimal syntax, oddities, and quirks.
http://www.trollope.org/scheme.html (referenced from http://paulgraham.com/avg.html)
2. First Steps in Scala 69
3. Next Steps in Scala 82
4. Classes and Objects 104
100 pages and you're only onto classes and objects!
Dive into Python has it right, IMO - show you something, then explain it bit by bit.
Now my default stance is, when in doubt, buy the book that's under 300 pages, since if you can't cover you're points in less than 300 pages you're either trying to say way too much or your book is mostly fluff and filler.
Also I imagine the ubiquity of fast internet connections and Google has made the 1200 page "complete reference to everything" type of books more or less obsolete. More and more books these days are "focused expert knowledge in one particular area" which is a lot more suited for the 150-250 page format.
I think Pragmatic Programmers has a better approach at quantity vs quality.
Back in the day when java was just being introduced, nearly every tutorial presented it in terms of how it compared to C++ (presence of garbage collection, use of references rather than pointers etc.). This is because languages don't live in isolation, they are part of a larger tradition. Java was created to address certain problems and short-comings of C++ and the target audience was therefore C++ programmers.
Most folks that I know who have become programmers made a concerted decision to accept the discomfort and pain of pushing through the challenge to picking up the nomenclature used by the programming community. I certainly appreciated tutorials that were geared for beginners when I started, but - in the end - simply immersed myself by reading so many different books and tutorials that the short-comings of one were overcome by the other. Terms that were left undefined in one were explained in another. There is certainly some responsibility for the person creating the tutorial to clearly define terms and consider the beginner. There is also the responsibility of the learner to accept their ignorance pursue answers outside of the presentation of an individual tutorial.
When I was teaching my girlfriend HTML, she had absolutely no interest in what a tag was, or why it even mattered. She could care less about semantics, mobile design, etc. All she wanted was to create something on screen. After having her use the inspect tool from Chrome, she found it more interesting, and could see values changing. This held her attention for a longer period.
Till this day, the best tutorial I've ever read is _why's guide. I've read it several times, because it's super interesting, and extremely entertaining. If more programming tutorials were written this way, I'd be one heck of a developer by now. Why can't authors make their tutorials fun? What's stopping them?
The same with everything nil and another novice caring stuff. This book is good (I know since I learnt from it), if authors cared about so-novice-people this book would suck so much. Imagine you want use lua for your C program, whant to learn it first and you read what associative array is. I'd be mad.
And I disagree with your point about "practical" examples. Practical stuff you learn at work. Examples are good to learn syntax and general stuff, rest you can find quickly in documentation.
On the other hand, programming tutorials needs rethinking, but I think it need far deeper change.
The point about PiL is not that it's a bad book, it's that it's a bad introduction for a non-programmer. PiL was extremely useful to me when I already knew C++ and Python, but I can also see that if it had been my first programming resource I would have been in trouble.
The Lua programming book isn't a tutorial, as far as I can tell. As an experienced programmer I appreciated its brevity and spare clarity -- it mirrors the language. Adding words would make it significantly less useful to me.
My first experiences were in c++ and that had me making little games in the command line. I eventually took it upon myself to write an implementation of conway's game of life once I learnt about 2d-arrays and realised I could use two of them to make it.
Visual studio 2010 has a very nice set of tutorials that I found really great for learning c# with. The first was just a program that had 3 buttons (open, clear and close) and a picture box. It just opened an image and displayed it. It was a really nice tutorial that was fun, taught fast and inspired me to make the first program that I actually use on my desktop. It's a pretty basic slideshow program, but I've never found one that fitted what I wanted and the tutorial gave me all the tools I needed to create it with, nothing more.
That tutorial made me sit for a weekend and write that program. The feeling of finally having a program that did what I wanted and the fact that I made it just added an extra level of joy. It really showed to me why programming is enjoyable.
The quality of a tutorial for an absolute beginner can make or break their motivation to ever try again. It's far too important to not do well.
Well spaced English, good examples.
If you are new to programming reading a tutorial aimed at experienced developers, then, as OP states, it can be difficult to understand paragraphs loaded with unfamiliar technology, or where the concepts are presented in an entirely abstract fashion.
If you are an experienced developer reading a beginners' tutorial, then it's easy to miss some crucial novel detail hidden amongst all the bits that you already know.
If the tutorial takes you on the journey from a blank text file to an application that does something, then all levels can be as engaged as they need to be.
On the other hand, it will be just as easy to make a rubbish tutorial in this way, as it is to make a rubbish one that teaches the language in a more abstract fashion.
There's no problem with books set for different levels. In-fact, I hate those beginner books now as they move too slow. The issue I see is most publishers incorrectly bucketing their guide as beginner-level, and either going too deep too fast or writing code without explaining the mechanics.
I've seen many people get frustrated, lost and give up as a result. You can argue they didn't have the mind / passion for this type of work, however I observe many people who stop before they get started.
The best programming books/tutorials I've read motivate the reader to ask questions and perform hands-on experiments, all while being as accurate & comprehensive as possible.
Language tutorials do not need to be dull walls of text, that's why I'm a big fan of the "Do X while Learning Y" tutorial style, and am glad whenever I see a good one pop up on HN.
The first few paragraphs of the article point out problems with some tutorials/manuals for languages getting too deep too fast, but I like that feature now that I know (in some manner) how to program.
I found music theory knowledge very helpful when learning how to play guitar. In fact, if somebody knows what intervals a minor triad and a major triad are made of, and they know what note each string of the guitar is, then they can work out how to play a lot of chords.
On the other hand, it's good that some books do actually target people with a programming background, but this is not really a problem anymore, since those people know where to find good books. Stackoverflow threads about books are here for that.
Many people on HN recount their early experiences of programming. They had some home computer, and they had a magazine program listing, and they typed it in. Then they tinkered around with it. Then they read the book that came with the computer, and wrote more programs.
That is pretty much the "Learn X the Hard Way" approach, and it's really good.
If you set out searching for easy learning, you'll only get frustrated and limit your options.
Ended up dropping C++ and learning Python years later.