118 karma · joined March 12, 2020
Then others at Xerox added more professional stuff, the kind programmers would want, which resulted in Smalltalk 76 and so on. These were not as approachable for children anymore allegedly.
Nowadays there's Squeak which is a Smalltalk implementation, which influenced Scratch I think (first version of Scratch was written in Squeak).
Search the internet for Adam Kay's documents on Squeak and educating children, helps to put on context what he had in mind (if you, like me, just install Squeak and expect a stunning tutorial... it's not like that, at least I didn't find).
Kay also said, having an IDE only takes you to the 70s from the 60s too... So there's work to be done yet.
Am interesting contrast, given most people know and are amazed by the game in retrospect.
(I'm neutral but I like the historic context)
(I recall that these interestingly share the same video editing backend, just the integration is different?)
First thought: but C is on the right.
Second thought: ah, I use Dvorak
I arrived to a design where SQLite databases would be synchronized by Kafka. Kafka is really robust, and has a friendly semantics when configured to be in-order delivery.
The catch is, you don't issue writes to SQLite anymore. You write Kafka messages, and have to prepare to resolve concurrency problems at read+write-to-db time. For example, user registration is not an atomic action anymore - you write a registration attempt message, and then it might race with a concurrent registration attempt from an other node (say due to retries and random load balancing).
You resolve the race in message-reception time (doable due to stable order on multiple reader nodes). I expect this would work nice, but needs you to rethink all actions that used to be synchronous db writes.
Maybe they mean keeping a stack of CLs ready, while waiting for a review? I often had 1-2 CLs based on.. rebasing was fun sometimes.
Or they mean diffbasing these subsequent CLs, for an early review? That was useful, but due to volatility dependent on the first review, a bit risky.
Plug for a code review project: https://reviewpad.com/
One of the pain points using Kythe is wiring up the indexer to the build system. Would Glean indexers be easier to wire up for the common cases?
Other is the index post-processing, which is not very scalable in the open source version (due to go-beam having rough Flunk support, for example).
Third, how does it link up references across compilation units? Is it heuristic, or relies on unique keys from indexers matching? Or across languages?
You can't reverse engineer and share random internals.
Other is adding atmospheric elements that serve no purpose to the plot, just paint scenes of life. In modern films, most things shown will have to compulsively have some utility later.
Doesn't match my experience. There's two levels to this:
A good review can catch bugs directly. But even more important, it can dispute an obscure design, ask clarification for intent of ambiguous pieces of code, ask for added tests.
A hassle short term, but saves accumulated debt long term.
I really recommend Secrets of Consulting. I was vary since it sounds a BS title, but excellent book.
Or anything from him, really.