Tcl/Tk is pretty good in terms of rapid development. Unfortunately it has stagnated quite a lot over the years.
Gtk on the other hand is absolutely terrible and its developers don't help by completely rewriting things every few years and breaking all existing code in the process.
C++ is hard to get safe in complex systems with hard performance requirements.
If the system is simple and you don't give a shit about performance, it's very very easy to make C++ safe. Just use shared_ptr everywhere. Or, throw everything in a vector and don't destroy it until the end of the program. Whatever, who cares.
This is quite timely as we need to write a simple UI for Windows (a few buttons, status, maybe a file menu). The main constraint is it must compile to a single binary (.exe) with no dependencies such as runtimes, DLLs, languages etc. It also needs to run on some older unsupported Windows systems, probably Windows >= 7, 32 bit.
My first thought was MFC. Basic, fast, well understood.
But then maybe WxWindows so we can cross-compile it (from Linux) and use the same UI on other platforms? It could probably be compiled statically although I've not tested it.
Or Mono, but that needs a runtime?
Edit: Some comments mention Qt which could also work although how large is the runtime? Can it be compiled statically?
Qt is compiled to a native .exe. It doesn't have a runtime. To give you a rough idea of size, I have 3 GUI application written using Qt/C++. The installers are 72 MB, 69 MB and 32 MB. The first 2 include a significant amount of documentation. I could probably get them a bit smaller if I really needed to.
For what you describe, .NET + WinForms or WPF will work just fine. These days it can built self-contained executables, although they won't be small (but then again, when many websites have multiple megabytes of JS...). Or you can target .NET 4.8 - for something this simple I doubt there'd be much difference but then you can ship an .exe that measures in kilobytes, and the runtime is included with every version of Windows going back 10 years.
> Edit: Some comments mention Qt which could also work although how large is the runtime? Can it be compiled statically?
You need a commercial license for that, but yes you could. But since applications are typically distributed with install bundles that put into application-local program files directories, it's not super-important as long as you only cherry-pick the Qt libraries you need.
This is wrong. There's a misconception that you can't statically link your app when using the open-source LGPL version of Qt. From my reading of the LGPL license this doesn't appear to be the case[1]. The LGPL allows you to statically link your app as long as you provide the object files and allow users to relink your app with a different version of Qt.
I've observed many people spreading this misinformation about only being able to dynamically link with the LGPL version of Qt. Please stop this.
Yes, that is true, but in practice nobody has ever done that. And the material complexity of offering that mode is higher than just dynamically linking the library.
Also, modern compilers make this method much harder to use. It is much harder to stably relink object files like that than to just use the normal dynamic link method.
The housing market is a bit broken: either expensive private housing or affordable publicly managed one, but very hard to get. People often cannot relocate.
Big debt.
Security, with addicted errands in some districts.
Have you been to St Etienne or Limoges ? If we talk >80k sized French cities, Paris is in the middle of the pack. Maybe on the tail end (if you don't have a lake or fast access to a sea I can windsurf on, you loose a lot of points by default), but clearly not the worse.
My team has at least one person in every continent (except Africa and the Antarctic, but we do have someone on Réunion), so meetings are and will always be video conferences.
That is both really useful and a great example of why they should have stopped writing code in C decades ago. So many kernel bugs have arisen from people adding early returns without thinking about the cleanup functions, a problem that many other language platforms handle automatically on scope exit.
You don't even need an LLM for this stuff. GCC has the __cleanup__ attribute, and kernel static analyzers like Smatch have been catching missing unlocks for a decade now. People just ignore linter warnings when submitting patches, so the language itself isn't really the issue. The LLM is basically just acting as a talking linter that can explain the error in plain English
Linux doesn't have any of: sufficient testing, sufficient static analysis, or sufficient pre-commit code review. Under those conditions, which I take as a given because it's their project and we can't just swap out the leaders with more tasteful leaders, adding this type of third-party review feedback strikes me as valuable. Perhaps, to your point, it would also be possible to simply run static analyzers on new proposed commits.
To be honest, during my ~10 years of experience, I haven't stumbled on any _project_ that has _sufficient_ amount of either testing, static analysis, and/or, where everyone who contributes gives a damn about linter/formatter warnings or errors.
Unless there is a CI that fails immediately when these checks fail, and it is not possible to bypass/override, then of course quality in the codebase improves significantly.
But that is very hard to give business results, in terms of ROI, 99.9% of the PMs will sweep these under the rug, because of unclear ROI.
Another remark I have to make is that, these things should be in a cloud/container (isolated environment) somewhere. Because I know several people who has their git commit aliased with no-precommit-hooks, because well, otherwise they complain that it is too slow. (Slowness is another issue that can be improved, but again, less visible ROI than just adding the command-line switch)
Of course I specifically avoided invoking that language's name within the context of kernel programming in fear of summoning a Linus.
And he's so right. I didn't think like that back then, but new/delete (which have to be overloaded for kernel) behind allocators behind containers, vtables, =0, uninitialized members, unhandled ctor errors, template magic, "sometimes rvo", compiler hints, "sometimes reinterpret cast", 3rd party libraries, it would have been a disaster 20 years ago. Now he's being nice to Rust partially to spite that lang I love some more.
reply