Thanks, we (Linux/BSD) users cannot bring up this topic often enough.
I totally understand, that it cannot work unless money is there, which simply is not, in the Linux desktop world. Compatibility is expensive, hard work and not much fun.
I do not think, this will ever change, in the end, the web/Electron has won, desktop operating systems are less important compared to mobile, so who should invest in a stable GUI platform for Linux?
By now, basically all applications I rely on are CLI programs (posix), web or Electron and a few simple GUI tools (PDF viewer, ...) which can easily replaced.
How is the saying: If you want a portable GUI application for Linux, target Win32 and run it via Wine.
It is so frustrating... in tech circles, it is widely known/understood for at least 2 decades, that an open file/data format is much more important than open source software.
Just make ODF the mandatory file format and be done with it. (Yes, I know, old documents and the work of transforming ... but if we do not start right now, when would be a better time?)
Thank you very much, and I also agree with your points: Electron Apps simply never feel right, even if I work within them all day (VS Code for example).
I also agree, wxWidgets is quite great, although I have to also agree with the comment above, that C++ for a GUI library is just a PITA when used from any other language. AFAIK the consumers from wxWidget (wxPython, wxErlang?, ...) are using a C wrapper around the C++ wrapper to use it.
I like, that you also added backwards compatibility and ABI stability, two very important and valid points. There is to this day the joke, that the best way to write a binary GUI app for Linux is to target the Win32 API and run it via Wine, if you care for a stable platform. ;-)
For the record: I have a terminal open at all times, my life is automated trough Bash scripts and I am a VIM / TMUX user.
With that background, most TUIs are really two steps back compared to a decent GUI. (Wild west navigation/hotekeys, broken copy and paste, lack of integration with the environment, just to name a few.)
The core of the problem is IMHO, that we really lack a decent cross platform GUI platform, which is really integrated into a programming language or part of the standard library.
Outside of Swing (which lacks access to a native browser element), we have Tk (no browser component, no drag'n'drop, at least from Tkinter), wxWidgets (seems that the community is very small and especially its bindings needed to be resurrected at least once), Qt with the ever looming possibility that it will get deshittified to make more money (... and no, KDE is not that important and I doubt the KDE community could take care of a fork long term).
Which leaves us with Electron or the other variants of 'browser component + JavaScript/CSS and callbacks to a local server, which is a really bad programming model (ignoring the memory/runtime overhead for even trivial applications).
The problem is, to build a decent cross platform gui toolkit, one needs a lot of funding and a lot of people (usability, accessibility, design, documentation, testing...). The open source community didn't manage to pull this off (GTK is by now for all practical purposes Linux only) and there is no modern contender for Qt or Swing (with their own problems).
TUIs are no solution to the core problem (and it would be absolutely possible to have a GUI toolkit with a TUI renderer for perhaps 80% of GUI needs), but I understand every developer who chooses TUIs for cross platform UIs given the alternatives.
What really annoys me about Python, is that a lot of problems that the language/infrastructure/community has can easily be tracked back to well understood problems that have been solved for decades in other communities. Some of these problems have been fixed with breaking changes, some others probably never will be fixed.
Just a list of bad/wrong decisions IMHO:
- Reference counting instead of using a real garbage collector
- The pyproject.toml format is under-specified, comes decades too late for a problem that has been solved good enough by Apache Maven more than 2 decades ago
- The absolutely weak support for functional programming, which then was patched by list comprehensions and co later
- venv and other solutions to isolate dependencies for a project
Python is successful because of the community support and a binding to almost everything, and this sadly outweighs a lot of poor choices from the language designers and the implementation. I just always feel frustrated, that during the great breakup from 2-3, they didn't try to fix more of the known issues (which again, have been solved by other communities decades before) instead of breaking the world and still managing to half ass it.
Programmed over the years in almost all mainstream programming languages at one time or another.
Saying this, Java was and is in many ways one of the best ecosystems to write software out there, if not the best (when it comes to server side software).
Maven is my favorite build systems so far: Default directory layout means everything has its place, IDEs can easily open any kind of Maven project, and being declarative, one can easily analyze pom.xml files. (I hate writing XML and I still like Maven.)
The next thing is Javas standard library. Well documented and big. Has it better and worse parts? Sure! But what people which never used a language with a good standard library don't get, is that even a bad standard library which is widely used is far better, than the npm-of-the-week clusterfuck, which means that nobody can read three lines of code and really understand, what is happening.
The IDEs are top notch, and you get even free ones (NetBeans, Eclipse) which can rival JetBrains and Visual Studio easily.
... and finally, Java is the only language that I know of, which has multiple strong companies and initiatives behind it, thanks that nobody trusts Oracle (rightfully).
Finally, Java code also got shorter, DI style is IMHO a very good default in any programming language (OOP, FP, Imperative), the community settled mostly on JUnit, so there are never discussions which of the 23 competing test frameworks to use...
In the end, there is a lot of rightful criticism of Java (historical baggage, too late when it comes to AOT, no modern GUI frameworks and a steep learning curve). Java getting new features with the new JDK releases is kind of double edged sword: Many things are good ideas, but they make the language more complicated at the same time.
The verbosity was IMHO never a big thing, because Java was always meant to be used in an IDE, for bigger projects explicit trumps implicit and finally newer revisions introduced stuff like 'var' statements etc.
It is kind of sad, that the Linux community never really jumped/accepted Java for desktop development (which might be explainable, when looking back at the lack of speed of Java in the 90s and the disastrous Solaris Java apps which were simply to slow to be usable).
Anyway, for work I am now using Golang, and it is hilarious how many lessons Golang did not learn from Java, when it comes to language design, although the tooling is top notch and the standard library has at least almost everything needed for writing backend services.
I don't see Java making a comeback, and I don't see anything modern going to replace java at the same time.
IMHO there are a lot of problems with the advice from Eskil.
His ideas about abstraction of the platform made a lot of sense in the past decades, but IMHO are not that applicable nowadays: It is well understood to separate domain logic from UI and storage, and a desktop application has a very different UI from a mobile app or even a web app.
My next critic point is, that Eskil assumes all domain knowledge is there from the beginning and will not change over time (his idea of having perfect APIs from the beginning).
No mention about error handling, reliability, response times, atomic operations etc.
To make it very clear: I believe Eskil gives his advice in good faith and his advice served him well in his own projects. In my opinion most of his advice is just not good advice in general.
(Besides having modules as black box building blocks if possible).
It is an Apple problem. Virtualization has been solved for good, even the cheapest consumer hardware has virtualization support since at least a decade by now and I sometimes run virtual machines on a 4GB netbook with an Atom processor just for fun.
I am running 100% automatically deployed/configured Debian desktops on Apple hardware for several years now, Intel and M1 CPUs. (100% reproducible is another level and another story).
Right now and for most of the past years I am running VMWare Fusion, which works with the features I need as long as you don't update macOS immediately after a new major revision was released. (Apple messing up internal APIs nearly every time.)
Sometimes in the past I also used the QEMU version provided by macPorts, and the only issue I had was with my non English keyboard, if you use a US keyboard layout you shouldn't have any issues at all.
Still, I am surprised, you seem to imply that you need to provision a new VM because of trouble with TypeScript/VSCode? Not sure what you are doing, or what plugins in VSCode you are running, but that I have to provision an entirely new VM to solve such kind of problems never happened to me and I haven't heard about that in my environment (big company, quite a lot of VSCode and TypeScript users).
Running Trixie/Gnome on a machine with 4GB (3.6GB usable) w/o any trouble.
Gnome runs better than ever, the problem is in my experience usually the web browser when it comes to RAM usage. Install ZRAM and the machine should be perfectly usable, if your usage patterns are similar to mine.
(Only thing which annoys me is that I cannot find an excuse to buy a better computer, because everything simply works on the machine...)
Tried to upgrade from Bookworm to Trixie for my desktops end of April.
Only thing that was broken was the desktop background, everything else worked great w/o any issue and even solved some trouble I had to fix by hand for Bookworm (WiFi sleep mode), so I upgraded all my physical and virtual machines.
Had no issues at all, only thing annoying compared to running stable was the amount of updated packages, which again run trough w/o any hitch and I have to take full responsibility. ;-)
Highly recommended if you want a Linux distribution for a server or a desktop which simply works and keeps working.
IMHO it is one of the big tragedies of modern IT history, that JavaScript and Python 'own' the market for scripting languages in the mainstream.
From a pure technical perspective, I would guess JRuby or one of the JavaScript implementations would have been a better choice for scripting, especially given the poor state of Jython.
From a pragmatic perspective and what your users are mostly able to figure out, Python might have been the best choice. I even saw software developers with years of experience in imperative languages struggling to understand Rubys blocks...
Out of pure interest: What was the purpose of the Java application and which aspects did you allow the users of the application to script with Jython?
Could you perhaps point me to a youtube video which demonstrates an experienced prompter sculpting code with Cursor/Clause Code?
In my search I just found trivial examples.
My critic so far:
- Examples seem always to be creating a simple application from scratch
- Examples always use super common things (like create a blog / simple website for CRUD)
What I would love to see (see elsewhere): Adding a non trivial feature to a bigger code base. Just a youtube video/demonstration. I don't care about language/framework etc. ...
Could you point me to a youtube video or a blog post which demonstrates how LLMs help writing code which outperforms a proficient human?
My only conditions:
- It must be demonstrated by adding a feature on a bigger code base (>= 20 LOC)
- The added feature cannot be a leaf feature (means it must integrate with the rest of the system at multiple points)
- The prompting has to be less effort/faster than to type the solution in the programming language
You can chose any programming language/framework that you want. I don't care if it is Java, JavaScript, Typescript, C, Python, ... hell, I am fine with any language with or w/o a framework.
I have read somewhere, that LLMs are mostly helpful to junior developers.
Is it possible the person claiming success with all these languages/tools/technologies is just on a junior level and is subjectively correct but has no point of reference how fast coding is for seniors and how quality code looks like?
I do not rule out, that I am just very bad with prompting.
It just surprises me, that you write you had massive successes with "java, js/TS, html css, go, rust, python, bitbucket pipelines/GitHub actions, cdk, docker compose, SQL, flutter/dart, swift etc.", if you include the usual libraries/frameworks and the diverse application areas for these technologies, even with LLMs support it seems to me crazy to be able to make meaningful contributions in non trivial code bases.
Concerning SQL I can report another fail with LLMs, in a trivial code base with a handful of entities the LLM cannot come up with basic window functions.
I would be very interested if you could write up a blog post or could make a youtube video demonstrating your prompting skills... Perhaps demonstrating with a bigger open source project in any of the mentioned languages how to add a non trivial feature with your prompting skills?
Yes, I have the same feeling about the wall/hype cycle. Most of my time is understanding code and formulating a plan to change code w/o breaking anything... even if LLMs would generate 100% perfect code on the first try, it would not help in a big way.
One thing I forgot to mention is asking LLMs questions from within the IDE instead of doing a web search... this works quite nice, but again, it is not a crazy productivity boost.
I totally understand, that it cannot work unless money is there, which simply is not, in the Linux desktop world. Compatibility is expensive, hard work and not much fun.
I do not think, this will ever change, in the end, the web/Electron has won, desktop operating systems are less important compared to mobile, so who should invest in a stable GUI platform for Linux?
By now, basically all applications I rely on are CLI programs (posix), web or Electron and a few simple GUI tools (PDF viewer, ...) which can easily replaced.
How is the saying: If you want a portable GUI application for Linux, target Win32 and run it via Wine.