• 1 Post
  • 75 Comments
Joined 2 years ago
cake
Cake day: September 24th, 2023

help-circle

  • Full of WTFs.

    My default development environment on Windows is the Linux-like MSYS2 environment

    I think this sets the tone nicely lol.

    it’s clear at this point already that Zig is a weakly-typed language

    Uhm… pretty sure it isn’t.

    You can only use the zig command, which requires a special build file written in Zig, so you have to compile Zig to compile Zig, instead of using Make, CMake, Ninja, meson, etc. as is typical.

    Yeah who wants to just type zig build and have it work? Much better to deal with shitty Makefiles 🤦🏻‍♂️

    Ignoring the obvious memory safety red herring,

    Uhhh

    we can worryingly tell that it is also a weakly-typed language by the use of type inference

    Ok this guy can be safely ignored.

    the fact that the unsafe keyword is required to cooperate with C interfaces gives even great cause for concern

    ?

    Rather than dealing with this ‘cargo’ remote repository utility and reliving traumatic memories of remote artefact repositories with NodeJS, Java, etc., we’ll just copy the .rs files of the wrapper directly into the source folder of the project. It’s generally preferred to have dependencies in the source tree for security reasons unless you have some level of guarantee that the remote source will be available and always trustworthy.

    Lol ok… Ignore the official tool that works extremely well (and has official support for vendoring) and just copy files around and then is surprised that it doesn’t work.

    Although you can use the rustc compiler directly, it provides an extremely limited interface compared to e.g. Clang and GCC

    That is a good thing.

    You get similar struggles with just getting the basic thing off the ground

    Uhm yeah if you ignore the tutorials and don’t use the provided tools. It’s literally cargo init; cargo run.

    What an idiot.









  • Private or obscure ones I guess.

    Real-world (macro) benchmarks are at least harder to game, e.g. how long does it take to launch chrome and open Gmail? That’s actually a useful task so if you speed it up, great!

    Also these benchmarks are particularly easy to game because it’s the actual benchmark itself that gets gamed (i.e. the code for each language); not the thing you are trying to measure with the benchmark (the compilers). Usually the benchmark is fixed and it’s the targets that contort themselves to it, which is at least a little harder.

    For example some of the benchmarks for language X literally just call into C libraries to do the work.




  • LLMs can’t think - only generate statistically plausible patterns

    Ah still rolling out the old “stochastic parrot” nonsense I see.

    Anyway on to the actual article… I was hoping it wouldn’t make these basic mistakes:

    [Typescript] looks more like an “enterprise” programming language for large institutions, but we honestly don’t have any evidence that it’s genuinely more suitable for those circumstances than the regular JavaScript.

    Yes we do. Frankly if you’ve used it it’s so obviously better than regular JavaScript you probably don’t need more evidence (it’s like looking for “evidence” that film stars are more attractive than average people). But anyway we do have great papers like this one.

    Anyway that’s slightly beside the point. I think the article is right that smart people are not invulnerable to manipulation or falling for “obviously” stupid ideas. I know plenty of very smart religious people for example.

    However I think using this to dismiss LLMs is dumb, in the same way that his dismissal of Typescript is. LLMs aren’t homeopathy or religion.

    I have used LLMs to get some work done and… guess what, it did the work! Do I trust it to do everything? Obviously not. But sometimes I don’t need perfect code. For example recently I asked it to create an example SystemVerilog file for me utilising as many syntax features as possible (testing an auto-formatter). It did a pretty good job. Saved some time. What psychological hazard have I fallen for exactly?

    Overall, B-. Interesting ideas but flawed logic.


  • These are probably the biggest reasons, but I think even after literally decades of development the actual desktop is still far behind Windows XP in many respects.

    For example today I wanted to add a “start menu” shortcut to a program I had downloaded. The most popular answer is to *manually create a .desktop file and copy it to some obscure dot directory! Hilarious. Even Windows 3.1 had a built-in GUI for this.

    Ok so there is a GUI to do it, but it isn’t actually integrated into desktops and isn’t installed by default. You have to install it separately.

    It’s the same for things like WiFi settings! There are some settings in GNOME but most are hidden in the third party nm-connection-editor (from memory) and of course GNOME doesn’t have an “advanced settings” button to open that.

    There are so many of these paper cuts I think Linux would be quite a frustrating experience for many people even if if had Windows-level hardware support.

    I also can’t see this changing any time soon. Not that many Linux devs actually care about this sort of thing and many of them don’t even understand that it is a problem in the first place. Cue replies.