>> for commercial products it is recommended to build software in the native language of the OS

I'm not sure I agree with this, it may have been true before VB on windows. People like Dropbox would also disagree, they use(d) python for their UI code on the desktop, I believe.

> Something like .NET is available but this is supported by the creators of Windows.

and .NET isn't?

Within the context of this discussion ... I was meaning that if you don't use C/C++ you could use .NET which "is" supported. So, with Windows you don't have to use the native language since C# is supported by the creators.

I keep hearing how .NET and C# are supposed to be pretty great these days. C# often gets credit for popularizing async/await, although I don't actually know if that's true.

Based on that, and the point you made, I'd definitely go the .NET/C# route if I ever ended up in the unfortunate position of having to develop software for Windows. Barring of course some reason that it had to be written in Go or something else.

Why 'unfortunate'? What is 'unfortunate' is developers having prejudice against any OS / IDE / language / etc; it restricts your creation of solutions for the problems that need to be solved. Keeping up with developments across all platforms - like the fact these days you can use C# for non-Windows targets- helps us be well-rounded and capable developers.

It's only prejudice if it's not based on direct experience. Many of us would rather avoid going back to Windows at all.

After several years using GNU/Linux I have happily returned.

Windows and Mac OS X are the only sane alternatives for developers that care about desktop applications and developer friendly toolchains. Same applies to iOS, Android and WP.

The other alternatives feel like only the CLI and daemons matter, stuck in a PDP-11 view of the world.

Then again, NeXT was the only UNIX based OS with an alternative culture regarding developers tools and UX.

KDE is the only environment that can match in terms of tooling and UX, yet it is lacking some serious love nowadays.

I want my developer and user experience to be a Xerox Star and not a PDP-11.

> KDE is the only environment that can match in terms of tooling and UX, yet it is lacking some serious love nowadays.

KDE? Seriously? It's one of the worst DEs on linux. Any DE which isn't based on gnome is just cheap nowadays.

>Seriously? It's one of the worst DEs on linux. Any DE which isn't based on gnome is just cheap nowadays.

I'll take your hot opinion and replace it with mine: Gnome (3) is hands down the worst DE in the entire Linux ecosystem and is actively harming all others by merely existing due to the mentality driving its development: "fuck everyone that's not us, we set the standards and you will like them".

Currently KDE is the most polished and feature complete of the "batteries included" DEs. And even then as a developer I prefer a bare-bones tiling set-up, picking and choosing what I want and having an experience customized to my preferred workflow.

So which other DE on GNU/Linux does provide the same tooling and platform abstractions as KDevelop/Qt Creator do?

GNOME has a very nice HIG from UX point of view, but it is stuck in C + POSIX as technology stack in what concerns developer experience. Vala is still not there and I don't believe in JavaScript for native UIs.

> So which other DE on GNU/Linux does provide the same tooling and platform abstractions as KDevelop/Qt Creator do?

Same or similar? It doesn't matter what they provide because I'd go with ScalaFX(http://www.scalafx.org/) + IntelliJ or Vala|Genie + Vala IDE. Mono is also an option if you're into it.

> but it is stuck in C + POSIX as technology stack in what concerns developer experience.

Yes, GTK isn't the newest but it isn't hard at all to develop apps with Vala/Genie(https://wiki.gnome.org/Projects/Vala/GTKSample , https://wiki.gnome.org/Projects/Genie/GtkGuiTutorial ?)

> Vala is still not there and I don't believe in JavaScript for native UIs.

What do you mean? Vala is almost the defacto standard language for ubuntu/gnome apps.

ScalaFX(http://www.scalafx.org/) + IntelliJ and Mono are not exposing any GNU/Linux specific feature.

I can use the same toolchain in many other operating systems.

The last time I bothered to check GNOME, there was some ongoing discussion of JavaScript becoming the official language to pair with C.

Just checked Genie and Vala IDE web sites, they still need to do catch up with what Borland was doing in the 90's, let alone modern IDEs.

> ScalaFX(http://www.scalafx.org/) + IntelliJ and Mono are not exposing any GNU/Linux specific feature.

Why would you need specific features? You wanted to develop desktop apps, not gnome plugins, right?

> Just checked Genie and Vala IDE web sites, they still need to do catch up with what Borland was doing in the 90's, let alone modern IDEs.

If you want RAD there's Glade(https://glade.gnome.org/) + GtkBuilder.

> You wanted to develop desktop apps, not gnome plugins, right?

Desktop apps that expose the features that make the platform unique.

> If you want RAD there's Glade(https://glade.gnome.org/) + GtkBuilder.

Not even close to Delphi and C++ Builder and we are talking about 90's here.

If I upgame to Blend + VS, XCode + Playgrounds, Android Studio then there is a lot of catch up to do.

@woflgke you're going off on a tangent: it's about the maturity of tools and not about "exposing" system features. That's unrelated to desktop apps.

No @woflgke is quite right.

Software development stack for desktop apps are all about exposing the features that make a platform desired to be used.

pjmlp asked:

> So which other DE on GNU/Linux does provide the same tooling and platform abstractions as KDevelop/Qt Creator do?

You answered:

> Why would you need specific features? You wanted to develop desktop apps, not gnome plugins, right?

Clearly KDevelop and At Creator expose GNU/Linux specific feature.

Exactly; hence if you were to say it'd be unfortunate for you to have to go back to Linux, I wouldn't say you were prejudiced either, since you know from personal experience.

I still use it of course (it is my travel netbook OS), just not with the same enthusiasm of former times.

What would be a good use case/type of project where you'd use C# to target non-Windows? Over, say, any of the JVM languages?

Cross-plateform mobile apps with Xamarin.

I don't see why someone wouldn't use C#/.Net to build a native Windows app. It's open source, and supported by Microsoft, the makers of Windows as the primary Windows app environment.

One reason would be if you're trying to build a node based app which you would like to use across other platforms.

The problem isn't C#/.NET but what GUI toolkit do you use? Winforms, WPF, UWP and others are either in maintenance mode or incomplete. The only complete toolkit is Win32 which brings you back to C/C++.

All new APIs since Windows 8 are now COM based, yeah it is still Win32, but I guess it is just following their original idea for .NET (COM+ Runtime and not the CLR).

In some future version of Windows, when UWP with its COM foundation becomes prevalent, they can ripoff all the Win32 APIs that aren't required to support WinRT.

Just like Apple has done with Carbon, Quicktime and many others.

We will see how UWP works out. I wouldn't be too surprised if they changed their strategy in the next few years to come out with something different. That seems to be the Microsoft tradition. As soon as something starts working it gets replaced by something else.

The only constants are COM and Win32.

Sure, however I am with high hopes with WinRT, as it is what .NET should have originally been designed instead of the CLR detour.

If you look at what Delphi, Modula-3, Ada, Component Pascal, Oberon variants, Eiffel were already offering before Java took off.

> As soon as something starts working it gets replaced by something else.

Just like everyone else. I can hardly think of any platform owner that has kept their APIs stable.

Not that you are not right to complain, I just get the impression many tend to forget about the other vendors similar practices.

I find this coming back from CLR to COM sad because the CLR support another very good language (F#) which isn't in WinRT and also because the CLR is going really multiplatform with .net core. Also too bad Microsoft didn't pursed a multiplatform framework like Silverlight and go with a solution that didn't even run on its own OSes (previous version of Windows).

Isn't Win32 basically in the same maintenance mode as WinForms? WinForms is mostly just a thin wrapper around Win32 anyway.

Pretty much everything new first gets exposed through Win32 or some COM interface like DirectX.

WTL is also great if you want or need something that doesn't use .NET. Building GUI apps doesn't suck with WTL. What I would like to see is an example of an app where I can build an app using both WTL/C++ and have Go code with channel support...