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

371–380 of 607 posts

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

#371

Post by emmelaich »

BeetleB wrote: post #219
dapperdrake wrote: post #66

Earlier quoted context omitted.

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.

Is magit much better than tig? I've never used magit.

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

#372

Post by rednafi »

I love reading about and occasionally tinkering with older text editors like vim, emacs, ed, acme, ex, nedit, and as such.

For actual work, though, I’ve been using VS Code exclusively since its inception. Electron might be a bloated mess, but spending time on alternatives doesn’t feel worth it. Maybe that’s because I didn’t grow up in the golden era of computing and can’t make the vim workflow stick no matter how hard I try.

I’m pretty sure twenty years from now, this generation of developers will get blurry-eyed reminiscing about how fast and feature-packed VS Code was, and how Microsoft built the best GUI text editor of its time.

As for TUI editors, I love micro because it has mouse support and doesn’t make you memorize a spellbook just to move around.

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

#373

Post by constantcrying »

eikenberry wrote: post #315
constantcrying wrote: post #231

Earlier quoted context omitted.

[flagged]

TUIs are the best cross platform apps. They run on all the major and minor platforms in general use. GUIs cannot compete with browsers being the next closest thing. They can be integrated with the shell and also work perfectly well remotely w/o issues. TUIs are superior in many ways to GUIs and have a place in the ecosystem.

TUIs do not even run the same across terminal emulators.

It is a total joke to call something which depends on how the underlying terminal emulator interprets specific ANSI escape sequences "multi platform".

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

#374

Post by constantcrying »

nec4b wrote: post #344
constantcrying wrote: post #338

Earlier quoted context omitted.

>As someone already mentioned before, I don't think you are talking about the same terminal as others are. People know perfectly well that I am talking about the way in which a terminal emulator can be used to display 2D graphics. By utilizing specific escape sequences to draw arbitrary glyphs on the terminal grid. >What are those hacks. Everything is a hack. TUIs work by sending escape sequences, which the terminal…

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.

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

#375

Post by dusted »

The issues mentioned in the article is generally applicable. While modern software does manage to make life marginally easier and simpler in some very specific ways, they generally manage to do so while also looking like absolute garbage, consuming hundreds of megabytes of memory to do tasks requiring kilobytes while burning through multiple orders of magnitude the amount of instructions actually needed to do the work.

Yes, Visual Basic was indeed the pinnacle, and today, it is QT, for what it's worth. But no, let's go write HTML and CSS, and when the Stockholm syndrome gets us bad enough, why not some React or Angular to get the party of pain going again ?

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

#376

Post by JoelMcCracken »

layer8 wrote: post #174
JoelMcCracken wrote: post #133

Earlier quoted context omitted.

To navigate emacs, you really only need to know ctrl, alt, and the basic norms of keyboard usage (return for newline/accept, shift for capitals) Really, compared to what I see here, the chief difficulty with emacs is the sheer volume of possible commands, and the heterogeneity of their names and patterns, which I believe is all a result of its development history. But the basics are just as you describe.

It’s a good question to what complexity (volume) the approach scales, but dialog boxes can get you quite far, and menus are fundamentally “just” a tree like keyboard shortcuts are. Emacs has Elisp commands first, then keyboard shortcuts for them, then maybe (not as a rule) menu items, and rarely dialog boxes. The Turbo Vision approach, from its design philosophy, has menus and dialogs first, then keyboard shortcuts f…

Yeah that’s fair. In many ways the spacemacs/doom model is more akin to what you describe, with a lot of caveats; it’s not a total rework of all key bindings. In emacs novice affordances are usually an afterthought, not part of the core design and community norms.

Of course, I must say there is a trade off here: you can design for novices or for advanced users, but very often not both.

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

#377

Post by pkal »

internet_points wrote: post #311
pkal wrote: post #67

Earlier quoted context omitted.

Transient is the worst part about Magit IMO (the best parts are how you can prepare a commit to just include the right changes, or the functionality bound inside the transient menus that make complex operations such as fixups or rebases trivial). Transient UIs are consistently uncomfortable to work with, and could usually be replaced by just using a regular special-mode keymap in a custom buffer. The fact that Transi…

Odd, I can `C-s` just fine in transient buffers. It works exactly like in other buffers. The `C-h` override is pretty cool there too, e.g. if from magit-status I do `C-h -D` (because I'm wondering what "-D Simplify by decoration" means), then it drops me straight into Man git-log with point at --simplify-by-decoration Commits that are referred by some branch or tag are selected. (Ooh, I learnt a new trick from writin…

OK, try the following in a Transient buffer:

- Search for something using C-s - Exit isearch by moving the point (e.g. C-n) - Is the transient buffer still usable for you? In my case it becomes just a text buffer and all the shortcuts just got mapped to self-insert-command.

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

#378

Post by steveklabnik »

immibis wrote: post #335
steveklabnik wrote: post #230

Earlier quoted context omitted.

You can only skip libc on Linux. Other unices and Windows don’t let you.

You can skip libc on Windows - you can't skip the system DLLs like kernel32. (In fact, Microsoft provided several mutually incompatible libcs in the past.) Well, you can non-portably skip kernel32, and use ntdll, but then your program won't work in the next Windows version (same as on any platform really - you can include the topmost API layers in your code, but they won't match the layers underneath of the next vers…

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

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

#379

Post by speed_spread »

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.

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

#380

Post by tpmoney »

nxor wrote: post #229
bibiver wrote: post #226

I saw this and was like, what? > have we advanced much in 30 years? IDEs have changed a lot, specially with AI-assisted ones. The author kind of acknowledges it, but imho it's a paradigm shift. Not just "a major difference". > The only major difference that we are starting to see might be AI-assisted coding, but this is a feature mostly provided by a remote service, not even by the installed code! Then I realized it’…

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

The same way a tailor understands stitches even if a sewing machine creates most of the stitches a tailor will ever stitch. Because understanding code is tangential to writing it. Which isn’t to say that writing it doesn’t help solidify knowledge and certainly plenty of people learn by doing and there may even be skills that atrophy as a result of not writing code in the same way that skills for writing assembly have atrophied with the use of higher level languages. But ultimately it is possible to understand some code without having written most of it by hand.
Post reply on HN