The title needs to be updated. These are IDEs we had 32 years ago.
32 years ago was 1993. Those IDE's were from the 80's.
IDEs we had 30 years ago and lost (2023)
491–500 of 607 posts
Re: IDEs we had 30 years ago and lost (2023)
#492Earlier quoted context omitted.
I doubt it, probably just running on a regular Power ISA rack mount server from IBM. Though I guess technically all IBM i aka AS/400 is running on an emulator. https://en.wikipedia.org/wiki/IBM_i#Technology_Independent_M...
Nope, we still have an IBM i deployment kicking around at $DAYJOB, it's running natively on POWER hardware. Way back in the days of the original OS/400 running on AS/400 hardware, IBM had the foresight to have applications compile to MI (Machine Interface) code; which is a bytecode format closer to something like LLVM IR instead of something like JVM or CLR bytecode. When a PGM object is copied or created on an IBM i…
In some ways the IBM mainframe line is an amazing piece of engineering. My understanding is that the emulation layers can even emulate hardware bugs/issues from specific lines of long-dead equipment so that ancient code (that was written to take these issues in mind) will still function as expected.
Re: IDEs we had 30 years ago and lost (2023)
#493Earlier quoted context omitted.
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.
Kind of like the syscall dispatch table on the Linux kernel side, right? After you issue the handoff instruction and it becomes the operating system's problem, there's still more code before you get to the code that does the thing you wanted.
Re: IDEs we had 30 years ago and lost (2023)
#494I 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…
> couldn't even figure out how to save a document
100% this.
It is (counts on fingers) 43 years since I got my first computer of my own, and I've been using Unix-like OSes since just 6 years later in 1988... So, 37 years?
Still, even now, Emacs is this bizarre thing that teleported in from 1962 or something. Older than Unix, older than -- well, anything else still used by almost anyone except Cobol and Fortran.
I am old, starting to think about retirement, and Emacs is weird and clunky and ugly. It uses weird nonstandard names for things like "files" and "windows" and even the keys on your keyboard.
I know they are native and natural for the fans. I'm not one. I'm a fan of the great era of UI standardisation that happened at the end of the 1980s and start of the 1990s.
I wish someone would do a distro of Emacs with ErgoEmacs built in, on by default, and which could pick up the keyboard layout from the OS.
ErgoEmacs is a brave attempt to yank Emacs into the 1990s but you need to know Emacs to use it, so it's not enough.
Re: IDEs we had 30 years ago and lost (2023)
#495> Visual Basic was the pinnacle of graphics programming I am still shocked how no tool since has managed to come even close to VB. You could easily develop a moderately complex GUI application that felt snappy in an afternoon. C# with WinForms is the second closest to that. All other iterations since have not been designed with individual developers in mind, sadly. A powerful developing alternative to this paradigm c…
The simplicity and efficiency of Visual Basic UI programming relied on several assumptions that became obsolete in 2000 when LCD and high-DPI displays became widely available. Everything in the VB UI editor was based on a fixed layout. There was a fixed font size, fixed DPI-density display expectation, and fixed button sizes. Every dialog assumed fixed sizes and was non-resizable. Adding a translation to such an appl…
> The simplicity and efficiency of Visual Basic UI programming relied on several assumptions that became obsolete in 2000 when LCD and high-DPI displays became widely available. Everything in the VB UI editor was based on a fixed layout. There was a fixed font size, fixed DPI-density display expectation, and fixed button sizes. Every dialog assumed fixed sizes and was non-resizable.
There are visual UI editors that provide for dynamic layouts. (The old Glade editor for GTK+ was one example; modern GTK+4 still does not come with a standard UI editor.) The underlying issue is pointless churn in modern UI frameworks, not the assumption of a fixed-DPI display.
Re: IDEs we had 30 years ago and lost (2023)
#496Earlier quoted context omitted.
People should also stop using terminal emulators. It is pretty silly to base software around ancient printing terminals. Everyone knows for a fact that only tech illiterates use a console instead of a GUI. Since all great devs use a GUI. Just a fact. Also, people should stop playing 2D games. It is pretty silly to base your entertainment on ancient technology when modern GPUs can render super-complex 3D scenes. And d…
Completely disingenuous. Stop the snark. For UI there exists a straight up superior alternative, which keeps all of the benefits of the old solution. Neovim is just straight up better when used outside of a terminal emulator. What is true for TUI vs. GUI is not true for CLI vs. GUI (or TUI for that matter) pretending the argument I made applies to the later is just dishonest. You can not replace CLI interfaces adequa…
Maybe on paper. But the snappy low-latency feel of TUI apps in the terminal is a joy, and unequaled in GUIs.
Re: IDEs we had 30 years ago and lost (2023)
#497Earlier quoted context omitted.
Thats_just_like_your_opinion_man.gif
This isn't reddit. Please do not do this, it is not only totally dishonest it makes discussion impossible. What I said about the separation of user interaction to graphics is also not an opinion.
You must be fun at parties.
Re: IDEs we had 30 years ago and lost (2023)
#498Earlier quoted context omitted.
The simplicity and efficiency of Visual Basic UI programming relied on several assumptions that became obsolete in 2000 when LCD and high-DPI displays became widely available. Everything in the VB UI editor was based on a fixed layout. There was a fixed font size, fixed DPI-density display expectation, and fixed button sizes. Every dialog assumed fixed sizes and was non-resizable. Adding a translation to such an appl…
> The simplicity and efficiency of Visual Basic UI programming relied on several assumptions that became obsolete in 2000 This is a great point that extends beyond rebutting the rose-colored glasses for the gool ole days of programming. While yes, things were simpler. That simplicity came at a cost. For instance, how accessible were VB apps to people who had sight-related disabilities?
More accessible by default than modern electron-based apps
Re: IDEs we had 30 years ago and lost (2023)
#499Things 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…
Another aspect of the sheer number of technologies that you have to use is that you can’t do very much as a solo developer. It introduces a social aspect. You must work as part of a team. Especially when you have a public facing website or large scale. So the field is less appealing for someone who is a typical introvert. The types of personalities are completely different compared to those from the mid-90s or before.
Re: IDEs we had 30 years ago and lost (2023)
#500I learned programming in turbo C++ - not because I grew up in 1990s, but because Indian education system is stuck in 1990s.
> So the question I want to part with is: have we advanced much in 30 years? Modern IDEs have some better refactoring tools, better features, and support more languages, but fundamentally… they haven’t changed much.
I can't give up any of: intellisense, type checking as I type, semantically meaningful navigation.