Live data from Hacker News

IDEs we had 30 years ago and lost (2023)

blogsystem5.substack.com

571–580 of 607 posts

Re: IDEs we had 30 years ago and lost (2023)

#571

Earlier quoted context omitted.

The simplicity and efficiency of Visual Basic UI programming relied on several assumptions that became obsolete in 2000 when LCD and high-DPI displays became widely available. Everything in the VB UI editor was based on a fixed layout. There was a fixed font size, fixed DPI-density display expectation, and fixed button sizes. Every dialog assumed fixed sizes and was non-resizable. Adding a translation to such an appl…

> The simplicity and efficiency of Visual Basic UI programming relied on several assumptions that became obsolete in 2000 when LCD and high-DPI displays became widely available. Everything in the VB UI editor was based on a fixed layout. There was a fixed font size, fixed DPI-density display expectation, and fixed button sizes. Every dialog assumed fixed sizes and was non-resizable. There are visual UI editors that p…

Even Java's Swing, introduced in 1999 (or maybe 98 in beta?), dealt with the problem of dynamic layouts fairly well. Of course, it performed like an absolute dog to begin with, but most of the performance kinks were dealt with during the Java 1.3 era (2000), and by 1.4 in 2002/3 or so, performance was absolutely fine, with most of the rendering quirks of the native look and feels having been dealt with as well.

Moving to C#/WinForms in late 2004 after working with Swing for 4 years felt absolutely jarring by comparison. No concept of layout managers and very limited options for dynamic layout in general (docking was about it, IIRC), really hard to customise components (if it was possible at all - for many it wasn't because they were just thin wrappers around Win32). It was terrible by comparison and I seriously considered quitting the job I was in, even though I liked the company, and finding a role in a Java shop again instead because I hated WinForms so very much.

Swing is obviously ancient history now. Is it still a thing? Do people still use it? Are there still Java desktop apps? I've no idea. But even 20-odd years later Microsoft have never managed to surpass it for desktop app development. WPF is OKish, and certainly addresses a lot of the problems of WinForms, but it's always felt over-complicated and the syntax of XAML has never really been a plus point in my opinion. Silverlight was... a debacle.

And, really, since 2013 I've only paid attention to distributed systems, web, and back end development (all of which have their own problems and complexities) so I've really lost touch with Microsoft's desktop development paradigm.

But I do find myself often yearning for the "simplicity" of desktop app development. Of course, that simplicity comes at a cost: you're trading it for complexity in licensing, distribution, deployment, and support because you have no control over your target environment, and you have to support almost unlimited combinations of machine configuration (which is not necessarily a picnic when you have thousands, tens of thousands, or hundreds of thousands of customers for each product). And, let's be real: nobody misses InstallShield and MSIs.

Re: IDEs we had 30 years ago and lost (2023)

#572
post #23

I think Emacs still does all of this; the argument the author makes is that it is "arcane", it just uses conventions he is not used to. It is however fully self-documented and interactive. For me the best textual interface I've ever used remains Magit in Emacs: https://magit.vc/ I wish more of Emacs was like it. I actually use emacs as my git clients even when I'm using a different IDE for whatever reason.

> It is however fully self-documented and interactive. Unfortunately not true. I've fired up emacs once or twice, and couldn't even figure out how to save a document because it didn't show me how to do that. It might be more documented than vi (but that bar is *on the floor, vi has one of the most discovery-hostile user interfaces ever made), but it's not self-documented enough to just pick up and use with no instruc…

In unconfigured emacs, you can literally just go Buffer>Save in the toolbar. If you didn't know to look in the buffer menu, then you didn't read even a little bit of the tutorial that appears when you open it

Re: IDEs we had 30 years ago and lost (2023)

#573

Earlier quoted context omitted.

I was talking about this with a friend earlier this week. The people who work in software these days seem much more extroverted and outgoing than the 'introverted nerd' stereotype from the 90s.

This is also due to the popularisation of computers, the internet and internet culture. Everyone and their aunts now are into computers, and one in x is a software "engineer". Back in the day, it was only the hardcore nerds that were attracted to these things :)

What are the introverts and "hardcore nerds" supposed to do now?

Where is the new refuge for us?

Re: IDEs we had 30 years ago and lost (2023)

#574
post #229

I saw this and was like, what? > have we advanced much in 30 years? IDEs have changed a lot, specially with AI-assisted ones. The author kind of acknowledges it, but imho it's a paradigm shift. Not just "a major difference". > The only major difference that we are starting to see might be AI-assisted coding, but this is a feature mostly provided by a remote service, not even by the installed code! Then I realized it’…

Is this not an overstatement? How does a person understand code if they write so much of it with AI?

Speaking only for myself, I do it by reading

Re: IDEs we had 30 years ago and lost (2023)

#575

Earlier quoted context omitted.

Yeah, basically when they said that it should’ve begged the question “why is he not used to those conventions?” And the answer would be because the conventions it uses aren’t used by anything else (which means they can barely be called conventions), and makes no effort to adopt any conventions of the platform it’s running on even just to get you started. Also, another user said it has a tutorial when opened which sho…

These conventions work in a lot of Linux GUI tools, in the built-in Git GUI, the shell and every text-box in MacOS.

emacs conventions do?

Re: IDEs we had 30 years ago and lost (2023)

#576

Earlier quoted context omitted.

> it just uses conventions he is not used to ...and everyone else, including everyone who is also using a GUI on Linux - even if they use the GUI version of Emacs.

and frankly including other emacs users, too. Any non-trivial use of emacs ends up involving a pile of customizations.

Yup

Re: IDEs we had 30 years ago and lost (2023)

#578

Earlier quoted context omitted.

> The simplicity and efficiency of Visual Basic UI programming relied on several assumptions that became obsolete in 2000 when LCD and high-DPI displays became widely available. Everything in the VB UI editor was based on a fixed layout. There was a fixed font size, fixed DPI-density display expectation, and fixed button sizes. Every dialog assumed fixed sizes and was non-resizable. There are visual UI editors that p…

Even Java's Swing, introduced in 1999 (or maybe 98 in beta?), dealt with the problem of dynamic layouts fairly well. Of course, it performed like an absolute dog to begin with, but most of the performance kinks were dealt with during the Java 1.3 era (2000), and by 1.4 in 2002/3 or so, performance was absolutely fine, with most of the rendering quirks of the native look and feels having been dealt with as well. Movin…

I've been doing development using JavaFX, Swing's successor, for many years. It's got its quirks, and places where the dev team stopped iterating on the API a little too soon; but it works and does some really nice stuff.

Re: IDEs we had 30 years ago and lost (2023)

#579

Earlier quoted context omitted.

These conventions work in a lot of Linux GUI tools, in the built-in Git GUI, the shell and every text-box in MacOS.

emacs conventions do?

Eh yes? They are mostly readline conventions. What's the question?

Re: IDEs we had 30 years ago and lost (2023)

#580

I used to use a Java-oriented IDE called “Visix Vibe”, at first as an experiment in application development with Java and then as an alternative to Delphi, which was my bread and butter tooling environment for custom application development. Both of these IDE’s gave me a huge productivity boost, and it used to be a no-brainer to give customers a realizable estimate for getting the UI done, then wiring up logic, and g…

> The moment someone produces a properly WYSIWYG tool for JUCE,

Side note: Steinberg's vstgui framework not only has a WYSIWYG editor, you can even build/edit the UI while the plugin is running in a DAW. I usually give Steinberg a lot of shit for their arrogance and ignorance, but this I found extremely cool! I have only toyed around with it, so I don't know how viable it is for complex plugin UIs.

Post reply on HN