Exactly one of the reasons I never went down with all the TDD dogma of only writing code to fix broken tests.

There is a reason conference talks are always about plain algorithms and data structures.

The biggest flaw I've seen with TDD is the fact that correctness does not compose upward. Every time two units come into contact, you've got an entirely new kind of unit. The tests from constituents do not cover emergent properties of the new things. You will repeat this same exercise the entire way up to the top, and the moment you come into contact with the customer (they want to change everything), the house of cards comes crumbling down and you have to start your agonizingly-slow process all over from the bottom again.

The only thing that the business seems to care about is top-down UI testing. This is also convenient because you can leave it until the very end after the customer has already seen several prototypes.

I do think TDD makes sense in isolated scopes (prove this specific custom parser works at the edges), but as the general policy for the entire product it's definitely not a viable practice. Much of the time if comes off as an ego trip to see just how cleverly we can mock something so that we can say we technically tested it.

Exactly, the whole system thinking and large scale architecture also fails apart, when writing everything from little working tests.

Patents, and tooling portfolio.

Only superficially, given what CUDA provides and what ROCm supports.

The competition to CUDA and proprietary 3D APIs always overlooks developer productivity.

For some strange reason there is this expectation, maybe due to UNIX background of those folks, that portable APIs have to exist without good IDE tooling, no graphical debuggers, no high level programming models, no libraries ecosystem.

Then for some "strange" reason, GPU developers mostly pick proprietary and the cycle repeats itself.

But the Modular stack is focused on developer productivity. It is still early but there has been substantial work on all these

I am yet to see the same Windows love as CUDA.

Same to IDE integration and graphical debugging experience for GPU code.

Until now, it was been the usual UNIX cli, and text mode lldb like debugging for CPU side.

At least it what I have been made aware of.

Julia and the Python JITs from GPU vendors will.

Mojo already lost the moment AMD, NVIDIA and Intel decided to fully support Python and Julia.

Additionally all of the parallel programming improvements in ISO C++ are coming from them as well, Modular did not have much moat when being a follower and not a driver.

Lisp, see Connection Machine and Star Lisp.

Several decades of their time.

Best of all, it is actually compiled without JIT drama.

This is the reasoning behind the guys that have created a whole new Common Lisp frontend to LLVM for biochemistry research at MIT.

He already did that, Swift for Tensorflow, the project hardly survived one year after the public announcement.

> Swift for Tensorflow, the project hardly survived one year after the public announcement.

This was doom to fail from the beginning.

Swift will always have the image of an Apple product binded and controlled by the Apple ecosystem. This is very unlikely to change.

Nobody sane of mind would bind there entire technology stack on something half proprietary with a support was from the beginning secondary outside of Apple platforms.

I think that was the motivation to make Mojo a superset of python.

Yes, but apparently even that ended up being a pivot, with just enough Python, and now lets see what Qualcom makes out of it.

Nowadays replaced with HSTRING.

Webviews have always worked since MSHTML, the issue is being comfy helping Google's market share instead of writing portable Web code.

That's a whole can of worms, Micro$lop entangling its own browser with its OS, getting a (gentle) slap on the hand for its abuse of monopoly position for it, having to remove it claiming it's "impossible", etc.

Yeah, it is mostly laziness and cost cutting at the expense of users.

Nowadays there isn't even an excuse anymore, just vibe code it away in native frameworks.

Which native framework?

Even in a "post-vibe code" era I wouldn't want to create multiple versions of the same app, and none of the "platform-native" GUI toolkits run on everything.

SwiftUI is apple-only, gtk has pretty bad compatibility on non-linux, qt is decent but requires C++ or python, and even so still not much for mobile. Don't even get started on "Windows frameworks", because as I write this sentence they may have left a new one in the ditch.

Flutter may be the closest, but why didn't they go with e.g. Java instead of a new language?

So yeah, if you want a truly universal UI then web is your best bet.

> if you want a truly universal UI

Right. If you want your app to look the same, custom way, ditching what the OS has to offer.

Some developers still believe an operating system has useful UI components and patterns worth adopting. From this thread it's clear that there's plenty who don't. Personally I view that as a regression.

Well, maybe Java's AWT has been correct all this time.

Of course there is value in having "OS-native" buttons, transitions, windows etc. And many parts of GUIs are basically standardized. The problem is all the parts that are not, and have to look the same everywhere.

The OS-component-oriented approach was defensible in the days of desktop only (though personally I think it was a mistake even then), but it's not sustainable now. People want your app on their PC to look and behave like your app on their phone (whichever combination of PC and phone they happen to have), and that's a lot more important to them than having it look and behave like other apps on their PC.

> People want your app on their PC to look and behave like your app on their phone (whichever combination of PC and phone they happen to have), and that's a lot more important to them than having it look and behave like other apps on their PC.

They don't. No one generates GBs of simulation data and create plots on their phones, and this is what "app" I am working on is doing.

Many times I've thought "what kind of idiot would try to use our app on a phone?" only to find one of our execs was doing exactly that, but YMMV I guess.

Probably many Electron users also view that as a regression, but a tradeoff worth making.

How about something like this https://github.com/gen2brain/iup-go? Still not released, but I plan to clean all todos in the next few weeks.

one missing from that list: Slint, which i work on. runs on Linux, Windows, macOS and embedded, with app logic in Rust, C++, Python or JS.

You can use JS but it doesn't ship a browser engine, it renders with its own lightweight toolkit.

The one which OS has to offer.

Web is bad everywhere outside of the browser.

I want to have both linux and mac users (but maybe also android, ios, windows).

You clearly see the issue.

When I started programming, one had to repeat in Assembly the same application for each computer brand.

We are not that bad nowadays, it is a skill issue.

There are plenty of ways to have portable applications with native UIs without shipping a browser.

Somehow we managed to do it for decades and without AI writing the code for us.

If you want to ship a browser, I already have one, thus standard Web, with a daemon if it really must be.

I agree on the standard web point, but you still failed to reply to what is a native UI for every OS.

Portable frameworks exist, but they are at most native to a single platform.

> You clearly see the issue

I don’t. VLC is available everywhere, so your requirement is clearly not a problem. Jetbrains is available on all major desktop OS.

Well, getting a hardware-accelerated blank buffer onto a screen to render video content is hardly the epitome of graphical user interfaces. VLC has very few and basic UI elements.

Jetbrains is a better example, using Java with Swing which is not a common choice. As seen from my other comment, I do think this is a good direction, but it ain't any more native than Flutter or for what it's worth an Electron app, none of these are "what the OS provide". FYI Jetbrains has to do quite a few platform-specific tweaks to make them better citizens on each platform.

Portable applications is not a recent need. The only requirement is to have a standardize interface and an implementation for each of the platform. Where you put that interface is an engineering skill.

VLC went with QT (which has done all the hard work) for the UI, and their own libraries for the media playing part. Other software like Emacs and sublime has implemented their own UI libraries. Some just ship libraries and others build UI for them.

The issue with Electron is that it brings a whole jungle and a gorilla holding the single banana that the devs actually need. And the dev flung the whole thing at the users. It's like establishing an iron mine, a steel factory and then pollutes the whole region when building a quick stone bridge would do. Because the only thing you know are suspension bridges.

VLC is not the example you're looking for. Written in Qt for desktop and their own libVLC wrapper for mobile. Yes, in the case of VLC, parent comment is right: you clearly see the issue. And a media player is a relatively uncomplicated piece of software, UI wise.

I never thought I'd defend Electron, but I'd rather use the bloated web UI than a vibe coded Qt/GTK version I'm positive will not have seen any human QA.

But GIMP! /s

When I can modify my desktop/theme (KDE) with css I will happily start doing it since that sounds easy.

Good news!

https://9to5linux.com/kdes-new-css-based-style-engine-union-...

Styling every application independently because it’s all individual Electron UI without a shared toolkit is much better indeed…

I have better things to do than spend my time adopting UI for various different systems. If Electron gives me the option to easily create a UI that looks the same everywhere, then I'll pick Electron over anything else any day.