Skip Navigation
The experience that made me hate programming, but that's all on me
  • This "full on rage essay" is nine sentences, including the tl;dr and the sentence fragments. There's really not a big difference between telling your coworkers a story like this and posting about it on social media.

  • std::underflow_error
  • I've met people with C++ Stockholm Syndrome, and I think their trajectory is different. There's no asymptotic approach toward zero; their appreciation just grows or stays steady, even decades into their career.

  • CppCon 2014: Mike Acton "Data-Oriented Design and C++"
  • When I watched it, I worked on embedded software for research devices, most notably this: https://www.beckman.com/centrifuges/analytical-ultracentrifuges/optima-auc

    I have since worked on a kubernetes job-runner for Spark workloads, insurance systems for a worker's comp startup, and currently the job runner and related software for some quantum computers.

    Most of my work has been in Python, C++, C#, Java, Scala, Go, and Rust. (Rust is my preference.)

  • [History] An editor letter by Edsger Dijkstra, titled: "go to statements considered harmful" (march 1968).
  • Does the catchphrase "blazing fast" ring any bells? Some people care.

    (Arguably that's just the pendulum swinging the other way; Ruby, Python, and Java ruled the software world for a while, and I think that's a large part of why the Go and Rust communities make such a big deal about speed.)

  • Amber - the programming language compiled to Bash
  • It's relevant because there are still platforms that don't have actual Bash (e.g. containers using Busybox).

    sh is not just a symlink: when invoked using the symlink, the target binary must run in POSIX compliant mode. So it's effectively a sub-dialect.

    Amber compiles to a language, not to a binary. So "why doesn't it compile to sh" is a perfectly reasonable question, and refers to the POSIX shell dialect, not to the /bin/sh symlink itself.

  • Amber - the programming language compiled to Bash
  • Compiled code is already effectively write-only. But I can imagine there being some efficiency gains in not always shelling out for arithmetic, so possibly that's a future improvement for the project.

    That said, my reaction to this project overall is to wonder whether there are really very many situations in which it's more convenient to run a compiled Bash script than to run a compiled binary. I suppose the Bash has the advantage of being truly "compile once, run anywhere".

  • Amber - the programming language compiled to Bash
  • No, I mean, analyzing the Amber expression to determine if Bash has a native construct that supports it is unnecessary if all arithmetic is implemented using bc. bc is strictly more powerful than the arithmetic implemented in native Bash, so just rendering all arithmetic as bc invocations is simpler than rendering some with bc and some without.

    Note, too, that in order to support Macs, the generated Bash code needs to be compatible with Bash v3.

  • Amber - the programming language compiled to Bash
  • Yes, I agree package managers are much safer than curl-bash. But do you really only install from your platform's package manager, and only from its central, vetted repo? Including, say, your browser? Moreover, even if you personally only install pre-vetted software, it's reasonable for new software to be distributed via a standalone binary or install script prior to being added to the package manager for every platform.

  • Amber - the programming language compiled to Bash
  • No, I agree that a package manager or app store is indeed safer than either curl-bash or a random binary. But a lot of software is indeed installed via standalone binaries that have not been vetted by package manager teams, and most people don't use Nix. Even with a package manager like apt, there are still ways to distribute packages that aren't vetted by the central authority owning the package repo (e.g. for apt, that mechanism is PPAs). And when introducing a new piece of software, it's a lot easier to distribute to a wide audience by providing a standalone binary or an install script than to get it added to every platform's package manager.

  • The stolen valor of terminal emulators! (+ Can you recommend some good ones for GNOME?)
  • Seconded. Wezterm seems to have a similar level of features and customizability as Kitty, but with Lua as its config/extension language. I migrated from Alacritty rather than Kitty, so I don't know how Kitty's speed compares, but I haven't missed Alacritty, which is honestly saying something.

  • Who's working on a "smaller Rust"?

    Almost five years ago, Saoirse "boats" wrote "Notes on a smaller Rust", and a year after that, revisited the idea.

    The basic idea is a language that is highly inspired by Rust but doesn't have the strict constraint of being a "systems" language in the vein of C and C++; in particular, it can have a nontrivial (or "thick") runtime and doesn't need to limit itself to "zero-cost" abstractions.

    What languages are being designed that fit this description? I've seen a few scripting languages written in Rust on GitHub, but none of them have been very active. I also recently learned about Hylo, which does have some ideas that I think are promising, but it seems too syntactically alien to really be a "smaller Rust."

    Edit to add: I think Graydon Hoare's post about language design choices he would have preferred for Rust also sheds some light on the kind of things a hypothetical "Rust-like but not Rust" language could do differently: https://graydon2.dreamwidth.org/307291.html

    63
    InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)BA
    BatmanAoD @programming.dev
    Posts 1
    Comments 217