I love fast software. That is, software speedy both in function and interface. Software with minimal to no lag between wanting to activate or manipulate something and the thing happening. Lightness.
Software that’s speedy usually means it’s focused. Like a good tool, it often means that it’s simple, but that’s not necessarily true. Speed in software is probably the most valuable, least valued asset. To me, speedy software is the difference between an application smoothly integrating into your life, and one called upon with great reluctance. Fastness in software is like great margins in a book — makes you smile without necessarily knowing why.
Nothing to add.
Even better still, applications that are not platform specific.
What is the point of fast software, if you have to go out and buy a different computer before you can use it!
Some of the assessments are a bit myopic, for example Photoshop in practice is much faster now than before, because new tools supplant many multi-step processes, so a single legacy step might be slower if you aren’t leveraging the new features and tools. To me this is often the case when I get the common complaint that the old way use to be better, it’s primarily because people don’t deal well with change and innovation.
Platform-agnostic apps are less useful to end-users nowadays. Most computing devices run at least 1 of the 4 widely supported OSes (Windows, macOS, iOS, Android) and most applications have platform-specific ports, or are web-based. The platform-specific apps almost always perform better than the web-based versions, due to translation overheads of Javascript and HTML, which plague almost all cross platform translation layers, such as Java, Flash, and of course, web apps.
Don’t get me wrong, cross-platform apps have their place. Web apps are cheap and easy to build, and are generally supported on anything with a web browser. Java is still used heavily in embedded applications, where the hardware the apps are running on is often very different between end products. Flash, which is very much depreciated now, had its heyday as the defacto cross-platform interactive layer for the web.
The other disadvantage with cross-platform translation layers, is you need the translation software to be ported to your platform. Many smaller alternative OSes, such as Haiku, AmigaOS etc suffer from a lack of software in general, including modern browsers. Without the base translation layer, your “cross platform” apps are useless.
The fact is, the performance bottlenecks, and security issues inherent with cross-platform application layers means that they have been phased out over the last few years, in favour of either web apps, which are much more cross-platform and reasonably easy to create. Most OSes have at least some form of relatively modern browser, which can run much of the modern web, or they have workarounds and special applications for handling specific tasks (Youtube, social media). With the rise of the modern web, and the demise of other cross-platform translation layers, the killer app of the modern world is the web-browser. As long as your OS has a modern web browser, you have a multitude os cross-platform applications available to you, This idea was extended by Google with ChromeOS, which essentially booted straight to a browser, and was very successful given it’s release date, where many other projects were not.
Yes, cross platform apps are dead. But long live cross platform apps.
More important is open data formats
What’s even better? Apps that do things I need them to do, very well, regardless of speed. Example, Adobe Lightroom, damn do i wish it was like 10x faster, but there’s nothing that tops it for photo editing functionality.
IMHE the first bottle neck is the idiot in front of the screen! That said, If my train of thought is forced to stutter because the application doesn’t keep up in the way one intuitively knows it should then I am apoplectic.
Cutting to the chase: we have had a pattern of GUI applications being developed in languages with a single threaded mindset by developers with a single threaded mindset. For some while my note to myself about GUI code has been …. remember to multi thread from the get go; and perhaps even select a language that runs with that approach. One candidate is Elixir with it’s wxWidget libraries; it is also cross platform …. and from where I am sitting a real learning curve.
ameasures,
Nothing “humble” about it.
GUIs rarely need threads, if at all. The problem is code doing work inside the GUI instead of passing the work off to somecode else that is multitasking, and allowing the user to do other things while waiting for the result. That doesn’t need threads – just a non-blocking event queue of sorts.
kwan_e,
Indeed. I prefer event queues for I/O handling. A single threaded event queue is fine for interactive use. The key is to never have blocking code in the event handler. Anything that cannot be handled immediately and cannot be scheduled to send an event may need to allocate a new thread, but otherwise there isn’t much benefit to using MT everywhere. It can work and some developers do it that way, but there’s generally more overhead, the stacks really add up, and MT brings about race conditions that are notoriously difficult to debug. Software that needs to be scalable should use the event queue model instead.