501–510 of 607 posts
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…
Earlier 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?
Coincidentally, they were very accessible because they used corresponding Win32 components for all logical UI entities, despite being fixed in layout. Therefore, they worked really well with screen readers.
Sadly, this is not the case with UI frameworks, which render the screen as a Vulcan/DirectX/OpenGL canvas. By the way, for today's Electron-based apps, you can use WAI-ARIA (or similar) standards to achieve a similar level of accessibility.
> 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…
I'm going to get punished for saying this, but I don't really see the point of IDEs when you have things like vim, Makefiles and bash. It just seems like more things to go wrong. I used Eclipse while I was doing Java development for a while and it had some conveniences but for the most part I just see it as one more thing that can go wrong and get in my way. Anyway, does anyone remember Metrowerks CodeWarrior? I see…
As someone who has been doing this either professionally (since 1996) or as a hobbyist programming in assembly and a little Basic (1986-1992), I’m always amazed at the feigned Slashdot style “I haven’t owned a Tv in 40 years why do people still watch them”. Are you really saying that you don’t see any utility in modern IDEs? Even back in 1999 I thought Visual Studio was a breath of fresh air let alone R# with all of…
I've tried IDEs and didn't like them. I don't even really like having close parentheses auto-typed for me. It breaks my flow.
Earlier quoted context omitted.
Damn that actually sounds superior. How did changing the size work?
There were a bunch of predefined modes in the video BIOS, and with a little bit of assembler you'd issue an interrupt (a system call really) which would change the video mode. Then as the parent comment said, you could write to video memory directly and your writes would either be interpreted as ASCII character/attribute pairs in a text mode, or colour palette indices in a graphical mode. Most games at that time used…
https://www.atarimagazines.com/compute///issue138/124_Laptop...
It ran the DOS text screen in VGA graphics mode, with soft-loaded fonts, but this also permitted all kinds of extra modes -- iff your DOS apps supported them. Some just read the screen dimensions and worked, some didn't.
Earlier quoted context omitted.
Is this not an overstatement? How does a person understand code if they write so much of it with AI?
Because I tell AI exactly what and very often how to write the code to avoid sub-optimal solutions AI so keen to propose if not properly directed. As for autocompletion, not sure about every tool but CLion and other IDEs I have from JetBrains are genius. Yes they can autocomplete multiple lines of code with a single keystrokes and no I do not really want to write it myself as it mostly boilerplate code I've written m…
See, I don't want my code to require boilerplate in the first place.
Earlier quoted context omitted.
As someone already mentioned before, I don't think you are talking about the same terminal as others are. >> need an enormous array of hacks to emulate basic features What are those hacks. As far as I can remember, TUIs ran faster on ancient hardware then anything else on today's modern computers.
>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…
Of course it doesn't, because it isn't a graphics API. It's a styled text API.
> Modern 2D graphics are extremely capable and deliver better performance in every metric.
A big part of the complaint is https://danluu.com/keyboard-latency .
> 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…
Earlier quoted context omitted.
When people love an IDE product so much that they can't work without it, they have overspecialised to their detriment. And possibly to the detriment of the code itself. > As for terminal IDEs The GNU/Linux terminal is the killer app . Multiple terminals in a tiling window manager is peak productivity for me. (Browser in a separate virtual workspace.) And modern scaling for a big display is unbeatable for developer er…
As someone that started when only rich people could afford GUIs, I don't understand what is killer app about it. We used text terminals because that is what we could afford, and I gladly only start a terminal window when I have to.
Exactly so. I am perfectly able to work entirely in a text/CLI world, and did for years. I don't becase I don't have to. I have better, richer alternative tools available to me now.
It was very odd to join Red Hat briefly in 2014 and meet passionate Vi advocates who were born after I tried Vi and discarded it as a horrible primitive editor.
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.
There's another reason you don't mention.
Consistent UI.
TUI apps can (and in the Windows world usually do) use the same keyboard controls, derived from IBM CUA, as their GUI equivalents do.
This is why I use Tilde in the Linux shell: the same commands work in it as in Pluma or Leafpad or Mousepad or whatever: Ctrl+O opens a file, Ctrl-X/C/V to cut/copy/paste, Ctrl+N for new, etc.