Just read it like a novel. Ignore the exercises. What struck me that it took 8 or 9 chapters until they even presented a loop, and it was none the worse for doing that. Actually helped my imperative lizard brain evolve.
Yes, its a book that uses lisp, but its not a lisp book. Its about programming techniques, i felt.
Of all the books that are usually recommended to be read and nobody actually does, this is the one that i actually read and liked.
Funny, I arrived at this "all software is.." piece last week.
Hypothesis: All of software *is* about change management
----
It dawned on me that all the software design efforts - Design patterns, programming styles, management practices - are all geared towards one thing at its core - managing change. For example:
* Command pattern: Figure out all the things that can be called and instead of a giant if/switch, look them up by name and call them. That way when you need to *change* the list of things you want to call, nothing else is affected.
* Structured programming: Keep the common code in one place and call them from many places. That way when the common code *changes*, we can contain the change to one place
* Object Oriented Programming: Keep the data and behavior common to one actor in the system contained in an object/class so that when it *changes* we have to change only that thing.
* Functional programming: *Changing* data is bad. Instead create copies of data and change them.
* Scrum: It's hard to predict too far into the future because things *change*. So let's try to plan for just the next n weeks.
At one point I was so used to Notational Velocity that I needed it on Windows and didnt want to adopt other available solutions. So I built a barebones clone in Java: https://github.com/vinodkd/jNV.
but maybe, they'll end up learning anyway? one thing i realized when i went back to studying online is that i was no longer the student who needed to prove something to someone else, and the typical test annoyed me. I get that this article is about a teacher trying to find out how much their students have learned a subject, but maybe that needs to change?
Edit: I've posted this same comment in multiple places in this conversation to get feedback from specific commenters, not as spam (it's a old personal project)
Edit: I've posted this same comment in multiple places in this conversation to get feedback from specific commenters, not as spam (it's a old personal project)
Edit: I've posted this same comment in multiple places in this conversation to get feedback from specific commenters, not as spam (it's a old personal project)
The second para of the article addresses this, as does the summary at the bottom. Maybe read the article and respond if your concerns about this particular article are still valid? Maybe it applies to the general "X is a code smell" article.
> Smells don’t necessarily indicate actual issues, just patterns that are likely to be used incorrectly and thus warrants extra care.
From the article:
> These rules may sound complicated, but really, they are about understanding the fundamentals of how a computer works.
... and from the post that the article links to:
> Understanding String vs &str implies an understanding of the ownership system, which implies an understanding of the lifetime system. That probably means that you’ve been exposed to pointers, references and perhaps even aliasing. There’s usually a discussion about mutability intertwined here. Gaining an intuition of data types that represent text benefits from understanding encodings, which benefit from understanding how CPUs operate.
> I’ve yet to find a way through this for complete beginners. Learners with that already know another systems programming language have a distinct advantage here.
This, IMO, is the key to understanding why Rust is hard to learn: it was written as a systems programming language, and we now expect it to be more than that. I nodded my head in agreement as I read the intro to Rust until I reached the explicit use of lifetimes. To me that was where the abstraction got leaky. If your core abstraction of borrowing needed to expose the fact that the compiler uses lifetimes and needs a hint from time to time, you're saying explicitly that your audience are system programmers and they get that no abstraction is clean.
Take that up a few levels of abstraction and application development with Rust is hard. Maybe the rust community should just say: "Yes, its hard in the beginning, but its worth it if you stick with it. Welcome"
PS: I personally found it hard to learn Rust when I was looking for a static single binary generating language for my side project, and went back to C (please don't judge, its just familiarity). But I see what Rust can do.
Agree. And after years of using it, I discovered osage, and after a few years more, gvpr. It gives and it gives. And yes, I'm forever fiddling with it to make it look the way i want it to, but in my heart I know the layout algorithms now better :)
Yes, its a book that uses lisp, but its not a lisp book. Its about programming techniques, i felt.
Of all the books that are usually recommended to be read and nobody actually does, this is the one that i actually read and liked.