Quote:Original post by Anonymous Poster 2) The lecturers claim that c# (the language they are using instead) is more portable the c++ and will work on ANY platform and with ANY hardware.
This might be true from the right POV. Do you consider Java portable? Well C# is just as portable. The problem with C++ is that it's compiled to native code1. C# however compiles to MSIL, therefore any platform with the .NET framework should be able to run it2. You also need to consider that most of the libraries you use in C++ only runs on some platforms (yes, even libraries like OpenGL and Boost.Filesystem can't run on all platforms, just the most popular), but in C# you have lots of standard libraries which should run everywhere.
1: One could imagine a C++ compiler compiling to some P-code. 2: One could also write an interpreter reading some popular machine code like x86 (this could also read C++ programs), but that would mean it was stupid to translate to machine code in the first place.
I really do feel c++ is not a bad language. It is intentionally minimalist i.e. libraries are supposed to do most of the work. In fact this is probably the reason why c++ has survived for a reasonably long time despite its shortcomings - flexibility. The language doesn't lock you into doing certain things in certain ways (like Java for example). If you want any extras, simple: write/beg/borrow/steal a library. Works for most developers currently. Sad to say there are parts in which it is lacking (concurrent support, too terse sometimes, tedious etc.). But all these have been at least partially solved by external libraries (though sometimes kludges are required). Most of c++'s problems can be solved (albeit sometimes only in the short term) by merely creating new template libraries or improving existing ones. There's no reason to bash any language just because you don't like it. There are people who aren't comfortable with c++ but there are also many who like it. Market demand/peer pressure cannot be the reasons why a significant number of people started using it INITIALLY. Objective C & the like were viable alternatives to C++: why aren't they as widely used? It's a matter of personal style, that's all. And certainly for any language there will be proficient as well as inept programmers. C++ doesn't seem way out of the ordinary - in fact most of the programmers who code badly in it do so because they use it as "C with classes" or "C with some other funny but useful features", or because they try to code in it as they would another language. This only attests to the flexibility of c++: you don't even need to force a paradigm shift on yourself to begin coding. Code as well or as badly as you want in almost any style you choose. Functional, OO, spaghetti, whatever. Every language has it's strengths and weaknesses. C++ is at least as good as any other language at present. It'll stay for many many years, maybe even up to 2026 (even with managed code: there is such a thing known as managed C++, clunky though it currently is).
Quote:Original post by zedzeek u must of misundersood my post, i was actually praising flash
No I didn't misunderstand at all. You posted saying there are thousands of 'simplistic' flash games and if you reread your post it sounds like you are saying 'Flash is good enough for snake but thats about it'. Maybe you didn't mean it that way but just go back and read your post and you will understand what I mean. There are actually quite a few complicated applications done in Flash/AS.
Also there are huge differences between C++ and Flash/AS.. I'm not sure why you think syntax is a problem at all? I mean it is never an issue for a developer at all. ECMA and C++ are at opposite ends of the spectrum and really have almost nothing in common.
Quote: The lecturers claim that c# (the language they are using instead) is more portable the c++ and will work on ANY platform and with ANY hardware.
Your lecturers are quite wrong:
C# will work on ANY platform and with ANY hardware for which the platform and hardware specific .Net framework has been implemented - many libraries will need to be totally rewritten on each platform
C++ will work on ANY platform and with ANY hardware for which the a C++ compiler has been implemented
Java will work on ANY platform and with ANY hardware for which the a Java virtual machine has been implemented
What are they doing teaching you specific languages anyway?
Quote:Original post by Anonymous Poster 2) The lecturers claim that c# (the language they are using instead) is more portable the c++ and will work on ANY platform and with ANY hardware.
This might be true from the right POV. Do you consider Java portable? Well C# is just as portable.
Some OSes would throw it away because it's an exe file. The same OSes might support .jar files quite well. Of course if some "smart" archiver will not try to open executable files. Java is also more rigidly specified, changing itself less often, and all Java libraries are OS neutral. So it looks like .NET has still a lot things to do until it might become as portable as Java.
Quote:One could also write an interpreter reading some popular machine code like x86 (this could also read C++ programs), but that would mean it was stupid to translate to machine code in the first place.
Stupid from them, they never thought about 64 bit computing, and they didn't wrote specifications for binary code for that future 64 bit computers.
Don't forget that C++ is destined to get some major upgrades with the upcoming new specs some years from now. I think that will be enough to ensure its dominance for quite some time.
As for how I would envision the next dominant language, well, it would abstract all the things we take as absolutes these days. That is, things like the compiler, the optimiser, the parser, the syntax tree, etc... will all become but modules in the languages. They can be swapped in and out, invoked only when needed and modified when necessary.
Source code will become a generic description, like a database, which can then be rendered in any view desired, be it text, a graph or even sounds.
Program execution will stop being considered a thing that starts each time the exe is run, but something that begins right from compilation and never ends. The period between what we see as seperate executions today will be considered more of a dorment period between active states.
Thus, one may write a program that starts by invoking an interpreter, which modifies the code and hands the result off to an optimisation package, which hands off to a translator that generates machine code, which itself has code embedded that will run of a JIT compiler when executed. The language will be more like a standard framework, a protocol, that enables disperate tools and libraries to be easily composed and managed to the end of manipulating and executing code. In this way, the programmer can use the right or familiar tool for the job, and still be sure that their code will work with future tools and other programmers can understand it. That protocol is what I would imagine the next dominant language to be, the language of programming languages.
Quote:Original post by Nitage C# will work on ANY platform and with ANY hardware for which the platform and hardware specific .Net framework has been implemented - many libraries will need to be totally rewritten on each platform
C++ will work on ANY platform and with ANY hardware for which the a C++ compiler has been implemented
Thats not half of the truth.
A compiler is not enough to port an application. You still need libraries matching the platform.
I mean C# compiles to MSIL, and you could quite easily write a decompiler that outputs C++ code. I mean MSIL and C++ are both turing complete, you can do anything with either. So why is a JIT compiler for a platform, that compiles all the .NET libraries and the application to machine code not enough to port it, but if you write your app in C++ syntax it would be enough?
The truth is that C++ is portable because it is popular, not the other way around. Because libraries are written for a lot of platforms. But you still need libraries fitting that platform, and many will need to be totally rewritten on each platform.
Quote:Original post by Nitage C# will work on ANY platform and with ANY hardware for which the platform and hardware specific .Net framework has been implemented - many libraries will need to be totally rewritten on each platform
C++ will work on ANY platform and with ANY hardware for which the a C++ compiler has been implemented
Thats not half of the truth.
A compiler is not enough to port an application. You still need libraries matching the platform.
If you depend on platform dependant libraries, yes. I don't think you'll find anyone arguing that you don't need *platform dependant* libraries (part of a standard library or not) to do *platform specific* things. In fact, most will conceed the point as obvious to the point of not in need of being explicitly mentioned.
But no, you don't need libraries matching the platform for platform independant tasks - those libraries can simply be recompiled since you have an available C++ compiler. If you were refering to C++'s standard library, I'd like to point out it's infinitely smaller than .NET - to the point that Nitage probably just felt it wasn't worth mentioning it was so tiny by comparison. There's what, the C imported stuff, and then file/console iostreams (presuming they're not implemented in terms of the C API)?
It's just a trade off. "Easily" implement enough to do "little" worthwhile ("out of the box") versus implement with a great amount of effort enough to do a bit more ("out of the box").
Quote: So why is a JIT compiler for a platform, that compiles all the .NET libraries and the application to machine code not enough to port it, but if you write your app in C++ syntax it would be enough?
I'm not saying that C++ is superior to C# in this regard - I'm saying that there's no difference.
I can't take a C++ application using DirectX and compile it to run on Linux, but neither can I take a C# program using managed DirectX and run it on Mono.
However, C++ compilers exist for many more platforms than C#, which currently makes it much more portable.
[Edited by - Nitage on September 25, 2006 4:58:03 AM]
