(Edit: in the old post title:) "everything is a value" is not very informative. That's true of most languages nowadays. Maybe "exclusively call-by-value" or "without reference types."
I've only read the first couple paragraphs so far but the idea reminds me of a shareware language I tinkered with years ago in my youth, though I never wrote anything of substance: Euphoria (though nowadays it looks like there's an OpenEuphoria). It had only two fundamental types. (1) The atom: a possibly floating point number, and (2) the sequence: a list of zero or more atoms and sequences. Strings in particular are just sequences of codepoint atoms.
It had a notion of "type"s which were functions that returned a boolean 1 only if given a valid value for the type being defined. I presume it used byte packing and copy-on-write or whatever for its speed boasts.
> It had a notion of "type"s which were functions that returned a boolean 1 only if given a valid value for the type being defined.
I've got a hobby language that combines this with compile time code execution to get static typing - or I should say that's the plan, it's really just a tokenizer and half of a parser at the moment - I should get back to it.
The cool side effect of this is that properly validating dynamic values at runtime is just as ergonomic as casting - you just call the type function on the value at runtime.
Thanks, I updated the post title based on this and another comment. Thanks for the pointer to Euphoria too, looks like an interesting language with a lot of similar ideas.
Strange. Middle-clicking the link opens a HackerNews frontpage, but copypasting into a new tab shows the article. Presumably the server shoos away referer links? To reduce load maybe somehow? Or maybe something's weird in my own configuration idk.
There are two distinct constructs that are referred to using the name variable in computer science:
1) A ‘variable’ is an identifier which is bound to a fixed value by a definition;
2) a ‘variable’ is a memory location, or a higher level approximation abstracting over memory locations, which is set to and may be changed to a value by an assignment;
Both of the above are acceptable uses of the word. I am of the mindset that the non-independent existence of these two meanings in both languages and in discourse are a large and fundamental problem.
I take the position that, inspired by mathematics, a variable should mean #1. Thereby making variables immutably bound to a fixed value. Meaning #2 should have some other name and require explicit use thereof.
From the PLT and Maths background, a mutable variable is somewhat oxymoronic. So, I agree let’s not copy JavaScript, but let’s also not be dismissive of the usage of terminology that has long standing meanings (even when the varied meanings of a single term are quite opposite).
“Immutable” and “variable” generally refers to two different aspects of a variable’s lifetime, and they’re compatible with each other.
In a function f(x), x is a variable because each time f is invoked, a different value can be provided for x. But that variable can be immutable within the body of the function. That’s what’s usually being referred to by “immutable variable”.
This terminology is used across many different languages, and has nothing to do with Javascript specifically. For example, it’s common to describe pure functional languages by saying something like “all variables are immutable” (https://wiki.haskell.org/A_brief_introduction_to_Haskell).
Probably variable is initially coming out of an ellipsis for something like "(possibly) variable* value stored in some dedicated memory location". Probably holder, keeper* or warden would make a more accurate terms using ordinary parlance. Or to be very on point and dropping the ordinariness, there is mneme[1] or mnemon[2].
Good luck propagating ideas, as sound as it might, to a general audience once something is established in some jargon.
> Probably variable is initially coming out of an ellipsis for something like "(possibly) variable* value stored in some dedicated memory location".
No, the term came directly from mathematics, where it had been firmly established by 1700 by people like Fermat, Newton, and Leibniz.
The confusion was introduced when programming languages decided to allow a variable's value to vary not just when a function was called, but during the evaluation of a function. This then creates the need to distinguish between a variable whose value doesn't change during any single evaluation of a function, and one that does change.
As I mentioned, the terms apply to two different aspects of the variable lifecycle, and that's implicitly understood. Saying it's an "oxymoron" is a version of the etymological fallacy that's ignoring the defined meanings of terms.
I think you are confused by terminology here and not by behavior, "immutable variable" is a normal terminology in all languages and could be says to be distinct from constants.
In Rust if you define with "let x = 1;" it's an immutable variable, and same with Kotlin "val x = 1;"
Lore and custom made "immutable variable" some kind of frequent idiomatic parlance, but it’s still an oxymoron in their general accepted isolated meanings.
Neither "let" nor "val[ue]" implies constancy or vacillation in themselves without further context.
Words only have the meaning we give them, and "variable" already has this meaning from mathematics in the sense of x+1=2, x is a variable.
Euler used this terminology, it's not new fangled corruption or anything. I'm not sure it makes too much sense to argue they new languages should use a different terminology than this based on a colloquial/nontechnical interpretation of the word.
I get your point on how the words meanings evolves.
Also it’s fine that anyone name things as it comes to their mind — as long as the other side get what is meant at least, I guess.
On the other it doesn’t hurt much anyone to call an oxymoron thus, or exchange in vacuous manner about terminology or its evolution.
On the specific example you give, I’m not an expert, but it seems dubious to me. In x+1=2, terms like x are called unknowns. Prove me wrong, but I would rather bet that Euler used unknown (quantitas incognita) unless he was specifically discussing variable quantities (quantitas variabilis) to describe, well, quantities that change. Probably he used also French and German equivalents, but if Euler spoke any English that’s not reflected in his publications.
"Damit wird insbesondere zu der interessanten Aufgabe, eine quadratische Gleichung beliebig vieler Variabeln mit algebraischen Zahlencoeffizienten in solchen ganzen oder gebrochenen Zahlen zu lösen, die in dem durch die Coefficienten bestimmten algebraischen Rationalitätsbereiche gelegen sind." - Hilbert, 1900
The use of "variable" to denote an "unknown" is a very old practice that predates computers and programming languages.
That makes me sad. I also love Posy's content, I'm using his cursors right now, and this new knowledge that there is some of it I cannot see gives me real consumerist FOMO anxiety. A little digging and I couldn't find anything. I don't suppose you remember any keywords?
I forgot how he introed it with the over the top AI visual and saying "I'll be hated for this" and then ends with a funny continuation of that opening.
Wanted features: (1) a way to preview the original MIDI again from a share link like this so I could still compare. Searching "ABBA Gimme Gimme Gimme" found one with the title "ABBA Gimme Gimme Gimme L" so I can't be 100% sure it's the same. And (2) a seekbar for the preview as well.
Kinda weird that search results seem hard-capped at 5. I guess it keeps things simple.
Cool enough I suppose, but the framing had me expecting the more farty twisted squarenoise instruments like in Wario Lands 1-3, and less smooth sines and squares. I tried out Kimi No Shiranai Monogatari and Daft Punk's Aerodynamic.
A fine sentiment, and would probably even be somewhat enforceable, as most AI slop is pretty obvious, but I suspect a lot isn't. You'd have to decide where to draw the line. How much LLM assistance transitions a work from HackerNews into SlopperNews? And how do you tell if the author (or "author") isn't forthcoming?
I'm pretty sure you aren't terribly serious, but I found it interesting enough to give it a little thought.
Edit: I realize now that my assertion "most AI slop is pretty obvious" could be hubris. I'm not actually very confident any more.
It's not about enforcement per se, I just want my old internet back, reading some obscure blogs, pre AI, pre influencers, pre 'content-creators'. There're still small safe spaces. bb forums and the likes.
I'm sad that Platine Dispositif pulled their games. Chelsea Has to Beat the Seven Devils to Death (known more widely in English as Bunny Must Die) was a lot of fun and one day I'd like to play some of their others, but they mostly seem to just release on Switch and Playstation stores in recent years. Their site[1] is getting pretty bitrotted, and their blog has an entry from a month ago[2] talking about their next game displayed in Digital Games Expo 2025. I don't immediately see any mention of Steam or intent to return anywhere.
This is a tangent on language semantics (of the English kind) instead of engaging with the (interesting!) narrative on miscompiles. Feel free to skip.
> A compiler is a translator that translates between two different languages.
I lament the word "compile" subsuming "translate" for most of tech. Computers interpret instructions and do them now, and translate instructions from one code to another that is later interpreted or translated again.
The English word "compile" means "bring together" and compiler systems usually have lots of interpreting and translating and linking to make some kind of artifact file, to wit:
> taking a step back, a compiler is simply a program that reads a file and writes a file
But not necessarily! You don't even need that much! Just source and target codes.
Forth systems (which I enjoy) for example have a single global STATE variable to switch between _execute this word now_ and _compile a call to this word for later_ directly into memory (plus metadata on words that allow them to execute anyway, extending the compiler, but I digress). You could snapshot the memory of the Forth process with its built target program and reload that way, but the usual Forth way is to just store the source and recompile to memory when needed.
Traditional threaded Forths compile calls to a list of routine addresses for a virtual machine interpreter routine (load address then jump to code, not much more work than the processor already does). I prefer subroutine threading, though, where calls are bone fide CALL instructions and the inner interpreter is the processor itself, because it's easier to understand.
Nowadays even the processor translates the instructions you give it to its own microcode for interpreting. It's code all the way down.
I've not tried jj yet so I can only speak to impressions, and those impressions appeal to me a lot. My understanding is that jj amends all the changes in _now_ so there's only one place where changes live: the commit graph. No index, no uncommitted worktree. Just commits. And then jj supposedly gives you a lot more freedom to move through and mutate the commit graph directly, rebasing dependent work for you automatically.
So instead of having to `git add -p` several times to pick apart changes from the worktree, the worktree always goes into the graph and you can `jj split` to pick them apart after.
jj split # split latest commit into two
jj edit @- # go back one
jj describe # change message
jj split # whoops, insert commit in the middle
jj edit @+ # move forward again
$EDITOR myfile # do some changes
jj st # amend the changes and show status
jj edit def # jump elsewhere in the graph
jj squash # put two commits together and auto-rebase its descendants
jj new abc # start working after latest
# etc etc
I confess I'm still pretty new to git. I haven't had a very long time to wed myself to git's index and its presence makes me do extra ceremony that I resent whenever I want to polish my graph for my personal projects.
The main difference, it seems, is workflow: git's "prepare then commit" vs jj's "commit then revise".
Currently I do make use of `git add -p` just like grandparent, but I also feel a psychological burden: I will often leave like 3 or 4 separate 2-line changes in the worktree because I don't wanna bother with the ceremony right now, but my perfectionism also resists me putting a lump commit. That's jj's main appeal to me. It amends my work in, then supposedly let's me sculpt it when I'm ready with less of that ceremony.
JJ and Git seem to have different philosophies, so they cater to different users. I want my VCS to do only things I tell it to, so recording things into the index on its own and automatically rebasing commits are not things I actually want.
> I confess I'm still pretty new to git. I haven't had a very long time to wed myself to git's index and its presence makes me do extra ceremony that I resent whenever I want to polish my graph for my personal projects.
Have you realized, that Git versions the index yet? It was written by a filesystem guy, who (I think) considers the filesystem to be a shared space, so Git doesn't consider the filesystem to be its playground. Think of "git add" less of preparing things for the next commit and more of telling git that it can consider some state to be part of its world model. Your repository does not consist of everything below a directory (it can actually span across multiple randomly located directories), it does consist of everything that was once added to the repository.
> The main difference, it seems, is workflow: git's "prepare then commit" vs jj's "commit then revise".
I do the latter just fine in Git, but yes "git add" is a fundamental part of my workflow. I often add some lines already to the index and start writing the commit message, then trying something again in the working directory and either throwing it away or also adding it, before I finally commit. To me the index is a feature.
> but my perfectionism also resists me putting a lump commit
Sounds like you will use a VCS correctly.
> I don't wanna bother with the ceremony right now
I don't know what exactly you consider to be the "ceremony", but I think nearly any git GUI/TUI will let you add lines by selecting with the cursor and pressing a key. The good ones also allow you to edit this. This also works in the opposite way: removing or editing specific lines from an already existing commit. In my experience carefully adding lines results in less mistakes than adding everything and then carefully removing lines, but YMMV.
In addition to my other comment as you wrote you are not familiar with Git yet, some comparison to these commands. You can be in a commit in JJ, while in Git, you are always outside.
'jj edit' seems to correspond to 'git checkout', '@-' is '@~'. '@+' is not possible in Git, because a commit can have an arbitrary amount of children, Git might not even know about, not sure how JJ does this. @~5 is the 5th ancestor, @^5 is the fifth parent, @{5} is this ref five actions ago. This is the ref-log, which you can look at with 'git reflog' or 'git log --reflog'. 'master@{37.days.ago}' also works.
'jj split': use 'git commit --amend' and unselect changes or 'git reset --soft' to an older version, recommit the first part and then take the original commit on top. A git commit consists of a state, not of a diff so putting some commit on top of another that already contains part of the changes results in splitting the former.
'jj describe': 'git commit --amend'
'whoops, insert commit in the middle': just commit
'jj squash': either 'git reset --soft @~2' then 'git commit -c/C' or 'git reset @~' then 'git commit --amend' or 'git rebase' with squash or fixup. The later is possible from some other commit by using 'git commit --fixup' or even 'git absorb' (I think also exists in JJ).
Working in a detached state is fine, but you might want to add a ref (branch or tag, or something else) when you are finished, otherwise Git will eventually garbage-collect them (defaults to 4 weeks to 90 days depending on how you access the commit). You can push just fine to a remote, just specify the branch, i.e. 'git push origin @:branch'. You can also push to local branches to update them without checking them out with 'git push . @~7:feature/something'. Don't use pull, it is stupid, merge when you want to merge, rebase when you want to rebase, but don't do it implicitly as part of fetch.
Ask, if I glossed over something and shall elaborate.
I've only read the first couple paragraphs so far but the idea reminds me of a shareware language I tinkered with years ago in my youth, though I never wrote anything of substance: Euphoria (though nowadays it looks like there's an OpenEuphoria). It had only two fundamental types. (1) The atom: a possibly floating point number, and (2) the sequence: a list of zero or more atoms and sequences. Strings in particular are just sequences of codepoint atoms.
It had a notion of "type"s which were functions that returned a boolean 1 only if given a valid value for the type being defined. I presume it used byte packing and copy-on-write or whatever for its speed boasts.
https://openeuphoria.org/ - https://rapideuphoria.com/
reply