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

251–260 of 607 posts

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

#251

Post by wat10000 »

heresie-dabord wrote: post #159
CGamesPlay wrote: post #125

(Article is from 2023, so the title should be updated to say "32 years ago", or something) The biggest loss in TUIs is the latest wave of asynchronous frameworks, which bring the joy of dropped keypresses to the terminal. In any TUI released before the year 2000, if you press a key when the system wasn't ready, the key would just wait until the system was ready. Many TUIs today still do this, but increasingly frequen…

When people love an IDE product so much that they can't work without it, they have overspecialised to their detriment. And possibly to the detriment of the code itself. > As for terminal IDEs The GNU/Linux terminal is the killer app . Multiple terminals in a tiling window manager is peak productivity for me. (Browser in a separate virtual workspace.) And modern scaling for a big display is unbeatable for developer er…

Why is it to their detriment? It's not like they're stuck with it forever. "Can't work without it" is really "won't work without it because they prefer installing it over going without."

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

#252

Post by pjmlp »

whartung wrote: post #249

I think these modern TUIs are a testament to the general failure of modern GUIs. It's not like they're particularly easier to write these. But since there's no remote GUI option, much less a portable remote GUI option, particularly one that's not just a video of an entire desktop, we're stuck with these. WHo wants to fire up an entire desktop to get open a simple utility app? Obviously the Web satisfies much of the d…

Failure of Linux Desktop you mean.

RDP works great and GUI tooling for Windows and macOS is quite comparable to using VB, Delphi, Smalltalk like experiences.

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

#253

Post by madmountaingoat »

floam wrote: post #70
PaulHoule wrote: post #8

In the golden age of DOS you had an array of bytes representing characters and an array representing attributes (background and foreground colors) and the hardware drew out of that. If you wanted to write a ‘A’ to a certain spot you wrote 0x41 to a certain memory address and that was that —- there were some wait states involved but it was way faster than drawing on a 9600 baud terminal with ANSI terminal commands tha…

Damn that actually sounds superior. How did changing the size work?

The standard screen was 80 by 25. There were two addresses you needed to know 0xb000 for monochrome displays and 0xb800 for color. For monochrome you could just blast characters/attributes to the address and everything looked great. For color you had to add a little bit of assembly so writes didn't happen when the monitor was doing certain things (or else you would get some flickering). The little hacks were all well known. Then you could build your own 'windowing' system by just maintaining separate screen buffers and having a little bit of code to combine for buffers when writing the actual hardware. In the early days everyone code was synchronous and code would start listening for keyboard events and react and repaint in a very ad hoc fashion. Mouses made things a bit more complicated as you needed to maintain a persistent model of the UI to process their events. So the UI code was simple and easy to work on, but you had to squeeze these programs into tiny memory footprints so you would spend a lot of time trying to find more memory. One of the bigger projects I worked on had a memory manager that relocated blocks to create contiguous space but since there was no OS support for things that like the code was actually updating pointer in the heap and stack - which was a great source of complicated bugs. Whoa onto anyone that tried to use a linked lists in such an environment. But yeah, it was a fun time.

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

#254

Post by nxor »

FpUser wrote: post #234
nxor wrote: post #229

Earlier quoted context omitted.

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

Because I tell AI exactly what and very often how to write the code to avoid sub-optimal solutions AI so keen to propose if not properly directed. As for autocompletion, not sure about every tool but CLion and other IDEs I have from JetBrains are genius. Yes they can autocomplete multiple lines of code with a single keystrokes and no I do not really want to write it myself as it mostly boilerplate code I've written m…

How can you recognize optimal / suboptimal solutions if you need to use AI in the first place? As for boilerplate, I thought there were ways to automate this without AI, but I guess that makes sense to me. Not trying to sound accusatory, just jarred by the AI hype generally

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

#255

Post by pjmlp »

heresie-dabord wrote: post #159
CGamesPlay wrote: post #125

(Article is from 2023, so the title should be updated to say "32 years ago", or something) The biggest loss in TUIs is the latest wave of asynchronous frameworks, which bring the joy of dropped keypresses to the terminal. In any TUI released before the year 2000, if you press a key when the system wasn't ready, the key would just wait until the system was ready. Many TUIs today still do this, but increasingly frequen…

When people love an IDE product so much that they can't work without it, they have overspecialised to their detriment. And possibly to the detriment of the code itself. > As for terminal IDEs The GNU/Linux terminal is the killer app . Multiple terminals in a tiling window manager is peak productivity for me. (Browser in a separate virtual workspace.) And modern scaling for a big display is unbeatable for developer er…

As someone that started when only rich people could afford GUIs, I don't understand what is killer app about it.

We used text terminals because that is what we could afford, and I gladly only start a terminal window when I have to.

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

#256

Post by uecker »

somat wrote: post #140
dapperdrake wrote: post #72

Earlier quoted context omitted.

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 real…

I would say autoconf/automake is not really useful anymore and probably somebody should just establish a new and simplified standardized setup and Makefile for C projects.

And yes, efficient separate and incremental compilation is major advantage of C. I do not understand why people criticize this. It works beautifully. I also think it is good that the language and build system are separate.

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

#257

Post by f1shy »

pjmlp wrote: post #252
whartung wrote: post #249

I think these modern TUIs are a testament to the general failure of modern GUIs. It's not like they're particularly easier to write these. But since there's no remote GUI option, much less a portable remote GUI option, particularly one that's not just a video of an entire desktop, we're stuck with these. WHo wants to fire up an entire desktop to get open a simple utility app? Obviously the Web satisfies much of the d…

Failure of Linux Desktop you mean. RDP works great and GUI tooling for Windows and macOS is quite comparable to using VB, Delphi, Smalltalk like experiences.

X could do that before RDP was even a project. I think OP is meaning something different.

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

#258

Post by gcanyon »

layer8 wrote: post #117
gcanyon wrote: post #87

Looking at Windows UIs from the '80s -- did Microsoft just not know the phone numbers of any graphic designers? Or did they make it ugly on purpose?

There are no Windows UI screenshots in the article.

Fair —- but are you claiming either:

1. The DOS screenshots in the article are in any way reflective of a designer’s input

2. That Windows was a visually pleasing design?

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

#259

Post by pjmlp »

rpodraza wrote: post #225
heresie-dabord wrote: post #159

Earlier quoted context omitted.

When people love an IDE product so much that they can't work without it, they have overspecialised to their detriment. And possibly to the detriment of the code itself. > As for terminal IDEs The GNU/Linux terminal is the killer app . Multiple terminals in a tiling window manager is peak productivity for me. (Browser in a separate virtual workspace.) And modern scaling for a big display is unbeatable for developer er…

Good luck writing Java with notepad.

We did that back in 1996, however the sentiment applies to most languages.

Example Notepad versus Turbo C++ described on the article.

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

#260

Post by snovymgodym »

markus_zhang wrote: post #169
cameldrv wrote: post #162

Earlier quoted context omitted.

Yes. Back in the DOS days, and even before, when people used actual terminals, there was a keystroke buffer. You'd see people who really knew the interface fly through tasks being multiple keystrokes ahead of the UI. Stuff would just flash onto the screen and disappear as it processed the input that was already in its buffer. It should be possible to implement this with modern frameworks, but it requires thought.

Yeah. I used to work as a phone surveyor, the one you hate. Our software is a terminal connected to a mainframe. I got used to it after a few weeks and was very productive. Costco Canada vision shops still use a terminal connected to an AS/400 machine as I snooped around last month.

Costco still uses AS/400 company-wide for their inventory system I think
Post reply on HN