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

471–480 of 607 posts

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

#471

Post by nec4b »

constantcrying wrote: post #461
nec4b wrote: post #399

Earlier quoted context omitted.

I don't think others are talking about what you are angry about. I said that with the first reply and I'm not the only one saying it. Nobody is trying to take Zed or Neovim away from you. By the way one of the most frequent modern TUI apps that I use is Midnight Commander. It's a very nice app, which I use mostly when I SSH into a remote machine to manage it. Is there a 2D accelerated GUI that can help me do the same…

>Is there a 2D accelerated GUI that can help me do the same? Of course. Just mount it through ssh and use whatever file manager you already have. It is very silly to switch tools just because the machine is somewhere else. Switching tools just to accommodate the machine being remote is just bizarre to me. You even said that you used mc mostly for remote machines. What is the point of that? Now you have to use at leas…

You seem to have very strong feelings when other people have different preferences then you. Why would use words like bizarre, delusional and total waste, when discussing such trivial matters.

>> Why? Do you think that is reasonable at all, when something as simple as just mounting over ssh exists?

In short yes. I use it mostly on remote machines and on my desktop Linux machine. Before that I used Norton Commander on DOS. I don't remote only from Linux machines but also from a Windows laptop. It is much quicker and easier to simple run "mc" in an ssh session when I need it than trying to mount the drive and then run another application on the local machine.

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

#472

Post by GuB-42 »

int_19h wrote: post #436
kccqzy wrote: post #424

Earlier quoted context omitted.

And I only recently discovered that Ctrl+Ins and Shift+Ins worked in my Emacs despite me never configuring it; and it even works in the minibuffer. It also worked in a couple of terminal emulators I have tried on Linux. It's really more universal than one might think.

It's unfortunate that the accidental standard also happened to be the one requiring the use of both hands. I think that's why Ctrl+X/C/V won in the end.

It doesn't. Shift+Del, Ctrl+Ins,... can be done just using the right hand, while Ctrl+X/C/V uses the left hand. And sometime you may want to use two hands, which can be done in both cases by using the other Ctrl and Shift key. I actually use both kinds of shortcuts, depending on the situation.

Del and Ins are also conveniently close to the cursor navigation keys (arrows, home, end, PgUp, PgDn).

The reason I think Ctrl+X/C/V won out is that it is more convenient when using the mouse, it is also better with nonstandard keyboards where the "Ins" key is awkwardly placed, if not missing entirely.

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

#473

Post by elric »

kristianp wrote: post #462

It's funny that students in the early 90s would use a pirated copy of turbo C or pascal, but in the early 2000s when Java took over curriculums, students couldn't access a decent IDE. Many never saw a debugger in action, and executed javac in a dos window.

That sounds unlikely. AFAIK both Eclipse and Netbeans have had pretty good debuggers since the early days, probably around 2002ish.

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

#474

Post by self_awareness »

badsectoracula wrote: post #368
self_awareness wrote: post #153

Earlier quoted context omitted.

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).

> Glibc is the main reason Linux software is binary non-portable between distros Linux software is binary portable between distros as long as the binary was compiled using a Glibc version that is either the same or older than the distros you are trying to target. The lack of "portability" is because of symbol versioning so that the library can expose different versions of the same symbol, exactly so that it can prese…

> Linux software is binary portable between distros as long as the binary was compiled using a Glibc version that is either the same or older than the distros you are trying to target.

Well, duh? "Property A is possible if we match all requirements of property A".

Yes, using older distro is the de facto method of resolving this problem. Sometimes it's easy, sometimes it's hard, especially when we want to support older distros and using a new compiler version and fairly fresh large libraries (e.g. Qt). Compiling everything on older distro is possible, but sometimes it's hell.

> And this is not unique to Glibc, other libraries do the same thing too.

This only means that it is a very good idea to drop dependency on glibc if it's feasible.

macOS has a "minimum macos required" option in the compiler. Windows controls this with manifests. It's easy on other systems.

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

#475

Post by self_awareness »

int_19h wrote: post #418
self_awareness wrote: post #153

Earlier quoted context omitted.

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.

Yes, Linux is reversed in this aspect -- glibc is not really binary friendly, but kernel syscalls are. On other systems, kernel syscalls are not binary friendly at all, but libc is friendly.

I'm fine with using libc on other systems than Linux, because toolchains on other systems actually support backward compatibility. Not on Linux.

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

#476

Post by Theodores »

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.

The keyboard buffer size was something like sixteen keystrokes. This was bad news if you noticed your input wasn't working and you needed to press CTRL + whatever to quit the program since the buffer was full and unable to accept the CTRL + whatever. Instead it had to be CTRL + ALT + DEL.

Three decades later I learn that there were utilities to make the keyboard buffer bigger. But, in those days before search engines, how was I to know?

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

#477

Post by viraptor »

jjav wrote: post #451
bigstrat2003 wrote: post #139

Earlier quoted context omitted.

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

>it's not self-documented enough to just pick up and use with no instruction. If they just plop you in front of a 3-d printer never having seen one and having no documentation, it'll probably take you a good while to produce something useful with it. All good tools require training & experience.

That's really not the case. I learned programming in the DOS Borland apps and did it with next to no instructions. I don't think I've ever seen the manual. Just read about the language itself. They were that easy to understand and use. Emacs is not in the same class as far as discoverable interface is concerned.

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

#478

Post by saint_yossarian »

speed_spread wrote: post #379
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's not about being arcane, it's about the lack of discoverability. Emacs and vi don't have (by default) affordances like a menu that enables a user to discover and learn the interface at their own pace. The learning curve is much smoother and allows for casual uses without having to pull a book each time.

Vim does have a menu system, and AFAIK it's still enabled by default in GUIs like GVim.

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

#479

Post by skydhash »

trinix912 wrote: post #460
prmoustache wrote: post #360

Earlier quoted context omitted.

vi is documented Problem is most people start it the first time by providing a text file instead of firing it on its own and be greeted by the tutorial. I guess that is because they are blindly following another tutorial instead of trying to understand what they are doing. My opinion is that "self documentation", "Getting started" pages and "tutorials" is a disease. People would actually get up to speed quicker by re…

VI or VIM? VI has no welcome screen. It drops you straight into a blank screen of '~' from where you just have to know to enter the insert mode, which is also not indicated anywhere unlike in VIM.

There was a time when manuals was kinda big physical books. I think I have a word perfect one that is the size of a textbook. It was not about getting a result (any result) in 5 seconds. It was more about having a goal and browsing through relevant sections to learn how to do it.

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

#480

Post by christophilus »

carra wrote: post #450

Things like Borland C and VB/WinForms really do take me to a simpler time. There was joy in being able to write simple programs very fast, in a more intuitive way, without needing to use browsers or frameworks or writing shaders to do the simplest things. Current systems are more powerful and versatile for sure, but for a teenager curious for coding they are a much less welcoming environment in a lot of ways. The eve…

VB6 was a revelation to me, coming from C and C++ at the time. It was so much easier and still plenty performant for the kinds of little business applications I was building at the time.
Post reply on HN