Wow, I clicked the 'Surprise Me!' button on Amazon and it took me to a page with this text:
"Namespaces are features often found within object oriented languages, such as C++, Ruby, and recently, PHP. A namespace allows libraries to use similar naming conventions without collision. The namespace often applies and implies a context for its identifiers."
Now I don't know how big this book is, but I don't think you can cram that much information in a children's programming introduction.
I also don't see at all how it is relevant to explain this much information about namespaces and their historic context. The amount of jargon you need to be familiar with to understand this paragraph is rather large and I know plenty undergraduates who'd have difficulty with understand this, even if they've used namespaces before..
Is this information for the parent or for the child?
(please don't see this as a middlebrow dismissal, I think it's a great idea to write programming books for young children and the cover of this one looks great, I am just genuinely surprised at this page being in there)
I really wanted to prove you wrong by finding some evidence that the quote you featured isn't included in the book, but instead I stumbled upon a page[1] about boolean data types which was equally inappropriate for a younger audience. So instead I found myself up-voting you.
In fact to further prove your point, the boolean page made reference to the history of the name, which even I was unaware of after 25 years of programming.
It's a great pity about the content of this book as it's actually a really good idea. But with the content as in depth as it is, I couldn't even justify buying it as to read to my kid as a novelty item.
> Named after George Boole, boolean is the most primitive data type, allowing for one of two values - true or false. Boolean operators are intended to represent truth values. Many languages contain a strict boolean data type, however, several languages, such as C and Lisp represent boolean values as the integers of 0 (false) and 1 (true). In most languages 1 and 0 are interchangeable for true and false.
I suspect the average lay adult pulled off the street would have a hard time understanding this, let alone a child.
Explained like I'm five: B is for Bit. A Bit is the smallest piece of Data a Computer can know. Arrays, and all Data, are made of Bits. Bits are either 0 or 1, nothing more, nothing less, and nothing in between.
(Booleans have no Business at B, Because Bits are Boolean)
Incidentally, Lisp doesn't even represent boolean values as 0 and 1, it represent them as nil (equivalent to '(), the empty list) and anything-but-nil. Indeed:
This is exactly what computer science is not about. I feel like I'm an astronomer looking for a great children's book to introduce my child to the wonders of the universe; but instead I get a book that goes over all the different parts and kinds of telescopes.
It's a book about programming, not computer science. You might be disconcerted to learn that the book isn't about chemistry, either, or whatever else off-topic content you insist the author had put in his book.
Somewhat offtopic: I learned to program using a variant of BASIC on an 8 bit machine. While it was limited in what it could do, it also forced me to reinvent the wheel, which I think as a novice is a good thing. Once you understand how you would build something, you will have an easier time understanding how others would do it. Since then, I have always used the approach of "how would I do this?" To figure out a new paradigm.
For example, how would you create a simple memory allocator? How would you multiplex a single timer interrupt to perform all necessary OS services? How would you create a process scheduler? How would you implement a syscall handoff from your running process to the OS and get the result back? How would you implement something like inotify/kqueue? I play this game with every bit of technology I touch.
The fun begins when you come across something where you are way off base. You think you have a great idea for how to do it, and then you see an implementation that is much more clever and usually simpler than yours. That is when I think you grow the most as an engineer: after you can truly appreciate the genius of the accepted solution.
In a similar vein is Lauren Ipsum (http://www.laurenipsum.org/). Technically it's for kids, but I'm an adult and I really enjoyed it. Highly recommended.
I don't mean to do the automatic-HN-criticism bit, but...
I reckon I can think of better examples for each of the terms than he/she's come up with there. The two we have are:
"A is for Array: a place to store your toys." - then there's a picture of a box with lots of DIFFERENT toys in. Shouldn't they all be toys of the same type? It should be obvious that an array means "more than one of the same thing".
"W is for While: While there is food on your plate, you will sit there" - doesn't really describe what WHILE does? The operation should be related to the condition. For example, maybe it should be, "While there is food on your plate, you will keep eating."
Not to be too picky over a book for 3 year olds, of course. :)
> Shouldn't they all be toys of the same type? It should be obvious that an array means "more than one of the same thing".
Not any more "the same thing" than all being toys. C, C++, Java, Ruby, Javascript, PHP all let you stuff references to objects that are entirely different into arrays some way or other, and I'd be quire confident in claiming that the same is true for most languages in common use.
> "W is for While: While there is food on your plate, you will sit there" - doesn't really describe what WHILE does?
It describes exactly what WHILE does. Whether or not there is an operation that changes the condition within the loop is an entirely separate concern from the while construct. Anyone with a child will have experienced situations where the child most definitively will not keep eating, and what changes the condition is that a parent as an outside actor finally takes the food away, for example.
That page seems sketchy. I wanted to see a bit more about the book. Does it teach programming or is it an ABC book? Also, I was suspicious of the Google shortened link for the Amazon link. I'm sure the author just wants some analytics, but it just felt off.
http://www.amazon.com/gp/customer-media/product-gallery/1489... is what I was hoping was on the front page, a picture from inside the book, to help explain what the book is. From the "Look inside" link on Amazon, I feel like the author touches on concepts, but doesn't really explain them, but then goes into implementation details in various languages.
I'd love to see somebody put together a book like what most of us expected this would be: an ABC book for kids that introduces some basic programming concepts in a cute and clever way. Nice effort by the authors but definitely geared towards an older audience (teenage?).
Good idea, but after browsing through the pages on preview on amazon, I am not sure my sister who is high school will understand most of this. There is a lot acronyms all of the place, and while there are illustrations, I have yet to see illustrations of the concepts. For example there is a page on YAML and comparing it to XML, pages like this and others seem to be just have short explanations of what they are but not sure a child would be able to take away anything from it. Maybe I am being too critical but as someone who has tried to encourage programming to a younger sister - Not sure this particular book would make an impact.
I think this book is a wonderful idea and the illustrations are great. Even if some of the topic explanations are a little more advanced, if nothing else, they should spark further conversations with the child. Which, correct me if I'm wrong, is exactly what sparked the idea to write the book in the first place! Great idea...just purchased. :)
Everybody's right about it being too high level, too far over the heads, etc. But it just looks fun, I sure am going to enjoy reading it to her, and to me, fun and enjoying yourself is what should animate a lifelong love of programming.
I don't understand the (automatic) HN critics that love to come in and pour Youtube-quality comments all over someone's work.
* Where does it say the book is for 3 year olds? Several people are commenting as though that is the intended audience. Am I just missing where the author says, "This is for your 3yo"? I don't see it. I think it's just ignorantly assuming that, because it's an "ABC" book that the paradigm is locked into 3yos.
* Brandon - you may want to go ahead and lock in the suggested age range for the book so that searchers can find your book easier. Naming the book "A is for..." is going to limit you with any parent of a child above 5 - by telling Amazon (and the viewers) the suggested age range, you remove a bias/filter that those parents would have about such a book.
This seems a little unfair to me. Personally I really like the idea, but I feel the implementation is lacking. That's my opinion, am I not allowed to express it, giving reasons why?
These are hardly "Youtube-quality comments". Clearly you've not been on youtube for a bit.
I don't think he's talking about everyone's comments. There are a few snarky comments in this thread that are totally unproductive.
I looked at my own "A is for Actuary" comment, and even that looks a little mean now. I meant it in a humorous way, personally I like the fact that he had the courage and creativity to write/draw a book for his kids that is relevant to his world, and the world of others.
You were nitpicking about the analogies the author used. Which is usually the kind of arguments that elitists make when they refuse to agree with an opponents point of view.
I think most of us can see things we would have done differently - just as I think most of us can see things that we do like about the book as well. But arguing about the intricacies of an analogy that is aimed at children strikes me as unfair.
Which was the point the former poster was making. We're not saying that you're not allowed to have an opinion nor a right to express it. Just that some of the perceived negativity (and I say that because your comment - intentional or not - does read negatively) comes across as pointless nitpicking.
At this moment, there are 33 total comments, and 12 top level comments, including yours. A rough breakdown of the 12 top level comments works out to:
1 semi related anecdote
2 questioning specific content of the book (both in regards to their appropriateness as well as technical precision)
5 pieces of encouragement/enthusiasm
2 questioning target age range
2 wanting more pictures
Honestly doesn't seem that ridiculous.
Wow not a single picture from inside the book.
They are either awefull and you try to sell on the name alone or you should switch "M" is for monad over to "M" is for marketing and add say 3 of them.
Might sell me.
Because this book is outrageous, as in most 3-year olds won't understand what a array, monad, functor, closure or lambda expression is. C'mon, they're only three!
No, they won't. But how exactly do you think they will learn? I dont think many 3 years old will grasp what it means, but at the same time I know how I learned to program:
At 5 I was watching my dad program from across the room (it helped that it was a VIC-20 with only 22 characters per line...), and I started copying the words he was typing. Soon enough he found me with sheets of papers with line numers and "IF", "GOTO", "PRINT", "THEN" etc. written all over them, and he sat me down with the computer and showed me a few very simple things. Then left me to experiment.
3-4 years later and I had exceeded his programming skills in most respects, largely because, while I didn't understand most of it for a long time, a 5 year old will relentlessly try things and see what works because what constitutes a sufficient reward to make it fun to keep going is so much simpler. When I discovered "POKE", I spent a day entering random values, and excitedly insisting my dad or mom come see whenever I managed to get random junk on the screen or trigger weird sounds.
And as I got older and started to understand the connections, a lot of the information I needed to make those connections had already been there for me for a long time.
There's a large gap between 3 and 5, but frankly:
Give them the outrageous stuff as soon as they'll pay attention to it, and while they won't understand what most of it is about at first (doesn't matter - kids read nonsensical stuff all the time), chances are quite a few will get much further than you expect if you keep preparing them for when they are ready to start making those connections.
"Namespaces are features often found within object oriented languages, such as C++, Ruby, and recently, PHP. A namespace allows libraries to use similar naming conventions without collision. The namespace often applies and implies a context for its identifiers."
Now I don't know how big this book is, but I don't think you can cram that much information in a children's programming introduction.
I also don't see at all how it is relevant to explain this much information about namespaces and their historic context. The amount of jargon you need to be familiar with to understand this paragraph is rather large and I know plenty undergraduates who'd have difficulty with understand this, even if they've used namespaces before..
Is this information for the parent or for the child?
(please don't see this as a middlebrow dismissal, I think it's a great idea to write programming books for young children and the cover of this one looks great, I am just genuinely surprised at this page being in there)