Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IDEs we had 30 years ago and lost (2023)

blogsystem5.substack.com

Post reply on HN
Print view View original

171–180 of 607 posts

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

#171

Post by chuckadams »

mkovach wrote: post #32

Ah, Borland’s IDE! An absolute delight. I’ve yet to find anything modern that matches it. Sure, nostalgia turns everything syrupy, but I actively hunt for excuses to use Free Pascal just to fire up that interface. Okay, fine—I like Pascal too. You caught me. I also use Sam and Acme from Plan 9 (technically from the excellent plan9port), but let’s be honest: those aren’t IDEs. They’re editors. Tools that let me think…

There's a lot from Plan 9 I love, but I couldn't find Acme's mouse-dependent UI acceptable in the least. I can't deal with any UI that requires precise aim when I have to use it hour after hour, and I'd hate to imagine using it if I had an actual disability.

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

#172

Post by constantcrying »

jagged-chisel wrote: post #99
constantcrying wrote: post #35

Earlier quoted context omitted.

What? "Slower" how? And why would dev experience not matter more? TUIs are bizarre legacy technology, which are full of dirty hacks to somewhat emulate features every other desktop has. Why would any developer use them, when superior alternatives, not based on this legacy technology, exist and freely available?

Lots of opinions in the thread without any substance to back it up. If you don’t like TUIs and terminals, that’s ok. But if you actually want to argue against them, let’s hear a substantive argument. What specifically is so bad about the TUI?

They are built on ancient technology and need an enormous array of hacks to emulate basic features, which are trivial to do in any modern GUI.

User experience is inconsistent with features varying wildly between terminals, creating a frustrating user experience. It is also making customization difficult. E.g. in a TUI IDE you can not have font settings. Short cuts are also terminal dependent, an IDE can only use those shortcuts the terminal isn't using itself.

Something as basic as color is extremely hard to do right on a terminal. Where in a normal GUI you can give any element a simple RGB color, you can not replicate that across TUIs. The same goes for text styling, the terminal decides what an italic font it wants to use and the IDE can not modify this.

They are also very limited in graphical ability. Many features users expect in a GUI can not be replicated or can only be replicated poorly. E.g. modern data science IDEs feature inline graphics, such as plots. This is (almost) not replicable on a Terminal. If you are using profiler you might want to plot, preferably with live data. Why arbitrarily limit what an IDE can do to some character grid?

The terminal is just a very poor graphical abstraction. It arbitrarily limits what an IDE can do. Can you tell me why anybody would seriously try to use a terminal as an IDE? Terminals UIs are more complex, because they need to handle the bizarre underlying terminal, they are often less responsive, since they rely on the terminal to be responsive. There might be some very marginal improvement in resource usage, do you think that is even relevant compared to the much increased dev experience of a normal GUI?

There absolutely is no real advantage of TUIs. And generally I have found people obsessing over them to be mostly less tech literate and wanting to "show off" how cool their computer skills are. All serious developers I have ever known used graphical dev tools.

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

#173

Post by raw_anon_1111 »

guerrilla wrote: post #135
raw_anon_1111 wrote: post #128

Earlier quoted context omitted.

As someone who has been doing this either professionally (since 1996) or as a hobbyist programming in assembly and a little Basic (1986-1992), I’m always amazed at the feigned Slashdot style “I haven’t owned a Tv in 40 years why do people still watch them”. Are you really saying that you don’t see any utility in modern IDEs? Even back in 1999 I thought Visual Studio was a breath of fresh air let alone R# with all of…

What I'm saying is that they can't do anything I can't do in a terminal. Another way of putting it is why would I need an IDE other than UNIX (GNU) itself? > But going further back, to the Turbo days in college and my first few years working, breakpoints, conditional breakpoints, watches etc were a godsend gdb does all of that.

I can also walk 13 miles or get in my car and drive. So why do I need a car?

GDB does guaranteed safe refactors over large code bases?

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

#174

Post by layer8 »

JoelMcCracken wrote: post #133
layer8 wrote: post #97

Earlier quoted context omitted.

To navigate a Turbo-Vision-style IDE and explore its functionality, you basically only need to know how the Alt and Tab keys work (okay, and Return and Esc and arrow keys), as alluded to in TFA. Emacs doesn’t quite have that base level of operating uniformity I think.

To navigate emacs, you really only need to know ctrl, alt, and the basic norms of keyboard usage (return for newline/accept, shift for capitals) Really, compared to what I see here, the chief difficulty with emacs is the sheer volume of possible commands, and the heterogeneity of their names and patterns, which I believe is all a result of its development history. But the basics are just as you describe.

It’s a good question to what complexity (volume) the approach scales, but dialog boxes can get you quite far, and menus are fundamentally “just” a tree like keyboard shortcuts are.

Emacs has Elisp commands first, then keyboard shortcuts for them, then maybe (not as a rule) menu items, and rarely dialog boxes. The Turbo Vision approach, from its design philosophy, has menus and dialogs first, then keyboard shortcuts for them.

One approach isn’t strictly better than the other, nor are they mutually exclusive. Ideally you’d always have both. My disagreement is with the “I think Emacs still does all of this” above. Emacs is substantially different in its emphasis, presentation, and its use of dialogs.

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

#175

Post by dardeaup »

spwa4 wrote: post #158
dardeaup wrote: post #95

Earlier quoted context omitted.

Delphi is still very impressive. However, they missed out on a much greater opportunity. Part of Delphi's crown jewels is VCL which can only be used on Windows. If you use Delphi for an OS other than Windows you have to use FireMonkey/FMX. Lazarus has LCL which is VERY similar to VCL, but LCL on Lazarus is not limited to Windows. One can write a LCL application and it works the same on Windows, macOS, and Linux. If D…

VCL was ported to linux in the "Kylix" product, for both Pascal and C++. It was non-free and didn't see any uptake really.

Granted, I never used Kylix, but it seems that it had all sorts of problems when it was first released. I don't remember, was Kylix available for Mac?

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

#176

Post by constantcrying »

tcoff91 wrote: post #137
constantcrying wrote: post #14

The arguments for using TUI IDEs are just very poor. Developers should not be relying on something as loaded with legacy bloat like the terminal, to do development. Zed has remote editing support and is open source. Resource consumption is a bizarre proposition, considering what abstractions the terminal has to be forced into to behave something like a normal window. Really, TUIs are not very good. I get it, I use th…

Neovim is my favorite editor and is a brilliant TUI. I think what TUIs get right is that they are optimized for use by the keyboard. I don’t care if they are a pain for devs to write vs OS APIs, they have the best keyboard control so I use them. I despise the mouse due to RSI issues in the past.

Neovim instantly becomes a superior piece of software if you use any of the GUI frontends. If you use neovim inside a terminal you are just straight up using an inferior product, with less features and more problems. The terminal version is most likely slower as well as you now also have the entire legacy terminal overhead.

>I think what TUIs get right is that they are optimized for use by the keyboard.

Neovim is just as much a GUI as a TUI. You can even use it as a backend for VSCode. Nothing about the keyboard controls have anything to do with this.

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

#177

Post by rbanffy »

mickeyp wrote: post #25

The knocks against Emacs feel unwarranted. It has plenty of colour; it has mouse support, even in the terminal, but not all terminals support it, so it's optional. It also runs in a GUI with, you know, image support and whatnot. You can rail against its defaults, but do not make misleading claims.

I wonder if it's still possible to run Guy Steele's era EMACS.

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

#178

Post by robenkleene »

mkovach wrote: post #32

Ah, Borland’s IDE! An absolute delight. I’ve yet to find anything modern that matches it. Sure, nostalgia turns everything syrupy, but I actively hunt for excuses to use Free Pascal just to fire up that interface. Okay, fine—I like Pascal too. You caught me. I also use Sam and Acme from Plan 9 (technically from the excellent plan9port), but let’s be honest: those aren’t IDEs. They’re editors. Tools that let me think…

> So many of those classic TUIs adopted WordStar’s sacred keystrokes.

What are the WordStar bindings and what do you like about them?

I have a general interest in the history of how these patterns emerge and what the benefits of them are relative to each other.

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

#179

Post by shermantanktop »

I struggle to understand what the author actually wants, aside from nostalgia about a specific look and feel that he imprinted on. And perhaps the simplicity of having few features.

I would have appreciated a breakdown of what specific individual features those crummy old ides are offering.

I suspect the one the author wants most is a time machine to go be 12yo again, but software can’t do that. Yet.

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

#180

Post by rbanffy »

RcouF1uZ4gsC wrote: post #55

To me VB 6 was the height of RAD IDEs You could throw together a CRUD app in under an hour interactively.

VB was the GUI equivalent of Dataflex - you could design the screen and it would automagically create the data structures under it. I also remember, from the same period, Mantis (from Cincom Systems) that did the same for 3270 terminals and IBM mainframes.

I often say Deteflex is Ruby on Rails for the VT100.

Post reply on HN