Live data from Hacker News

Delphi Timewarp – 1995 and Delphi’s Mythical Origins

blogs.embarcadero.com

61–64 of 64 posts

Re: Delphi Timewarp – 1995 and Delphi’s Mythical Origins

#61
post #58
post #46

Earlier quoted context omitted.

My VSCode takes considerably less RAM than Webstorm on the same project - and yet IMHO VSCode does it better.

Load VSCode with the same amount of plugins, and measure all of the out of process executables that make part of the experience and then you will see how much RAM is actually being consumed.

I have like 30 extensions to give it the same level of functionality (or more precisely, the subsection I use), and it takes less than Webstorm.

Re: Delphi Timewarp – 1995 and Delphi’s Mythical Origins

#62
post #61
post #58

Earlier quoted context omitted.

Load VSCode with the same amount of plugins, and measure all of the out of process executables that make part of the experience and then you will see how much RAM is actually being consumed.

I have like 30 extensions to give it the same level of functionality (or more precisely, the subsection I use), and it takes less than Webstorm.

Counting the external processes RAM usage?

Just measuring code.exe isn't enough.

Re: Delphi Timewarp – 1995 and Delphi’s Mythical Origins

#63
post #60

Earlier quoted context omitted.

I mean, "better than a bloated java app" is not really a compliment is it ? Every time I try to use jetbrains IDE I am just unable to given how slow everything feels, my hands start shaking from the stress in merely a few minutes

Well and what editor can you use that isn't either a bloated Electron app, a bloated Java app, or a bloated C++ app? Comparison to its next best competitor is the only thing that makes sense IMHO.

No recent C++ IDE I know (Qt Creator, KDevelop mainly) has the kind of endemic UI slowness than the others have (recent VS in C#, Electron stuff, Java stuff).

Re: Delphi Timewarp – 1995 and Delphi’s Mythical Origins

#64
post #54
post #50

Earlier quoted context omitted.

Citation needed? At least in actual motif. Can’t find any information about either thing.

I love this seeing is believing in tech. DPI independence was already supported, because each X Windows terminal was different beast, hence layout managers and multiple coordinate systems. "Common Desktop Environment: Internationalization Programmer's Guide" https://www.cs.auckland.ac.nz/references/unix/digital/COSEPR... "Developing Applications for the Display PostScript System" https://www.cs.auckland.ac.nz/referen…

DPI independence definitely existed in some forms. (Heck, even GDI theoretically had DPI independence baked in, since I guess everyone was inspired by PostScript et al.) And I never really disputed layout management, since I was aware that some systems were doing that, too. I dispute that most systems from that time period could do what we do today and scale correctly on high resolution displays. I’ve had enough experience setting Xresources to be skeptical. But frankly, I just don’t have enough experience with Motif and CDE to really stake a claim here. So I’ll fold on that one: DPI scaling is certainly not absent.

I was most curious to hear about screen readers, because I wasn’t aware of any accessibility protocols or buses on UNIX-likes prior to ATK. But I’m guessing CDE desktops really don’t have that. Maybe the easiest way to find out would be to just boot up CDE and find out, since I’m pretty sure it’s still maintained…

Post reply on HN