Birbla

Discussion summary

The discussion covers Nixie tubes' size and function, the implementation of a subleq machine in a programming contest, and various technical enhancements in low-level programming.

What the discussion says

  • Nixie tubes were larger than some claim, about the size of vacuum tubes.
  • A subleq machine was implemented with additional features like LLVM backend.
  • Optimizations like indirect addressing and macros are discussed for performance and creativity.
“Nixie tubes were about the size of a vacuum tube.”
— drfuchs
“The subleq machine also had a full LLVM backend and compiler.”
— wzdd

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • > 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)

    by RicoElectrico
  • 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.
    by drfuchs
  • You are confidently incorrect.

    https://ethw.org/Nixie_Tubes

    by tasty_freeze
  • 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?
    by russfink
  • Given the Mandelbrot program is 450k probably not.
    by wzdd
  • 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
    by NooneAtAll3
  • 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.

    by anthk
  • They already added indirect addressing (see https://github.com/adriancable/eternal/blob/main/docs/machin...) to make it faster.
    by dividuum
  • 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?

    by Refreeze5224
  • With macro rust can surely produce some creative stuff
    by Narew
  • 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.

    by bunderbunder
  • 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.

    by AlotOfReading
  • Typechecking is more less picking a decidable set of invalid programs and making an efficient checker for them. As for ruling out programming styles, a language is, after all, Turing complete, so one could write an IR and an interpreter and then encode the rest of the program in the IR...

    Personally, while I see the social advantages of having all code in one language be similarly structured and use the same idioms, I think a language is meant to be used, and it should offer all the building blocks for writing programs in whatever is the most natural way.

    by titzer