Having read the book Dealers of Lightning about Xerox PARC and Kay,I think Smalltalk 72 was the original smaller simple language, with which children were taught.
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.
There's even a pretty fun documentary on the Squeak project, with Seymour Papert, Alan, and Jerome Bruner. [0] Or, if you want to go further back, read the original "Personal Dynamic Media" papers.
I recall reading it, and strangely I felt that making of the game is just a side-happening, while the author was on pursuit to get into movie industry rather.
Am interesting contrast, given most people know and are amazed by the game in retrospect.
It invented a lot of common cliches and tropes that are frequently used in other movies so in many ways it's a victim of its own success. For example in Star Wars the planet of Tatooine is Casablanca and the Cantina is Rick's Cafe.
Yep. I've joked a fair amount that watching Casablanca now is very likely to make you think "this is full of clichés" until you realize, "wait, this is where all these clichés actually started, isn't it?"
Similar to attending a play from The Repertory and hearing all the quotes that originate from it. Especially Shakespeare. But also the rest of the usual suspects. I'm shocked (Shocked!) to learn that movies borrow from Casablanca or Shakespeare.
Decryping is ephemeral though. No request body gets stored, except in RAM. Malicious operators etc, well that's always a possibility, but they supposedly have controls for that. And as others noted, they are not the only players in the path of serving your data.
The TLS handshake itself is independent of how things get stored. It takes time to set up a secure connection. There are processes in place to help reduce that time for follow up requests in a short period of time (typically within the same session) but it's still CPU time and network time. Having to do this twice (Cloudflare's SSL cert + your origin's cert) is doubling those times. It could be tens of milliseconds or even hundreds since the network is involved (round trips to your server).
> And as others noted, they are not the only players in the path of serving your data.
There are other hops in the path to serve your data but it's just moving your encrypted bytes over the wire, decryption doesn't happen in each hop.
Great question. They are similar concepts in that they both allow you to define a C4 model and generate diagrams based on that model. The key difference is simply that PlantUML (and Structurizr) allow you to define the model using markup or code, whereas Carbide uses a graphical interface. I know some people prefer the code or markup approach, and I know others that prefer a simple graphical interface. I think it comes down to personal preference really, but in the end they accomplish the same thing, which is model-first diagramming.
