This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
346
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 07, 2010, 02:32:32 pm »
Anyone before learning that it is undefined behavior.
That buffer overflows, segmentation faults and stack overflows are undefined behavior, I can understand, but is the performance benefit of leaving this undefined really that much?
Either way, undefined is undefined. This would be a perfectly legitimate-looking code. So this blows up your whole "predictable" point: C++ is either as predictable as, or less predictable than, Java and C#.
Here are our points so far:
- C/C++ is faster than, Java/C#, although computers now are much faster than computers when C was invented and either way JIT means Java/C# speed isn't really that bad.
- C/C++ has basically no API(stdio, iostream, match, etc. are hardly enough). Java/C# have big, useful, unified APIs. Somehow, you think this is an advantage for C/C++. I think it's an advantage for Java/C#.(we're not in the runtime size issue yet here)
- C/C++ has no built-in garbage collector, although bad-quality garbage collectors, so programmers are forced to deal with complex memory leaks/segmentation faults situations. Java/C# have mandatory first-class garbage collectors. You claim C++ is better because (supposedly) this is faster and gives you more freedom. I think the freedom claim is bogus since people don't want to deal with language stupidities when they are solving real problems, so the only thing here is the perceived speed advantage. This difference is negligible. Also, garbage collectors(particularly of JITed languages) know what they are dealing with(hardware) so they can optimize for specific caches and avoid memory fragmentation(which native malloc/free are bad at), so the GC is not really the bottleneck of these languages' speed.
When an application is slow, it is more likely an algorithm problem(such as using O(n^3) when a log(n) solution exists) than a language problem. It is important to note that we are talking in a game-related forum, where speed(frames per second) is particularly important, which is a possible excuse for your excessive obsession with speed. Aside from games, very few problems suffer from garbage collection/speed issues. Usually, development costs and Moore's law are enough to justify using Java/C#(and, once again, Java/C# aren't as slow as you might think).
The "consumes more memory" issue is very similar to the speed issue.
Anyway, going on:
- C/C++ have a (relatively) small runtime(libraries, etc.), while Java/C# have big runtimes. In terms of available hard disk space, this issue is irrelevant, in terms of internet bandswidth, I understand your problem. Either way, many computers come with Java/.NET so, in the end, the size of the runtime(in terms of what the end-user has to download) is about 0. Also, C++ executables can get really big with things like templates, and those can't come with the computer(C++ ABIs is hell, while C/Java/C# ABIs are relatively easy to manage. By the way, "ABI" means "Application binary interface", for those who don't know: it's kind of like APIs, but for compiled applications).
Things I hope to have proven as false:
- "Java/C# are interpreted so they can't be faster than C/C++": Even if Java/C# are indeed as slow as you claim it to be, Java/C# are NOT typically interpreted. They are JIT compiled. In fact, there are AOT compilers for C#(this is how Mono allows C# applications to run on the iPhone, where compilation and interpretation are forbidden by Apple). This happens regardless of *.class and *.dll files.
- "C is more predictable than Java": Java has less undefined behavior situations than C, and both are clearly defined in their own specifications, so Java is either as predictable or more predictable than C. So "predictable" in NOT the word you want. Perhaps you say you like being able to do stupid things and that C doesn't attempt to stop it. I don't see how this is an advantage, but indeed C allows that. This is not being "predictable".
- "C/C++ is the best possible language for all possible situations": This is incorrect. C is a language that's best used in some cases, and particularly bad in others. If you're writing a kernel, a driver or you're on a microcontroller with 8KB of memory, then C or Assembly are probably the only reasonable choice. If you're developing some Math simulations, which don't need to go super-fast but indeed need to be drafted fast - then C is a horrible choice. Depending on the kind of simulation, functional languages or languages like Python are far better. If you want to do web design, where multiple layers of security and fast development cycles are more important than saving a few clock cycles, then PHP, Java and/or C# are the best choices(and, in this field, C# is really competitive relatively to competition). Once Josh admitted the possibility of using V8, he implicitly admitted he couldn't use C for everything(V8 is in C, but it executes JavaScript). For desktop applications where you have a fast-moving competition and need to provide features rather than being for hours trying to find out that annoying memory leak that's taking 100MB of memory(which is far more than what a GC consumes and, yes, it happens in C because people aren't perfect), then Java/C# might indeed be better than C.
That buffer overflows, segmentation faults and stack overflows are undefined behavior, I can understand, but is the performance benefit of leaving this undefined really that much?
Either way, undefined is undefined. This would be a perfectly legitimate-looking code. So this blows up your whole "predictable" point: C++ is either as predictable as, or less predictable than, Java and C#.
Here are our points so far:
- C/C++ is faster than, Java/C#, although computers now are much faster than computers when C was invented and either way JIT means Java/C# speed isn't really that bad.
- C/C++ has basically no API(stdio, iostream, match, etc. are hardly enough). Java/C# have big, useful, unified APIs. Somehow, you think this is an advantage for C/C++. I think it's an advantage for Java/C#.(we're not in the runtime size issue yet here)
- C/C++ has no built-in garbage collector, although bad-quality garbage collectors, so programmers are forced to deal with complex memory leaks/segmentation faults situations. Java/C# have mandatory first-class garbage collectors. You claim C++ is better because (supposedly) this is faster and gives you more freedom. I think the freedom claim is bogus since people don't want to deal with language stupidities when they are solving real problems, so the only thing here is the perceived speed advantage. This difference is negligible. Also, garbage collectors(particularly of JITed languages) know what they are dealing with(hardware) so they can optimize for specific caches and avoid memory fragmentation(which native malloc/free are bad at), so the GC is not really the bottleneck of these languages' speed.
When an application is slow, it is more likely an algorithm problem(such as using O(n^3) when a log(n) solution exists) than a language problem. It is important to note that we are talking in a game-related forum, where speed(frames per second) is particularly important, which is a possible excuse for your excessive obsession with speed. Aside from games, very few problems suffer from garbage collection/speed issues. Usually, development costs and Moore's law are enough to justify using Java/C#(and, once again, Java/C# aren't as slow as you might think).
The "consumes more memory" issue is very similar to the speed issue.
Anyway, going on:
- C/C++ have a (relatively) small runtime(libraries, etc.), while Java/C# have big runtimes. In terms of available hard disk space, this issue is irrelevant, in terms of internet bandswidth, I understand your problem. Either way, many computers come with Java/.NET so, in the end, the size of the runtime(in terms of what the end-user has to download) is about 0. Also, C++ executables can get really big with things like templates, and those can't come with the computer(C++ ABIs is hell, while C/Java/C# ABIs are relatively easy to manage. By the way, "ABI" means "Application binary interface", for those who don't know: it's kind of like APIs, but for compiled applications).
Things I hope to have proven as false:
- "Java/C# are interpreted so they can't be faster than C/C++": Even if Java/C# are indeed as slow as you claim it to be, Java/C# are NOT typically interpreted. They are JIT compiled. In fact, there are AOT compilers for C#(this is how Mono allows C# applications to run on the iPhone, where compilation and interpretation are forbidden by Apple). This happens regardless of *.class and *.dll files.
- "C is more predictable than Java": Java has less undefined behavior situations than C, and both are clearly defined in their own specifications, so Java is either as predictable or more predictable than C. So "predictable" in NOT the word you want. Perhaps you say you like being able to do stupid things and that C doesn't attempt to stop it. I don't see how this is an advantage, but indeed C allows that. This is not being "predictable".
- "C/C++ is the best possible language for all possible situations": This is incorrect. C is a language that's best used in some cases, and particularly bad in others. If you're writing a kernel, a driver or you're on a microcontroller with 8KB of memory, then C or Assembly are probably the only reasonable choice. If you're developing some Math simulations, which don't need to go super-fast but indeed need to be drafted fast - then C is a horrible choice. Depending on the kind of simulation, functional languages or languages like Python are far better. If you want to do web design, where multiple layers of security and fast development cycles are more important than saving a few clock cycles, then PHP, Java and/or C# are the best choices(and, in this field, C# is really competitive relatively to competition). Once Josh admitted the possibility of using V8, he implicitly admitted he couldn't use C for everything(V8 is in C, but it executes JavaScript). For desktop applications where you have a fast-moving competition and need to provide features rather than being for hours trying to find out that annoying memory leak that's taking 100MB of memory(which is far more than what a GC consumes and, yes, it happens in C because people aren't perfect), then Java/C# might indeed be better than C.
347
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 07, 2010, 11:58:48 am »Code: [Select]
int x[5];
for (int i = 0; i < 5; ++i)
x[i] = 0;
int i = 1;
x[i] = i++;
printf("0=%d;1=%d;2=%d\n", x[0], x[1], x[2]);
getc(stdin);
Causes a -Wall warning: "operation on 'i' may be undefined"
348
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 07, 2010, 10:58:12 am »
The problem is not increment. The problem is using an incremented variable again in the same statement. Knowing if it is incremented or not is undefined.
It's not a specific compiler that sucks. It's the C STANDARD that sucks.
It's not a specific compiler that sucks. It's the C STANDARD that sucks.
349
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 07, 2010, 10:33:17 am »
@retep
Incorrect. Your behavior is unspecified.
Are you sure it is the first element(0)? Why not the second?
The fact it is UNDEFINED. It may indeed give the result you think. But you can NEVER be sure. C doesn't specify it.
One compiler may give the result you predict. Different compilers or different optimization flags may give different results.
@RetroX
Deciding who is "responsible" for deleting objects is remarkably hard, and very few people do it right. Which is why memory leaks(and garbage collectors) exist.
Incorrect. Your behavior is unspecified.
Are you sure it is the first element(0)? Why not the second?
The fact it is UNDEFINED. It may indeed give the result you think. But you can NEVER be sure. C doesn't specify it.
One compiler may give the result you predict. Different compilers or different optimization flags may give different results.
@RetroX
Deciding who is "responsible" for deleting objects is remarkably hard, and very few people do it right. Which is why memory leaks(and garbage collectors) exist.
350
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 07, 2010, 09:34:25 am »
Ask Google for help. They're trying to bring 1Gb/s internet to the world. Now, think of the effect THAT has on the competition(hint: it might convince them to improve their services)
But yes, I'll take that as a legitimate problem. However, I think .NET already comes with most Windows copies. As people replace their computers, they also get .NET along with it.
Last time I checked, DirectX was C/C++, so you hit your own language.
Bloated != Useful.
Who says they didn't? The fact is, in C(and not only in C), you can have multiple variables pointing to the same memory location. This problem does not happen with garbage collectors. In C, it happens pretty often, otherwise no programmer would know what "segmentation fault" means.
You want C undefined behavior? This, for instance:
But yes, I'll take that as a legitimate problem. However, I think .NET already comes with most Windows copies. As people replace their computers, they also get .NET along with it.
Last time I checked, DirectX was C/C++, so you hit your own language.
Bloated != Useful.
Who says they didn't? The fact is, in C(and not only in C), you can have multiple variables pointing to the same memory location. This problem does not happen with garbage collectors. In C, it happens pretty often, otherwise no programmer would know what "segmentation fault" means.
You want C undefined behavior? This, for instance:
Code: [Select]
int x[3];
int y = 0;
x[y] = y++;
Different compilers may give different results. In fact, the same compiler may give different results for that same code.
351
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 07, 2010, 06:22:02 am »
C#, however, has uint(and the equivalent for other types).
"register" in C is a suggestion, never an order. You can have 50 variables in "register" in a processor with less than 50 registers.
Because software is not frozen in time, its complexity increases over time(think browsers and HTML5, for instance).
A good language is essential for maintainability reasons.
C# and Java aim to simplify software so we can solve our problems instead of reinventing the wheel or have to deal with the language's problems like in C. The big API is part of that simplification.
The size of modern disks(several GB, maybe TB, and going up) means that, proportionally, the size of these APIs is perfectly reasonable(also, the .NET 4.0 installer is smaller than reaching its peak with 3.5)
"register" in C is a suggestion, never an order. You can have 50 variables in "register" in a processor with less than 50 registers.
Because software is not frozen in time, its complexity increases over time(think browsers and HTML5, for instance).
A good language is essential for maintainability reasons.
C# and Java aim to simplify software so we can solve our problems instead of reinventing the wheel or have to deal with the language's problems like in C. The big API is part of that simplification.
The size of modern disks(several GB, maybe TB, and going up) means that, proportionally, the size of these APIs is perfectly reasonable(also, the .NET 4.0 installer is smaller than reaching its peak with 3.5)
352
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 06, 2010, 01:43:37 pm »
JNI/JNA and P/Invoke, Josh.
Assembly is relatively minimalistic. C++ is a whole world. So adding Assembly to C++ is relatively easy.
Adding C++ to Java/C# is not trivial.
But yes, this whole Java-vs-C++ debate is pretty much like old C-vs-Assembly debates. The C guys trying to convince the Asm guys that C isn't that bad, that C solves some problems easily when Assembly is highly complex and Assembly guys saying that Asm does everything that C does and more(interrupts, anyone?) and that C is "far too slow" and "forces specific methods instead of giving freedom"(such as register allocation), with the C programmers saying that C is no longer as slow as it used to be and is relatively capable of competing with Assembly, even if well-coded assembly is faster than C.
But yes, we are mostly in a transition period which is kind of painful. If most of the world used C# though, we'd look at C and complain how hard integration is. C makes ABI(Application Binary Interface) very easy, but the same does not apply to C++. C++'s polymorphism and classes make binary interfaces notably hard to predict and keep.
.NET does allow hybrid executables(managed and unmanaged code), so in theory it should be possible to mix C# and C++ easily, but I confess I'm not sure how(separated assemblies with DLL should make this simple, but merging in a single executable requires methods I'm not fully familiar with).
Assembly is relatively minimalistic. C++ is a whole world. So adding Assembly to C++ is relatively easy.
Adding C++ to Java/C# is not trivial.
But yes, this whole Java-vs-C++ debate is pretty much like old C-vs-Assembly debates. The C guys trying to convince the Asm guys that C isn't that bad, that C solves some problems easily when Assembly is highly complex and Assembly guys saying that Asm does everything that C does and more(interrupts, anyone?) and that C is "far too slow" and "forces specific methods instead of giving freedom"(such as register allocation), with the C programmers saying that C is no longer as slow as it used to be and is relatively capable of competing with Assembly, even if well-coded assembly is faster than C.
But yes, we are mostly in a transition period which is kind of painful. If most of the world used C# though, we'd look at C and complain how hard integration is. C makes ABI(Application Binary Interface) very easy, but the same does not apply to C++. C++'s polymorphism and classes make binary interfaces notably hard to predict and keep.
.NET does allow hybrid executables(managed and unmanaged code), so in theory it should be possible to mix C# and C++ easily, but I confess I'm not sure how(separated assemblies with DLL should make this simple, but merging in a single executable requires methods I'm not fully familiar with).
353
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 06, 2010, 11:49:24 am »
Different computers have different hardware. Some processor-specific optimizations fail when you switch computers.
Also, on prediction of C and Java, consider this code:
In Java, I can predict that someField of x will become 2.
In C, I can predict nothing. In spite of the check, the application could still crash(segfault) if, for instance, x was free()d.
When I write code in C, the spec states what happens. Ok, that's predict. But - guess what? - the same applies to Java.
If nothing else, Java is MORE predictable than C because there is less *undefined behavior*(which C has plenty).
So, I said it and I'll say it again - as a language, C is great for low-level tasks. For high-level tasks, it is basically the same as Brainfuck(where everything is technically possible, just like in C).
You're complaining that Java/C# are too high-level when it's their greatest advantage. This is not 1970 anymore. Most tasks no longer require such low-level tools.
You can theoretically dig a 100km-wide hole, but nobody does it. The right tools for the right job. Possibility is irrelevant. What matters is viability.
EDIT: Just found this gem in Wikipedia:
Also, on prediction of C and Java, consider this code:
Code: [Select]
//C++
if (x != NULL) x->someField = 2;
//Java
if (x != null) x.someField = 2;
In Java, I can predict that someField of x will become 2.
In C, I can predict nothing. In spite of the check, the application could still crash(segfault) if, for instance, x was free()d.
When I write code in C, the spec states what happens. Ok, that's predict. But - guess what? - the same applies to Java.
If nothing else, Java is MORE predictable than C because there is less *undefined behavior*(which C has plenty).
So, I said it and I'll say it again - as a language, C is great for low-level tasks. For high-level tasks, it is basically the same as Brainfuck(where everything is technically possible, just like in C).
You're complaining that Java/C# are too high-level when it's their greatest advantage. This is not 1970 anymore. Most tasks no longer require such low-level tools.
You can theoretically dig a 100km-wide hole, but nobody does it. The right tools for the right job. Possibility is irrelevant. What matters is viability.
EDIT: Just found this gem in Wikipedia:
Quote
Ngen pre-compiles (or "pre-jits") bytecode in a Common Intermediate Language image into machine native code. As a result, no runtime compilation is needed. .NET framework 2.0 shipped with Visual Studio 2005 runs Ngen on all of the Microsoft library DLLs right after the installation.So it appears that even your beloved .NET DLLs are compiled. Worse - they combine the optimization advantages of JIT with the minimum startup delay of AOT!
354
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 06, 2010, 10:20:24 am »
There are AOTs for C#.
355
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 06, 2010, 10:11:41 am »
No kernel is done in C then.
It is IMPOSSIBLE to write a kernel in C.
You need always a very small assembly component.
Most modern C-based kernels use the linker to mix it with Assembly(inline assembly is also used in some cases, but might not be enough)
Because, somehow, C is *too* high-level for some kernel tasks.
It is IMPOSSIBLE to write a kernel in C.
You need always a very small assembly component.
Most modern C-based kernels use the linker to mix it with Assembly(inline assembly is also used in some cases, but might not be enough)
Because, somehow, C is *too* high-level for some kernel tasks.
356
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 06, 2010, 09:50:27 am »
There was a time where people said C was too slow that it was unusable.(asm programmers)
Turns out C is now "fast enough for most purposes, sometimes faster".
http://unity3d.com/gallery/game-list/
http://docs.google.com/viewer?a=v&q=cache:6aTCMeFMbfUJ:simcitysocieties.ea.com/help/readme/readme_en.pdf+Simcity+societies+.NET&hl=en&pid=bl&srcid=ADGEESjMcZl10XCwCQyoSjd83qROSAmuCKMshtYYzWKrU5o6pjTEmIOTfq1-tHdBVxcHMU5NaSfKUQ_gCfAFvYJAdnXrOMc8SeJkl2xezMkeFQ_0VKjDiHbrVIyYKAEoRWy27k390Gr7&sig=AHIEtbTeUtbE081MKORjFEzLRZej-lub-g
With frameworks like Unity3D and XNA, along with Mono's iXXX efforts, I think the trend is going to be reversed.
Java and C# are *COMPILED*. Get used to it. The JVM takes those class files and, depending on how much they are used, compiles and optimizes them(some classes are more worth optimizing than others).
Those ".NET-interpreting DLLs" are the API, which can also be compiled.
That's why it's called "Just-in-tme" compilation instead of "Ahead-of-time" compilation(JIT vs AOT)
Java and C# do what I say too. So they are predictable(by your own definition of "predictable").
Sure, there can be errors on bound checking, but they are perfectly clear on the language standard, and therefore predictable.
Yes, it is possible for kernels. Cosmos is a C# kernel. Not sure about Java, but I'm pretty sure they are possible.
And, technically, it is possible to do *ANYTHING* in BRAINFUCK too. Which means your argument just puts C along with turing tarpits.
Turns out C is now "fast enough for most purposes, sometimes faster".
http://unity3d.com/gallery/game-list/
http://docs.google.com/viewer?a=v&q=cache:6aTCMeFMbfUJ:simcitysocieties.ea.com/help/readme/readme_en.pdf+Simcity+societies+.NET&hl=en&pid=bl&srcid=ADGEESjMcZl10XCwCQyoSjd83qROSAmuCKMshtYYzWKrU5o6pjTEmIOTfq1-tHdBVxcHMU5NaSfKUQ_gCfAFvYJAdnXrOMc8SeJkl2xezMkeFQ_0VKjDiHbrVIyYKAEoRWy27k390Gr7&sig=AHIEtbTeUtbE081MKORjFEzLRZej-lub-g
Quote
SimCity Societies requires .NET 2.0. This will be installed along with SimCity Societies if
necessary. Visit www.microsoft.com for .Net.
With frameworks like Unity3D and XNA, along with Mono's iXXX efforts, I think the trend is going to be reversed.
Java and C# are *COMPILED*. Get used to it. The JVM takes those class files and, depending on how much they are used, compiles and optimizes them(some classes are more worth optimizing than others).
Those ".NET-interpreting DLLs" are the API, which can also be compiled.
That's why it's called "Just-in-tme" compilation instead of "Ahead-of-time" compilation(JIT vs AOT)
Java and C# do what I say too. So they are predictable(by your own definition of "predictable").
Sure, there can be errors on bound checking, but they are perfectly clear on the language standard, and therefore predictable.
Yes, it is possible for kernels. Cosmos is a C# kernel. Not sure about Java, but I'm pretty sure they are possible.
And, technically, it is possible to do *ANYTHING* in BRAINFUCK too. Which means your argument just puts C along with turing tarpits.
357
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 06, 2010, 08:59:31 am »
C#/Java: Rarely interpreted. Usually compiled. This is a huge point. It's the same for JavaScript. Almost nobody runs interpreted JS(IE9 has JIT too). Modern browsers COMPILE the code into native code. Which is why JS is recently having such huge performance boosts.
C++ is much LESS predictable than Java/C#. Undefined behavior is EVERYWHERE. Weird interactions occur. Stuff like buffer overflows make code pretty much impossible to predict.
Java pretty much FORCES code to be predictable.
Therefore, your "predictable" argument is bogus. Java and C# are predictable unless there is a bug in the VM/JITer. And, guess what, C compilers can have bugs too.
My main point is being closer to the processor(also known as "low level") is better if you want to solve a problem that's close to the processor(kernels are a typical example).
As the tasks you need to do become more complex(and, therefore, require abstractions to be possible to solve), having "high level" languages becomes more useful.
This is why C++ has some popularity over C - you can do ANYHING with C and, in fact, C code equates much more closely to the actual code being executed by the processor than C++.
And this also why C# and Java become more popular as the task becomes more complex.
In other words, C++ is a low-level language, where everything is possible but nothing is simple. C/C++ are BRILLIANT languages for low-level programming.
Java is a high-level language, where low-level things are more complex(and therefore hardly worth the effort to replace C), but things that were insane in C are very easy to handle in Java.
Low-level tasks -> Low-level language(C)
High-level tasks -> High-level language(Java/C#)
C++ is much LESS predictable than Java/C#. Undefined behavior is EVERYWHERE. Weird interactions occur. Stuff like buffer overflows make code pretty much impossible to predict.
Java pretty much FORCES code to be predictable.
Therefore, your "predictable" argument is bogus. Java and C# are predictable unless there is a bug in the VM/JITer. And, guess what, C compilers can have bugs too.
My main point is being closer to the processor(also known as "low level") is better if you want to solve a problem that's close to the processor(kernels are a typical example).
As the tasks you need to do become more complex(and, therefore, require abstractions to be possible to solve), having "high level" languages becomes more useful.
This is why C++ has some popularity over C - you can do ANYHING with C and, in fact, C code equates much more closely to the actual code being executed by the processor than C++.
And this also why C# and Java become more popular as the task becomes more complex.
In other words, C++ is a low-level language, where everything is possible but nothing is simple. C/C++ are BRILLIANT languages for low-level programming.
Java is a high-level language, where low-level things are more complex(and therefore hardly worth the effort to replace C), but things that were insane in C are very easy to handle in Java.
Low-level tasks -> Low-level language(C)
High-level tasks -> High-level language(Java/C#)
358
Off-Topic / The grand c++ vs everyone else debate
« on: April 06, 2010, 08:19:47 am »
I'm thinking that, if we're to discuss the whole C++ vs Java/C# issue, this might be a better place than the Announcements.
Does everyone else agree? (Or is that discussion over?)
Does everyone else agree? (Or is that discussion over?)
359
Announcements / Re: Anaphase
« on: April 05, 2010, 04:28:54 pm »
@seprex
Coq looks math. It could be considered at most functional programming, while C++(and Java too, by the way) is imperative.
GML is imperative too, making its implementation(or, should I say, translation) easier in C++ than in Coq.
Rusky already said that a modification to the C compiler would possibly work.
@RetroX
Here was I thinking that the flamewar was over. My mistake, sorry.
C/C++ is not a better language. It is different. Which is why you have so much trouble accepting Java and C#.
Pointer allocation is called malloc, calloc or new. It already exists in C++ and is widely used.
There is also GC for C++(see Boehm's, for example). However, they are imperfect. Far worse than GCs for GC-designed languages like Java.
Sure, C++ can have lots of things, but with each layer of abstraction you add, the syntax gets uglier and the language more complex. Java does the opposite. It adds those features and *still* has a simpler syntax. Java assumes everybody wants GC and turns out they were right for a HUGE percentage of all cases.
Now, to put this in a way you understand:
Java is a better language. If you want to make loads of standard libraries in Java for non-GC memory, pointer management, etc., that's fine with me. In fact, I'd love that.
But forcing people to use them(pointers, non-GC memory) in the language is a completely terrible and bad thing to do.
You can't use the argument "IT'S JUST BETTER WITH C++" because it's not. Yes, some C++ APIs are better than what Java has. It does not mean that C++ is a better language.
If the APIs are duplicated every day with no interoperability, that means they're obviously not standard enough.
---
Now that I put this out.
The above example is just to prove RetroX that his arguments can be used against him.
I don't consider Java to be absolutely better than C++ the way RetroX seems to think C++ is absolutely better than Java.
I certainly wouldn't care about a non-GC memory/pointer manipulation Java library(JNI-based, I guess).
C++ APIs are available in quantity, but that means fragmentation. Java includes lots of things in the standard library in a (partially successful) attempt to avoid that problem.
For the record, I don't consider Java to be the best language ever. I consider C# to be the best language, although I dislike GUI C# library inconsistent because it's the same problem C++ has. So the thing I hate most in C# happens to be a "feature" of C++? Neat, huh?
EDIT:
Exactly what are you trying to prove with the WinAPI/Xlib argument?
Coq looks math. It could be considered at most functional programming, while C++(and Java too, by the way) is imperative.
GML is imperative too, making its implementation(or, should I say, translation) easier in C++ than in Coq.
Rusky already said that a modification to the C compiler would possibly work.
@RetroX
Here was I thinking that the flamewar was over. My mistake, sorry.
C/C++ is not a better language. It is different. Which is why you have so much trouble accepting Java and C#.
Pointer allocation is called malloc, calloc or new. It already exists in C++ and is widely used.
There is also GC for C++(see Boehm's, for example). However, they are imperfect. Far worse than GCs for GC-designed languages like Java.
Sure, C++ can have lots of things, but with each layer of abstraction you add, the syntax gets uglier and the language more complex. Java does the opposite. It adds those features and *still* has a simpler syntax. Java assumes everybody wants GC and turns out they were right for a HUGE percentage of all cases.
Now, to put this in a way you understand:
Java is a better language. If you want to make loads of standard libraries in Java for non-GC memory, pointer management, etc., that's fine with me. In fact, I'd love that.
But forcing people to use them(pointers, non-GC memory) in the language is a completely terrible and bad thing to do.
You can't use the argument "IT'S JUST BETTER WITH C++" because it's not. Yes, some C++ APIs are better than what Java has. It does not mean that C++ is a better language.
If the APIs are duplicated every day with no interoperability, that means they're obviously not standard enough.
---
Now that I put this out.
The above example is just to prove RetroX that his arguments can be used against him.
I don't consider Java to be absolutely better than C++ the way RetroX seems to think C++ is absolutely better than Java.
I certainly wouldn't care about a non-GC memory/pointer manipulation Java library(JNI-based, I guess).
C++ APIs are available in quantity, but that means fragmentation. Java includes lots of things in the standard library in a (partially successful) attempt to avoid that problem.
For the record, I don't consider Java to be the best language ever. I consider C# to be the best language, although I dislike GUI C# library inconsistent because it's the same problem C++ has. So the thing I hate most in C# happens to be a "feature" of C++? Neat, huh?
EDIT:
Quote
If the APIs aren't used by everyone, that means that they're obviously not good enough. How many people use WinAPI? How many Unix APIs have XLib as a base?I actually missed that flaw. C++ APIs aren't used by everyone. The "not good enough" is obviously a C++ problem, not a Java problem(since everybody uses java.lang). So you just attacked your own language.
Exactly what are you trying to prove with the WinAPI/Xlib argument?
360
Announcements / Re: Anaphase
« on: April 05, 2010, 03:33:50 pm »
Assuming your arrays are 0-started, but I get your point.
Although possible, that's notably hard.
There are two possible choices for that:
- Have a really REALLY strong type system.
- Have an amazingly efficient type inference system.
Neither are possible with C nor Java.
So instead of "C is perfect" or "C and Java are the best choice in different cases", we got to "both C++ and Java suck".
That requires a specific paradigm of programming languages that, for some reason, never really became mainstream.
That particular paradigm is really annoying to program in(since very often it is terribly hard to find out the code possibilities, and we end up with annoying errors), but also really bug-safe. Once again, we have something that's more adequate in some cases than others.
Although possible, that's notably hard.
There are two possible choices for that:
- Have a really REALLY strong type system.
- Have an amazingly efficient type inference system.
Neither are possible with C nor Java.
So instead of "C is perfect" or "C and Java are the best choice in different cases", we got to "both C++ and Java suck".
That requires a specific paradigm of programming languages that, for some reason, never really became mainstream.
That particular paradigm is really annoying to program in(since very often it is terribly hard to find out the code possibilities, and we end up with annoying errors), but also really bug-safe. Once again, we have something that's more adequate in some cases than others.