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
Raku Advent Calendar (2009-2019) 