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

411–420 of 607 posts

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

#411

Post by int_19h »

eikenberry wrote: post #366
pjmlp wrote: post #353

Earlier quoted context omitted.

Xerox PARC, Atari, Amiga and many others had shells, without needing to live on a teletype world. It is only cross platform as long as it pretends to be a VT100.

It's not about needing to live in a teletype world, it is about how language/text is just a better interface for a general use computer. Computers primary feature is that they are programmable and an interface that allows you to take advantage of that is superior to one that doesn't. The programmable GUIs all failed to gain traction (smalltalk and like), that left the shell (and maybe spreadsheets) as the best UI for…

The reason why GUIs became so popular so quickly after they were introduced is because text is not "just a better interface for a general use computer".

Like OP, I remember the days when command line was all you had, and even then we used stuff like TUI file managers to mitigate the pain of it.

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

#412

Post by int_19h »

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.

Was literally a thing in some colleges.

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

#413

Post by int_19h »

eikenberry wrote: post #320
pjmlp wrote: post #252

Earlier quoted context omitted.

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.

RDP works great on Linux as well. The problem isn't remote access, it is lack of good cross platform GUIs. There is a reason browsers are dominating the UI space and TUIs are popular.

Qt is still around. And there's stuff like Avalonia.

The problem is that people don't use that and reach for Electron instead, and then you get that "bad on any platform (but good enough to ship)" effect.

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

#414

Post by int_19h »

pjmlp wrote: post #271
f1shy wrote: post #257

Earlier quoted context omitted.

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

Of course it could, it is essentially dead, because hardly anyone still does X remoting, and Wayland doesn't support it.

Ironically these days the built-in "remote desktop" feature in Gnome is literally RDP.

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

#415

Post by int_19h »

miohtama wrote: post #168
JeremyHerrman wrote: post #121

I'm interested in how these old IDEs were used during the transition from assembly to high level languages. It seems especially topical given the LLM integration into today's IDEs. Back then was it common to have a split or interleaved view of high level and assembly at the same time? I'm aware that you could do something like the following, but did IDEs help visualize in a unified UI?: $ cc -S program.c $ cat progra…

It was not very common to interleave assembly in MS-DOS IDEs. Assembler and its IDE were separate tools you paid for. But not unheard of. You could "dump" your OBJ file for assembly. Later C compilers got some better inline assembler support but this was towards the 32-bit era already. Also Borland had its own compiler, linker and such as separate binaries you could run with a Makefile but you really never had to, as…

It was quite common actually, most DOS C compilers supported asm{} blocks and Turbo Pascal also supported inline assembly. Paid assemblers like MASM were high-end tools.

On Unix though it was more common to have .s files separately.

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

#416

Post by int_19h »

ranger_danger wrote: post #402

We didn't lose all of them though. I know at least mcedit and eFTE are still kicking. And there's some new ones that pay tribute to the interface style such as https://github.com/istoph/editor

If you like mcedit check out https://github.com/elfmz/far2l (`-e` starts it in editor mode).

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

#417

Post by int_19h »

microtonal wrote: post #321
dardeaup wrote: post #175

Earlier quoted context omitted.

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?

As far as I recall VCL was ported, but the IDE itself was running WINE (as it was written back then) and it was not very stable. I just googled and Wikipedia seems to confirm my memory: https://en.wikipedia.org/wiki/Borland_Kylix#Features

Kylix apps in general looks like Windows apps, which is to say, rather out of place on a Linux desktop.

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

#418

Post by int_19h »

self_awareness wrote: post #153
Onavo wrote: post #13

Earlier quoted context omitted.

Go especially, on some platforms they go straight to syscalls and bypass libc entirely. They even bring their own network stack. It's the maximalist plan 9 philosophy in action.

I don't really like Go as a language, but this decision to skip libc and go directly with syscalls is genius. I wish Rust could do the same. More languages should skip libc. Glibc is the main reason Linux software is binary non-portable between distros (of course not the only reason, but most of the problems come from glibc).

The consequences of this genius decision were stuff like this:

https://github.com/golang/go/issues/16570

Which is why they have already backpedalled on this decision on most platforms. Linux is pretty much the only OS where the syscall ABI can be considered stable.

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

#419

Post by gldrk »

constantcrying wrote: post #374
nec4b wrote: post #344

Earlier quoted context omitted.

There are no escape sequences when running TUI apps in DOS. They have direct memory access to the video card. >> This is just delusional. That is a bit uncalled for.

Did you just not read the rest of my post? We are not talking about DOS, we are talking about "modern" TUIs you would use on a modern Linux/Windows/MacOS system. I even made that explicit in my first paragraph.

Windows NT has a native console API that every non-Cygwin program used until a few years ago, when Microsoft finally implemented terminal emulation. See, for example, https://github.com/vim/vim/blob/e7c765fe5997daa845222351e114.... It’s just that there is little interest in TUIs from Windows users.

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

#420

Post by int_19h »

immibis wrote: post #382
steveklabnik wrote: post #378

Earlier quoted context omitted.

Yes, it's not literally libc on windows, but the point is that directly calling syscalls is not supported, you have to call through the platform's library for doing so. On some systems, this is just not a supported configuration (like what you're talking about with Windows) and on some, they go further, and actually try and prevent you from doing so, even in assembly.)

There's still something on the platform that you can call without extra indirection in the way on your side of the handoff. That is true on all platforms; whether it's an INT or SYSCALL instruction or a CALL or JMP instruction is irrelevant.

If it's a CALL instruction into a user-space DLL, that's still an extra indirection.
Post reply on HN