Question C, C++ or Assembly ?

[hotaru.hino]

But for non-performance sensitive GUI apps? C# as a language is well designed, simple to use, and free of many of the pitfalls of C/C++. Mono on Linux isn't bad so far as portability goes, but portability is a concern if you want to live on multiple platforms. But the framework does remove a lot of the low-level implementation you need to do to implement similar features in C/C++, which makes C# a heck of a lot quicker to get something up an running, and (assuming the framework or reimplementation is supported on your platform) does ensure portability with minimal effort.

I'm presuming your experience using C# is with a development suite like Visual Studio or Unity. Because a GUI doesn't really matter here with regards to language choices. You can build a GUI based app using Python and Tcl/Tk or C++ with Qt. And I know Qt comes with a visual editor so you can design the GUI beforehand. Even HTML/CSS/JS using jQuery is an option (plus it's very portable). But even then, for more advanced GUI doohickies, you'll need to programmatically tweak them at a point where they're not even visible in the visual editor from the start.

Also what low-level stuff? The only thing I can think of that anyone really needs to touch at that level between C# and C/C++ is memory management. While C likely still has issues requiring manual memory management (at least, using the stdlib), C++ has largely allowed programmers to get away from that. And if you're not using the tools C++ has (e.g., unique_ptr and shared_ptr) and the techniques you should be using (such as RAII), then you're doing it wrong.

 

[gamerk316]

I'm presuming your experience using C# is with a development suite like Visual Studio or Unity. Because a GUI doesn't really matter here with regards to language choices. You can build a GUI based app using Python and Tcl/Tk or C++ with Qt. And I know Qt comes with a visual editor so you can design the GUI beforehand. Even HTML/CSS/JS using jQuery is an option (plus it's very portable). But even then, for more advanced GUI doohickies, you'll need to programmatically tweak them at a point where they're not even visible in the visual editor from the start.

All those are well and good, assuming you don't have any licensing/redistribution/security concerns to consider. If you do, then using third-party (and worse: Open Source) third-party libraries are a major headache. As a result: We still use MFC.

You see why I consider Windows Forms a massive upgrade?

Also what low-level stuff? The only thing I can think of that anyone really needs to touch at that level between C# and C/C++ is memory management. While C likely still has issues requiring manual memory management (at least, using the stdlib), C++ has largely allowed programmers to get away from that. And if you're not using the tools C++ has (e.g., unique_ptr and shared_ptr) and the techniques you should be using (such as RAII), then you're doing it wrong.

Direct hardware addressing.

I live in a work where not only do we still talk directly through HW (usually using drivers we create ourselves), but the use of the heap is still frowned upon for "stability" reasons. [Serious talk here: I recently had a major fight to add the use of a single dynamically sized std::vector rather then pre-allocate a few MB of space at compile time. And I've worked on more then a handful of projects where the concept of a malloc simply does not exist.]

 

[hotaru.hino]

All those are well and good, assuming you don't have any licensing/redistribution/security concerns to consider. If you do, then using third-party (and worse: Open Source) third-party libraries are a major headache. As a result: We still use MFC.

You see why I consider Windows Forms a massive upgrade?

Do you work for Microsoft? Because unless you're rolling out your own thing, Microsoft is technically third party software where all of the licensing, redistribution, and security headaches also apply. And even if you're working for Microsoft, the latter two still apply.

The only FOSS license you have to worry about are copyleft ones, most predominantly GPL. But if you're using something that's licensed under BSD or MIT, then the most you have to do is retain the copyright and license somewhere.

Direct hardware addressing.

Directly accessing hardware depends on where you are in the software stack. If you're above the kernel level space, that's not a thing. And I would imagine even within the kernel level space, unless you're in the foundation levels of the stack, I wouldn't really call that directly addressing the hardware. Then again, unless the thing is memory mapped, I can't consider that directly addressing the hardware too since the other end abstracted itself through a communication protocol.

C just gets you a less abstracted programming language, but that doesn't make mean it's low level on the software stack.

I live in a work where not only do we still talk directly through HW (usually using drivers we create ourselves), but the use of the heap is still frowned upon for "stability" reasons. [Serious talk here: I recently had a major fight to add the use of a single dynamically sized std::vector rather then pre-allocate a few MB of space at compile time. And I've worked on more then a handful of projects where the concept of a malloc simply does not exist.]

Dynamic memory allocation is not deterministic, and less determinism generally means less stability and/or less reliability. System software is supposed to provide the foundations for which other applications can run on top of. If the software is unpredictable, how do you instill confidence that the foundation is stable? In addition, casually just using malloc is asking for trouble.

In my time as a software developer, I'd say a vast majority of the stuff I worked on had no dynamic memory allocation. The rest that did have it was either done internally within a library or the previous developer had no idea that you don't need to invoke "new" on every object if you're doing class composition. And we could get away with that because most things about the software were clearly defined, including the limitations.