LeanQt

For all of my projects it is good enough. C++11 onwards has a few advantages, but I don't need them. Moving ownership between containers to avoid allocations was possible with the standard library even before C++11, and Qt offered "implicit sharing" which has a similar effect without syntax changes and incompatibilities. Even with my C++11 projects (e.g. https://github.com/rochus-keller/eigen/) I had to take care still in 2024 which feature not to use on MSVC because it didn't work or behaved differently. I never have any ownership issues and I implement large compiler projects with different AST and IR layers. All my projects still compile with https://github.com/rochus-keller/leanqt/ on all platforms. I would never trade a tiny language advantage with a whole world of dependability issues. One day I will revive and refactor GCC 4.7 to g

This is an impressive achievement, given there’s a whole language plus IDE. Kudos to the author. I couldn’t see any indication of what the author plans to use it for - I hope he can share more below? I’m intrigued by the LeanQt library as well that the IDE uses (https://github.com/rochus-keller/LeanQt) too.

It's a rather traditional type system; the specification is here: http://software.rochus-keller.ch/busy_spec.html. The main advantage are the combination of modularization, types and formal declarations, so that if you make a change in a large build (such as my https://github.com/rochus-keller/LeanQt or https://github.com/rochus-keller/LeanCreator systems) incompatibilites are immediately found by the compiler. Without these features you can never be sure whether all effects were checked.

> Then do you (developers on HN) stay away from CLAs? Depends on the CLA, but generally I do stay away. E.g. I never checked in anything to the official Qt repository because I don't agree the the CLA by QTC. Instead I finally made my own fork and call it LeanQt and LeanCreator (see https://github.com/rochus-keller/leanqt/ and https://github.com/rochus-keller/leancreator/). The "weird licence which is basically a modified version of the MIT licence but with a clause that prevents competitive usage" is likely not even recognized as a true "open source" license. > would it be possible to relicense a fork of Polaris to MIT (removing the Shopify clause?) Likely not, because only the IP owner can determine who can do what with their IP under what license. If you use the software of an IP owner under a specific licence, you usually don't have t

> As a former Smalltalk developer, what do you think about it would actually slow you down (despite popular claims re productivity in Smalltalk)? I was a Smalltalk developer in the early nineties as well, but then switched to statically typed languages and the source file concept for many reasons (performance, testing effort, integratability, etc.). For the present case performance is critical (parsing and cross-referencing of large code base) and also the specific required presentation/interaction features which come with Qt out of the box; and I already have a large toolbox based on C++ which I was able to reuse. > And is it one goal of yours, then, to mold Oberon+ so that it would eventually be at parity, productivity-wise, with C++? It would take more than a lifetime to achieve that goal given that my https://github.com/rochus-keller/

See https://github.com/rochus-keller/LeanQt. Neither depends on Qmake nor Qt Creator.

I made myself independent of the "Adventures in Qt Land" by switching to https://github.com/rochus-keller/LeanQt.

https://github.com/rochus-keller/LeanQt A minimum and easy to build fork of QT

> Qt for MCU [..] seems like a big advantage over Qt LGPL-3.0. I have my doubts. MCUs powerful enough to run Qt GUIs smoothly are more expensive than, say, an i.MX6ULL with a Cortex-A7 application processor and Linux. It’s a lot easier to find developers for an embedded Linux system ... This is a very convincing argument. A Linux embedded system is also more flexible and the degree of code reusability is usually higher; it's also easier to develop and debug, and one can profit of a huge ecosystem (e.g. OTA update and the like). > Shall we use Qt LGPL-3.0 or Qt Commercial? LeanQt (https://github.com/rochus-keller/leanqt/) is still available under LGPL v2.1. I will not switch to Qt 6 with my projects.