My favourite one was on a C64 disk mag called "Input". It looked roughly like this:
menu entry 1
<-> * menu entry 2
menu entry 3
-----------------------------
with
<-> a little space ship
* a projectile
----- the ground
You had to move the spaceship up and down and then fire at the menu entries to select them.
Since the menu entries had gaps between them you could miss. You likely missed by accident even, because control on home-computers was not what we are used to today.
When you missed the projectile was reflected from the opposite wall and if you didn't dodge, it hit your own ship.
The little ship crashed to the ground and a tiny, just a couple of pixels, figure appeared complaining and dragging his broken ship off the screen.
This reminds me why I studied CS. I planned to do something else but one day in school we got the assignment to write a computer program and I wrote an ascii scroller game instead and I realized how fun that is and changed my plans to become a programmer.
I put it in AI and even that couldn't fix the sentence sufficiently for me to understand it completely.
"So, in ordinary language:"
"One dirty raw ingredient introduced far more spores than expected, and the way it was mixed into the water made the sterilization cycle less effective against them. The autoclave itself was probably not broken."
"The exact relationship to water temperature remains somewhat ambiguous because the HN commenter did not provide the detailed investigation findings."
To be fair I omitted some key information.
The 'dirty raw ingredient' mixed in room-temperature purified water wasn't sterilisable. The same process but mixed in 60°C purified water was sterilisable.
It actually took me a minute to decide whether or not to upvote the AI-content post. But it was informative, you were forthcoming on the origin, and the GP has yet to elaborate. Thank you for posting that.
It's nice they acknowledge and confirm the need for small, fast native executables.
Having followed the story for this in Java over the decades I'm skeptical about the practicality.
GCJ existed in the 90s and the technology was good, but there was no ecosystem support.
After many small steps between GraalVM Native finally tackled the problem more holistically and the ecosystem followed. All the major libraries and frameworks put effort into being GraalVM compatible.
And, still it's a major pain to make even simple existing applications run flawlessly natively.
I'm glad something like scriptc exists but I'm afraid until this is of practical use it will be s long thorny way.
I think the Graal team was also trying to take a meta-interpreter approach like this too. For cases where you need to dynamically load bytecode or do reflection where native couldn't handle it they would try to interpret with their espresso java implementation.
It was and is the conventional extension for the Perl programming language, and Perl was most popular for server side (CGI) scripts for some time.
At same time the idea that webserver and user agent should negotiate the most suitable form of content was all the rage. Little of that survived (compression algorithm) but it used to be used for language as well.
Apache had the convention to use the two letter language code as file extension to encode the language. For example it shipped with collection of error messages in many languages, e.g. 404.html.pl.
Since this conflicted with Perl CGI scripts, Perl got .plx for Perl Executable in Apache and it was proposed as the official Perl extension, but did not stick.
"Our task as the older generation is to shield the young from those who would exploit their naïveté without infecting them with our own accumulated pain and cynicism." [33:53] stuck with me and is my take away.
Shield is the wrong word. At some point, the shield must fall, and then the young are no longer young, but are still näive.
There will always be exploiters, don't believe that they will die once we manage to shield the young for enough time for the exploiters to die of old age.
People are good at different things. Usually they like the things they are good at and vice versa. Different tasks require different mind sets and dev, QA and ops are vastly different in that regard.
That is why we have assembly line production in basically every industry except software.
I think INI-style config is one of the few good things that came out of the Microsoft/Windows ecosystem. Shame that it is so underspecified. We have TOML, of course, but I think for stupid config even that is too much.
The intersection of INI and TOML would be perfect.
All scalar types other than strings (especially nonsense like datetimes). I'm already ingesting the configuration file as a string and parsing it into a language with actual types, e.g. Rust, and the act of parsing it into my defined configuration type will itself identify any problems with the config; having half-assed types like "int" in the config file format itself is not only useless, it's counterproductive because it requires people to ask questions like "okay, but what actually is the maximum range of integer values allowed to be contained in this type?". Just enforce UTF-8 encoded string values and let me take care of data validation.
You won't end up with a mix in the same program unless the code that you're using to parse the config is deliberately written to allow a mix, which no sane code owner would allow. And even if it did, that still wouldn't be enough to outweigh the aforementioned downside of the impedance mismatch between the """types""" in your config file format (how many bits wide is this integer? how much precision is this float? how is nullable data represented?) and the types in your actual language where it matters.
How do you figure? Commodore had strong sales through the late 80s, and the C64 wasn't discontinued until 1994.
My family's C64 was the first computer I ever used, and I am barely in my mid 40s. And although my family later purchased an IBM PC clone around '89 or '90, that just meant the C64 moved into my older brother's room, where we used it even more.
"Mid thirties" is absolutely not a common definition of mid life. For reference, Wikipedia defines "middle age" as being the age range from 40 to 64, based on citing nine different sources: https://en.wikipedia.org/wiki/Middle_age
And also why do you believe the life expectancy for HN users (mostly adults, large portion based in US) is only 72?!
Sure and there you have the problem. No wonder people who do not take mid life literally and plan as if half of it is over with 36 (or let it be 40 if you must) are in crisis with 50. "Midlife" is really just an euphemism for "old, but in denial".
Making the thing that describes the bounds of an arbitrary length thing itself arbitrary length sound like an unnecessarily risky complication to me.
Especially since it only grows with the log of the thing it bounds. So, we could easily have s fixed length length field that covers all ever possible length values.
Or you could just have the standard have a "Conformance Limits" section where it says something similar to "Every implementation shall support a length field value of at least 9223372036854775807, with an unlimited number of leading zeros".
In other words, values beyond that are not forbidden by the spec, but are outside of the conformance requirements. It is a quality of implementation issue whether a given implementation handles more than required.
My favourite one was on a C64 disk mag called "Input". It looked roughly like this:
with You had to move the spaceship up and down and then fire at the menu entries to select them.Since the menu entries had gaps between them you could miss. You likely missed by accident even, because control on home-computers was not what we are used to today.
When you missed the projectile was reflected from the opposite wall and if you didn't dodge, it hit your own ship.
The little ship crashed to the ground and a tiny, just a couple of pixels, figure appeared complaining and dragging his broken ship off the screen.
reply