Live data from Hacker News

IDEs we had 30 years ago and lost (2023)

blogsystem5.substack.com

481–490 of 607 posts

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

#481

A few others not mentioned: DOS: FoxPro 2.x, dBASE III Plus, dBASE IV, Turbo Pascal 5.5/6.0 was probably the pinnacle for me OS/2: Watcom VX-REXX - extremely powerful and productive Windows: Delphi before .NET

There is also Open Watcom for FreeDOS.

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

#482
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…

You can still run Visual Basic 6 in Windows 11 and compile programs like in '99. Windows is incredibly backwards-compatible.

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

#484
post #377

Earlier quoted context omitted.

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.

Thanks for the bug report. Fixed. The next release will come out in about two weeks.

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

#485

Earlier quoted context omitted.

In the late 90s I was required to slowly replace dumb terminals with PCs. One of the older ladies taking phone orders was most put out by this, understandably. She was lightning fast on that terminal. She'd never used a PC (I hit on the idea of using solitaire to learn to use a mouse, which worked amazingly well), and was never able to get to the same speed with one as she'd done on her dumb terminal. It's hard to be…

An inventory management app was one of my first paid software engineering projects. Sometime in early 00s I had to rewrite it for Windows because the ancient DOS codebase had a bunch of issues running on then-modern Windows versions. I sat down with the users and watched how they were using the DOS version, including the common patterns of keyboard navigation, and then meticulously recreated them in the WinForms vers…

The sit down with users part seemed to be the most crucial one. Sadly nowadays developers of such software perhaps are not even in the same continent, and zoom talk can’t do this easily.

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

#486
post #425

Earlier quoted context omitted.

An inventory management app was one of my first paid software engineering projects. Sometime in early 00s I had to rewrite it for Windows because the ancient DOS codebase had a bunch of issues running on then-modern Windows versions. I sat down with the users and watched how they were using the DOS version, including the common patterns of keyboard navigation, and then meticulously recreated them in the WinForms vers…

The world needs more of this. It is nowadays rare for programmers to sit down with users and observe what they are doing. Instead we have UX designers designing the experience and programmers implementing that.

It is so frustrating that I’m not good enough to create software for myself. Maybe I should just buckle up and start working on that.

I use an iPhone and found a lot of usability issues. Some apps such as Stock are perhaps not too difficult to recreate in Obj-C. I’m kinda old timer so prefer Obj-C even that I don’t know anything about it.

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

#487

> 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 application was pure hell. Typically, you needed to add a lot of buffer space for English strings to ensure that German strings, for example, would not break the layout too much. UI frameworks that solve these problems with a proper layout management system are obviously more complicated, but they address issues that VB6 never touched.

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

#488

Earlier quoted context omitted.

It's mind-blowing because it makes git actually usable.

Maybe it's Stockholm syndrome for me, but I never really understood what was so unusable about the vanilla command line git interface. If you want to do some really advanced stuff, sure it's a little arcane, but the vast majority of stuff that people use in git is easy enough. Branching and committing and merging never seemed that hard to me.

imo git does a terrible job of showing its state so when anything more complicated than committing changes you really have to have thing internalized.

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

#489

> 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

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?

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

#490

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

This really shows the value of saying “no” to use-cases you consider peripheral.

If your customers live in one country, and you don’t care about cloud scalability, things can be much simpler.

Of course, some applications really do need all the complexity.

Post reply on HN