I’d argue Terraform/HCL is quite popular as a Level 4 configuration language. My biggest issue with it is that once things get sufficiently complex, you wish you were using a Level 5 language.
In fact, it’s hard to see where a Level 4 language perfectly fits. After you’ve surpassed the abilities of JSON or YAML (and you don’t opt for slapping on a templating engine like Helm does), it feels like jumping straight to Level 5 is worth the effort for the tooling and larger community.
I'm very surprised we don't see more people using a level 5 language to generate Terraform (as level 3 JSON) for this exact reason. It would seem to be the best of both worlds -- use the powerful language to enforce consistency and correctness while still being able to read and diff the simple output to gain understanding. In this hypothetical workflow, Terraform constructs like variables and modules would not be used; they would be replaced by their counterparts in the level 5 language.
That actually works quite well. I once built a templating engine for Terraform files based on JQ that reads in higher level Yaml definitions of the resources that should be created and outputs valid Terraform Json config. The main reason back then was that you couldn't dynamically create Terraform provider definitions in Terraform itself.
Later on I migrated the solution to Terramate which made it a lot more maintainable because you write HCL to template Terraform config instead of JQ filters.
This is basically how pulumi and tfsdk work.
You write go/ts/python/... that generates a bunch of config files to a temp folder, and then reconciles those.
This is exactly how we do it with our very own rudimentary internal library and scripts. Barely enough and even though I worry at times it will break unexpectedly but so far we are surprised by how stable everything has been.
Although I really wish there was a first party solution or a well established library for this but I suspect that while it is easy to build only enough to support specific usecases but building a generic enough solution for everyone would be quite an undertaking.
The problem with HCL is that it's a Level 4 language masquerading as a Level 3 language, rather than a Level 4 language masquerading as a Level 5 (like Starlark, Dhall, even JSONNET). Because of that its syntax is very limited and it needs awkwardly nuanced semantics, and becomes difficult to use well as a result.
HCL is best used when the problem you're solving is nearly one you could use a level 3 language for, whereas in my experience, Starlark is only really worth it when what you need is nearly Python.
The choice between 4 and 5 is more about what you get to avoid. By choosing level 5 you are opening the possibility to make some really complicated configurations and many more footguns. When you stay at level 4 you're forced into using more "standardised" blocks of code that can easily be looked up online and understood.
Level 4 is also far more declarative by nature, you cannot fully compute stuff so a lot is abstracted away declaratively. This also leads to simpler code since you're less encouraged to get into the weeds of instantiation and rather just declare what you'd like.
Overall it's about forcing simplicity by not allowing the scope of possibilities to explode. Certainly there are cases where you can't represent problems cleanly, but I think that tradeoff is worth it because of lowered complexity.
Another benefit of level 4 is that it's easier for your code can stay the same while changing the underlying system you're configuring. Since there's a driver layer between the level 4 configuration and the system which can (ideally) be swapped out.
As someone who’s too young to have been around for HyperCard, what was the main draw? Was it the accessibility of the tech or was it just really well executed?
It was both, really. HyperCard put the power of a GUI into your hands with simple metaphors and syntax. The language is English-like enough to feel easy to use, but not so much as to fool you into thinking it can do things it actually can't do (looking at you, Inform 7!). You'd attach code to widgets in a visual way that drove home the idea that this bit of code generated that behavior when you clicked a button, typed into a text field, etc. Oh, and, let's not forget that the HyperCard environment also implemented object persistence, which came in handy, because you wouldn't have to write file handling code, or any kind of "save state" functionality. Of course, you could also mess up a stack in such a way that it was hard to figure out and hard to fix due to said semantics, but, on balance, I'd say transparent object persistence was a pretty big win.
And, it was literally right there if you had a Mac. After selling it briefly as a standalone product for $49.95, Apple started bundling it with every new Mac for about a decade. If your Mac came with System 6, 7, 8, or 9, you had HyperCard. It also came with the Apple IIGS during that time. (Great machine, BTW!) Despite its limitations, I even remember seeing a couple of nontrivial apps implemented with it.
More than anything, HyperCard made personal computing personal again, in a way it hadn't been since computers would boot straight into a BASIC interpreter, and that was a very good thing.
I imagine that Inform 7 has been a net positive for accessibility over older "code"[1] Inform syntax (personally, I bounced right off Inform 6 as a kid), but there were times where it felt like I needed a great understanding of the underlying model that would have been more self-evident from the "code" syntax.
That said, that's my experience from many years ago. Might be better now.
[1] Inform 7 is code too in a sense, but I mean syntax that doesn't look like natural language.
Macs only had a free version of Hypercard for a few years in the late '80s / early '90s, before it became a commercial product again (first under Claris then back to Apple). By the Mac OS 8 / 9 era it was a moribund product on life support, not something bundled with new systems.
Worth noting that while Hypercard was the glue which held everything together, most of Myst's functionality was implemented in native plugins. (or at least that's what Robyn and Rand told me when I chatted with them at a MacWorld Expo around its release). Their earlier games (The Manhole, Cosmic Osmo, etc) had been much more pure-Hypercard affairs.
Interestingly, for Riven (Myst's sequel) they were still using Hypercard to author the game, but the game no longer ran through Hypercard; instead, it ran on a custom C++ engine which ran on the data files output by the Hypercard authoring tools.
The cool thing about Myst being built in HyperCard is you can just change the file type from APPL to STAK and open it up in HyperCard and mess around. All of the color, video and audio was built with XCMDs, but the buttons and logic around the puzzles is in HyperTalk.
I think what drove them away from being HyperCard-native for Riven was the difficulty in producing a Windows version
> After selling it briefly as a standalone product for $49.95, Apple started bundling it with every new Mac for about a decade. If your Mac came with System 6, 7, 8, or 9, you had HyperCard
The full story here is:
Bill Atkinson went on an LSD trip and had the idea for HyperCard (literally according to his own account), and wrote it. He gave it to Apple in return for the promise that they would bundle it with every Macintosh for free.
Eventually Apple realized that selling and giving away Macintosh software like MacWrite, MacDraw, etc, undercut their attempts at getting people to write software for the platform, so they spun off their software division as Claris, which coincided about the time of HyperCard 2.0 releasing, which became a paid Claris product. From then on, every Macintosh shipped with a copy of HyperCard Player, which just let you run stacks other people made but not author them yourself.
There were ways around the Player issue though. The copy of HyperCard on our family Mac somehow had the HyperCard application from 2.0, but the Home and other stacks from HyperCard 1, leading to me always being confused with reading any documentation, it took me literally years to realize what was going on (we didn't have AOL or anything back then, all I had were two HyperCard books from my uncle)
The last major update to HyperCard was in 1992, after which it was abandoned (but still sold, with no updates, for another decade)
There was an effort to rebuild HyperCard as a new interactivity layer for QuickTime 3.0 so that you could build multimedia applications and host them cross-platform on the web with the QuickTime plugin. This made it to an early alpha that was demoed at WWDC. Steve Jobs came back, and hated Bill Atkinson since he was a traitor who stayed at Apple instead of going to NeXT, so killed it.
> Bill Atkinson went on an LSD trip and had the idea for HyperCard
There's another (to me more plausible) story. Steve Jobs had plans for a 20MB hard drive, but marketing could not find users who wanted that much space. So Steve asked Bill to create an application full of graphics and sounds/media where people would build huge documents making floppy discs too painful.
> If your Mac came with System 6, 7, 8, or 9, you had HyperCard.
I'm pretty sure Apple stopped development of it before System 8, and I'm certain it wasn't bundled. I'm also pretty sure (but not absolutely certain) it wasn't bundled with System 7.1.
Hypercard 2 (1990) definitely required a separate purchase (I had to talk my parents into buying it), but I think we had Hypercard 1 from being bundled with System 6.
I think Hypercard was one of last gasps of the idea that computer users should have the tools to create their own applications.
> More than anything, HyperCard made personal computing personal again, in a way it hadn't been since computers would boot straight into a BASIC interpreter
And in a way it hasn’t been since, either. Web browsers and Javascript just aren’t the same. Javascript, shell, even Emacs Lisp are just too low-level. HyperCard gave one a GUI builder and a simple yet powerful language to get things done in, and it was everywhere.
Aside from that excellent summary of features: the model of cards in stacks sending messages to components or up through a hierarchy was SmallTalk-inspired and enabled plain old people to do a kind of object-oriented programming long before there were any languages for it.
When I was in 5th grade, HyperCard was akin to early software development for me. I would spend hours after school creating games and choose your own adventures. You could put in goto statements, loops, animations, simple functions (play this sound when clicked and then go to this page), and more. I was totally hooked and it probably led to my passion for BBS development.
I actually used Hypercard to write a BBS (of sorts) that worked via filesharing on our high school appletalk network. We had maybe 10 users at it's peak. Chatting and message boards that updated via polling a shared file. It was very amateurish but it worked
Wow all these years (and countless references as the "original puzzler") and I never knew Myst was built in HyperCard! That's amazing. Even today I try and find games for my kids that are the "Mysts of our generation".
This was before the web or even Flash existed. It was a relatively simple multimedia/interactive program authoring tool for non-programmers that had WSYWIG layout. You could build all kinds of things in HyperCard from ways of interacting with databases to stories for school kids.
I remember being introduced to HyperCard and the idea of linked cards- hypertext, in other words- blew my mind. I imagine it was a lot of other people's introduction to hypertext too, even if they didn't realize it. It was the Adobe Flash of its era.
It was a well-done Smalltalk-like language with a RAD component that made making, albeit limited, GUIs about as complicated as using PowerPoint.
You could give it to a "smart" kid, and they could, at the very least, make interactive fiction with it with very little instruction. The vast majority of HyperCard stacks could be considered to be non-linear PowerPoint slide decks---cards with buttons that called goto statements that jumped to other cards.
> It is among the first successful hypermedia systems predating the World Wide Web.
But HyperCard was not ported to OSX, now MacOS; which has Slides and TextEdit for HTML without MacPorts, or Brew,.
HTML is Hypertext because it has <a name= href=> edges and scripting IIUC.
Then there was Flash by Macromedia, which also created Dreamweaver for HTML editing before Adobe acquired Macromedia.
By now there are Open Web Standards like HTML5 and ECMAscript (ES (JS not JavaScript)), WebSockets, WebRTC, WebGL, WebGPU, WASM, and various UI-to-state bindings, as Flash called what e.g. React is used for today.
Instead of the DOM and JS addEventHandler, with React/preact you call setState(attr, val) to mutate the application state dict/object so that Components can register to be updated when keys in the state dict are changed with useState() https://react.dev/learn/adding-interactivity#responding-to-e...
The HyperTalk language has a fairly simple grammar compared to creating a static SPA (Single Page Application) with all of JS and e.g React and a router to support the browser back button and deeplink bookmarks with URI fragments that "don't break the web":
https://github.com/antlr/grammars-v4/blob/master/hypertalk/H...
Power, accessibility, and execution. A doctor could make a stack to manage their office. A child could make a game. A teacher could make an interactive tool to teach a lesson.
You could learn HyperCard by reading an article in a magazine, and you could share your stack with the rest of the world.
It was very accessible and I think it really made a difference that it appeared on a new computer that was supposed to represent the future of computering (i.e. had a GUI) yet was not meaningfully programmable out of the box, unlike the supposedly obsolete 8-bit computers it was replacing which came with BASIC. HyperCard looked like a thing that could fill that same ecological niche.
In 1998 I started work at the 'Advanced Techniques Department' of a traditional UK engineering company (Plessey). We primarily used Symbolics Lisp machines (and later, TI Explorer Lisp cards for Macs) but one of our contractors used HyperCard to build demos that could be easily taken to customer sites / used in exhibitions to get customer feedback. We also used it to mock user interface concepts, etc. We also made a lot of use of ResEdit which was great for creating and modifying assets such as icons, strings, bitmaps, etc.
Once I got into the Mac ecosystem, it was stunning how quickly you could build sophisticated (for the time) GUIS, demos etc. It sure beat trying to build interfaces using curses on a traditional unix box and was a lot cheaper than a Sun box or a Lisp machine!
For me it was: WOW ... the internet before the internet ... we were kids who'd grown up programming Basic on BBC Micro's in school! (or Basic on Atari 800xl's at home!)
I remember it being called object oriented programming, and putting things together like jigsaw puzzles.
It is hard to separate out HyperCard from where I was in life when I was using it.
It was 1991, my family had just bought a Mac LC, and I was 8 years old. I had learned BASIC from reading an old book from 1978 that a co-worker of my dad had given me when I expressed interest in computers. That same friend said I should try HyperCard.
It literally changed my life. It is hard to explain to people who have grown up with the internet, but at this point my family had no internet access at all (we didn't even get a modem for a few more years) and I didn't know anyone who knew how to program. Everything was self taught from reading books that I either got from my dad's co-worker or from the library.
HyperCard was so easy to learn for me as a kid. For one, it was all visual. If you wanted to add a button for someone to click, you would select "Add Button" and drag it to where you wanted it to be. In addition, you could learn how to do things from other HyperCard stacks by clicking on various buttons and reading what the script for those buttons did.
Since I was self taught (and very young), I didn't know anything about data structures or algorithms. However, HyperCard made everything intuitive to me. To persist data, you could output it into 'fields' (which like buttons, could be created by clicking 'new field' and placing it where you wanted). While I later learned how to make these fields invisible, when I first started I would just make them really small and put them in a corner behind something else. I would then write data to them from button scripts, allowing me to persist data.
Since I didn't know about data structures, I would treat everything as strings that I would store in these fields. I didn't know what an array was, so I just would create a long string of comma separated values that I would read in, act on, and then write back out to the fields. I created primitive databases by having each line of the field be a different record... I had never heard the term 'csv' at the time, but it just seemed natural to me.
Debugging was easy; I could just expand the fields into my visible view to see what was being written to them. Things being 'object oriented' was very natural, since everything in HyperCard is a visual object you can interact with.
I learned SO MUCH hacking around with HyperCard. It made me love programming, and it was so much fun. I didn't even realize how much I was learning until much later in life; I avoided majoring in computer science because I feared ruining my favorite hobby if I pursued it as a career. Later (after not finding an alternative to pursue after graduating college) I decided to give software development a try, and I realized how much I already knew just from HyperCard. Event driven architectures just made sense, because that is how HyperCard always worked. I had a pretty good grasp of data structures because I had created them visually as I needed them, without realizing what I was doing.
33 years later, I still get a thrill from programming that HyperCard instilled in me.
It’s funny, the graphic nature of Hypercard is what put me off of it.
It was essentially MacPaint with a few controls and a scripting language. While fundamentally it was persistent cards with fields, buttons, and actions, as presented with the assorted demos, it was graphically rich.
And myself, I am not graphically rich. Hardly. I find it intimidating. I find the web intimidating for the same reason. I really struggle trying to make a web page, even with a zillion templates. For whatever reason, it’s very hard for me.
It’s a cool system. It was a bit hamstrung later on by being trapped with its original card size. Even as screens got larger.
I am usually the same way, and have zero graphic design sense.
HyperCard never felt like it does designing a web page... i just placed buttons wherever, and they were never properly lined up in my stacks. All slightly different sizes, not aligned, horrible UI choices all over the place... but I never really concerned myself about it because I very rarely shared my projects. They were for myself.
Yeah, I could never do serious front-end work, I just can't do (and also don't enjoy) making anything graphical.
That said I have made a couple web apps for personal & work use (and I have a Neocities) and it is certainly a freeing experience to write them without giving a crap about aesthetics or design. I get the job done, it's not pretty, but once the functionality's there I'm happy.
Fighting with CSS to make things align properly is the least fun aspect of this, but it is pretty fun to figure out the logic to generate the HTML, interact with the backend, have some JavaScript for basic interactivity, etc.
If these vehicles tackle the roads of Boston, there will be no stopping this company. That place has one of the most confusing road networks I’ve ever seen in addition to some of the most confused drivers.
NYC is another obvious challenge but Boston seems like a challenging middle ground.
The issue is not a confusing road network, it's that Waymos require a modicum of grace in other drivers to operate. They aren't super aggressive, they'll defer to pedestrians and other drivers, they drive safely.
That I think is where they'll find problems when expanding to locales with less than conscientious drivers.
From what I got out of the article and my own limited understanding of double entry bookkeeping, the "double" seems to be referring to the part where we split a transaction into credits and debits as opposed to a transaction with positive or negative balance. The doubling is happening with the labels we use to describe what's happening with the money.
From an individual account perspective, there's a doubling of the number of columns you could enter a transaction's amount into.
The core innovation of 'double entry' is that you can see the flow of money between accounts for every transaction.
This is possible because you (the accountant) are always adding a back-reference from the other account (hence the 'double' in 'double entry').
There's really not much to it. It throws people that are new to it for a loop, I think, because it is a strange way of behaving, and it isn't obvious why you're doing it until you have to track down something that doesn't balance. It's just a disciplined behavior that accountants started using because it allows one to track things that were difficult without it.
this is probably not true, but I heard that this stuff predates the idea of negative numbers so you have db and cr accounts that offset each other without negatives.
The most interesting takeaway from this article for me was that there's an inverse correlation between the number of syllables spoken per second and the bits of information conveyed in that time.
> Japanese, for example, has an extremely high number of syllables spoken per second. But Japanese also has an extremely low degree of complexity in its syllables, and much less information encoded per syllable.
It seems like our brains might only be capable of processing ~39 bits of spoken information per second. Now I want to see a comparison of the information throughput of other forms of communication!
(Good) podcasts are not recorded at anything approaching the normal limits of understanding. They're paced for good conversation or storytelling and know that the vast majority of their listeners are multitasking, not giving them their full attention.
I'd say less transmitting, and more preparation of the message.
"Please move" or "Get the fuck out of the goddamn way" both communicate the same information, one a bit more colorfully.
establishing and maintaining context, desired action and desired outcome take (well, me anyway) a substantial amount of time. Partly (for me) figuring out what the desired outcome actually is, and partly encoding that in a way that will be well received.
Yeah, the sender-side is probably the main bottleneck, just consider how often people speak filler phonemes like "uhm", it's so common that you might not notice unless you're looking for them. They are basically placeholders into the data-stream, to indicate that it isn't over yet but there's a delay producing the next item.
In contrast, consider a listener who is equally focused and invested as the producer: They don't often indicate that their own buffer is full or request a repeat. While you may say "hold up" or "run that by me again", it's usually for reasons other than word-rate. (For example, to prompt the producer to try another encoding, to express disbelief or contempt, etc.)
> It seems like our brains might only be capable of processing ~39 bits of spoken information per second.
I'm quite sure this isn't true, since I can listen to even fast English speakers at 2X speed and still understand them. Although that's right up against my limit, presuming the speaker is already on the fast side of normal.
I would say, rather, that the bottleneck is the human ability to synthesize and speak the message they intend to convey.
As someone who has managed keycloak in production for work, it's a solid solution but boy is it easy to make mistakes that cause difficult to debug issues. It's a headache that does what it says on the tin.
I stopped being interested in poker when I realized that by far the best strategy is simply to play with the worst players you can find. Everything else pales in comparison to simply playing with new players.
I understand that these are people who are willingly coming to play the game and putting up their money but I just don’t feel comfortable intentionally seeking them out to take it from them.
Pretty sure that means I’m simply not cut out to play the game but the theory is definitely interesting.
Brokers fees for the apartment in Cambridge I rent were $4k. This was in addition to first and last months’ rent. Extremely annoying but when every other apartment is doing it too, you don’t have much of a choice if you want to live in the area.
In fact, it’s hard to see where a Level 4 language perfectly fits. After you’ve surpassed the abilities of JSON or YAML (and you don’t opt for slapping on a templating engine like Helm does), it feels like jumping straight to Level 5 is worth the effort for the tooling and larger community.