Counter perspective: I worked through The Little Schemer and got a lot out of it. I covered the answers with a piece of paper and tried to answer them myself one by one. I wrote the code by hand...
Counter perspective:
I worked through The Little Schemer and got a lot out of it. I covered the answers with a piece of paper and tried to answer them myself one by one. I wrote the code by hand and didn't use an editor. When I got an answer wrong, I asked why and made sure I could answer before moving on. The book is short and this did not take long.
There are many skimmable programming books that just serve up information. This book is more of a journey for someone who wants to really think through programming problems from first principles.
I had some programming experience, but just as a hobbyist. I'd say that book is fine for an absolute beginner. It has no math, no hard syntax, and assumes no prior knowledge whatsoever. However,...
I had some programming experience, but just as a hobbyist.
I'd say that book is fine for an absolute beginner. It has no math, no hard syntax, and assumes no prior knowledge whatsoever. However, I'd say the author is right to say the book is peculiar. You can't just skim through it and absorb the knowledge. It demands a lot from its reader.
Also loved it as a programmer. Opened a new perspective on how I approach algorithms. I don’t really understand why the reviewer says this book is not for first year cs majors. I think both the...
Also loved it as a programmer. Opened a new perspective on how I approach algorithms. I don’t really understand why the reviewer says this book is not for first year cs majors. I think both the paradigm and the method of teaching are invaluable for new cs students. I got caught up learning a lot of syntax and surface level understanding of data structures. This book encourages deep understanding gained from questioning constantly, building curiosity, and then satisfying it.
Only went through a few dozen pages. As a long time Ruby developer, LISP/Scheme is close to the heart. Homoiconicity—which Ruby also has. Love it. If only Clojure had taken off more. Java is such...
Only went through a few dozen pages. As a long time Ruby developer, LISP/Scheme is close to the heart. Homoiconicity—which Ruby also has. Love it.
If only Clojure had taken off more. Java is such a chore. So verbose. There are so many JVM languages that provide nearly the same speed of Java but with all of the tech stack features due to integration. Alas!
Wrote after the rest of this comment: I immediately found myself down the Ruby rathole.
Yes, there are a lot of good feelings associated with Ruby.
Sadly, there is far less work than there used to be for those of us who enjoy working with the language. Anecdotally, I've seen an enormous drop-off in job postings for it. I can only assume this is because most more mature companies move to stacks that require less compute resources at scale.
For speed of new web app development, it's hard to beat Rails. For expressiveness, it's hard to beat Ruby.
Yet I'll give Ruby (really, Rubyists) some grief for the tendency to abuse:
metaprogramming
"mixins" (read: multiple inheritance but not quite)
Ruby metaprogramming is, in a word, amazing. That also means that it's:
Easy to see as a hammer for most nails
Results in code that is perhaps an order of magnitude or more harder to debug than ordinary code.
Used sparingly, Ruby metaprogramming is a superpower. However, just like driving on the highway, everyone else is either a "chicken" (coward, for non-Americans) or a "crazy bastard": either too simple or too overzealous in their use of the power.
Mixins (using Ruby's include keyword), like inheritance, result in code where finding where any given method is defined is a pain in the ass. Ruby object member variables are prefixed with a @ yet those same variables are inherited. Methods, too, are inherited. So which method are you getting? And, as Ruby supports calling methods without the use of parentheses, when calling a method with no arguments, is it a local variable or a method?
As much as I adore Ruby, partly for the zeitgeist of most of the community (it's become more divisive, seemingly like everything else, since 2016. Thanks again for the polarization, orange demon from hell), Ruby's tendency to prefer shorthand and implicit instead of explicit dependencies, makes it cumbersome to wield at scale.
To be fair, the same argument can easily be made about any language: it's more the discipline of the developer (team) and, in professional settings, the support given by management to continuously invest in consistent and coherent codebases.
Statically-typed language folks will say how important it is to have a compiler. And I'll say back "yes but have you experienced the wonder and the glory that is duck typing?"
I find myself recalling an anecdote by one of the earliest Ruby luminaries: Dave Thomas, the author of the original "pickaxe" book, the O'Reilly book that popularized Ruby. He said somethjng like, "Any sufficiently mature LISP program becomes its own DSL."
The same can be said of Ruby.
And, so, you either learn the API for that DSL, and should you need to maintain/extend it, all of the facilities that make it work, or you find yourself at risk of shooting yourself in the foot with a tool that you never understood.
EDIT: If you got this far, I'll add: still looking for work and would love to work in Ruby for someone! This wasn't a shill for work but, I figured, why not mention something? 12 years as a Rubyist, 10 in Java, and time spent all over the map in other languages and stacks.
Counter perspective:
I worked through The Little Schemer and got a lot out of it. I covered the answers with a piece of paper and tried to answer them myself one by one. I wrote the code by hand and didn't use an editor. When I got an answer wrong, I asked why and made sure I could answer before moving on. The book is short and this did not take long.
There are many skimmable programming books that just serve up information. This book is more of a journey for someone who wants to really think through programming problems from first principles.
I had some programming experience, but just as a hobbyist.
I'd say that book is fine for an absolute beginner. It has no math, no hard syntax, and assumes no prior knowledge whatsoever. However, I'd say the author is right to say the book is peculiar. You can't just skim through it and absorb the knowledge. It demands a lot from its reader.
+1 on enjoying it as an experienced programmer.
Also loved it as a programmer. Opened a new perspective on how I approach algorithms. I don’t really understand why the reviewer says this book is not for first year cs majors. I think both the paradigm and the method of teaching are invaluable for new cs students. I got caught up learning a lot of syntax and surface level understanding of data structures. This book encourages deep understanding gained from questioning constantly, building curiosity, and then satisfying it.
Only went through a few dozen pages. As a long time Ruby developer, LISP/Scheme is close to the heart. Homoiconicity—which Ruby also has. Love it.
If only Clojure had taken off more. Java is such a chore. So verbose. There are so many JVM languages that provide nearly the same speed of Java but with all of the tech stack features due to integration. Alas!
Wrote after the rest of this comment: I immediately found myself down the Ruby rathole.
Yes, there are a lot of good feelings associated with Ruby.
Sadly, there is far less work than there used to be for those of us who enjoy working with the language. Anecdotally, I've seen an enormous drop-off in job postings for it. I can only assume this is because most more mature companies move to stacks that require less compute resources at scale.
For speed of new web app development, it's hard to beat Rails. For expressiveness, it's hard to beat Ruby.
Yet I'll give Ruby (really, Rubyists) some grief for the tendency to abuse:
Ruby metaprogramming is, in a word, amazing. That also means that it's:
Used sparingly, Ruby metaprogramming is a superpower. However, just like driving on the highway, everyone else is either a "chicken" (coward, for non-Americans) or a "crazy bastard": either too simple or too overzealous in their use of the power.
Mixins (using Ruby's
includekeyword), like inheritance, result in code where finding where any given method is defined is a pain in the ass. Ruby object member variables are prefixed with a@yet those same variables are inherited. Methods, too, are inherited. So which method are you getting? And, as Ruby supports calling methods without the use of parentheses, when calling a method with no arguments, is it a local variable or a method?As much as I adore Ruby, partly for the zeitgeist of most of the community (it's become more divisive, seemingly like everything else, since 2016. Thanks again for the polarization, orange demon from hell), Ruby's tendency to prefer shorthand and implicit instead of explicit dependencies, makes it cumbersome to wield at scale.
To be fair, the same argument can easily be made about any language: it's more the discipline of the developer (team) and, in professional settings, the support given by management to continuously invest in consistent and coherent codebases.
Statically-typed language folks will say how important it is to have a compiler. And I'll say back "yes but have you experienced the wonder and the glory that is duck typing?"
I find myself recalling an anecdote by one of the earliest Ruby luminaries: Dave Thomas, the author of the original "pickaxe" book, the O'Reilly book that popularized Ruby. He said somethjng like, "Any sufficiently mature LISP program becomes its own DSL."
The same can be said of Ruby.
And, so, you either learn the API for that DSL, and should you need to maintain/extend it, all of the facilities that make it work, or you find yourself at risk of shooting yourself in the foot with a tool that you never understood.
EDIT: If you got this far, I'll add: still looking for work and would love to work in Ruby for someone! This wasn't a shill for work but, I figured, why not mention something? 12 years as a Rubyist, 10 in Java, and time spent all over the map in other languages and stacks.