because someone believed an ANSWER on a different question answered my question
Yeah that is actually their official position. Your question is duplicate if an answer elsewhere might answer it, which is clearly absurd. Essentially they think “what’s 1+3?” is a duplicate of “what’s 2+2?”.
I think fundamentally they gamified moderation too well, and for many people they turned the site into a mod-maxing game, which obviously makes it an abysmal place to be for normal users.
It isn’t really. This is based on slightly implausible statistics and an unusual definition of “growing”.
Can’t remember tbh. It was a work setup. It wasn’t an unreasonable one though. 32 is not very many!
I hit a bug recently in KDE Wayland where the task bar was just slightly offset from the edge of the screen, so there was a gap behind it. Very dumb.
OPAM (OCaml’s package manager) had a bug where it couldn’t find curl or wget to download stuff with (don’t ask me why it shelled out to those in the first place) if you were in more than 32 Unix groups. Have fun thinking of a reasonable explanation for that!
Even if there are tight time constraints, you won’t sacrifice quality, because that would make you slower.
Too right. People find this so hard to understand. I think they dramatically underestimate the payback time on technical debt.
I am currently working in a startup that has the classic “we’re a startup, quality doesn’t matter” attitude. They think that they might not be around in a year so it’s best to go fast and not give a shit about tech debt.
In my experience that attitude bites in under 6 months. I’m already wasting entire days sorting out messes that they neglected to deal with.
I mean, it would be great if this succeeded… ffmpeg is nice and all but its interface is clearly terrible and there’s absolutely no way it is remotely secure. Anyone that uses it on a server basically has to run it in its own VM, or a severely locked down sandbox.
But good luck supporting all the codecs people expect. I’m not even talking the obscure ones ffmpeg supports; just the ones “normal” people use will be a life’s work.
Also you have to change the name!
Obscure 10 years ago maybe. These days there have been so many articles about them I bet they’re more widely known than more useful and standard things like prefix trees (aka tries).
I think this could have been about 1/4 the length. Fairly basic stuff by modern standards and you don’t need so many words. It is all correct at least, as far as I could see!
Yeah… I mean they should have just copied whatever video conferencing platforms do because they all work fine behind corporate proxies and they also don’t suffer from this “increasing delay” problem.
I haven’t actually looked into what they do but presumably it’s something like webrtc with a fallback to HLS with closed loop feedback about the delay.
Though in fairness it doesn’t sound like “watching an AI agent” is the most critical thing and mjpeg is surprisingly decent.
Doesn’t say anything you didn’t already know. Probably written with AI.
Also the conclusion is wrong:
Neither approach is universally superior.
The Rust approach is obviously superior.
Right, I’m not saying it isn’t simpler in terms of syntax. The point I was making is that the syntax is simpler but in a way that makes it worse because while it’s easier for computers to read, it’s harder for humans.
it was only later discovered that they can be compiled down to native code.
That sounds extremely unlikely. I think you’re misinterpreting this quote (which is fair enough; it’s not very clear):
Steve Russell said, look, why don’t I program this eval … and I said to him, ho, ho, you’re confusing theory with practice, this eval is intended for reading, not for computing. But he went ahead and did it. That is, he compiled the eval in my paper into IBM 704 machine code, fixing bugs, and then advertised this as a Lisp interpreter, which it certainly was. So at that point Lisp had essentially the form that it has today …
As far as I can tell Lisp was always intended to be compiled and executed. That quote is about compiling the eval() function (which was just meant to explain how Lisp is executed) into a binary and using that as an interpreter.
Also I skimmed the paper that is from, and in fact Lisp was intended to be targeted by AI (in the same way that we get AI to write and execute Python to solve problems), which explains a lot. It wasn’t designed for humans to write, so why bother with nice syntax; just have the machine write the AST directly!
(I expect that was only part of the motivation tbf, but still!)
This comment perfect captures why I don’t like Lisp. Essentially “it’s simple, this easy to read code transforms to this AST”. Lisp basically says “we can make parsing way easier if we force programmers to write the AST directly!” which is really stupid because computers can perfectly well parse syntax that is easy for humans to read and turn it into ASTs automatically.
It makes it easier to parse for computers at the cost of being much harder to parse for humans, which is really the wrong choice in most cases. (The exception is if you’re DIYing your compiler, e.g. if you’re teaching how to write a compiler then Lisp is a good target.)
Yeah it’s great for little scripts. There’s even a cargo script feature that’s being worked on so you can compile & run them using a shebang.
I’d use a shell script if it is literally just a list of commands with no control logic or piping. Anything more than that and you’re pointing a loaded gun at your face, and should switch to a proper language, of which Rust is a great choice.
It’s definitely a growing problem with Rust. I have noticed my dependency trees growing from 20-50 a few years ago to usually 200-500 now.
It’s not quite as bad as NPM yet, where it can easily get into the low thousands. Also the Rust projects I have tend to have justifiably large dependencies, e.g. wasmtime or Slint. I don’t think it’s unreasonable to expect a whole GUI toolkit to have quite a few dependencies. I have yet to find any dependencies that I thought were ridiculous like leftpad.
We could definitely do with better tooling to handle supply chain attacks. Maybe even a way of (voluntarily) tying crate authors to verified real identities.
But I also wouldn’t worry about it too much. If you a really worried, develop in a docker container, use a dependency cooldown, and whatever you do don’t use cryptocurrencies on your dev machine.
Best option is to switch to C++ and use QtWidgets. You don’t need to know much C++ for that - if you want to tediously micromanage strings you can still do that in your business part of the program.
It’s the language and the domain. They work pretty well for the web and major languages (like top 15).
As soon as you get away from that they get drastically worse.
But I agree they’re still unambiguously useful despite their occasional-to-regular bullshitting and mistakes. Especially for one-off scripts, and blank-page starts.
Is Deno not convenient and fast? I am also interested in knowing why I would want to use Bun over Deno.
I’m glad this is still alive. It’s a good idea. I keep thinking about doing the same for TCL.
I do wonder if Bash is perhaps just a bit too insane to make this really feasible though.
Reversed range support
This is a misfeature.
It’s because as soon as one country forces it on their citizens the others can say “it can’t be that crazy - Australia and the UK have already done it!”