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

361–370 of 607 posts

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

#361

Post by bitwize »

constantcrying wrote: post #334
bitwize wrote: post #288

Earlier quoted context omitted.

I know, man. Unless your window full of text is GPU-accelerated, tear-free and composited, with raytraced syntax highlighting and AI-powered antialiasing, what is even the point? TUIs are great if your structure them around keyboard input. There's more of a learning curve, but people develop a muscle memory for them that lets them fly through operations. I think the utility of this is sorely underestimated and it mak…

You are conflating a method of interaction with a method of drawing things to the screen. These are totally different things. Whether you have a keyboard focused interface like vim or not, has absolutely nothing to do with whether you are drawing graphics by sending escape codes to a terminal emulator to render the interface. Neovim and it's frontends prove that if you remove terminal emulators the applications becom…

Thats_just_like_your_opinion_man.gif

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

#362

Post by skydhash »

marssaxman wrote: post #273
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.

It's possible I might once have given emacs a try, if the way people talk about it did not sound like such baffling moon-language: when I encounter stuff like "so I C-x C-f’d into my init.el, M-x eval-buffer’d, then C-c C-c’d an org-babel block before C-x k’ing the scratch buffer" I just want to back away slowly and leave them to it, whatever it is they're doing. Y'all have fun with your C-r X-wing mork-butterfly por…

So you don’t ‘git clone’ and ‘git commit’, or ‘mkdir’ and ‘grep’?

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

#363

Post by badsectoracula »

spwa4 wrote: post #158
dardeaup wrote: post #95

Earlier quoted context omitted.

Delphi is still very impressive. However, they missed out on a much greater opportunity. Part of Delphi's crown jewels is VCL which can only be used on Windows. If you use Delphi for an OS other than Windows you have to use FireMonkey/FMX. Lazarus has LCL which is VERY similar to VCL, but LCL on Lazarus is not limited to Windows. One can write a LCL application and it works the same on Windows, macOS, and Linux. If D…

VCL was ported to linux in the "Kylix" product, for both Pascal and C++. It was non-free and didn't see any uptake really.

IIRC it wasn't VCL but another framework like VCL that was built on Qt.

LCL (Lazarus' equivalent of VCL) took another approach where the base stuff are very Windows-y (due to the VCL heritage) but the backends have to essentially implement not only the backend-specific (Gtk, Qt, etc) widget functionality but also a small subset of the Windows API.

While this makes porting harder for the Lazarus developers, it makes it easier to port stuff between OSes and even port stuff from Delphi to Lazarus (some developers can also use both Delphi and Lazarus - e.g. AFAIK Total Commander uses Delphi for the 32bit builds and Lazarus for the 64bit builds).

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

#364

Post by TacticalCoder »

bigstrat2003 wrote: post #139
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 instruc…

[dead]

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

#365

Post by prmoustache »

geophile wrote: post #201

Turbo Pascal was completely amazing. I remember resisting it for a long time, because IIRC it implemented non-standard Pascal. But the competitive tools were less powerful and far more expensive, (e.g. the Microsoft tools). And then I tried it, and was completely blown away. I no longer cared about the non-standard stuff. I had a fast intuitive IDE running on my original IBM PC. As for modern IDEs, Intellij has been…

Except for resource usage.

I chose it becaue I don't have access to neovim on my cloud desktop and ideavim is a superior solution to any vim like plugins for vscode. It is struggling with 4 cores and 16GB of ram with only a few projects open at a time. Some of it is due to being win11 with the amount of security malware installed by my company but still vscode doesn't seem to make it suffer that much.

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

#366

Post by eikenberry »

pjmlp wrote: post #353
eikenberry wrote: post #310

Earlier quoted context omitted.

The killer thing about it is that it is a gateway to the shell, all the command line tooling and the best cross-platform UI.

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 this. Though as AIs mature we might see a shift here as they could provide a programmable interface that could rival shell scripting.

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

#367

Post by jasperry »

dualogy wrote: post #283
duanhjlt wrote: post #170

Nostalgia aside, those classic TUIs nailed responsiveness and cohesion. Modern setups can match features, but rarely that instant, synchronous feel. Emacs + Magit shows the power of text-first integration, yet JetBrains-style debuggers and glue still win for many. It’d be great to see a modern, fast, Borland‑like TUI with solid LSP and LLDB integration.

TextAdept, the most criminally-underhyped high-quality text editor that I know of, has supported LSP for quite some time now IIRC, and has (not just GUI versions but also) a first-class TUI version.

TextAdept and its possibilities have intrigued me for a while now; a fast Qt GUI and Lua-based configuration sounds like a sweet spot for me. But I've never fully taken the plunge to configure it for development. I'm open to reading more propaganda for it if you can point me to any :)

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

#368

Post by badsectoracula »

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

> 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 preserve backwards compatibility without breaking working programs.

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

The solution is to build your software in the minimum version of libraries you are supposed to support. Nowadays with docker you can set it up in a matter of minutes (and automate it with a dockerfile) - e.g. you can use -say- Ubuntu 22 to build your program and it'll work in most modern Linux OSes (or at least glibc wont be the problem if it doesn't).

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

#369

Post by manquer »

mbreese wrote: post #238
disqard wrote: post #228

Earlier quoted context omitted.

Sci-fi author Robert Sawyer (who has won Hugo and Nebula awards) is a big fan of Wordstar -- he uses it to write his books. I highly recommend reading this: https://www.sfwriter.com/wordstar.htm

So is George R.R. Martin. https://news.ycombinator.com/item?id=26695017

Not an example we want to cite for prowess of productivity with WordStar, given Martin's throughput as a writer in last couple of decades.

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

#370

Post by em-bee »

tombert wrote: post #304
SoftTalker wrote: post #247

Earlier quoted context omitted.

Wnen I do anything more than commit/push/pull at the command line I will quickly get myself so confused that I end up deleting the directory and cloning it again. That doesn't happen to me (much) with magit.

Fair enough. I feel like I do a fair amount of the more advanced features (interactive add and rebase, bisect, worktrees) without any fancy tooling and I don't have a problem much anymore, but admittedly they did confuse me at first.

i don't remember confusion. i find it's mostly understanding the data model and in particular the branches and references/reflog. when i am worried i might break something then i tag the the checkout where i am at and i know i can always revert to that. i also compare the original with the new state. i usually know what that diff should look like, and even if the operations in between are confusing, if the diff looks like what i expect then i know it went all right. trust the process but verify the results.

the big thing i am missing from it is a branch history. a record for every commit to which branch it once belonged to. no improved interface can fix that. that would have to be added to the core of git.

Post reply on HN