3 ms·

I suppose you are right. I worked with MFC/C++ and COM and it was horrible. Delphi and C++ Builder things were nicer to use but fell by the wayside, particularl

I suppose you are right. I worked with MFC/C++ and COM and it was horrible. Delphi and C++ Builder things were nicer to use but fell by the wayside, particularly after Borland lost their focus and didn't bother supporting VCL correctly in themes and also had major issues with their C++ compiler. They suffered a brain drain. I remember Windows Explorer opening swiftly back in the day (fileman even faster - https://github.com/microsoft/winfile https://github.com/microsoft/winfile now archived sadly) and today's Explorer experience drives me insane as to how slow it is. I have even disabled most linked-in menu items as the evaluation of these makes Explorer take even longer to load; I don't see why it can't be less than 1 second. Anyway, I do recall Netscape taking a long time to load but then I did only have a 486 DX2 66MHz and 64MB of RAM.... The disk churning did take a long time, now you remind me... I think using wxWidgets on Windows and Mac was quite nice when I did that (with wxFormBuilder); C++ development on Windows using native toolkits is foreign to me today as it all looks a mess from Microsoft unless I have misunderstood. In any case, I can't see why programs are so sluggish and slow these days. I don't understand why colossal JS toolkits are needed for websites and why the average website size has grown significantly. It's like people have forgotten how to write good speedy software.

mike_hearn 1y ago
Well, today I spent a lot of time waiting for some slow software that I wrote and maintain, a program that helps ship large desktop apps that use JVM or Electron. It can do native apps too but nearly nobody writes those. So I guess I both feel and create your pain in several directions. Why is my software slow? Partly because the task is inherently intensive. Partly because I use an old Intel MacBook that throttles itself like crazy after too much CPU load is applied. Partly because I'm testing on Windows which has very slow file I/O and so any app that does lots of file I/O suffers. And partly because it's a JVM app which doesn't use any startup time optimizations. But mostly it's because nobody seems to care. People complain to me about various things, performance isn't one of them. Why don't I fix it anyway? Because my time is super limited and there's always a higher priority. Bug fixes come first, features second, optimizations last. They just don't matter. Also: optimizations that increase the risk of bugs are a bad idea, because people forgive poor performance but not bugs, so even doing an optimization at all can be a bad idea. Over the years hardware gave us much better performance and we chose to spend all of it on things like features, reducing the bug count, upping complexity (especially visual), simplifying deployment, portability, running software over the network, thin laptops and other nice things that we didn't have on Windows 98. Maybe AI will reduce the cost of software enough that performance becomes more of a priority, but probably not. We'll just spend it all on more features and bug fixes.
- chii 1y ago
  > People complain to me about various things, performance isn't one of them. which is fine, and you are doing the absolutely correct thing regarding fixing what's being complained about. But the complaints i keep hearing (and having myself) is that most apps are quite slow, and has been increasingly growing slower over time as updates arrives - mobile phones in particular.
  - mike_hearn 1y ago
    I think this reflects a shift towards all software depending on a remote database, more than some change in programmer attitudes or bad software in general. Win 9x era software relied entirely on files for sharing, and there was no real notion of conflict resolution or collaboration beyond that. If you were lucky the program would hold a Windows file lock on a shared drive exported over a LAN using SMB and so anyone else who tried to edit a file whilst you'd gone to lunch would get a locking error. Reference data was updated every couple of years when you bought a new version of the app. This was unworkable for anything but the simplest and tiniest of apps, hence the continued popularity of mainframe terminals well into this era. And the meaning of "app" was different: it almost always meant productivity app on Win 9x, whereas today it almost always means a frontend to a business service. Performance of apps over the network can be astoundingly great when some care is taken, but it will never be as snappy as something that's running purely locally, written in C++ and which doesn't care about portability, bug count or feature velocity. There are ways to make things faster and win back some of that performance, in particular with better DALs on the server side, but we can't go backwards to the Win 9x way of doing things.
    - hollerith 1y ago
      DAL == data access layer

mike_hearn 1y ago

Well, today I spent a lot of time waiting for some slow software that I wrote and maintain, a program that helps ship large desktop apps that use JVM or Electron. It can do native apps too but nearly nobody writes those. So I guess I both feel and create your pain in several directions. Why is my software slow? Partly because the task is inherently intensive. Partly because I use an old Intel MacBook that throttles itself like crazy after too much CPU load is applied. Partly because I'm testing on Windows which has very slow file I/O and so any app that does lots of file I/O suffers. And partly because it's a JVM app which doesn't use any startup time optimizations. But mostly it's because nobody seems to care. People complain to me about various things, performance isn't one of them. Why don't I fix it anyway? Because my time is super limited and there's always a higher priority. Bug fixes come first, features second, optimizations last. They just don't matter. Also: optimizations that increase the risk of bugs are a bad idea, because people forgive poor performance but not bugs, so even doing an optimization at all can be a bad idea. Over the years hardware gave us much better performance and we chose to spend all of it on things like features, reducing the bug count, upping complexity (especially visual), simplifying deployment, portability, running software over the network, thin laptops and other nice things that we didn't have on Windows 98. Maybe AI will reduce the cost of software enough that performance becomes more of a priority, but probably not. We'll just spend it all on more features and bug fixes.

chii 1y ago
> People complain to me about various things, performance isn't one of them. which is fine, and you are doing the absolutely correct thing regarding fixing what's being complained about. But the complaints i keep hearing (and having myself) is that most apps are quite slow, and has been increasingly growing slower over time as updates arrives - mobile phones in particular.
- mike_hearn 1y ago
  I think this reflects a shift towards all software depending on a remote database, more than some change in programmer attitudes or bad software in general. Win 9x era software relied entirely on files for sharing, and there was no real notion of conflict resolution or collaboration beyond that. If you were lucky the program would hold a Windows file lock on a shared drive exported over a LAN using SMB and so anyone else who tried to edit a file whilst you'd gone to lunch would get a locking error. Reference data was updated every couple of years when you bought a new version of the app. This was unworkable for anything but the simplest and tiniest of apps, hence the continued popularity of mainframe terminals well into this era. And the meaning of "app" was different: it almost always meant productivity app on Win 9x, whereas today it almost always means a frontend to a business service. Performance of apps over the network can be astoundingly great when some care is taken, but it will never be as snappy as something that's running purely locally, written in C++ and which doesn't care about portability, bug count or feature velocity. There are ways to make things faster and win back some of that performance, in particular with better DALs on the server side, but we can't go backwards to the Win 9x way of doing things.
  - hollerith 1y ago
    DAL == data access layer