[ my public key: https://keybase.io/talideon; my proof: https://keybase.io/talideon/sigs/xrQeNgJwDeDVr__AMXDdSK8I6jDosMvyymcRZIGGMyA ]
- The latest US national security strategy, one would assume.
- asciinema should do the job. It has GIF generation support via its 'agg' tool: https://docs.asciinema.org/manual/agg/
- You can at least in part blame Milton Friedman for this mess. His reframing of ficudiary duty as profit maximisation in his "shareholder theory" has done a tremendous amount of damage. The wariness of people when it comes to public companies is a direct consequence of this.
- > mean do plumbers have an advent of plumbing where they try and unblock shit filled toilets for fun?
You've obviously never watched "Drain Cleaning Australia" on YouTube!
Yes, some people find this stuff fun, because they find coding fun, and don't typically get to do the fun kind of coding on company time. Also, there'd be a hell of a lot less open source software in the world if people didn't code for fun.
Let people enjoy things. Just because you don't like that par of your job as much as them doesn't mean they're wrong.
- OCaml. There's just enough in the standard library to cover what you need for everything, for any non-trivial parsing tasks, there's a parser generator and lexer generator bundled, and if you want to pull in extra support libraries so you're not looking to implement, say, a trie from scratch.
- I typically use OCaml myself for them and have never found the standard library to be particularly "depleted" for AoC, though I do have a couple hundred lines of shared library code built up over the years for parsing things, instrumenting things, and implementing a few algorithms and data structures that keep cropping up.
Also, dune makes pulling in build dependencies easy these days, and there's no shame in pulling in other support libraries. It's years since I've written anything in Haskell, but I'd guess the same goes for cabal, though OCaml is still more approachable than Haskell for most people, I'd say. A newbie is always going to be at some kind of disadvantage regardless.
- That's not right. They were an early investor in ARM Ltd., but they in no way "helped develop ARM". That was all Acorn. ARM Ltd was created because Apple thought ARM was a good fit for the Newton, but didn't want to be beholden to a competitor, which Acorn was.
- Starlark is a subset of Python that's only primitive recursive. And in a distributed build system, being able to guarantee termination is a very good thing. It also means Bazel can do predictable fan-outs of builds. Starlark has very good reasons for existing.
CMake almost ended up using Tcl, but it was rejected because that would've introduced an external dependency, running counter to what they were trying to achieve at the time. Would Lua have been a good alternative to creating their own (rather janky) language? Sure, but Lua had very little mindshare in 2000. Even with the weird configuration language it has, it's still preferable to the horrible agglomeration of m4 macros that is Autotools.
If you want to pick on any build system for not picking an existing language, Meson would be a better target, as it's similar to but not Lua, and a suitable subset of Starlark-esque subset of Lua would've been useful.
- Well, I'd say the Qualcommisation of Arduino is happening as expected and apace.
- True, but writing imperative code in OCaml feels quite right. Maybe it's just me, but it always feels significantly clunkier than the functional equivalent. I've had things I've been implementing and though "this works be easier to express imperatively", and almost invariably I've gone and rewritten the code to be functional because of how ungainly the imperative implementation ended up being. It feels a bit too much like somebody embedded a subset of Rexx or Pascal awkwardly into an otherwise perfectly reasonable functional language
- If that's what you use as your yardstick of what's Unixy, then I guess you don't consider "find" to be Unixy, in spite of being one of the early Programmer's Workbench tools.
Short options were a compromise to deal with the limits of the input hardware at the time. Double dashes were a workaround for the post-dash option car crash traditional Unix tooling allows because teletypes were so slow. There is nothing particularly Unixy about any of these options other than the leading hyphen convention.
OCaml using single hyphens is not un-Unixy.
- Yeah, this puzzled me too. I'm assuming they're referring to the semantics of "var" in JS vs "local" in Lua, with the latter resembling "let" in JS, which doesn't have broken scoping.
- You're conflating a few things here. V8 and Spidermonkey aren't the only interpreters out there. There are a number of them explicitly designed to be small, easy to compile and to embed, such MuJS, Fabrice Bellard's QuickJS, and more still. I can't speak to their FFI interfaces, but you can't judge JS's ability to call C functions based off that of Node/V8. I'm not sure how FFI runs against its execution model given JS is generally used as an embedded language, necessitating foreign function calls.
- Sure, there are many ways to achieve the same end of limiting blast radius, but that's not really the point here: the point is that we should dismiss projects like this solely because something might go wrong, especially when there are ways to mitigate against real damage.
- Nah. There are ways to mitigate the blast radius of experiments like this.
You can't utterly wrap developers up in cotton wool. Ultimately, people learn strong lessons from screwing up. You can at least make sure they're doing this learning within a sandbox in which the damage is contained. Like, maybe containerising it so it has limited access to anything that could do any real damage. If somebody builds a blogging app and the worst thing that happens is that they learn the value of sanitising your input, preventing SQL injection, that spam is an unfortunate fact of life, and that you should be very careful with how you manage cookies, I would consider that a _very_ big win for that novice developer.
Because we're talking about _developers_ here.
- The only way it can break is if you skip straight to forward to a release that no longer contains the tooling allowing you to make the transition cleanly. They outlined this is the article.
- It's Mitchell's hobby project. If he had an interest in improving other technologies, he would. People are allowed to have hobbies.
- Ghostty is his hobby project: why would he do that?
- The Python docs say it's part of the built-in standard library, not that it's literally there and in scope by default.
We learned the value of modularity decades ago. This is a sign of Fortran's age, not a good thing. Very few modern languages that aren't heavily domain-specific will have more than a bare minimum of functions in scope by default without needing to import them or a module containing them. The only relatively counterexample I can think of is PHP, and even it's grown namespaces over the years.
Secondly, what does this give me that either systemd or Supervisor (where systemd isn't available) don't already give me?