Or he just prefers GTK. I sure like it better than QT.

No person who has written software with both prefers GTK :D

I can still use and develop GTK2 software in Debian out-of-the-box, but not Qt3 or even Qt4.

Yes, because GTK2 is so difficult to upgrade to new versions, whereas Qt4 to Qt5 usually only involved replacing a few identifiers (cannot speak to Qt6 since I don't do Qt anymore). That's why distros need to drag GTK2 along even though we are already at GTK4.

I work on the IUP fork, where I have and support the Qt driver, which works with both Qt5 and Qt6, and I only need a couple of checks to make it work on both. I often check if I broke the Qt5 build; nope, all good there, hard to break. For GTK3 and GTK4, those must be separate drivers; there's no way you can handle that with a couple of checks. Everything is different. That was possible to some extent and works with GTK2/GTK3 (single driver), but there are so many checks and workarounds there. Qt is so nice to work with.

> so difficult to upgrade to new versions

Perhaps, because GTK developers insist, that GTK2, GTK3, GTK4 are different toolkits.

> Qt4 to Qt5 usually only involved ...

I'd start with Qt3 to Qt4.

Yeah let's start on a specific version that they overhauled the API since computers are getting new hardware features, god forbid a different DPI. And use that as a leverage point against a library that kept their API quite stable for the last 20 years!

Especially when comparing Qt against a library who couldn't keep its shit together for 5 years and is infamous for breaking all sorts of API and removing features.

> since computers are getting new hardware features

It's not possible to move forwards fast anywhere.

> and removing features

Yeah, this is indeed very unfortunate. They claim the GTK core team is about 2 devs, so tiny that we're lucky the development goes further at all. Hard to understand considering Red Hat became part of IBM.

He seems to completely ignore Ladybird project for some reason.

Lisp was meant to be written with M-expressions instead of S-expressions anyway.

For a brief period of time over 60 years ago, yes. :)

If you want a Lisp that basically has M-expressions, try Dylan. It even started with an S-expression syntax initially and then converted to infix.

M-expressions were never implemented and never used.

Actually, variations on M-expressions have been created many times in the Lisp world. (Look what you can do with macros!) So far, none of them has caught on. The latest attempt for Scheme is SRFI-266, which creates a very nice infix expression sublanguage. If I were working on a team, I would encourage them to use this, but I don't know if it has enough traction to become widespread.

It's a common mistake to think that the syntax of Lisps are a problem. People solving the supposed problem then discover it wasn't something that needed to be solved.

Haskell's syntax comes from ISWIM, which was motivated quite a lot by m-expressions.

Except in mathematica - which isn’t formally a lisp, but practically it’s used like one a lot of the time.

I actually created one for some time ago. It's nothing special but it has Vi keybindings.

https://github.com/RauliL/levite

This is brilliant! Thank you for creating it

Unchecked exceptions will eventually lead into programs crashing because some developer forgot to catch specific type of exception somewhere.

And developers never forget to check error codes.

Looking at code, it‘s easier to spot the missing check for an error code, than a not catched exceptions.

Also error codes are part of the signature of a function, which exceptions aren‘t.

If you need to wrap each call in try/catch, it's better to use return codes in some form or rethink the approach.

may I introduce you to the nodiscard attribute[1]?

  enum (class)? [[nodiscard]] Error {
    Ok,
    NoMem,
    ...
  };

[1]: https://en.cppreference.com/w/cpp/language/attributes/nodisc...

   C attribute: nodiscard (since C23)

[1] https://en.cppreference.com/w/c/language/attributes/nodiscar...

FWIW I’ve been using warn_unused_result in both gcc and clang since about 2020.

Yep, partial remedies are available for quite some time.

That seems like a better outcome than continuing when an error happened while thinking everything succeeded?

Yes, but that's not a dichotomy. Languages like Java have function declare what exceptions they throw, and the caller must either catch it or also declare that it throws it. Gets cumbersome quickly, but I believe it's for the best to encode exceptions at the type system.

In case you want to use React to make Web sites as well.

They should make a version of that runs as an app on a phone

They have one, it's called React Native Web Native

Mozilla later added them after the concept became popular thanks to Firefox. Mozilla and Firefox browsers coexisted for quite a while and Firefox was the lite version of Mozilla that didn't include E-mail client and other such features that Mozilla did.

Xfce is way too minimal to be great. An great DE must be written mostly in JavaScript and hoard gigabytes of memory in order to render a single window.

If I understand the target of your snark, Gnome shell on my machine uses 172MB of RAM, if I sum all other gnome-related stuff (gdm-wayland-session, gjs, gnome-session-service, etc), it's 200MB.

Hardly GB. You don't have to lie to make a point.

yeah, i have a couple older machines and tried xfce and it wasn't really worth it memory wise, sure xfce is probably lighter but it's easily less than 100 meg difference

Ok, but did you also run it for a while and compare how snappy or laggy the different DEs are? Because with xfc my old T440s Thinkpad from 2013 is still perfectly fine for browsing the web, or watching movies on the HD projector, without sacrificing too many modern interface conveniences.

I can't say the same for Gnome or KDE, and that's no slight against either (I happily use the latter on my more recent work laptop).

Having said that VSCode runs perfectly fine on the T440s too, so Electron and JavaScript aren't the fundamental reason those DEs are too demanding to use.

i ran gnome on this thing: https://www.techbuy.com.au/p/505010/NOTEBOOKS_11.3SCREEN/Len... for about 6 months, other than dropping to maybe 10fps while switching to overview it was perfect

tbh i kinda miss the 6hr battery life

xfce and gnome are by far my most used desktops and i probably would put effort into using xfce more if it supported wayland etc but i guess i like to tinker with newer stuff

to me the only reason to use xfce would be if i wanted to use a lightweight desktop app on a borderline useless computer, cause once you start trying to load websites you're going to blow through so much memory that desktop environments are irrelevant

I'm writing this on my old 2014 acer aspire.

Currently gnome-shell is taking 135MB of ram, with other gdm/gnome related background services ranging in 700KB-3.2MB each to like 20MB together.

And it's as snappy as my sway config I log into depending on the needs.

I just spammed virtual desktop changes, opening Files, browsing, and it's as snappy as it is in sway.

I think gnome is getting a lot of unfair performance criticism online as it looks like something that would be slow. Maybe it was slow back in the starting gnome3 days. Maybe there are some heavy differences in how distros package it? (arch btw)

... though I will say that from my experience it's the KDE that's the slow one. I don't have it installed currently on this machine but had in the past and have it on my steam deck(which is stronger then this laptop). It feels sluggish and I have this bouncing cursor wait animation in my head right now just thinking about it.

I wish there was a Chrome extension to filter out snarky meme comments like these.

I just don’t see the point in posting something like this aside from baiting an argument. There’s nothing about JS or Electron in this article.

A good reason not to use those LLMs if they can be manipulated that easily.