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?)

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. ;-)

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.

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.

Could not imagine using regular cd for navigating file systems anymore.

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.

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).

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).

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...)

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.

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?

Fully agreed, that LLMs/assisted coding is nice for these kind of contained tasks.

In my personal experience, LLMs help with:

- answering questions

- generating simple code/scaffolding in a vacuum

At the same time I don't have much success using LLMs to generate code in a simple CRUD application (around 20K LOC).

What I am looking for, is a video showing w/o time lapses/breaks, how an experienced prompt engineer uses an LLM to add a non trivial feature to a code base with at least 20K LOC.

What I am looking for:

- It must be used to add 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

- Any programming language/framework is fair game

- Any LLM is fair game

- The code base can be a bigger open source project (since I assume all LLMs were trained on open source projects, this should make it easier for LLMs to perform)

Comments URL: https://news.ycombinator.com/item?id=43786270

Points: 2

# Comments: 0

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

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.

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?

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?