Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Which is why I find so ironic that many still think only languages like Assembly, C or C++ have a place in IoT on devices like ESP32.

Short answer, Parkinson's law.

When I browse the Web, open my Windows File Explorer, open Photoshop, open Visual Studio, open just a graphical application that needs GPU acceleration, or do whatever thing that should not be an issue, I find that Parkinson's law very much applies.

https://youtu.be/GC-0tCy4P1U?t=1727

https://youtu.be/GC-0tCy4P1U?t=2172

https://twitter.com/rogerclark/status/1247299730314416128

Wtf. Did you see how fast VS6 started on a machine from almost 20 years ago. Today I get depressed whenever I need to open Visual Studio, and I don't even know that I use any more functionality that wasn't available 20 years ago.

Many many programmers (in my perception at least) are extremely dissatisfied with today's state of computing, and the reason why we got here is the popular opinion that we don't need to worry about performance.

Nobody should optimize representations of Pi or count CPU cycles by default. That's not the point. But if you claim that Java is always fast enough for example, then I think we're having a strong disagreement. It's partly confirmation bias and being unaware of vast parts of the landscape, but it's also a fact, that I couldn't name you a complex GUI written in Java with satisfying ergonomics.



Java (the language) is not especially slow; back in the mid 2000s I was optimising a Java GUI to display hundreds of thousands of nodes for chip design clock trees.

Java (the culture) makes it hard to be performant. There's a great tendency to use all sorts of frameworks and elaborate object systems where much simpler code would give you at least 90% of the functionality for 10x the performance.

But if you get some programmers with experience beyond Java who care about performance and are rewarded for performance, it's certainly possible.

I briefly wondered whether the demoscene ever had a go at Java, and indeed they did: http://www.theparty.dk/wiki/Java_Demo_1999 / https://www.youtube.com/watch?v=91HzuGqpTHo


Yep I agree. Java isn't slow if you build a trivial application. Or an HTTP server. Or something for batch processing. Or if you're a masochist working around performance issues until you reach about ~C level of performance and performance "robustness".

The problem is what Java encourages you to do. And I didn't want to single out a language; Java is just one that I revisit from time to time and I'm always astonished how awkwardly hard it is to do the simplest things in a straightforward (and CPU-efficient) way.

And yes, there are a lot of slow C++ programs, and even slow C programs. There's just a clear tendency for C programs to be faster and more responsive.


> tendency for C programs to be faster

I was involved in a massive rewrite of a website from C to Java a while back. One coworker observed that, when they were coding in C, it took a lot longer to get anything working, but once you did, it was pretty solid: C had a tendency to just crash if anything was wrong, so you'd work for quite a while before you got something that didn't crash consistently. Java, on the other hand, allowed you to get something working (that is, running without crashing) much quicker: but the things that were out of place were still there, they just caused harder-to-find problems that were much more likely to become customer-facing before they were caught.


The problem isn't Java, after all Photoshop also has performance issues when compared with its old self, and it is C++.

The problem is that mechanical sympathy seems to be a lost art, and it is going to be slow as molasses regardless of the language being used.

What to expect when Electron is the new darling for writing desktop applications?


I totally agree that the problem is lack of mechanical sympathy.

A big problem is simply that software development is too hyped, and there is too much money in the industry, so there are too many unexperienced developers bringing bad software. Also, projects are too ambitious, leading to compartmentalization of implementation, leading to slow and unreliable code. The problem often starts already with the things that people want to build.

And my guess is that the use of Java and other object languages is highly correlated with these developments.


Legacy products like visual studio and photoshop also suffer from age. Those codebases are both over 20 years old and have a gazillion features that customers start to rely on. Add in that and codebase that old will be slower to make changes on then something fresh and you end up where they are.


Visual studio had a UI rewrite to .net about a decade ago.

VSCode is electron.

If they had kept maintaining the old thing maybe they would experience less performance issues, which you say is suffering from age, but actually they threw out the old thing and rewrote on costlier and more recent frameworks.


The bizarre part is that if you mention to the people making visual studio that every version is slower and has more latency and lag in the interactivity, they seem to have no idea what you are talking about and ask what specific situation you are running in to. They either don't know or don't acknowledge the evolution of the performance of their software.

I read once that adobe acrobat has thousands of static variables that initialize on startup. Multiple pdf readers like sumatraPdf are successful largely because of their bloat and start up time.

It's crazy what happens when programming teams have no priority for not wasting user's time and computer resources.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: