I wonder at what level you could enforce/how far you could take the idea of "don't allow invalid states to be represented" to a programming language, to prevent this kind of language debauchery.
C does seem to sit at the perfect intersection of language age and low-level access to allow this kind of competition, whereas something like Go seems far less suited for it. Javascript is routinely obfuscated pretty well for human readers. I'm not familiar enough with Rust to say, but I bet with what little I know of its syntax you could create some pretty ugly stuff?
> at what level you could enforce/how far you could take the idea of "don't allow invalid states to be represented" to a programming language
Standard ML, Haskell, and Lisp, among other languages are pretty serious about invalid states. One should never be able to break the virtual machine and put it into an unknown state, unless intentionally mucking around with unsafe {} or its equivalent. Rust is often described as being at least partly in the ML family because of its approach to types and safety, which is very ML-ish.
Dependent typing like in Rocq goes even further, and makes it impossible to express invalid algorithms. Expressing practical programs in formal terms like that is rather hard though. It largely goes over my head, for sure.
I used to write obfuscated C for fun. I haven’t touched it in a while, but as I recall there are really two C syntax features that unlock most of the “magic”. Whitespace is generally not significant, so you can cram a whole lot onto a single line. And the combination of pointers and weak typing lets you be as anarchist as you like about manipulating data. (Oh, and the preprocessor. The one and - thankfully - only C preprocessor.)
Of the two^H^Hhree, I think that the first is what contributes most to the aesthetic appeal of obfuscated C. The only other languages I’ve used that are as good for making code that looks impenetrable are Forth and JavaScript, both of which share that feature.
(Probably any lisp, too, but for some reason I’ve never actually tried. I can say, though, that the most confusing codebase I ever inherited was written in Clojure.)
So yes, I’m inclined to agree that Rust can be a good language for writing deliberately ugly code, and Go not so much. But for a different, perhaps more trivial reason.
On the subleq VM, it would run faster if they implemented Muxleq, but it woudn't win the IOCCC contest maybe. Altough in unobfuscated it's C it's just an extra short if clause with two more lines.
TL;DR: the one entry implemented a subleq machine. Google it - it’s a One Instruction Set Computer (OISC). This made me smile. But it also raised a question: when were OISC’s first conceived? Would Apollo and computers of that era have benefitted from this insight?
that entry won not because it "just" implemented subleq. Dude also made LLVM backend for it, drivers, set up full-on compiler and successfully did compile-and-run for tons of various programs
I've found an OISC that is surprisingly efficient.
four operands: A B D N
D = A - B. If zero or negative then jump to N else PC++.
Various configurations of this give one instruction for: move, subtract, branch equal, jump, inc, dec and most key: branch and link return address. Two instruction sequences synthesize: add, push, pop. And self-modifying code two instruction sequences for: load, store, call, return from call.
With a bunch of macros you get a reasonable instruction set.
Self-modifying code is terrible from an implementer's perspective once you want to go pipelined and have caches involved. And the instruction set lacks any way to rotate right or operate bitwise. So that involves an expensive loop over the width of the word. Otherwise quite practical.
The AI slop Lisp interpreter weighed in at about 40 kilowords.
> Nixie tube is a tiny electrical tube with filaments in the shapes of all the digits stacked one on top of another, and it displays the desired digit by making just that filament glow
Lol, no. That's a Numitron (although they were 7 segment)
Nixie tubes, like all gas-discharge tubes with negative light, do not use any filament.
A filament could be needed with a higher pressure gas, to emit electrons that would ionize the gas, to facilitate the initiation of a discharge. A filament might also be needed sometimes when the gas is a metal vapor, like mercury vapor or sodium vapor, in order to heat and vaporize the metal, though that is more commonly done by adding some noble gas, like neon, to cause a preliminary discharge that heats the metal until enough vapor is present, which allows the initiation of the main discharge.
You are of course right, but you should have pointed out that the text quoted by you was not 100% wrong, because the ten cathodes have indeed the forms of the ten digits and they are stacked one above the other.
The only wrong parts were that the cathodes are not filaments and the cathodes themselves do not glow.
The Nixie tubes are filled with neon at low pressure and the electric discharges through them produce the so-called negative light, i.e. where the luminescent gas is confined around the cathode. Therefore the negative light takes the shape of the cathode. The cathodes are not glowing, but they are surrounded by glowing neon gas.
In my opinion, negative light, which comes from an apparently empty space, looks somehow more beautiful than solid light emitters, like an incandescent filament or a fluorescent lamp (like VFD, i.e. vacuum fluorescent displays; display tubes with incandescent filaments or with fluorescent segments were alternatives to Nixie tubes, until all of them were replaced by cheaper LEDs and LCDs).
The neon tubes that were used in advertising for making letters or other shapes, use positive light instead of negative light, i.e. where the luminescent gas occupies most of the glass tube, away from the electrodes, so giving various shapes to the glass tube provides various shapes of the visible light, regardless of the shapes of the electrodes (unlike for negative light, where the shape of the cathode matters, while the shape of the glass tube is irrelevant).
Also, Nixie Tubes were absolutely not “tiny.” Typically, they were about the same size as a vacuum tube you’d find in the back of your radio or TV. They were universally used on electronic equipment; less so on consumer devices.
I wonder at what level you could enforce/how far you could take the idea of "don't allow invalid states to be represented" to a programming language, to prevent this kind of language debauchery.
C does seem to sit at the perfect intersection of language age and low-level access to allow this kind of competition, whereas something like Go seems far less suited for it. Javascript is routinely obfuscated pretty well for human readers. I'm not familiar enough with Rust to say, but I bet with what little I know of its syntax you could create some pretty ugly stuff?
> at what level you could enforce/how far you could take the idea of "don't allow invalid states to be represented" to a programming language
Standard ML, Haskell, and Lisp, among other languages are pretty serious about invalid states. One should never be able to break the virtual machine and put it into an unknown state, unless intentionally mucking around with unsafe {} or its equivalent. Rust is often described as being at least partly in the ML family because of its approach to types and safety, which is very ML-ish.
Dependent typing like in Rocq goes even further, and makes it impossible to express invalid algorithms. Expressing practical programs in formal terms like that is rather hard though. It largely goes over my head, for sure.
You can write programs of a similar spirit in most languages. C has a programming culture that's much more tolerant of it than say, Python though.
Zig could probably support a similar contest as it grows up.
I used to write obfuscated C for fun. I haven’t touched it in a while, but as I recall there are really two C syntax features that unlock most of the “magic”. Whitespace is generally not significant, so you can cram a whole lot onto a single line. And the combination of pointers and weak typing lets you be as anarchist as you like about manipulating data. (Oh, and the preprocessor. The one and - thankfully - only C preprocessor.)
Of the two^H^Hhree, I think that the first is what contributes most to the aesthetic appeal of obfuscated C. The only other languages I’ve used that are as good for making code that looks impenetrable are Forth and JavaScript, both of which share that feature.
(Probably any lisp, too, but for some reason I’ve never actually tried. I can say, though, that the most confusing codebase I ever inherited was written in Clojure.)
So yes, I’m inclined to agree that Rust can be a good language for writing deliberately ugly code, and Go not so much. But for a different, perhaps more trivial reason.
With macro rust can surely produce some creative stuff
On the subleq VM, it would run faster if they implemented Muxleq, but it woudn't win the IOCCC contest maybe. Altough in unobfuscated it's C it's just an extra short if clause with two more lines.
On 32k roms for the GB emulator:
https://github.com/tbsp/Adjustris
Old build:
https://pdroms.de/?__df=24010f101611170c163a13544b55553a4d22...
Someone ping back the IOCCC creator, please.
TL;DR: the one entry implemented a subleq machine. Google it - it’s a One Instruction Set Computer (OISC). This made me smile. But it also raised a question: when were OISC’s first conceived? Would Apollo and computers of that era have benefitted from this insight?
that entry won not because it "just" implemented subleq. Dude also made LLVM backend for it, drivers, set up full-on compiler and successfully did compile-and-run for tons of various programs
I've found an OISC that is surprisingly efficient.
four operands: A B D N
D = A - B. If zero or negative then jump to N else PC++.
Various configurations of this give one instruction for: move, subtract, branch equal, jump, inc, dec and most key: branch and link return address. Two instruction sequences synthesize: add, push, pop. And self-modifying code two instruction sequences for: load, store, call, return from call.
With a bunch of macros you get a reasonable instruction set.
Self-modifying code is terrible from an implementer's perspective once you want to go pipelined and have caches involved. And the instruction set lacks any way to rotate right or operate bitwise. So that involves an expensive loop over the width of the word. Otherwise quite practical.
The AI slop Lisp interpreter weighed in at about 40 kilowords.
https://github.com/retrac0/ulqasm/blob/main/demos/13_protoli...
Given the Mandelbrot program is 450k probably not.
> Nixie tube is a tiny electrical tube with filaments in the shapes of all the digits stacked one on top of another, and it displays the desired digit by making just that filament glow
Lol, no. That's a Numitron (although they were 7 segment)
You are confidently incorrect.
https://ethw.org/Nixie_Tubes
your article says it's a gas discharge vacuum tube, so no filament. You seem to be confidently incorrect too.
Multiple types of gas discharge vacuum tubes use a filament of some sort for excitation, be it a coil or grid.
Nixie tubes, like all gas-discharge tubes with negative light, do not use any filament.
A filament could be needed with a higher pressure gas, to emit electrons that would ionize the gas, to facilitate the initiation of a discharge. A filament might also be needed sometimes when the gas is a metal vapor, like mercury vapor or sodium vapor, in order to heat and vaporize the metal, though that is more commonly done by adding some noble gas, like neon, to cause a preliminary discharge that heats the metal until enough vapor is present, which allows the initiation of the main discharge.
Filament implies it is resistively heated, per tube terminology. Nixie is essentially a neon lamp, specially shaped, whose cathode is cold.
You are of course right, but you should have pointed out that the text quoted by you was not 100% wrong, because the ten cathodes have indeed the forms of the ten digits and they are stacked one above the other.
The only wrong parts were that the cathodes are not filaments and the cathodes themselves do not glow.
The Nixie tubes are filled with neon at low pressure and the electric discharges through them produce the so-called negative light, i.e. where the luminescent gas is confined around the cathode. Therefore the negative light takes the shape of the cathode. The cathodes are not glowing, but they are surrounded by glowing neon gas.
In my opinion, negative light, which comes from an apparently empty space, looks somehow more beautiful than solid light emitters, like an incandescent filament or a fluorescent lamp (like VFD, i.e. vacuum fluorescent displays; display tubes with incandescent filaments or with fluorescent segments were alternatives to Nixie tubes, until all of them were replaced by cheaper LEDs and LCDs).
The neon tubes that were used in advertising for making letters or other shapes, use positive light instead of negative light, i.e. where the luminescent gas occupies most of the glass tube, away from the electrodes, so giving various shapes to the glass tube provides various shapes of the visible light, regardless of the shapes of the electrodes (unlike for negative light, where the shape of the cathode matters, while the shape of the glass tube is irrelevant).
Also, Nixie Tubes were absolutely not “tiny.” Typically, they were about the same size as a vacuum tube you’d find in the back of your radio or TV. They were universally used on electronic equipment; less so on consumer devices.