Day 6 – Five golden rings, Four calling birds, Three French hens, Two kinds of programmers?, And a book review in a Perl tree! (or Rakudo Tree? ;-)

PREFACE

In the following, this novice programmer will try to make the case for two kinds of programmers, which I then use as a springboard to my review of Think Perl 6, the Perl 6 introduction to programming book.

A little about me: I learned my first coding language summer of 2017.  My interest in programming started around the year 2000, when I was in the 8th Grade.  (Spare you the math, I’m 31 years old, trying to enter programming career without a degree.)  It was actually that book I got in 8th Grade that I read this summer, C– How To Program (I kid about the minuses.)  It was really neat to open that book and see the old Amazon bookmark of that time, and even where I had stopped reading.

I’ll touch real quick on the question, Is Perl 6 a good beginning code language?  Short answer, if only the imperative paradigm is taught first.  I think the beginner finds it comforting to know what every character in the program does.  So, the idea of introducing objects before the beginner knows what functions are, just doesn’t sound right to me.  I prefer the old-school method of learning first control structures, then functions, arrays, pointers, strings and characters, I/O, THEN classes.

I do think Perl 6’s lack of strict typing is a major disadvantage, because developing the mental muscles of keeping track of data types is a good idea, as well as enforcing the Principle of Least Privilege.  Perhaps if a Perl 6 author were to use code that adhered to this strict typing 100% of the time, that would be enough to train the novice in the way they should go.  I think it requires much repetition to drill into the untrained mind that values can be limited to types, and that this is a good thing.  In short, I don’t think a quick paragraph discussing types does the topic justice.  It must be encountered frequently.

The chief quality I nurtured in programming was to understand how programs work, rather than a desire to build something.  This difference summarizes the main argument of my article, which is that some people prefer to stay in the shallow-end of the pool and to simply understand, while others have a stronger desire to do more than just understand, but to actually build something.

I wonder if for those more interested in building, they more-or-less don’t care what .say is, rather they just care that it prints what they want to say.  So for a do-er type person, I wonder if they don’t care which paradigm they learn first.  For such an one, maybe Perl 6 is fine for a first programming language.

Finally, your calibration of the accuracy of this article will be skewed if I do not express to you what kind of thinker I am , and what sort of programmer I would be.  I say this because I perceive that I’m much different than the typical pursuer of programming knowledge, and this review may be vastly out-of-touch with the majority.  So we will take a detour on that subject real quick.

From my browsing of the internet, in those places where people that inspire to be programmers come to the watering holes of knowledge (Stackoverflow.com, Quora, Youtube, et cetera), I’ve discovered there seem to be two different kinds of programmers. The first is the stereotypical programmer, what I refer to in this article as the Computer Scientist (CS) — people that math hard, naturally talented, self-taught, can use a reference manual as a primary learning source, and so forth.

The other kind is the lowly Information Technology (IT) group – people that are better with computers than the average population but typically not fans of math, not able to effortlessly “pick up” command prompts like bash or even IRC or reference manuals, and frankly, they just aren’t as into computers as much as the CS guys. This IT group, I believe , is the majority of people interested in programming. One of the most popular questions associated with programming and beginners is, Do you have to be good at math to be a programmer? Notice I say majority of the people INTERESTED. I believe that the vast majority of ACTUAL programmers are the CS-type.

Whether you have a degree or not is not the point I’m getting at.  I chose to use those terms because a recent video I watch (https://www.youtube.com/watch?v=hT7RNAq-zvo) explained the difference between the two collegiate degrees which was a recent revelation to me.

Anyway, I am the IT kind of programmer.  So it is from this background, Perl6er, that I present to you my thoughts on your programming language’s leading book for novices of programming, Think Perl 6.  So take my opinion for whatever it’s worth.

REVIEW

The very second paragraph of Think Perl 6 is interesting because it touches the heart of this article.  The author states, “The single most important skill for a computer scientist is problem solving.”  I may be completely scornfully naive because I have zilch experience with programming, but I’m hoping for this statement to be wrong.

Working through a first programming book, I believe most beginners wrestle with the idea, am I cut-out for programming?  I’ve meditated on this, and I found that the ideal job description for me would be working on existing code that I debug or slightly modify. Certainly, this still requires problem solving, but I think the association of “problem solving” in computer programing is math word problems.  In short, I think most of these IT types are turned off by this phrase “problem solving”, regardless of how the author intended it.

THE BOOK IS DESIGNED FOR CS GUYS

Now back to the question, Is the current book for Perl 6 the right book for novices of programming?  For CS type guys, I would say, “Sure.”  The book has like 80 pages of solutions to practice problems, and I think the pace of the book is right down their alley.

So the rest of the article is geared to those IT programmers that need their hands held and “walked-through” the book.

Let me start off by saying that I have contacted the author to inform him of my pending review, and he was VERY courteous in his response to me.  He didn’t know this was going to be an Advent post, and neither did I until I chatted with some eager folks on IRC a few day ago.

I don’t wish to lambaste the author, I am merely recording what notes I took during my process of reading the text, with no respect of persons to who or what the author was or his status.  I’m focusing on the negative aspects of the book because that’s what invariably gets noted in a book.  But I will say real quick, the author does an outstanding job of summarizing the totality of programming on Page 4 better than anyone else I’ve read (I’ve now read a total of 3 programming books and two networking books), does well using comedy, explained modulus well and taught me something new about it, presents well some unique strengths of Perl 6’s: nested conditionals (p.62), for range-loop (p.64); and did an amazing job with a very clean example of recursion on Page 66, his tip on Incremental Development (p.79) was new to me and helpful, tip on debugging new to me and helpful(p.106).

TOPICS TAUGHT IN SOLUTIONS

I believe many people new to programming prefer to read the book through without doing any coding.  I know, I know, this is pretty much universally considered to be the wrong thing to do.  Regardless, I think the strongest reason for people doing so is because of the question, Am I really cut-out to be a programmer?  The fastest way to answer that question is to read through the book quickly, which means skipping the practice problems.

So one of the pitfalls to me of this book was as the author explains it on Page iii, “the solution section of the Appendix also introduces examples of topics that will be covered in the next chapter – and sometimes even things that are not covered elsewhere in the book” — meaning some topics are ONLY covered in the practice exercise solutions.  It only recently occurred to me that I could have gone directly to the answer section in the appendix.  But anyway, the material being separated to the back means many beginners will do what I did, just move on to the next chapter.

CODE SNIPPETS VS. COMPLETE PROGRAMS

I started my journey in programming the summer of 2017 reading the book C++ How To Program by Deitel.  It was a blessing that I started on this book because from what I can gather, this seems to be one of the few introduction to programming books that presents the reader with COMPLETE programs and their output to the screen and not just code snippets.  And, he does this for ALL the chapters.

The output was very important for me to figure out what was going on.  It helps tremendously when you see the value the author entered-in, and you can use his value to verify your understanding of the program is correct.

It was when I bought my second C++ book (Stroustup’s Programming) that I realized that I preferred complete programs because Stroustrup, like most other authors of today, only use short examples of code (snippets).

I was not able to “absorb” what Stroustrup was explaining even though he was teaching the basics which I had already learned.  It was and still is discouraging (and fascinating) to me that a certain method seems to be a requirement for me to learn; that is, that the author “holds my hand” and “walks me through the book”.  However, this lack of being able to read most of the computer books I encounter is the main contributor to the question, Am I cut-out to be a programmer?

No doubt this crutch of needing complete programs to understand is associated with the route I took – of just reading the book rather than doing exercises.  But I feel there is more to the picture.

I believe some people learn better reading code than writing code.  Or another way of saying it, I believe some people are better equipped to take jobs that require just reading code and modifying it, than developing new software.  This leads into the mysterious subject of various types of programming job descriptions, which seem to be an elusive hidden topic.  But anyways, on to the review.

THE BOOK LOOKS LIKE IT WAS RUSHED

Page XV describes the font conventions that will be used in the book: italics, bold, c o n s t a n t widths, and icons! — of a lemur for tips — a crow for general comments — and a scorpion for warnings.  However, these icons were never used in the book, and I never saw a bold word in the entire book, aside from section titles.  I didn’t see constant width used.

On Page 32, the author cites proper examples as

> round 42.45, 1;

42

> round 42.45, .1;

42.5

> round(42.45, .1);

42.5

>round( 42.45, .1);

42.5

but forgets a format he himself uses often throughout the book:

round (42.45, .1);

As I worked through the book, I kept wondering if the space was an error or not.  This may seem like nit-picking, but when someone is new to programming, they shouldn’t be concerned whether there are typos in what they are trying to learn.  This leads to thoughts of whether they bought the right book or not, or whether this programming code language community is professional or not, et cetera.

I know what you’re thinking, “Just go type it into a computer, you lazy fool.”  All I can say to my defense is that I grab these books and start reading.  I hate interrupting reading to type in code.

This goes back to what we talked about earlier, a beginner is more likely to want to get through the book quickly and skip coding.  Besides, beginners inevitably will have problems getting editors running, and command prompt issues.  So its best to make it easy for them to not need to.  It happened with my first book, as well. C++ How To Program 2nd edition was written in 1998?.  And it was tough finding an easy-to-install IDE; and then when I tried the code, it was outdated.  (No std::cout back then.)  So, I just went back to reading the book, instead of hassling to get things working to code.

Chapter 7 glossary includes the terms “item” and “slice” which are introduced in Chapter 9.  This is frustrating as a diligent reader will go back and re-read the chapter, assuming that they forgot the material.  And there are other details, which I won’t bore us with.  In summary, I felt the book was done in a hurry.

EXAMPLES WERE NEEDED OF:

the difference between ++variable and variable++ in a loop (p.20)

a function that returns void (p.43)

difference between a function and a function “mutator” (p.43)

what a caller to a function is (p.44). The author assumed the reader knew what a caller was. Page 40 was where the author introduces a code example involving a caller, but the author did not explain the function call.

to show where “if” or “when” needs to be used (p.89)

to show what implementing a dispatch table as an array means (p.198)

CODE NOT EXPLAINED

Author uses comment in example on Page 7, but doesn’t explain comments until p.25. This is discouraging because I remember when I was learning C++ the author carefully explaining each line of code, which was a comfort.

No explanation of: the comma in say ‘The answer is ‘, $value Page 22. I wondered if it was a typo.

necessity of ( ) for a variable representing a no-name function (p.48)

$*IN (p.69)

\n (p.99)

~$0 (p.117)

parentheses in regex /(<[\d.-]>+)/ (p.121)

m: (regex match operator) (p.126)

rx (p.128)

s/ / / operator (p.130)

handle (member-function of class IO) (p.141)

No explanation of bottom of Page 159, last line of code. I can’t understand my notes by just glancing at them, but there is some confusion with 1..3 being confused with [1], [2], [3].

Author didn’t explain why $_ is now needed for this example (p.168)

\t (p.189)

colon (p.190).

(Does this colon operator have a name?)

isa (p.240)

atan2 (p.243)

reduction operator (p.207)

THIS IS NOT A GENERAL BOOK ABOUT PROGRAMMING

I disagree with the author’s opening paragraph where he says, “this book is less about Perl 6, and more about learning how to write programs for computers.”

The author doesn’t mention anything in the book about the most fundamental element of good software design, which is the Principle of Least Privilege.

The author doesn’t introduce the term “identifier” (p.15 would be the area to do it) which is very important in a world of abstraction and names.

Author doesn’t explain what typed variables are and how they, not scalar variables, are used in most coding languages (p.16).

The author does not differentiate between assigning and initializing a variable (p.19). Initializing first gets mentioned on Page 97.

“Script” is defined as a file, rather than a small program (p.21).

Author does not tell reader what I/O stands for (p.139) And carriage return never explained (p.141).

ODDS AND ENDS

Confusing word choice for a novice: “non-alphanumerical” vs. “a symbol”, bijective (p.193).

Author talked about the necessity of declaring variables before you can use that variable (p.16), but in the first example that has two variables (p.23), he doesn’t remind the reader by demonstrating a declaration. It is assumed the variable is declared, which is confusing to the beginner, as he never stated it was assumed to be declared.

Author doesn’t tell reader how to pronounce ~ (p.24), and same thing with & (p.47).

Type conversion not explained (p.33).

Explanation of flow of execution was much too short (p.39).

Author doesn’t tell reader what things stand for: is rw

Author doesn’t explain first-class citizens (p.47).

Author gives the reader the code first, then explains later: p. 57, p.64, 109-110, 121. I prefer the explanation first, then the code, because I stay at that code focusing intensely if I am forgetting something I read before that would explain my confusion.

Significant typo on Page 161. Correct output reads: [1 2 3 4 5 6 7 8 9].

Index and glossary were not immaculate: twigil not in Ch. 9 glossary, index does not include $/ (p.118), .. (p.64, => (p.184) <=> (p.173), “data structure” 221 (correction: p.1, 145*, 157, 178, 221), “pointy block” needs pages 113 and 70 included, “state” needs p.198 included, topical variable needs pages 88 and 113 included.

CONCLUSION

I want to thank the author for writing this book. Without it I wouldn’t have met this nice Perl 6 community, and I also wouldn’t have been introduced to this Declarative Programming paradigm that looks so interesting. I read the book in the midst of me also reading other computer science books and learning C, so my brain is a mess. However, the more I learn about computing, the more Perl 6 looks like a sleeper car. You know, in street racing, how people have cars that look slow, but are actually very fast.

And finally, if there’s going to be a throwing-in of possible Perl 6 aliases, I’m submitting 6lerp (pronounced slurp)!  Stay warm out there folks, both inside and out.

-COMBORICO1611

12 thoughts on “Day 6 – Five golden rings, Four calling birds, Three French hens, Two kinds of programmers?, And a book review in a Perl tree! (or Rakudo Tree? ;-)

  1. In 2003 I wrote a very long page on PerlMonks about how and where to learn Perl. I describe a lot of books and resources where people can start learning Perl, and the many ways that people prefer to do the actual learning: by reading a book, or by reading the docs / specs, by hands-on experimenting, etc. The page is hopelessly out of date (I once had the desire to update it, and I did bits of it, but it’s just too much work).

    The original idea behind the post still is valid: the many ways people learn something. One way that works for a certain group, does not have to work at all for another group, and vice-versa.

  2. Hi comborico,

    first, I would like to thank you for your detailed review and comments. Even if I am far from agreeing with much of what you say, I am grateful for that.

    Your article combines actually at least two different types of comments: it is a book review on the one hand, and an errata sheet on the other. I don’t think it was a good idea to combine these two types of things in the same writing, because they usually pursue very different aims. But that’s how things are by now, so be it.

    First, I would like to thank you for the errata sheet, I’ll certainly review it in detail at a later point, and I am sure it will be very useful for making this book better for the future. However, a number of the items you list are wrong in my humble opinion and stem from the fact that you haven’t tried to run any code and haven’t taken the time to go through the exercises and their solutions presented in the appendix. And this is kind of disappointing to be, because I spent a lot of time designing these exercises and testing their various solutions and this is one of the most essential parts of the book. I’ll come back to that later.

    I will not comment further on the errata sheet, as this is not the right place to do it in my view.

    Back to the beginning of your writing, I would make a few comments.

    First I certainly agree that not all people operate in the same way and that there must be some different ways to learn programming (or any other subject).

    You say: “Is Perl 6 a good beginning code language? Short answer, if only the imperative paradigm is taught first. … So, the idea of introducing objects before the beginner knows what functions are, just doesn’t sound right to me.”

    Well this is your opinion, I am sure many others will disagree. Having said that, I essentially followed that route and did not introduce objects before chapter 12.

    “I do think Perl 6’s lack of strict typing is a major disadvantage. (…) Perhaps if a Perl 6 author were to use code that adhered to this strict typing 100% of the time, that would be enough to train the novice in the way they should go.”

    Sorry, but I think the second sentence above is wrong. Adhering to strict typing would just be contrary to the very spirit and philosophy of Perl 6, which makes a big point about gradual typing.

    “The very second paragraph of Think Perl 6 is interesting because it touches the heart of this article. The author states, “The single most important skill for a computer scientist is problem solving.” … I found that the ideal job description for me would be working on existing code that I debug or slightly modify. ”

    Contrary to what you appear to think, debugging is more difficult than writing programs (see the opening quote by Brian Kernighan at the beginning of chapter 15). And debugging is even more about problem solving than writing new code. Not in the sense of a math problem you’re assigned to solve in school, but in the sense of a real-life problem you’re trying to solve or of detective work in a criminal investigation: gee, this damn code does not work as expected, why? What is wrong in it?

    Now to my main point, to something that is absolutely essential.

    “I believe many people new to programming prefer to read the book through without doing any coding. ”

    That is just the wrong approach, and you had been thoroughly warned against that misconception very early in the book. This what I wrote in the very first page of the preface:

    “It is not possible to learn programming or to learn a new programming language by just reading a book; practicing is essential. This book contains a lot of exercises. You are strongly encouraged to make a real effort to do them.”

    In the first sentence of the debugging section of Chapter 1, I also recommended to try the code example as you go, and also to try to do mistakes, in order to see how the computer reacts.

    There is really no excuse for not trying the code examples in the text of the book and also no excuse not to try to do the exercises. These are not just examples; in a way, they are the most important part of the book, the rest might just be considered to explain these examples. The crux of the matter is very simple: you’re just ain’t gonna learn something about anything without practicing. Period!

    Most of these code samples are very short, sometimes only one code line, but still are very often complete programs. Typing such short programs in the REPL to see what’s going on is very easy.

    I know, I’ve been there before. I’ve also sometimes read books about, say, a new programming language without testing the code. I could probably grasp some feeling about the language, but that’s simply not the way you can learn a language.

    I would have hundreds of other things to say about your article, but I want to finish on this point because this is so crucial. Just quoting myself again, the concluding remark (page 344) of the book says:

    “I should stress that you can read as many books as you want about the theory of swimming, but you’ll never know swimming until you really get around to doing it. The same is true about learning to program and learning a programming language. Write new code. Modify existing examples, and see what happens. Try new things. Go ahead, be bold, dive into the pool and swim. The bottom line is: you will really learn by doing.”

    Do yourself a favor: read the book again, test each of the code examples and try to do the exercises. Many of the things that were obscure to you will become clear. My take is that, by the time you’ve done that, you’ll be able to program.

    Anyway, thank you again for your interest with my book

    Best,
    Laurent.

  3. Clearly the advent calendar is not the right place for this particular article to reside. It’s really not about Perl6, and it’s not cool in my opinion. It’s a shame that much-respected ‘Think Perl6’ author Laurent R. has been essentially forced into having to write a rebuttal to the article, in the lowly comments section. There are other more accepted sites to write book reviews, where it’s possible to consider contrasting viewpoints. I think the best course of action would be to remove the article from the advent calendar, on the grounds of not enough focus on Perl6, and to encourage the article author to post it elsewhere (on his own blog, or as a product review somewhere).

    1. The relation to Perl 6 is clearly there. If somebody had written a gloating review of a Perl 6 book, nobody would have complained.

      We should respect opinions that differ from the community consensus, not censor them.

      Comborico communicates that his own perspective might not generalize to the whole potential audience for “Think Perl 6”, and I think any intelligent reader will be able to make that judgement individually.

    2. Thank you for your comment, bazzaar. I am also not entirely convinced that the advent calendar was the best place to publish such a piece (as I said earlier, I’m a bit concerned that this piece mixes a book review and an errata sheet, i.e. two very different exercises making it very difficult for me to answer), but, now, it is there, so be it. I certainly don’t support the idea of removing the article from the advent calendar.

      And, despite my numerous points of disagreement with comborico’s piece, I certainly welcome his or her article as a useful opinion. And I don’t consider my previous answer to be a “a rebuttal to the article,” and did not mean my answer to be such a rebuttal, but more as just my own opinion on comborico’s opinion and my (own perhaps biased) judgment on the fact that comborico did not run the code samples.

  4. So, I was struggling with your “no snippets, gimme code that reads well and is well explained” preferred approach to learning to program.

    But when I cast my mind back to the 4+ decades ago when I took up programming, well, I realized I learned the way you like to. I started with a book on BASIC, and I read it like a novel, trying to understand the narrative of the text and the code, trying to keep the story/programs running in my mind. Since getting computer time was a rare event (go ahead, laugh at that constraint :), that was the best use of my time. I couldn’t read some at a terminal, then type, then read some more. Instead, I had to be ready to work out what I couldn’t understand right away, try out some of the examples from the book, and get to coding up my vocabulary quiz or whatever. That meant a lot of book time up front.

    I don’t learn new languages that way anymore, mind you…but maybe that’s a lie, since I haven’t tried a single bit of code from this year’s Advent calendar :)

    Thanks for this day’s post.

    And I think you’ve got a career in programming, for what that’s worth. I dang sure think some publishing houses should contract with you for pre-release feedback on their intro programming texts. I bet your perspective could make their books better.

    1. Chris, your comment was shocking to read. Thank you so much! I think you made my six months! (A year is so long, I think a comment can’t make a year. Haha!) Thank you for the encouraging words, I mean that.

  5. bazzaar,

    It’s funny you say that. On #perl6, I argued the same sentiment, that my book review wouldn’t be appropriate material. But still I was encouraged to write it for the Advent project. I wasn’t convinced. So I requested that jnth, being present in the channel at the time, give the okay. I requested jnth because it’s my understanding that he is leading the Perl 6 development.

    Then perlpilot informed me that actually he was the guy that started the Advent project to begin with. I can’t remember the other prominent user which also encouraged me to write an article – but the sentiment was that, being new to programming, I had a valuable perspective to share. So, with perlpilot’s support, I took up the writing of the article. So that answers how that went down.

    Next, I totally disagree that my scathing article somehow forced Laurent to action, for the following reasons:

    If you consider Laurent’s response, the bulk of what he speaks to and his main point, I already admitted and addressed in the article – as I say in my article, “to read the book through without doing any coding…is pretty much universally considered to be the wrong thing to do.” So the bulk of Laurent’s response is telling me something that I, and the readers of my article, already know. Bottom line: No rebuttal can be made if the point was already established.

    As for the other few tidbits Laurent replied with:

    I never stated Think Perl begins outside the Procedural Paradigm. The quote Laurent cites is me giving a recipe that I think an author writing an introduction to programming should stick with. Why Laurent thought I was speaking of his book, I don’t know. It’s the holidays, and maybe he was pressed for time and read my article in a hurry. I don’t know. It’s not a big deal. So there IS a rebuttal there, but its a rebuttal to a non-argument. :-)

    Laurent then goes on to write about my preference for strict typing and how that is un-Perl-like. This isn’t about his book. So no “forcing a rebuttal” being done there, either.

    Lastly, “debugging is more difficult than writing programs”. Again, this isn’t about his book, so no rebuttal.

    bazzaar, just because you see a negative write-up, doesn’t mean people are being nasty and accusatory. As I tried to get you to understand by writing, “I don’t wish to lambaste the author, I am merely recording what notes I took during my process of reading the text”.

    Now whether a negative review of a book is suitable for the Advent Calendar write-a-thon, I don’t know. I do know that as communities can grow and die, it is important that the people that care about those communities know what Initiates think. So I do know my article is important. And if the Advent Calendar is the time when many Perl eyes are watching, then I do think it is appropriate. I kept the article civil, and stuck to business. I let the reader know thoroughly of my inadequacies, weaknesses, possible naivety. How much more gracious could I have been? Besides, the worst things I’m saying about the book aren’t that bad: the book looked rushed, lists examples needed, lists code not explained, and odds and ends, and everything is cited. Sounds like quality feedback to me. Whats the big deal? Seems pretty cool to me.

    1. Hi comborico,

      I am surprised that you find bazzaar’s response funny. The fact that some people encouraged you to write it, probably without having seen it, doesn’t mean it’s proper. The situation is this. I wrote a book (and believe me, I did not rush it out, it took me eleven months (probably more than 1000 hours) to write it, plus another five or six months or so through the editorial process at O’Reilly)..

      I acknowledge that you said that you don’t want to lambaste the author, but I think that’s pretty much what you did. And that’s OK with me, we can have diverging opinion.

      But the main point here is that my previous answer was certainly not meant as a rebuttal of your article. I was only trying to set some matters straight on some specific subjects.

      Clearly, on the main point of my response, you had stated quite clearly your view on the matter. I think (very strongly) that you’re wrong and I explained why.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s