- cross-posted to:
- technology@lemmy.world
- hackernews
- cross-posted to:
- technology@lemmy.world
- hackernews
Cross-posted from https://sh.itjust.works/post/47610810
You must log in or register to comment.
American Big Tech is the world leader because they employee and train the best engineers in the world
OR
American Big Tech is the world leader because they employee illegal anti-competitive business practices and bribe/lobby US officials to not stop them
It’s obvious which is correct. All of big tech has been leaking competence for a long time, and this AI frenzy is only accelerating it. The solution to these problems is to enforce the law and break them up, as smaller companies can’t survive by being incompetent, and can’t afford to compensate engineers with ridiculous salaries/inflated stock just to prevent them from joining/launching a competitor (or in the case of big tech, using illegal agreements to not poach from each other).
The worst part is that even if this problem reaches its apex, and some/all of these companies start to fail, the market won’t correct itself. I can already see the government bailing them out so they can keep doing the same shit.
just me that feels the article is written using an llm?
Which cues do you see?
- “This isn’t x, it’s y” literally everywhere in the article. No one uses that phrase that often.
- Em dashes are littered throughout.
- Random bolding of phrases for no reason.
- More headers than is really necessary.
- Far too many markdown lists.
But what happened to QA?
Quality Abandonment?
I can assure you the quality is top without looking at the product! /s
In my opinion, the problem is not technical debt by itself, or technical issues. These are fixable if you know how.
However: Organizations which heap technical debt have likely a culture that encouraged it. It is unlikely you can change that without management buy-in. Especially if old developers don’t have the desire to change their ways. Many believe that producing bad quality gets results faster (which isn’t true once you look further than about 6-9 months - it is an erroneous belief system).
I think these incidents like a calculator leaking 32GB are not the problem in the industry. These are isolated issues, and fixable as you say. The bigger problem are many “smol” programs are written without performance in mind at all, with crazy languages like JavaScript, its bloated environment and runtimes and frameworks like React and a huge browser to run it. While they do not leak memory like crazy, they hog a lot and people accept it. If all programs are like this, then you end up doing 16GB for simple tasks (random number chosen for likes), while the 32 GB leaked app is corrected and now just uses 200 MB at max (just random number again, to illustrate my point).
While they do not leak memory like crazy, they hog a lot and people accept it.
They do not leak memory at all. Using a lot of memory is not the same as leaking memory. And from a practical perspective, it doesn’t really matter if a calculator app on iOS uses a gigabyte or three of RAM, as the amount of multi-tasking a user can do on a phone is severely limited, and the operating system kills background apps when it needs to reclaim memory for the foreground.
The bigger problem are many “smol” programs are written without performance in mind at all
Do you have specific examples of this? The iOS calculator sucks, but it does not have performance problems. People who think every piece of software needs to be hyper-optimized are either unemployed (or should be) as they don’t get any work done, or they just don’t practice what they preach. IME, it’s usually beginners/novices who discovered what a “native” language is, like C++ or Rust, and are going through a phase. None of those people know how to actually optimize a program, haven’t even heard of Compiler Explorer, think “MESI” is a soccer player, and probably know more about TUI frameworks than profiling ones.
Yes, the concept “release early, release often” is the most practical, especially if you’re doing something new and therefore cannot fully predict how the things should be.
Yes, the concept “release early, release often” is the most practical, especially if you’re doing something new and therefore cannot fully predict how the things should be.
That is not the same. The Linux kernel project. releases early and often, but it is high quality.
Iterating in small steps is a consequence of that you usually can’t lay out all requirements beforehand. But you still need to plan architecture, determine requirements, write down design, document APIs and pre-conditions, run tests and so on. And change and adapt all that, again and again , when requirements change. (Which means that, in larger or long-running projects, requirements which are missing merely due to laziness do have a high cost.)
John Ousterhout talks about this at length in his book “A Philosophy of Software Design” (right now discussed here)… He calls that “strategic” vs. “tactical” programming.
Agree
Personally, I see this as a variation (superset?) of Conway’s Law
Anyone who had changed jobs because the software quality / technical debt was too bad? Do you agree with the article that the quality is becoming worse?
On my third job in the two years of my career now, and this one and the previous one both had mountains of technical debt. I am actively looking for job 4 now, but this time I’m a bit more cautious. (Job 2 counter-offered a 1000+€ raise and I turned it down for having basically the same wage at job 3 because it supposedly would be a better technical environment. It is not.)
The only common denominator between the last two is that both are small-ish and ERP software so idk. [Edit: also ‘me’, but for sure it can’t be this bad everywhere right]
And for both it was caused by a very short-term way of looking at things. (Sure we could speed up development by X2, but that would take two months and the client wants this feature now)
Here. The tooling was no fun as a consequence.
And yes, i agree that overall software quality goes downhill.
lol duh
It’s written in Objective-C. Rewrite it in Rust.
Modern problems require modern solution.
Rewrite it in Rust.
I tried. Building a simple cli tool to get a feeling for it for a bigger project. But then the “Rust by example” starts with installing
clapas argument parser, which pulls 10 dependencies and LSP complains about not being able to build, because it doesn’t find a matching version, unless i do the implied version, but then it can’t derive features.Now trying argparse, that was intuitive in python. And else getops. And else i try Safe-C or something.
Right now I am working on a Rust cli tool with clap and have no issues with the LSP in Neovim. It might be a configuration error. Clap is used by many and is the defacto standard cli parser in Rust. As a fan of argparse in Python, I think clap is even better. argparse being implemented as standard library is the biggest pro over clap. I wouldn’t even use getops anymore, unless it is a Bash script. And even so, Bash has its own builtin argument parser that I use for scripts.
If you really wanted to try Rust, you should sort of that issue. Clap works great and lot of users use it. Who knows, you may even end up liking it and Rust.
Edit: BTW which example do you refer to exactly? I looked at the official ones and couldn’t find: https://doc.rust-lang.org/stable/rust-by-example/
Thanks. Yeah, i’ll try again. The (Rust-)tooling is already selected for the bigger project anyway.
It’s from https://docs.rs/clap/latest/clap/ the
features --derive.I explicitly only use it with
features --derive. It let’s you write the cli option setup as astruct, which feels super natural to me. That’s why I know for a fact it works well. Look in your Cargo.toml under the section[]there should be an entry for clap:clap = { version = "4.5.41", features = ["derive"] }is mine. Right now version 4.5.48 is the newest I think.Also from your previous reply, what do you mean “unless i do the implied version, but then it can’t derive features”? I don’t know why you shouldn’t be able to use derive. I’m no expert either BTW, just wondering what went wrong.
Edit: typo
