Why exactly does MS gaming employ over 20.000 people?

And when people started writing books instead of memorizing epic poems.

Python caches bytecode, so the translation happens only once.

Java loads everything immediately and keeps it in memory. All beans, all connections, etc. That takes up a ton of memory.

Of course, but I’m not productive in it.

If I have to do everything myself, it will take more time to get it done. The trade-off is of course always control/speed vs convenience, but C is definitely too inconvenient for me.

Not that limited. Limited means an old thin client, not a microcontroller. I already set up a small web server on a pi pico with mpy, so it’s quite impressive. But from what I understand, the interop with “MacroPython” is not that great.

Did you use mpy for x86 devices? Are the limitations worth it?

But that would mean either using Graal/native image or going full Scala, right?

I only used Scala for Gatling, where it’s obviously very java-y.

There’s nothing to really grow. It’s mostly just small helpers. Aggregate sensor data, pull data from A and push it to B every hour, a small dashboard, etc.

C is too involved for my case , I want to be productive after all.

Rust is already rather low level, though there are some cool looking frameworks.

Of course it is like that. You’re saying that the complaint is wrong because the author doesn’t know the history, and now you accuse me of not understanding you, because I pointed this out.

If you have to accuse everyone of “not understanding”, maybe you’re the one who doesn’t understand.

It’s easy to criticize something when you don’t understand the needs and constraints that led to it.

And that assumption is exactly what led us to the current situation.

It doesn’t matter, why the present is garbage, it’s garbage and we should address that. Statements like this are the engineering equivalent of “it is what it is shrug emoji”.

Take a step back and look at the pile of overengineered yet underthought, inefficient, insecure and complicated crap that we call the modern web. And it’s not only the browser, but also the backend stack.

Think about how many indirections and half-baked abstraction layers are between your code and what actually gets executed.

Stored Procedures have been a thing for literally decades. But they’re an absolute pain.

What would really improve the usefulness of databases are autoindexes and generally more “let me handle that for you”. I’d argue 90% of business apps essentially need a way to store objects and their relationships, but doing that in an efficient manner is really hard (at least if you’ve got a few more rows to handle).

The ranking is perfectly fine, since some of these languages in practice are interchangeable.

You’ll find business software in Java, C#, Python (and VBA, but we’re not talking about that), and you’ll find more system oriented software in C, C++, Rust.

Now, you’re right insofar that it’s misleading to lump all languages together, C and JS rarely compete, but it’s a useful tool to gauge developer/employer pools. If you decide, which language to learn because you want to dip into a new niche, you might not want to learn Steve’s obscure cross-paradigm language (SOCL), but e.g. Rust or whatever is popular.

Same is true for businesses. Yes, your software may be written in really good C, but it’s probably a good idea to go the Java route for the next project, since it’s hard to find 20 new C devs for web apps.

I’m not saying that this specific ranking here is good, its metrics are dubious at best, but the idea isn’t inherently stupid.

I worked on a system whose database setup looked kind of like this. Interesting to see, that they weren’t the only ones using that approach.

We had an online database for online transactions, all tables used a sequence generator table (basically a key/value with the key being table name and the value being the last id) l, every few minutes all the new transactions where dumped into a second instance for research and monitoring. Every night a job started, that first dropped all the transactions older than a few weeks from the online db and then exploded every single transaction into a bunch of id, key, value tuples. These were then push/pulled (very weird construct) into the datawarehouse. Since each new value was its own table, we had something like 20 tables, mostly being nulls. You might had columns like serviceA_call1_customer3_adress_streetname. Absolutely bonkers and only one man understood that thing.

I’ll call mine Guillermo.

This is a niche. Logitech doesn’t make its billions in revenue selling a handful of specialty keyboards. And that trend will subside soon, too.

Logitech makes money by selling hundreds of millions of generic mice, keyboards, webcams, etc. That’s where the money is. And if these devices don’t break, why buy new ones? A 20 years old usb mouse is still perfectly usable (I’m using one right now), that’s not good for business. So either you have to cater to fads like mechanical keyboards, which don’t really add anything, or sell crap like subscriptions.

And what exactly is innovative about that? They’re trying to replicate a Model M. A keyboard older than most keyboard users.

Mechanical keyboards are gimmicks, nothing more.

Let’s be honest here, the HID business has absolutely no innovation in the near future. There’s nothing they could meaningfully improve, so the need to either release marketing driven products or pull you into a subscription.

Quite frankly, I think you don’t understand what I mean.

Don’t kid yourself, “patterns” are boiler-plates so common they have a name. Yes, SQL makes things much faster, but that’s just the beginning. As soon as you venture out of the almost trivial cases, things get ugly fast. Think about something as simple as a form. That’s a standard problem. But I can’t just write down a “form-spec” and have a frontend and backend for that. No, I need a bunch of libraries that don’t quite work together and need a lot of persuasion to work together.

Or think of Rest-APIs. How many times could you really just ingest a spec and have everything working as expected? That’s very rare. Some libraries are plain weird, some don’t support certain aspects of what you want, etc. etc. etc.

A simple CRUD app should not require a single line of code. Yet, 80% of us are essentially doing exactly that.

Not really, no. The over-abstraction Java is often doing is a question of mindset. Java devs tend to be very keen on reusability , which is fine, but often enough the result is unusable.

The problems behind abstractFactoryBuilders are not inherently unsolvable without these constructs, it’s just that Java devs chose this rather weird approach.

But that’s exactly what’s holding us back.

Let’s divide the problem sphere very broadly into business and technical. The business problem is “I want to store an order” the technical problem is “We need to connect to a database and map our data onto the table structure”.

What we should be doing is solving the technical problem once, and then map thousands of business problems onto that. But instead, the same technical problems are solved again and again, even though there is a technical solution, because that solution is too leaky for us to rely on.

I don’t want to write the 200th iteration of basically the simple problem again and again. I want to solve the actually hard problems. Yes, software can do the simple stuff, that’s what’s the entire point of our profession. Every developer should try to make themself obsolete.

I don’t want to sound harsh, but your sentiment reminds me a lot of the “back when men were men and wrote their own mouse drivers” comments from ye olde time. But that’s not what our job is about.

I’ve written it countless times before, but software engineering desperately needs to do some engineering.

What you’re describing is absolutely true, but compare the way you’re working with an actual engineer. No sane engineer would start investigating the production process of a steel beam just to build a regular old warehouse. The steel beam has certain characteristics and unless you have very good reasons, you don’t need to question that.

We are software developers however need to know a lot of our steel beams and can’t rely on many of them. That means even simple stuff takes forever and we tie ourselves to it way more than we should.