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

211–220 of 607 posts

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

#211

Post by a-dub »

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…

> Anyway, does anyone remember Metrowerks CodeWarrior?

didn't it have a cute little re-distributable header file that had a bunch of useful containers in it? (linked lists, hash tables, etc)

i didn't work with it much but once worked with a mac guy who added it to our project. sometimes i'd have to build his stuff, i remember lots of yellow road construction icons!

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

#212

Post by igouy »

jll29 wrote: post #181
karmakaze wrote: post #148

Earlier quoted context omitted.

I wasn't paying attention to when 30 years ago actually was... So disappointing to expect a GUI Smalltalk System Browser and seeing DOS TUIs. And then delight recalling Turbo C/Pascal and MS C 4.0 with CodeView that even worked in 43 or 50 line modes.

Yes, me too, I was expecting either Smalltalk or LISP machine GUIs. Having said that, some old TUIs were clearer and faster even on weaker hardware. This should be a lesson for us today. Color transitions and animated icons flying over the desktop are NOT what I need, but speed, clarity, and discoverability of more rarely used functionality are vital.

May 1988 -- Smalltalk/V 286 -- on IBM-PC, PS/2 or compatible, with an 80286 or 80386

"INTRODUCTION TO THE SMALLTALK/V 286 ENVIRONMENT"

http://stephane.ducasse.free.fr/FreeBooks/SmalltalkVTutorial...

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

#213

Post by tombert »

SoftTalker wrote: post #193
nobleach wrote: post #129

Earlier quoted context omitted.

For reference, I did use Magit for my short stint with Emacs (and then Spacemacs/Doom Emacs). I've always been more into Vim. I tried the Atom editor several years ago with lots of Vim emulation and quite a bit of customization - one of those being a Magit clone. I moved to NeoVim many years ago and have been using NeoGit (a supposed Magit clone) the entire time. It's good but I'm missing the "mind blowing" part. I'd…

It's mind-blowing because it makes git actually usable.

Maybe it's Stockholm syndrome for me, but I never really understood what was so unusable about the vanilla command line git interface.

If you want to do some really advanced stuff, sure it's a little arcane, but the vast majority of stuff that people use in git is easy enough. Branching and committing and merging never seemed that hard to me.

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

#214

Post by ataru »

The interfaces look like they wanted to be graphical, as they have windows and drop down menus, and they wanted to have multi-tasking, as they implemented the overlay tools in Borland Sidekick. They wanted those things but they were limited to staying in text mode because widespread adoption of any real graphical interface was slow.

It seems a little humorous now that professionals were stuck for several years doing their day to day word processing, spreadsheets and databases in text mode, where getting different sized text or different fonts was almost impossible. This also wasn't just in the 80s, it was still somewhat true in the early 90s, not very long before the beginning of the internet as we know it.

Still, I wonder if things are really any better now, as we're all using software interfaces built on something else that's not really appropriate for the job. HTML.

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

#215

Post by constantcrying »

prinny_ wrote: post #200
constantcrying wrote: post #176

Earlier quoted context omitted.

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

> If you use neovim inside a terminal you are just straight up using an inferior product, with less features and more problems I use neovim like that and the selling point for me is that it's 1 less program that I have to install and learn with the added (crucial) benefit that it doesn't update on its own, changing UI and setting that I was used to.

>benefit that it doesn't update on its own, changing UI and setting that I was used to.

This exact thing remains true though, you are using the exact same neovim, but instead of it being wrapped inside a totally bizarre piece legacy software, it is rendered inside a modern graphical frontend. It looks mostly the same, except it handles fonts better, it is independent of weird terminal quirks and likely faster. There is no dowside.

And again, your point about using TUI stuff because of the input method or whatever is just false. Neovide has the exact same input method, yet has a complete GUI. Using the terminal makes no sense it all, it is the worst neovim experience there is.

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

#216

Post by danparsonson »

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?

There were a bunch of predefined modes in the video BIOS, and with a little bit of assembler you'd issue an interrupt (a system call really) which would change the video mode. Then as the parent comment said, you could write to video memory directly and your writes would either be interpreted as ASCII character/attribute pairs in a text mode, or colour palette indices in a graphical mode.

Most games at that time used mode 13h which was 320x200 with 8-bits per pixel which therefore indexed into a 256-colour palette (which could itself be redefined on the fly via reading from and writing to a couple of special registers - allowing for easy colour-cycling effects that were popular at that time). Here's a list of the modes: https://www.minuszerodegrees.net/video/bios_video_modes.htm

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

#217

Post by Matumio »

cameldrv wrote: post #162
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…

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.

Remember the venomous, desperate BEEP! when the keystroke buffer was full. (Or was it when pressing too many keys at once?) Like a tortured waveform generator constantly interrupted by some higher-priority IRQ. Good times.

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

#218

Post by cindyllm »

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…

[dead]

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

#219

Post by BeetleB »

dapperdrake wrote: post #66
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.

Magit is mind blowing. How did the magit guy or people even come up with the data model? Always had the feeling that it went beyond the git data model. And git porcelain is just a pile of shards.

> How did the magit guy or people even come up with the data model?

It's not all that different from a typical TUI interface.

Magit isn't great because of the interface. It's great because the alternative (plain git) has such a crappy interface. Contrast principle and all.

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

#220

Post by NetMageSCW »

Lapel2742 wrote: post #53

> “In my house”, we used something called SideKick Plus (1984), which wasn’t really a code editor: it was more of a Personal Information Management (PIM) system with a built-in notepad. Finally! Someone who still remembers the best software ever written. I looooved Sidekick and we used it throughout our small company. It's so long ago. I remember only parts of it now but it was such a useful tool.

The best software ever written was ThinkTank (and next it to it, Memory Mate). Sidekick was great for popularizing the TSR, though.
Post reply on HN