My experience using docker on windows has been pretty awful, it would randomly become completely unresponsive, sometimes taking 100% CPU in the process. Couldn’t stop it without restarting my computer. Tried reinstalling and various things, still no help. Only found a GitHub issue with hundreds of comments but no working workarounds/solutions.
When it does work it still manages to feel… fragile, although maybe that’s just because of my experience with it breaking.
You can cap the amount of cpu/memory docker is allowed to use. That helps a lot for those issues in my experience, although it still takes somewhat beefy machines to run docker in wsl
My Firefox package updates are usually slow, limiting downloads to <500kb. So, whenever the download speed used to drop, I knew Firefox released an update.
So when the XZ articles started popping up, the first thing I did was verify all sources.
The type system is still really bad, and apparently TypeScript gets mixed with native libraries in common practice, which makes a bad situation worse when something breaks.
The typing system is just a “quirk”. As long as you understand the (admittedly annoying) exceptions to the way your brain expects typing to work, everything works quite well.
And tbh, transpiled TypeScript libraries can be called from JavaScript as if it was JavaScript… because it is JavaScript. There’s no need to worry about typing unless you’re doing something like passing a string into a function that expects an int, and you’d run into those same problems if the function was originally JavaScript.
I mean, sure, but taking that argument to it’s logical extreme we should still be programming in assembly, because you can if you just know enough to do it.
A language is a tool. If it’s harder to use successfully than the next tool it’s a worse tool.
No? How is that the logical conclusion? You need to understand any language, and any quirk of that language, in order to effectively write in it. JavaScript is powerful, and moving farther every iteration. Strong typing is just not something it takes into consideration. In the same way that C# doesn’t take white space into consideration, and python doesn’t terminate its instructions with semicolons.
Each language is different, each language has its own quirks that you need to understand and get used to. If that wasn’t the case, we would have one objectively “perfect” programming language to use in all situations, on all machines, for every use case.
You need to understand any language, and any quirk of that language, in order to effectively write in it.
That seems to imply they all have the same amount of quirks, which I think most people here would agree is untrue
Something like Haskell has far, far fewer quirks than x86 assembly code. It really only has quirks to do with interactivity; everything else is very predictable and visible in the code. Meanwhile, assembly code is but a maximally useful set of quirks in a specific electronic circuit.
Ditto if you look at older languages. FORTRAN is unpleasantly quirky, which is why it’s almost obsolete.
If that wasn’t the case, we would have one objectively “perfect” programming language to use in all situations, on all machines, for every use case.
I mean, I hold out hope that that will eventually happen, at least for the vast majority of use cases and machines. Obviously we’re not there yet.
There have been languages that basically dominate their own niche. C/C++ was almost the only game in town for performance coding until someone discovered a way to compile mid-level code while also guaranteeing memory safety. Memory errors were a terrible quirk, so now Rust might steal its crown.
I personally don’t think that’s the issue with the typing system. With vanilla js if I’m looking at a function that has say four parameters that are not trivial objects like strings but are actually complex (think dependency injection) it’s very difficult for me to know what these objects are other than reading through the code of the function.
Actually, even if the parameters are simple, I’m not sure of that until I look into the function and see what it’s doing. This is a huge pain in the ass most the time, because I just wanna look at the function name its parameters and move on. However, that being said, most of this can be remedied with jsdocs and a good linter/lsp.
what does jquery give you that vanilla js doesn’t? it was good before browser inconsistencies got ironed out and js didn’t have as many features built in, but nowadays I have no idea why someone would need it
5.3 was a big leap for PHP. It became actually very good at that point.
I learned it when it was on 4 and boy oh boy was that something.
But nowadays, with 8, it works great, tooling is fantastic. I just kinda wish the documentation, which is absolutely top notch for 90% of the language, was this good for the rest 10%.
I want to play around with Fibers, but I just don’t get the info I want to.
pthreads were so out of date in docs it was shameful.
But the language is good, typing is coming along nicely, and basically the only thing I want PHP to do is to call Postgres and encode the output to json. Works like a charm.
Yeah i’ve heard good things about it recently. I’ve always liked how easy curl can be in php.
Adding typing seems like it would fix most of the problems i did run into but
Has PHP raised its standards on function naming? Or do you still have batshit situations like realEscapeString2() because the first 30 other functions for escaping strings are deprecated?
If you get even 1 thing wrong, the entire program stops working and you don’t get any information about it. Turns out those cryptic errors like “error: object reference not set to instance of an object at address 0x007e00” are kind of important information to have. Unless you specifically know where it’s crashing, finding the source of the problem is like finding a needle in a haystack. If it’s your own code it’s borderline manageable but you’ll regret every decision that led you up to that point. If it’s someone else’s code such as an old project from 9 years ago that doesn’t work anymore, absolutely forget about it.
The only advantage of php is that it’s incredibly lightweight. I was running an Athlon XP home server on Gentoo as late as 2022 and still had php running despite only having the SSE1 instruction set and a cpu less powerful than whats probably on a modern led lightbulb.
But ACKTCHUALLY I think django and python bottles can be run on even shittier computers than php can since it uses python and python has been demonstrated to be runnable on a pentium 1. So there is no reason to use php.
Java is disliked because it’s designed around flawed OOP principles developed in the 80s and 90s. The code easily turn into a mess if you adhere to these principles, because they’re flawed. If you avoid using these principles, you will still get a mess, because that’s not how Java is supposed to be used.
Java was such a fractal of stupid design choices in its early years, and a lot of it is still there. OOP except when it’s not (int vs Integer, [] arrays but also List et al), no unsigned number types, initially no way to do closures or pass methods around so everything had to be wrapped in super verbose bullshit, initially absolutely dogshit multiparadigm support and very noun-oriented, initally no generics either meaning everything’s an Object, when it did get generics they had to do type erasure for backwards compatibility, etc etc etc
Great article, thanks for the link! It makes good points that I hadn’t really considered; I’ve probably just been cranky about it because I’ve preferred heterogenous translations
I think having null is great in some cases where you need to represent missing value. It’s just that there’s no good way to know for sure if you need to do null checks or not. The only way around it is to do null checks everywhere, which no one wants to do because fuck that. Nowadays there’s Optional which solves some of this, but it was introduced way too late.
If I were to redesign Java the first thing I would do is to add a nullable keyword or something.
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.