• 6 Posts
  • 92 Comments
Joined 3 years ago
cake
Cake day: September 7th, 2023

help-circle
  • Ease of adoption, if I’m not mistaken (so I was told 20-ish years ago when I started learning C++). Think back to the early/mid '90s - there was a lot of existing C code out there back then, people really didn’t want to throw it away but had few options if they wanted to use something else. C compatibility offered a way for large companies to incrementally adopt C++. All you had to do was change your compiler and your existing C code would compile, and you could write new stuff in C++. In the mean time, other languages could only leverage that existing code by using message passing or FFI-like frameworks. For example, you would have to use JNI if you were writing Java I think - maybe there were other options, but it was a big pain to deal with at the time, especially since tooling was probably not as polished back then.

    Maybe it’s not as much of an issue today, but they have to maintain compatibility with earlier versions, so while it helped adoption a lot, it also is a big challenge for the language and its ability to move forward.


  • Sure, I’m familiar with the conditions under which Javascript was created, but those are all political issues, not technical ones.

    If you had to go back and recreate another C++, you would be forgiven for creating a bad language, because making a good, usable language without a garbage collector is really hard, and even moreso when it has to be compatible with C. If you had to recreate Javascript… I would think it would be expected that you don’t make a language with the same kinds of flaws JS has today. There were plenty of examples of languages Javascript could have been based off of when it was written (like Java).

    Case in point: it took decades for Rust to come around which was the first real challenge to C++. In the same period of time, we saw several GC languages appear (Java, C#, Go, PHP, Swift, Ruby, Python, all younger than C++), all competing against each other. Javascript would have been abandoned if it didn’t have a monopoly on web programming.



  • I’m not trying to goad you into an argument, though I could have admittedly phrased things better. I just can’t think of any reason why someone would want adopt Javascript as it is with all of its problems. A slice of pie is better than nothing at all. On the other hand, using Javascript when a much better alternative exists (namely Typescript) would be a significant liability in my opinion.

    In fact, pretty much everyone on our front-end team at work would agree too - they’re pretty much unanimous in saying that Javascript should basically never be used.


  • I also agree that Javascript is worse. C++ has two excuses for being bad:

    1. It has to be compatible with C, a language that’s multiple decades older than it, and
    2. It is not garbage collected.

    Javascript has neither of those two excuses. People only use it today because of the ubiquity of web programming. In fairness, it did kill off a few other technologies, like Flash and Java applets, but that was more Webkit and Chrome picking it as the winner than anything else.

    Maybe these arguments are a bit hand-wavy, but the way I see it, it’s like the C of the web programming era.


  • C++ and JS are objectively shit languages from the pool of used languages.

    This is a great point. There are a lot of even worse languages that are dead/dying and deserve to do so.

    But personally, I see a lot of people who continue to defend JS. And I have worked in C++ for about 5 years now and nobody I have worked with praises the language - most want to ditch it entirely and switch to Rust. I can think of maybe one person who claims that C++ is good enough, which is hardly any praise.

    This is all anecdotal stuff, so maybe we don’t see eye-to-eye though. I personally love C++, because it’s a really fun language to write, but I simultaneously think it’s an awful language, and the people who write/standardize it keep making the same kinds of bad mistakes over and over again.




  • I haven’t read through the other responses in the thread, but I don’t think it’s the slightly old software that’s the problem. I think it has more to do with using older kernels, meaning that the latest hardware won’t always be supported (on the stable branch at least - there’s always testing and unstable too of course which may have better hardware support).

    That may have changed with recent releases though - I haven’t used Debian for several years now. But if your hardware is supported then it’s a pretty solid choice.

    Some other people sometimes mention that Debian isn’t as beginner friendly as Ubuntu or Mint, but my experiences have been similar to yours - I found Debian to more user-friendly than Ubuntu for example. Assuming that the hardware works of course - if it doesn’t then it obviously is a worse choice.


  • I also don’t get why they seem to be popular with people who like to act scientific, because they seem very unscientific to me.

    They absolutely are. And it’s very aggravating to see people immediately invoking it without a second thought. They just assume it to be some absolute universal truth that should be accepted without question. But why?? How is that any different from religion at that point?


  • I utterly loathe Hanlon’s razor. It’s peak naivete, especially when it’s applied to groups of people that have ulterior motives - like business interests. It essentially gives companies a carte blanche to do evil shit, and when they get caught, all they have to do is blush and say “oops, how could that have possibly happened???!” But in reality, they were just doing some sort of self-serving behavior and hoping they could get away with it. And of course, they’ll just end up doing it again a few months or years later on when the attention has died away.

    Moral of the story: Hanlon’s razor does not apply to corporations or other business interests. If it’s your neighbors, well maybe give them the benefit of the doubt. If it’s a multinational conglomerate, hell no, fuck that. Assume guilt 100% of the time.


  • The whole notion of CSDs is a blueprint example of what happens when UI designers try to think things through too hard. They come up with grand solutions to trivial problems that are so poorly thought through that they create even bigger problems.

    Realistically, nobody is going rewrite their entire application just because of what a tiny cabal of Gnome developers think. Just read this post that was linked elsewhere in this thread. At the end, Tobias is basically arguing that people should go out there and harass the developers of all Linux desktop applications (including the entire KDE project!) to follow through on this ridiculous idea:

    Thus, our goal is for as many apps as possible to have the following properites [sic]

    • No title bar
    • Native-looking close/maximize/minimize icons
    • Respects the setting for showing/hiding minimize and maximize
    • Respects the setting for buttons to be on the left/right side of the window

    Which apps are affected? Basically, all applications not using GTK3 (and a few that do use GTK3). That includes GTK2, Qt, and Electron apps.

    If that alone doesn’t alert people of how out-of-touch the Gnome developers are, then I don’t know what would.




  • The number-one frustration, cited by 45% of respondents, is dealing with “AI solutions that are almost right, but not quite,” which often makes debugging more time-consuming. In fact, 66% of developers say they are spending more time fixing “almost-right” AI-generated code.

    Not surprising at all. When you write code, you’re actually thinking about it. And that’s valuable context when you’re debugging. When you just blindly follow snippets you got from some random other place, you’re not thinking about it and you don’t have that context.

    So it’s easy to see how this could lead to a net productivity loss. Spend more time writing it yourself and less time debugging, or let something else write it for you quickly, but spend a lot of time debugging. And on top of it all, no consideration of edge cases and valuable design requirement context can also get lost too.



  • The last Windows OS I used was XP, around 2004-ish. Even back then, it was obvious to me that, because it was closed source, that they could one day start acting against my interests, and there was nothing I could do to stop it. I saw open source as an insurance policy - it prevents vendors from acting maliciously against their users. In that very quaint, old time, nobody believed that MS would ever do something like that, but it didn’t matter - the fact was that they could, so inevitably, they would.

    I’m quite proud of how prescient I was when I look at what they’re doing today. No evil is too great to stop a greedy businessman.

    Anyway, I decided to just be brave and create a partition on my main drive and install Ubuntu on it. All I needed to get my work done was OpenOffice, LaTeX, a browser, a compiler, Python… Everything worked better in Linux than Windows so even though I was dual-booting, I practically never used Windows again after a couple weeks. Later on, I switched to Debian, and the next laptop that I bought, I just wiped the hard disk and used Linux for the whole thing. I kept the recovery partition because I was paranoid but obviously never needed it.

    Today, there’s no doubt in my mind that Linux is the best OS. Sure, Macs have better batteries, but if I’m doing productive work, then I don’t really need more than an hour away from my charger. I could maybe agree that the BSDs are better, but I’ve never tried them.


  • I wrote a program that scanned object files (compiled from a large C++ project) to see how they were interdependent. It was pretty useful for detecting cycles in the shared libraries that we were compiling from them, but the biggest benefit was it enabled me to very easily rewrite the build system from scratch.

    It was surprisingly simple - most ELF parsers can read a file and dump the symbol tables in them. (In this context, a symbol means a defined function, so if a C/C++ source file has int main() in it, the corresponding .o file will have a main symbol in it.) They also include information about which symbols are defined in the .o file, as well as which symbols it depends on which are undefined. This allows you to figure out a dependency graph, which you can easily visualize using graphviz or use to autogenerate build files for CMake or any other build system you may wish to use.

    In my case, I wrote this kind of program twice in two separate jobs. Both of them had a very janky build system using custom Makefiles. I used this program to rewrite the build systems in CMake. The graphviz dependency graphs are also just generally helpful to have as project documentation. CMake can do this natively, by the way - here’s the documentation for it: https://cmake.org/cmake/help/latest/manual/cmake.1.html#cmdoption-cmake-graphviz


  • Yeah, I’ve seen a lot of those videos where they do things like {} + [], but why would anyone care what JS does in that case? Unless you’re a shit-ass programmer, you’re never going to be running code like that.

    By this same logic, memory safety issues in C/C++ aren’t a problem either, right? Just don’t corrupt memory or dereference null pointers. Only “a shit-ass programmer” would write code that does something like that.

    Real code has complexity. Variables are written to and read from all sorts of places and if you have to audit several functions deep to make sure that every variable won’t be set to some special value like that, then that’s a liability of the language that you will always have to work around carefully.