How to go from only being able to compile the project on a Windows machine (due to obscure dependencies that every other Java project has for some reason) to not being able to compile on anyone’s machine in just 1 simple step.
I didn’t realize that. I use a .xyz for a lot of my personal stuff and didn’t realize this. I wanted basically .website … i didnt want .com or .org or anything with tld that meant something, so xyz felt nice. Also, the domain I wanted with any popular tld was insanely expensive and i got my xyz for cheap when it was brand new (not for 1 dollar though).
Maybe I need to look into new domains, but I probably will just stick with it since its primarily for personal use anyway.
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.
I would say that over a decade of my career was coming in as a freelancer to fix codebases where a couple of people tought they knew better than the previous ones and proceeded to add yet another very different block to a codebase already spaghetiffied by a couple such people.
Sometimes it was coding style, sometimes it was software design, sometimes it was even a different language.
I reckon thinking that just deploying one’s EliteZ skills on top of an existing code base without actually refactoring the whole thing will make it better is a phase we all go through when we’re still puppy-coders.
The majority of puppy-coders I’ve encountered (including myself) actually want to refactor rather than just add onto. They are fundamentally correct in this, but they don’t grasp that 1) few companies want to acknowledge that the code base which is their greatest tangible “asset” is actually complete shit, and 2) that due to their inexperience, their refactored replacement is probably going to end up as bad as or worse than the original.
Please for the love of god don’t use merge, especially in a crowded repository. Don’t be me and suffer the consequences. I mistakenly mention every person with a commit between the time I created the branch until current master.
There’s 102 people mentioned in that commit and two of them happen to meet in the comments of a meme thread on Lemmy of all places. I love the Internet.
They were mentioned because a file they are the code owner of was modified in the PR.
The modifications came from another branch which you accidentally(?) merged into yours. The problem is that those commits weren’t in master yet, so GH considers them to be part of the changeset of your branch. If they were in master already, GH would only consider the merge commit itself part of the change set and it does not contain any changes itself (unless you resolved a conflict).
If you had rebased atop of the other branch, you would have still had the commits of the other branch in your changeset; it’d be as if you tried to merge the other branch into master + your changes.
Could have been worse. I mean, like, imagine of you were using like CVS and you put a watch on the root! Haha and then like every trivial commit in the repo caused everyone to in the entire org to get an email and it crashed the email servers.
Like who’d even DO that?! Though, I bet if you met that guy he’d be ok. Like not a jerk, and pretty sorry for all those emails. A cool guy.
That’s exactly how “best” works. Everyone thinks their language is the greatest and shits on everything else. If they all chose “the best” there would be 50 of them. Opinions are like assholes. Everyone has one.
I wouldn’t say so. They are inexperienced. They don’t know where the bottleneck of most of the modern software is (it’s io in 80-90% of cases) and how to optimize software without rewriting it to C++
How are they ignorant? It’s a known fact that java is slow, at least slower than some others. Sure, it’s still fast enough for 95% of use cases, but most code will run faster if written in, say, C. Will have 10x the amount of code and twice as many bugs though.
the jvm brings enough bugs to outweigh any benefits there…
it is relatively fast, but it’s slow in that it takes up a bunch of resources that could be doing other things…
i decline your invite to debate the merits of java and jvm… i will instead walk my dog through this beautiful park here…
but, it’s all been said on top level comments on this post.
it’s trash, and honestly, even if it was perfect, sun microsystems has ruined any potential benefits.
Java is indeed slower than C, Rust, in some cases than Go.
But that doesn’t mean that
code will run faster if written in, say, C
Again, like 80-90% of production code are bounded by disk/network io operations. You will gain performance from using C in embedded systems and in heavy calculations (games, trading, simulations) only.
Which is exaxtly what I said, that it’s fast enough for most use cases.
In theory though, you will “gain performance” by rewriting it (well) in C for literally anything. Even if it’s disk/io, the actual time spent in your code will be lower, while the time spent in kernel mode will be just as long.
For example, you are running a server which reads files and returns data based on said files. The act of reading the file won’t be much faster, but if written in C, your parsers and actual logic behind what to do with the file will be.
But it’s as you said, this actual tiny performance gain isn’t worth it over development/resource cost most of the time.
My favourite is “all the boilerplate” then they come up with go’s error checking where you repeat the same three lines after every function call so that 60% of your code is the same lines orlf error checking over and over
When you handle all your errs the same way, I’d say you’re doing something wrong. You can build some pretty strong err trace wrapping errs. I also think it’s more readable than the average try catch block.
Yeah, that’s the other thing - it does become easier to accidentally fail to deal with errors and the go adherents say they do all of that verbose BS to make error handling more robust. I actually like go, but there’s so much BS with ignoring the pain points in the language.
Do you really think the reason people hate Java is because it uses an intermediate bytecode? There’s plenty of reasons to hate Java, but that’s not one of them.
.NET languages use intermediate bytecode and everyone’s fine with it.
Any complaints about Java being an intermediate language are due to the fact that the JVM is a poorly implemented dumpster fire. It’s had more major vulnerabilities than effing Adobe Flash, and runs like molasses while chewing up more memory than effing Chrome. It’s not what they did, it’s that they did it badly.
And WASM will absolutely never replace normal JS in the browser. It’s a completely different use case. It’s awesome and has a great niche, but it’s not really intended for normal web page management use cases.
Do you really think the reason people hate Java is because it uses an intermediate bytecode? There’s plenty of reasons to hate Java, but that’s not one of them.
And WASM will absolutely never replace normal JS in the browser. It’s a completely different use case. It’s awesome and has a great niche, but it’s not really intended for normal web page management use cases.
While I overall agree that JS / TS isn’t likely to be replaced, Microsoft’s Blazor project is interesting conceptually … Write C# webpages and have it compile down to WASM for more performance than JS could offer.
What, you can write a website in C# and have It output as a website using wasm? I have never touched wasm. That might be an interesting way to try it though.
The problem with blazor as I understand it, is that no, it does not compile your C# into WASM. Instead, it compiles into a standard .net module – with as much excising of unused code as possible – and distributes it with a CLR that is compiled to WASM. So effectively you’re running the .net VM inside the WASM VM. If you do client-side blazor, which is not even MS’s push anymore because they stand to make more money if you write server-side blazor and deploy it to Azure.
Do look it up yourself tho. I could have a totally wrong understanding. I haven’t looked into it in some time because I’ve not been in a position to start a new frontend project from scratch. I would love to do my frontend stuff in C# though, don’t get me wrong.
Interesting, yeah. I inherited a Blazor project though and have nothing positive to say about it really. Some of it is probably implementation, but it’s a shining example of how much better it is to choose the right tool for the job, rather than reinventing the wheel. For a while I was joking about setting the whole project “ablazor” until we finally decided to go back to a React/C# ASP.NET stack. If you’re thinking of using Blazor still, though, I think two fun things to look into are “linting issues with Blazor” and “Blazor slow”. I’ve heard people praise it, but they tend to be those who consider themselves backend devs that occasionally get stuck making frontends.
programmer_humor
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.