Java...
Did you seriously just state that C++ is not "powerful enough" to support reactive programming, rapidcoder? Because if so then I'm afraid I shall have to mimic the action I performed when you stated that the Java's allocation speed is faster than malloc.
-Albatross
-Albatross
Did you seriously just state that C++ is not "powerful enough" to support reactive programming, rapidcoder? |
Of course you can emulate it to some extent in C++, but it will nowhere be as handy as in a language that supports closures, lazy evaluation and continuations. And the second, simpler reason (or effect?) is: there is no reactive GUI framework for C++, sorry.
Java's allocation speed is faster than malloc. |
And is it not?
Incrementing a pointer is much faster than searching a block on a free-list, no matter how well optimised a free list it is. And deallocation in Java is obviously much faster than a call to delete - zero is always smaller than a positive constant.
Last edited on
Reactive programming as I see it is a declarative programming concept. Functional, I don't know, but you can emulate declarative programming to a *huge* extent in C++ with the help of some polymorphism and "event" objects (example; there are several ways to do it).
The C standard does not state how malloc is supposed to be implemented. As I see it, saying that Java's allocation speed is faster than malloc is like saying that my car is faster than all the cars without regard to what sort of cars they are and what sort of terrain I'm driving on, not to mention who's driving them and how they're used.
-Albatross
The C standard does not state how malloc is supposed to be implemented. As I see it, saying that Java's allocation speed is faster than malloc is like saying that my car is faster than all the cars without regard to what sort of cars they are and what sort of terrain I'm driving on, not to mention who's driving them and how they're used.
-Albatross
Last edited on
You can emulate *ANY* programming paradigm in *ANY* language. But C++ is not good at declarative / functional thingies - it lacks some important features I mentioned, just like C is not a good OOP language (but you can emulate it with function pointers etc).
You are knitpicking. s/malloc/typical free-list based implementation of malloc/
Now better? Anyway, no matter how you implement it, you can't do that as efficiently as it is in Java because of a simple reason - you can't defragment memory, because you don't know where pointers are.
Poor analogy. Much better would be that my fighter aircraft is faster than your car. It really doesn't matter if your car is a truck, or a ferrari.
The C standard does not state how malloc is supposed to be implemented. |
You are knitpicking. s/malloc/typical free-list based implementation of malloc/
Now better? Anyway, no matter how you implement it, you can't do that as efficiently as it is in Java because of a simple reason - you can't defragment memory, because you don't know where pointers are.
As I see it, saying that Java's allocation speed is faster than malloc is like saying that my car is faster than all the cars without regard to what sort of cars they are and what sort of terrain I'm driving on, not to mention who's driving them and how they're used. |
Poor analogy. Much better would be that my fighter aircraft is faster than your car. It really doesn't matter if your car is a truck, or a ferrari.
Last edited on
Boy, it sure doesn't feel like I've seen this discussion before.
What do you mean "scalable"?
| rapidcoder wrote: |
|---|
| As for the event-driven model for GUI - I'd expect the reactive model to be much better and much more scalable |
| rapidcoder wrote: |
|---|
| C++ is not good at declarative / functional thingies - it lacks some important features I mentioned |
| rapidcoder wrote: |
|---|
| C++ [...] will nowhere be as handy as in a language that supports closures, lazy evaluation and continuations. |
Maybe we have a different definition of power, but from the looks of it the problem isn't that C++ isn't powerful enough, but that it just isn't designed for this task.
| You are knitpicking. |
Am not! The implementation can vary quite a bit across platforms, as can the performance.
| Poor analogy. Much better would be that my fighter aircraft is faster than your car. It really doesn't matter if your car is a truck, or a ferrari. |
Actually, that analogy doesn't hold water either, because there was a car that broke the sound barrier in 1997, and I'm sure there were fighter jets operational at the time that were incapable of this. Forget the obvious fact that one of the two categories of transportation is highly specialized and that both operate in different spaces and are bound by different rules and suitabilites for tasks.
-Albatross
Last edited on
Do you guys get the feeling rapidcoder wrote a program (in Scala, of course) that scans these forums for any mention of Java and. when it finds one, sends him an e-mail notifying him and containing the URL? Of course it would have to catalogue ones it had already found and check its database to make sure it isn't reading an old post... I kind of want to write it now (but I still haven't looked at Scala yet)...
Dude, why would he write it in scala when Clojure is purely functional AND garbage collected? He could accomplish something that would work best imperatively and doesn't need memory re allocated often in a functional language that creates a whole other thread to take care of the memory for you!
Anyways, have any of you guys ever met some one who has to be right, even when he knows wrong?
Anyways, have any of you guys ever met some one who has to be right, even when he knows wrong?
Last edited on
From: cpp.com-script@localhost.localdomain
To: rapidcoder@localhost.localdomain
Subject: Libel against Scala
Body:
---
Yes, many times, and I've been accused of it myself before, although the people said I didn't always have to be right, just that I was overly stubborn and rarely admitted to being wrong (I jokingly replied "Maybe I'm just rarely wrong" which was probably the wrong thing to say).
To: rapidcoder@localhost.localdomain
Subject: Libel against Scala
Body:
| xander337 wrote: |
|---|
| Dude, why would he write it in scala when Clojure is purely functional AND garbage collected? He could accomplish something that would work best imperatively and doesn't need memory re allocated often in a functional language that creates a whole other thread to take care of the memory for you! Anyways, have any of you guys ever met some one who has to be right, even when he knows wrong? |
---
| xander337 wrote: |
|---|
| Anyways, have any of you guys ever met some one who has to be right, even when he knows wrong? |
Yes, many times, and I've been accused of it myself before, although the people said I didn't always have to be right, just that I was overly stubborn and rarely admitted to being wrong (I jokingly replied "Maybe I'm just rarely wrong" which was probably the wrong thing to say).
I hate interfaces in Java because I fail to see how they are useful. It really confuses me why anyone would give you skeleton and say "you have to write the body every...single...time". Copy-paste is beside the point here.
I don't like not being able to overload operators...simply put.
I don't understand why you would clutter classes so much with all that extending/deriving/inheriting, and why no multiple inheritance?
Why would you ever want to have a non-extendable class (final class)? This makes no sense to me...
Why isn't there a scope resolution operator? The book Java Puzzlers details why this is such a problem.
I don't like how the String replace and replaceAll functions replace after the last replacement rather than the start of the last replacement + 1 (eg replace " cat " with " dog " in "cat cat cat" and you get "dog cat dog")
Besides the issues above and other unmentioned issues it's a nice language, with the downfall of never being able to make a true "Stand-Alone" executable. I like it and hate some parts of it essentially X)
I don't like not being able to overload operators...simply put.
I don't understand why you would clutter classes so much with all that extending/deriving/inheriting, and why no multiple inheritance?
Why would you ever want to have a non-extendable class (final class)? This makes no sense to me...
Why isn't there a scope resolution operator? The book Java Puzzlers details why this is such a problem.
I don't like how the String replace and replaceAll functions replace after the last replacement rather than the start of the last replacement + 1 (eg replace " cat " with " dog " in "cat cat cat" and you get "dog cat dog")
Besides the issues above and other unmentioned issues it's a nice language, with the downfall of never being able to make a true "Stand-Alone" executable. I like it and hate some parts of it essentially X)
| L B wrote: |
|---|
| I hate interfaces in Java because I fail to see how they are useful. |
An interface is just an abstract class. The reason they are designed the way they are in java is because of the lack of multiple inheritance. Multiple inheritance was left out to avoid the diamond problem.
| L B wrote: |
|---|
| I don't like not being able to overload operators...simply put. |
AFAIK, Operator overloading is just syntactic sugar... but I agree with you on that one. I hate not having them. It makes certain actions look nicer in my opinion.
| L B wrote: |
|---|
| Why would you ever want to have a non-extendable class (final class)? |
When you tack on final to your class declaration the jvm does some optimization it can't do otherwise. So if you know for a fact that a class should not be inherited go ahead and declare it final, not only will you get that little boost, you will also have some security. I should mention that classes aren't just there for ease of inheritance, they also allow for easier modular programming.
| L B wrote: |
|---|
| Why isn't there a scope resolution operator? The book Java Puzzlers details why this is such a problem. |
It doesn't have one because it doesn't need one. Everything in Java must be encapsulated in a class, and namespaces are replaced with packages. So everything in this manner is accessed with the '.' operator.
| L B wrote: |
|---|
| I don't like how the String replace and replaceAll functions replace after the last replacement rather than the start of the last replacement + 1 |
I agree with this one too. But then again, you could always write your own replace method...
| L B wrote: |
|---|
| never being able to make a true "Stand-Alone" executable. |
I haven't looked into it too much but google Java AOT Compiler. I'm pretty sure they do just that.
Disclaimer: I prefer C++ to java in most applications. JSYK
| I hate interfaces in Java because I fail to see how they are useful. |
| Why would you ever want to have a non-extendable class (final class)? This makes no sense to me... |
A class with no virtual table (in Java, all classes by default have virtual tables [I think]) is more efficient in both space and time. If anything, Java's approach to final types beats C++'s, which will just let you inherit from a class without a virtual destructor without a peep from the compiler.
One thing I find that's pretty irksome about Java is the abundance of exception handling. It is the generally accepted error handling paradigm in the Java world, so not only do you have to do it when using the standard library, but also when using third-party libraries.
As an example, say you're going to read a text file that has some number in it that you want converted from a String to an int. You can do it the lazy way and just do
As an example, say you're going to read a text file that has some number in it that you want converted from a String to an int. You can do it the lazy way and just do
try {...} catch (Exception e) {...}. Or you can do it the "proper" way and catch FileNotFoundException, IOException, and NumberFormatException. Catching all these kinds of exceptions leads to code bloat.
Last edited on
code bloat... as in an extra couple bytes tact on to a source file? I'm not sure I see the big deal :P
Forget the obvious fact that one of the two categories of transportation is highly specialized and that both operate in different spaces and are bound by different rules and suitabilites for tasks. |
GC and manual memory management are bound by quite different rules, and are suitable for different tasks, so the analogy holds. Manual memory management is great if you have very little memory, GC is great in all the other cases. However, you are right, that the example with a car is wrong, because there is probably no malloc implementation even remotely close in performance to increasing a single pointer. The best malloc implementations require about 60 CPU cycles on average per malloc of a small object, for a single-threaded program (and default malloc in Linux / Windows require 100+ cycles, and this gets worse in case of multithreading). Contrary, Oracle's JVM requires 10 CPU cycles per allocation on average, so?
The guys from IBM describe in detail, why allocation in Java is much faster (and probably .NET, because most things for Java are true also for .NET):
http://www.ibm.com/developerworks/java/library/j-jtp09275/index.html
Add to that, that JVMs can now even eliminate some calls to new and replace them with stack allocation, making a cost of allocation essentially 0. I wish C++ compiler could do that, one common probem of library designers - "should this be passed through stack, or maybe I should return a pointer to a newed object?" would be solved.
When you tack on final to your class declaration the jvm does some optimization it can't do otherwise. |
Nice explanation, but completely wrong. Final has nothing to do with performance, maybe it had 10 years ago. Modern JVMs don't require that information to apply optimisations - forgetting to add final does not penalise optimisations in any way.
Two of the most important applications of final is implementing immutable classes and strenghtening security related stuff (e.g. so that you cannot override finalize method to bypass security checks in the constructor of the attacked class).
One thing I find that's pretty irksome about Java is the abundance of exception handling. |
Well, this is because Java has usable exception handling (could be better, but at least it is usable). Because it is ok, people just use it. C++ exception handling is troublesome, because it does not play well with manual memory management, it is hard to get exception-safety right, so programmers stay away from it as far as they can.
Last edited on
I taught myself java in two weeks. I never ever wrote a java program though. It taught me about oop :D.
| code bloat... as in an extra couple bytes tact on to a source file? I'm not sure I see the big deal :P |
Not a big deal, no. Fewer lines of code, without sacrificing readability of course, means a more easily-maintainable project. Sure, if there's a few isolated cases of a bunch of added lines here and there, there is no difference whatsoever. It becomes a problem when hundreds of lines are put aside just for that. And really, I just find it annoying when I add a line, compile, and then the compiler comes back and says "Exception (x) must be caught or declared to be thrown".
But hey, don't get me wrong, I don't hate Java, I just like C++ better. I wouldn't mind whatsoever if I had a Java job (I did for an internship).
Last edited on