You say that C# (I think you refer to it) it brings only restrictions to the table. In fact every compiler/platform brings restrictions. For example, there is no C++ GEM (Ruby world "libraries in a package manager) support, and .Net (Visual Studio basically) have something primitive (NuGet). Unnecessary, did you mean about RTTI (oreflection!?). Syntax is not only diferentiator as far as I know: F# is fairly different from C# (even both end with #), and all are different with Boo. In fact there are instructions in MSIL (for example "Tail" which will make a tail call, that you cannot call in C#, even 4.0, but is specially used for functional languages). I can agree that C# got some of the features out of every language by a little (Linq a bit of functional programming, Generics a bit of meta-programming, dynamic a bit of dynamic dispatch, and so on), and Visual Basic was gotten convergent, but even with this, combining it with frameworks (like WPF, WCF, etc.) make a way to talk in real world, that are much more different than just a syntax sugar over MSIL (I mean BAML / Xaml world). Of course any of those decisions have choices, some are good some are bad, but overall, inside the .Net package you have a lot to get. Or in Java, or in Python. The idea of "batteries included" is maybe what you think that strikes you. I mean, what bothers you? The idea that .Net is too big? The lowest cost "laptop" I find in Spain with Windows, have a Windows that includes .Net 4 (http://www.pccomponentes.com/asus_ee...0gb_10_1_.html ) and it has bundled a 320 GB disk. Windows' disk usage, around 10 GB. And you compare a 40 MB package download, that the code include by default a lot of code that other components, like Paint.Net, would not have to download. So Paint.Net download package is just some MB (low number).
Originally Posted by Togga
At the end, I think that in a part, you are right: additional runtime environments bring restrictions. So you may use Cygwin and as cygwin provides Mono, you can target all Unixes with Mono programs. If you mean that C++ applications have any benefit to portability, compared to Mono, I'm curious of your platform to develop in, is it Qt? (which in itself is a platform, and as I worked professionaly with it, I can say that in some configurations is buggier than GTK+, in special with non-standard window-managers)
If static type checking it can be done just with a plugin. Don't you want this, and want a supported compiler-integrated checking? You can check Code-Contracts. As OpenTK is the de-facto wrapper for OpenGL, and gl/GL.h is the de-factor for C++, what you state is still a talk which is not yet proven.
The GL-problem, as I said, is easily solved with additional syntax checking tools/scripts and you will get both the type-check for each GL function and the leaner and nicer syntax given by C/C++ (compared to C#). If static type-checking of the compiler is your main priority, you should probably go for ADA or similar.
Are visual designers really a good way to do good UI:s? I'm provoking here, but the best UI:s I seen rarely come from visual tools. Compare for instance the output from LaTeX vs a manually written Word document. You can't be creative enough with visual tools and often both you and the tool get restricted by the tools. If you instead focus on the problem and the logic you can often dynamically create a better GUI, and you have a program where the GUI structure are not setting any restrictions.
Restrictions in UI are mostly the norm, you don't want to break anything, that's why you would prefer a Visual Form Inheritance to work by default! Most UIs like OS X are restricted by code guidelines, that users care to have what they expect, not how imaginative is the designer.
Did you ever looked the generated Vala code? Is mapping 1:1 to C? Or by runtime overhead, you mean, nothing else than GObject? And it is a bit buggy on Windows!? Or that it doesn't have annotations in the C# sense? And it doesn't have dynamic keyword, or PLinq.
Yes, and OOP is a way of design and could be done in most languages without the syntactic sugar in the "OOP languages". Likewise with "Abstract programming", "functional programming", etc. If you aim for syntax, look for instance at how Vala abstracts all C-calls to the gobject system and still doesn't require any other runtime overhead than what their C library interface does (compile-time syntax sugar).
I do not see any feature here that motivates a VM and the .NET API. You may initially have to go an extra mile in design but that is reusable and completely worth it.
I think this is an excellent choise. An interpreted high level language for quick prototyping / scripting / etc and then a portable lower level language for performance. .NET is an environment that isn't particularly good in either of these directions. You can also use these high level languages to auto-generate low-level code in C for instance and you will both have customized high abstractions and performance.
"I don't see any feature"... is fine. It still makes the point true: the abstractions pay a price a lot of times. Sometimes small, sometimes by making a language specification and understanding really huge (like C++). I mean, using a smart-phone forced us to think phones with "gestures", "post-PC era", and so on, which is really far far away from the phone that was barely digital (in the past I catched my grandma using a wheel to call to the numbers).
And I do think that even by any standard, the basic phone is still good enough for many usages, and a smartphone can be sometimes too complex to grasp how to "install application from Marketplace". They make no sense in many ways, at least for basics. But when you get used, you simply cannot look back.
Should we write only binary, as INI files or XML files are too slow to parse and are abstractions? Certainly the binary files are faster. Should we write for saving data our back-store database and not using a database? Imagine, most databases use Inter-Process communications, and the ones that don't are somewhat slow, even the performant ones, use a query engine that sometimes is using a JIT (I'm saying about Oracle query planner that uses a Java VM to optimize and generate dynamically the query conditions, using HotSpot Server).
At the end, should we all use Windows 95/NT 4.0 !? It is small (I remember that Win95 was like 40 MB on disk, Win 95 OSR 2 like 120M, NT 4 was like 100+ M), it should start instantly on today's hardware, had 64 bit support (only NT), no multiple runtimes to support, so no headaches. It did not had a (functional) browser control so no hassles with incomatible HTML. In fact we would not need ClearType, 3D Aero, and a 512 MB OS usage, when all those 3 OSes would work just fine with just 32 MB, and 64 MB would be the high end machines of their times.