vinodkd

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.

Thanks. Also, nice blog post about MMM. Good analogy to finance.

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.

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?

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 :)

Not sure I agree. I didnt know about gitjournal until vHanda's post, but immediately saw how it could be a replacement for my use of Google Keep (which I use when I'm on the go vs at my laptop). And there was already an exporter for Google Keep. I'm guessing that exporter benefited from a spec being available.

Your point about "if you're the only one using it, just use it" does apply, but sometimes we do find ourselves being more successful than we originally expected and defining things via a spec is not a bad thing.

nope, no hate for google keep. i just hope they dont make it go away. really useful for all sorts of notes/lists

same. tried FF and Chrome on Windows, and FF on Ubuntu. Blank space where the editor should be.