Hacker News Reader

That's not a problem of the craft however, it's a problem of the culture.

We are perfectly capable of writing native GUIs, and we have powerful tools for it as well. QTDesigner comes to mind as a well known example.

The problem is, about 12 years ago, application design went through a gameification and "toy-i-fication" phase, from which it has yet to recover, because suddenly, everything had to look like it was designed for tablets or gaming consoles. Then the "javascript for everythiiiing!" happened, and suddenly the tools and workflows behind all the bloated, inefficient, low-information-density apps were swept into the desktop world.

But, since the modern definition of an "App" is basically everything that is displayed on a phone ever, and devices got so powerful that no matter how badly devs f* it up it still kinda-ish works (if we ignore the battery screaming for dear life), and this situation has generally been accepted.

The problem is when this culture extends a couple of generations the craft gets lost.

Not really, because there is always a high demand for good software. Just because cookware nowadays is usually made from cheap, industrially pressed sheet metal, doesn't mean high-quality copper and cast-iron cookware is no longer made.

It is a culture problem, but it goes back before phones and Javascript.

Even before that, application design was usually terrible. Apps were almost universally ugly. Developers just aren't very good at it; it's not in their skill sets. They're good at making apps fast and small, but not at making them usable.

Rare companies would hire separate designers, and the apps could be functional and attractive, but they were the exception. It was a lot of money for something generally considered ancillary.

Browser-based apps get to leverage the work done by browser makers, who put in the effort to make toolkits that looked nice by default. They're not small or fast -- though Moore's Law has made them usable anyway. They also favor the things that designers like -- including not overwhelming the user with dense information. You can still use them badly, but by default any programmer can make an app that isn't awful.

There never was a golden age when developers made good, small, fast apps. It was usually a "pick two" situation, except by spending a lot of money. I'm just as happy to let my battery scream and not cringe at every single app that comes up, and so cheaply that they can give it away or cost dollars rather than tens or hundreds. Others disagree, of course, but I think the market tends to show a heavy thumb on one side of that scale.

I disagree. Honestly since UI have become the primary domain of designers and "UX" experts they have regressed massively. 15 years ago you opened an application. The feel was consistent. I had a bar at the top which showed me the option in an straightforward manner which allowed to quickly explore and click through to relatively specialized things. Now, every app has it's own UI. And even worse everything is as hidden as possible in the name of being "clean".

>They're good at making apps fast and small, but not at making them usable.

I don't know which apps you are talking about, but I use apps built and designed by developers every day, and they all work great.

My problems start when Apps are NOT designed by developers, but rather people who have seen 100 videos about color theory, and know all the latest fonts their social media du jour is excited about, but very little about hardware, programming, and the difference between localhost and accessing a server over cheap WiFi from somewhere else on the planet.

Because these are the "apps" which do something ridiculously simple, but somehow manage to eat up 2-3GiB of RAM and let the laptops fans spin out of control.

>They're not small or fast -- though Moore's Law has made them usable anyway.

Moores Law is over however, and there is no justification for an app that, say, plays locally stored mp3s to require 2GiB of RAM and 10% CPU. If an application thinks this is justified, it will get to know my good friend `rm -rf`, beacause I have vlc running in ncurses mode right now, playing my entire playlist, and its eating less memory than the terminal emulator it's running in ;-)

The answer to bad software, and overloaded/overused/oversold frameworks is not "built more powerful computers" but "make better software".

>There never was a golden age when developers made good, small, fast apps.

Good != Beautifully designed.

Good means small, fast, portable, reliable, easy to install, easy to learn, easy to remove, does its job.

I wonder where the notion that productivity software should be “attractive” came from. Were whole businesses not built on VisiCalc?

The registers at B&H photo in NYC appear to be some DOS terminal system, but the employees know the keyboard shortcuts by muscle memory and the interface’s reaction time is instantaneous. If that’s not good software I don’t know what is.

I wonder where the notion that productivity software should be “attractive” came from.

From the people who make choices about where to put their money. You can get away with ugly software -- especially if you had something that worked 20 years ago and is still sufficient, and there is no alternative. But if users have the choice of something attractive, they'll pick it.

That depends entirely on the use case and the user.

I have the choice of many many many text editors and IDEs to manage my source code.

What do I use? vim. In a terminal(-emulator).

Why? Because I like my editor to be ready the moment my finger leaves the ENTER key, I like direct interoperability with the terminal, I like that I can hack together even the most absurd things in .vimrc, and I like that I have the same editor with the same settings on all servers I take care of, even when I connect to them via ssh.

I also use vlc for playing audio and video. Are there players that have a more edge UX? Sure. Do they come with builtin-full support for almost all formats, have a tiny memory footprint, can be used to convert stuff, don't spy on me and can be controlled via a terminal (hello ncurses mode!)? Nope.

VLC is bloated. Try mpv from https://mpv.io/

Thanks, looks like an interesting project, will definitely keep it on my radar.

However, after compiling it and measuring it on an older machine (a Lenovo T430 running Arch) against the out-of-the-box vlc install, I can see no advantage in memory footprint or cpu usage, they are about the same. (I compared mvp running in terminal against vlc running with ncurses interface module)

Since mpv doesn't offer an ncurses interface, and is still in development, I will, for now, stick with vlc.

However, the scripting options definitely seem great, as I said i will keep it on my radar.

Hm. Don't know how to respond to that. Let me explain how my usage began. Somewhen in the days of early Arch long before systemd...don't know how and why exactly I tried it. I mostly used mplayer before. Even with mplayer I've been wondering why I should use VLC over it, because anything I've thrown at mplayer just worked. While VLC had so many options for nothing I'd need. And it was bloated in direct comparison. Maybe that has changed meanwhile by change of toolkit, or whatever. IDK, not touching it. MPV feels like mplayer to me, with the difference of even less hassle for daily usage, and under active development, with the option of embedding it into several popular scripts to download/stream content from popular sites to watch it outside the browser/app or to archive it in the desired format and quality. Either from CLI or via several frontends. Which I have almost no use for. However, for my simple needs for local playing of downloaded stuff it just works for everything I throw at it, be it CLI, or click in some graphical filemanager. Instantly. Sometimes on even older systems than yours. With probably less RAM. Say 8GB, with something booted from USB, running 'live', so only 7GB, no SWAP. I wouldn't want to use VLC on that. If it's on the image, I remove it and exchange it for mpv during remastering.

Maybe you compiled yours with all the bells&whistles which aren't needed for sufficient local playback?

Furthermore I didn't cover (re-)streaming to chromecasts, TVs, or such. Don't have it, don't want it.

> While VLC had so many options for nothing I'd need.

This has next to zero impact on its performance, as the ncurses player talks exactly to the parts of libVLC it has to.

>Instantly. Sometimes on even older systems than yours. With probably less RAM. Say 8GB, with something booted from USB, running 'live', so only 7GB, no SWAP.

The system I tested this on has 4GiB of RAM. And I have used `VLC -I ncurses` from live systems-on-a-stick as well. It runs before my finger leaves the ENTER key, same as mpv.

> Maybe you compiled yours with all the bells&whistles which aren't needed for sufficient local playback?

I'd be happy to repeat the measurement with different settings.

I miss VB. it was really easy to use. There are tools out there but you have to pay every month for them.

Check Lazarus [0] for Free Pascal [1].

Another viable option would be Visual Tcl [2] for Tcl/Tk [3]. Given the event-based nature of Tcl and Tk, I find it matches well for a methodology like VB provided.

And it's far from the only one I remember (although you'll need to do some research here [4]). For example, Komodo IDE used to have a Tk GUI builder that provided for the same kind of methodology, which has been split off in [5].

Enjoy!

[0] https://www.lazarus-ide.org/

[1] https://www.freepascal.org/

[2] http://vtcl.sourceforge.net/

[3] https://www.tcl-lang.org/

[4] https://wiki.tcl-lang.org/page/GUI+Building+Tools

[5] http://spectcl.sourceforge.net/

What is preventing you to use VB.NET with WinForms? Still out there.

Yeah. I know VB gets a lot of derision in these parts, but Visual Studio community edition is free, and .NET is free. So it's totally free to write applications with.

Is it indeed annoying that every app isn't "cool" unless it attempts to reinvent the user interface.

How comes that circa 2000 VB6 was the most hated and belittled programming language out there? I was there, I remember it. Now it's suddenly part of the golden age of desktop programming? I think you should put your nostalgia glasses off.

Because the language itself was terrible. The RAD tooling/UI designer was excellent. There was a product that had those but included a better language -- Borland's Delphi, but Borland and its successors squandered its initial success and didn't invest in improving it.

VB was good at some things (e.g. UI design) and bad at others (e.g. doing complex computation).

I think that the most hated part of VB6 was more the BASIC language rather than the GUI design part... but maybe I'm wrong.

I think it had more to do with VB being so easy it attracted lots of inexperienced programmers who didn't care about performance or correctness as long as the job got done. Sort of like a pre-internet PHP ;)

I also remember DLL hell and all the issues to make safely run on every Windows installation a VB6 program and its runtime. But I agree with the other commenters that the IDE and the visual part was really nice (too nice for the average skilled developer of the time, VB6 was the NodeJS of that time)

The language was crap - the IDE/designer was excellent.

For me - the sweet-spot that I used for all of my own personal projects after outgrowing VB1-6 was... Borland Delphi.

The IDE/designer was at least as good as VB - but the Object Pascal language was so powerful. It was truely object-oriented and if one wanted, one could work at a high level of abstraction. Yet it could also natively drop-down to low-level Windows API's, and handle pointer-based work if necessary.

Unfortunately - for my professional career, Delphi never captured the large-scale Enterprise market - that went to .NET or Java and the rest is history...

(Occasionally I noodle about with FreePascal for the nostalgia factor)

It's for much the same reason that BASIC (in general) was maligned and people wax nostalgic for it today. A lot of people cut their teeth on it, may that be learning how to program or embarking upon a career in programming. In other words, they have much to be thankful for.

When the option was between VB 6 or doing COM in raw C++....

Granted we still had MFC, but then the COM lovers at Microsoft started pushing for ATL, and everything that followed from there.

On the other side we had (and still have) Delphi and C++ Builder, but Borland's management killed the indie culture around them.