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

131–140 of 607 posts

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

#131

Post by rbanffy »

dimitar wrote: 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 just uses conventions he is not used to.

It just came up with conventions few others adopted later when they reinvented the wheel.

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

#132

Post by tcoff91 »

pragmatic wrote: post #33

TUIs sucked and they still suck. Programmers are trying to bring them back bc nostalgia I guess? I floated the idea of TUIs to our data engineering team and got very negative responses. (My nostalgia for undergrad turbo pascal TUI I guess lol)

TUIs are great! So fast and efficient to use and accomplish tasks in.

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

#133

Post by JoelMcCracken »

layer8 wrote: post #97
dimitar wrote: 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.

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.

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

#134

Post by username223 »

When I use an editor, I don't want eight extra KILOBYTES of worthless help screens and cursor positioning code! I just want an EDitor!! Not a "viitor". Not a "emacsitor". Those aren't even WORDS!!!! ED! ED! ED IS THE STANDARD!!!

TEXT EDITOR.

-- https://www.gnu.org/fun/jokes/ed-msg.txt

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

#135

Post by guerrilla »

raw_anon_1111 wrote: post #128
guerrilla wrote: post #31

I'm going to get punished for saying this, but I don't really see the point of IDEs when you have things like vim, Makefiles and bash. It just seems like more things to go wrong. I used Eclipse while I was doing Java development for a while and it had some conveniences but for the most part I just see it as one more thing that can go wrong and get in my way. Anyway, does anyone remember Metrowerks CodeWarrior? I see…

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.

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

#136

Post by buescher »

Thirty years ago was 1995. TUI programming environments were closer to obsolete than obsolescent. We had 32-bit versions of Visual C++. We had Delphi and the Borland C++ stuff for Windows. We had Codewarrior. On the lighter end of RAD, Visual Basic was four years old, HyperCard was eight years old, and LabView was nine years old. The future was very unevenly distributed back then. I see now the article is from 2023, well, adjust appropriately.

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

#137

Post by tcoff91 »

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.

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

#138

Post by JoelMcCracken »

layer8 wrote: post #119
skydhash wrote: post #109

Earlier quoted context omitted.

The base input of emacs is ‘M-x’. From there, any command is accessible. And you have ‘M-:’ for evaluating any bit of elisp code. There’s a few UI concepts to learn (frame, window, buffers, point, mark, region,…), but that would fit in a single sheet of paper.

The keys I enumerated are sufficient to discover and execute all available operations in that style of TUI. You don’t have to type commands or command-specific keyboard shortcuts, like you have to in Emacs. It’s analogous to how in a traditional GUI you can discover and execute everything just using the mouse. Like in the GUI analogy, you can then choose to remember and use the displayed keyboard shortcuts for freque…

For most fundamental operations there are menus available. Most heavy emacs users opt to turn them off however.

You can even see the menu atop the screen shot in the article, with the familiar names etc.

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

#139

Post by bigstrat2003 »

dimitar wrote: 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 instruction.

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

#140

Post by somat »

dapperdrake wrote: post #72
badsectoracula wrote: post #56

Earlier quoted context omitted.

AFAIK Borland C++ (even on Windows) used to read the source from whatever editor buffers you had already in the IDE and since the compiler was part of the IDE, it cached various states in memory, which is why it was so fast (for a C/C++ compiler anyway - Delphi was much faster) even on slow hardware. Meanwhile Visual C++ (and modern IDEs) had you autosave the file to disk so the compiler, that was launched as a separ…

From what I remember researching it really js this. Today, Python, Rlang, PHP, Java, and Lisp bring these features. But not C. Oh the irony.

C does as well, that is half the point of make. When building a large C project it will first create a bunch of object files from the source files then link them into an executable. make then keeps track of what source files have changed and rebuilds only those object files. The first build is slow, subsequent builds are much faster. only needing to compile one file then link them.

At least that's the theory, in reality make has a lot of warts and implementing a good solid make file is an art. Don't even get me started on the horrors of automake, perhaps I just need to use it in one of my own projects but as someone who primarily ports others code, I hate it with a passion. It is so much easier when a project just sticks with a hand crafted makefile.

For completeness: The other half of make is to implement the rest of the build process.

Post reply on HN