Live data from Hacker News

IDEs we had 30 years ago and lost (2023)

blogsystem5.substack.com

61–70 of 607 posts

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

#61
post #16
post #5

Speaking of bloat: why are binaries from Rust or (much worse) Go so damn huge? This is in release mode with debug off. It’s weird because memory use for the same sorts of programs is not much worse than other languages. In Rust memory use seems comparable to C++. In Go there’s a bit more overhead but it’s still smaller than the binary. So all this is not being loaded. I get the sense devs just don’t put a lot of effo…

Rust doesn’t strip debug info by default.

The vast amount of debug info does make the problem worse, but it doesn't take long before a moderately complex Rust programs grows to 100MB even after stripping.

When I tried to compare Rust programs to their C(++) equivalents by adding the sizes of linked libraries recursively (at least on Linux, that's impossible for Windows), I still found Rust programs to have a rather large footprint. Especially considering Rust still links to glibc which is a significant chunk of any other program as well.

I believe many of Rust's statically linked libraries do more than their equivalents in other languages, so I think some more optimisation in stripping unused code paths could significantly reduce the size of some Rust applications.

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

#62
A little bit later, there was visual editors for gui app like Delphi and Visual Basic and co.

Despite VB to be a little bit shitty, I think that a big loss happened in the GUI software development world since web apps became the norm.

Not many remember this world where you could easily graphically create your UIs by placing components and that reactive interface were a given without effort.

I really miss the original Delphi before things went DotNet shitty...

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

#63
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.

So, I have been using emacs on and off for 32 years at this point, and I my emacs all set up with eglot and rustic and magit and the like and it's great.. but I still find I just fall back to RustRover when doing development because (unlike some the classic TUI IDEs mentioned in TFA) it just never feels like it's fully glued together and it's always a bit fragile and I never remember how to do certain things -- even…

There is a good IDE-style debugger available for Emacs these days: https://github.com/svaante/dape

Since it has no dependencies, I wouldn't be surprised if it gets merged into Emacs core at some point.

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

#64

I used to use a Java-oriented IDE called “Visix Vibe”, at first as an experiment in application development with Java and then as an alternative to Delphi, which was my bread and butter tooling environment for custom application development. Both of these IDE’s gave me a huge productivity boost, and it used to be a no-brainer to give customers a realizable estimate for getting the UI done, then wiring up logic, and g…

You may laugh, but that is how I use html forms today. Simple. And effective.

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

#65
Good article.

I'm more of a GUI guy who is contend with VSCode. I'm intrigued to learn Emacs but don't have the time for it.

Back in the 90s, however, Borland TUI was indeed the pinnacle. I remember I played with Turbo C for a while but did not learn anything, but it was fun just to use the IDE.

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

#66
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.

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

#67
post #28
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.

The Magit experience is due to the use of the transient package for its UI. Some other packages also use it. Most notably for my personal usage is the gptel package.

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 Transient hooks into the MVC and breaks elementary navigation such as using isearch or switching around buffers has irritated me ever since Magit adopted the new interface.

The real neat thing about Emacs' text interface is that it is just text that you can consistently manipulate and interact with. It is precisely the fact that I can isearch, use Occur write out a region to a file, diff two buffers, use find-file-at-point, etc. that makes it so interesting to me at least.

A far more interesting example than Magit is the compile buffer (from M-x compile): This is just a regular text buffer with a specific major mode that highlights compiler errors so that you can follow them to the referenced files (thereby relegating line-numbers to an implementation detail that you don't have to show the user at all times). But you can also save the buffer, with the output from whatever the command was onto disk. If you then decide to re-open the buffer again at whatever point, it still all looks just as highlighted as before (where the point is not that it just uses color for it's own sake, but to semantically highlight what different parts of the buffer signify) and you can even just press "g" -- the conventional "revert" key -- to run the compile job again, with the same command as you ran the last time. This works because all the state is syntactically present in the file (from the file local variable that indicates the major mode to the error messages that Emacs can recognize), and doesn't have to be stored outside of the file in in-memory data structures that are lost when you close Emacs/reboot your system. The same applies to grepping btw, as M-x grep uses a major mode that inherits the compile-mode.

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

#68
No mention of Visual Studio, as distinct from Visual Studio Code. No mention of JetBrains, PyCharm. The author didn't mention that Borland cost $99.95 in 1987, back in the day. Now, Visual Studio costs $499.92/mo. Yeah, the free versions aren't as fully featured or as well integrated as the thing you paid for, what else is new?

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

#70

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?
Post reply on HN