Java will exceed the speed of a C++ program in many cases nowadays. I worked for a large insurance company and we had to prove to them using benchmarks that Java was faster.
Yes... and I was implicitly asking readers to provide me with better information... which you sort-of have. But I'd really like to be able to see some side-by-side comparisons (if one isn't strictly faster than the other, then where are the differences showing up?).
You're avoiding the issues of real-world development also. What is the expense of a memory leak? You can claim that they also can exist in Java but as we all know in C++ they are a constant problem--especially for the newbie programmers.
No, I believe I explicitly addressed that the strengths of Java weren't technical strengths. We're agreeing on this point, really. Though, I am a firm believer in the RAII idiom in C++, which really makes C++ a lot simpler once you get used to it... but yes, it's a higher bar to start with, especially for newbie programmers. And it's certainly something I never heard about in school (whereas I learned about garbage collection algorithms as a freshman).
Are you proud that it's so easy to create a memory leak in C++?
Nope. But there are strengths to using C++'s model that Java users tend to ignore. RAII allows you to manage any resources, not just memory. I think Python has the best setup, though: garbage collection with deterministic destruction, which lets you use RAII without forcing you to manage your memory (though you still have to think about it, since the GC isn't as advanced as Java's, and gets stuck on cycles when destructors exist unless you explicitly use weak references, IIRC).
Frameworks like Hibernate allow you to cache the results of SQL calls so that if the same SQL is reissued (even between different users) the cache reads the result, not the database. Usually you can pick which calls are cached versus which ones have to be live.
Also consider looking at something like memcache, which is a very fast distributed caching mechanism. You can use it to cache more than just SQL queries, too.
Then why are all these companies standardizing on Java? You think you're brighter than all these corporations? I doubt it. C++ is dying and I say good riddance.
Most companies standardize on Java not because it gives them a higher "maximum power", but because it gives them a higher "minimum power". The language as a whole is designed (whether intentionally or not) to reduce the damage done by less-than-stellar programmers, which is more important to a business than increasing the power of the superstar programmers.
Plus, you don't think Sun puts out all of the Java marketing buzz for nothing, do you? Java is sponsored by a corporation, and connections like that make a big difference to managers. While it may be a good thing for many companies to standardize on Java, they're not doing it because Java has an ounce of technical superiority.
I haven't done any personal testing, but I'm under the impression that speed-wise C/C++ stack > Java (everything is on the heap) > C/C++ heap. Since realtime Java code seems to encourage disabling garbage collection, that seems consistent. So yeah, you might be able to tweak out your speed by avoiding the heap in some cases, but I'm not sure. Maybe someone in the hard-real-time environment can enlighten us on that.
that "open, free" internet was just a bunch of sites that were created out of curiosity and created in mostly academic institution infrastructures. without ads internet wouldnt be the trans-national concept it is today.
Yeah, because without ads, sites like Amazon.com wouldn't make a bajillion dollars selling things online in a trans-national market. It's ad revenue alone that keeps them alive. Yup.
You know what? Sites like The Krib are a relic nowadays... that's the sort of content that most of the interesting parts of the WWW used to contain. I was happy with it back then! "Shoot the monkey" advertisements and selfishly duplicated content (uhh... wikipedia text showing up on hundreds of different ad-laden sites?) don't add any value.
Except for slicing if you're dumb enough to actually cast to the object type itself. Of course, in the real world, you do everything with pointers (which is the only way to get polymorphism anyway)...
Yeah, slicing sucks... but slicing, dangling pointers, and reference counting are all entirely orthogonal to the concept of abstract-classes-as-interfaces. Java could have implemented interface Foo { void doFoo(); } as abstract class Foo { void doFoo(); } or class Foo { void doFoo() = 0; } without changing how they work.
Imagine implementing + and += operators for everything that implements the base class, even though the += operator always looks exactly the same.
Actually, stock operator overloading is a prime example for the Curiously Recurring Template Pattern. Boost probably has a library somewhere that does this already, but you can do something like
template <class Derived>
class Addable
{
viritual ~Addable() {}// C++ boilerplate
// requires operator+= to be defined
Derived operator+(const Derived &other) {
Derived sum(*this);
this += other;
return other;
};
class Number : public Addable<Number> { // viola! if we define +=, + comes "for free"
};
The main benefit of Java interfaces is that you can have a single class implement multiple interfaces without having to resort to something like C++'s multiple inheritance. So the Monkey class can also implement HairyInterface, EvilInterface and SlingInterface.
The main benefit of C++ abstract classes is that you can have a single class inherit from multiple abstract classes without having to resort to something like Java's interfaces.
You think multiply inheriting from a bunch of C++ abstract classes is somehow worse than implementing multiple Java interfaces? Abstract classes are interfaces, and inheriting from an abstract class is identical to implementing an interface. All of the problems you hear about for the evils of multiple inheritance go away when you start talking about pure abstract classes. There's no worrying about "which parent class method will be active when they have identical signatures" since there aren no parent methods.
A lot of that is scripts that load a lot of code that is parsed, loads a lot of other code that is also parsed, and then finally, after 50 to 100 or more files are loaded and parsed, it gets around to actually starting to DO something.
Personally, that's why I avoid PEAR... Any PEAR solution is general enough to work for most people, but far bulkier than a hand-tailored solution, and generally notorious for dividing code out into about 5 bajillion scripts. If you want to generalize something and keep it fast, do it in C and export it as a PHP module like PECL. In any case, the cost of excess mandatory includes can be significantly reduced by a script-caching engine like APC.
Then there's the problems of concurrency, etc., which get worse the more cpus you throw at a problem, which is why throwing more servers into the mix doesn't scale linearly.
Typical PHP apps pretty basic, and pretty easy to parallelize. The "hard" concurrency is all in DB land, and it doesn't matter if 100 different processes are connecting or one process is connecting 100 times; it's going to look the same to the DB (minus TCP overhead, but if you're worrying about TCP overhead, stop using scripting language!). Throwing more servers at the problem will scale it very well, provided the DB is fast enough. It's not the same as more CPUs on a single server; there's much less contention between processes on a server farm than processes on a single megalomonster computer.
The same can be said for server loads - page generation is going backwards in terms of cpu usage. I've seen php scripts that end up #including almost 100 other scripts ON EVERY PAGE LOAD!!!
It may brighten your day to discover that a well-optimized site can still include a lot of scripts and avoid latency due to script caching engines like APC. Actually, the best-case scenario for something like APC is a script that performs 0 conditional includes: everything up at the top, always the same, so that it can precompile as much as possible. It's the same notion as using Precompiled Headers in MS Visual Studio to speed up your build time. Rasmus Lerdorf works like a fiend to optimize syscall count in PHP, particularly with APC and initial script loading.
Remember all that about premature optimization being the root of all evil. If you haven't measured the relative cost of all of those includes, you can't make a blanket statement about HOW HORRIBLE IT IS!!!!
So, you would rather write code and tests rather than code and comments?
Sounds to me like more work and less information available for the poor fool who has to maintain that code after you leave.
Tests are typically better documentation than inline comments, because
it's easy to verify that they are correct (if the test suite runs, they are correct)
they provide a wealth of examples of how to use a piece of code, likely moreso than any comment will
The things that you can't capture in code or tests is semantics. Who cares what the syntax of a function is, if I don't understand its purpose? Someone's inline comments aren't going to do that. It's going to be a combination of
intention-revealing function/class/variable names (what tells me more about an accounting system? plus5(x) or plusServiceFee(cost)?)
architectural documentation. Not API-level documentation. Design documentation discussing what the entire piece of software is the way it is (is it set up as a chain of pipes and filters? why? What information goes through the pipes, and what do the filters do?).
If it confuses you to see "and", "or", and "not", that should make you sad (like the "I don't understand relationships between code and language" sort of sad). Though, I fully agree with you on the blocks (begin/end isn't any more logical than {/}).
I mean honestly, you shouldn't have overall architects who haven't actually written code before. They will absolutely fudge the software requirements because they really don't know what they need to get the job done.
That's why I never understood why the Architecture group at Lockheed Martin was actively pursuing people who have neither any programming experience nor any desire to learn algorithm fundamentals. Federal tax dollars paying for designs that are being created by people who don't have the foggiest idea of how to implement those designs:(
If one player was, for example, massing carriers, one strategy that often worked was to sneak up (or unhide) a devourer which would cast dark swarm (no hits from air) and then plague... End-result is that the rush fails nicely.
Calling massed Carriers a rush is like calling a Beowulf cluster your laptop.
Chess, go, checkers, and tic tac toe are really the only offline games that can be learned such that a game cannot be lost.
I Am Not A Go Player, but I'm under the impression that it's rather hard to solve Go automatically. The search space in a game of Go is so huge that it's akin to brute-forcing cryptography (^:
Also, you should add Connect 4 to that list. A computer algorithm (or a perfect player) that starts the game can be guaranteed to win.
Since camera makers dropped the ball and don't have easy intuitive image tagging capability built into the camera.
I wouldn't say camera makers have dropped the ball... I'd say you're just looking at the wrong ball. Canon, Nikon et al are coming out with fantastic low-end DSLRs with "easy intuitive" controls for ISO, aperture, shutter, white balance... things that are important for taking pictures. Adding tagging directly to the camera would either mean a clunky typing interface (not enough buttons), an expensive and fragile touchscreen, or an expensive (both $$$ and electricity) speech recognition chip.
I'm happy with a camera that does a really good job at taking pictures. Leave the tagging for some software "image productivity" suite.
Well, if you're the type that can think of putting access to/etc/passwd into, say, an object that's destroyed just before dropping root, then you can probably think of a way to prevent yourself from calling dangling pointers too.
Can you do both at the same time, while dealing with dozens of other headaches? Do you really want to? There's something to be said for reducing the programmer's mental workload so he can more efficiently think about the problem he's supposed to solve.
The grandparent is referring to the idiom Resource Acquisition Is Initialization, which is common in C++ (and other languages with deterministic destruction) for helping a programmer to manage resources without having to think too hard about it. The cost of RAII is that it takes more time to plan resource management in the first place; in this example, you'd have to create a wrapper class that handles opening and closing/etc/passwd.
The benefit is that when you go to use that wrapper class, you can think about problem you're supposed to solve, since the resource management is already taken care of. As a programmer, I don't want to be thinking about these low-level details when I'm working with the high-level behavior. I even specifically use a RAII wrapper around glPushMatrix() and glPopMatrix() in OpenGL so I don't have to worry about the low-level details. Even though it sounds like more planning, it's more shallow planning, and it really does help with my mental workload.
Random needs to be impossible to predict, statistically uniform and capable of producing any number
I believe you mean uniform random. In any case, a non-uniform distribution would allow prediction, so my original statement (unintentionally) implies uniform.
Actually, unpredictability is what makes something random. If you could devise an algorithm to predict future bits in an infinite sequence, the success of that prediction would imply that the sequence lacks randomness. Randomness = Unpredictability = Incompressibility
just because it is 'impossible to predict' doesn't mean there's not a pattern to it that humans are just too dumb to figure out!
Actually, "impossible to predict" is precisely what random is. "Very hard to predict" is rather different from "impossible to predict" in the same way that md5 hash collisions are rare, but possible.
If it's based on something (Anything!) then it isn't truly random.
What if it's a random stream based on another random stream? It's possible to make the output impossible to predict (though in reality you're far better off using the original stream).
OK there is plenty of good software in other languages, but ugly, boring PHP seems to be doing very well.
The same could be said of C (vs. Lisp). The subject has been talked about plenty before, under the label Worse is Better. The general idea is similar to time-to-market. A product (in this case, a language / compiler) doesn't have to be perfect, it just has to be good enough. The perfect solution will always fail to be the popular solution, because of the effort required to produce it.
Now, that doesn't mean that the popular solution really is better. Paul Graham made a killing with Lisp specifically because he went against the popular solution at the time. It's no wonder that Lisp and Smalltalk are more popular in the academic community than in the professional (where Java is the order of the day... blechhh).
Any one who still complaining about PHP is definitely not "experienced" neither in PHP nor programming at all. because PHP is in most cases powerful enough!
It's not always an issue of being "powerful enough". All general-purpose languages are essentially Turing-complete, which means they're all identical power-wise. I think PHP is a great tool for web applications, but it has a lot of weaknesses in comparison to other languages. Sticking your head in the mud doesn't mean that the weaknesses don't exist.
Slashdot Mirror
Patently false!!! It just silently truncates data. That's not a bug, it's a feature!
Speaking of languages supported by VS, which of the following do you mean?
What?
Yes... and I was implicitly asking readers to provide me with better information... which you sort-of have. But I'd really like to be able to see some side-by-side comparisons (if one isn't strictly faster than the other, then where are the differences showing up?).
No, I believe I explicitly addressed that the strengths of Java weren't technical strengths. We're agreeing on this point, really. Though, I am a firm believer in the RAII idiom in C++, which really makes C++ a lot simpler once you get used to it... but yes, it's a higher bar to start with, especially for newbie programmers. And it's certainly something I never heard about in school (whereas I learned about garbage collection algorithms as a freshman).
Nope. But there are strengths to using C++'s model that Java users tend to ignore. RAII allows you to manage any resources, not just memory. I think Python has the best setup, though: garbage collection with deterministic destruction, which lets you use RAII without forcing you to manage your memory (though you still have to think about it, since the GC isn't as advanced as Java's, and gets stuck on cycles when destructors exist unless you explicitly use weak references, IIRC).
Also consider looking at something like memcache, which is a very fast distributed caching mechanism. You can use it to cache more than just SQL queries, too.
Most companies standardize on Java not because it gives them a higher "maximum power", but because it gives them a higher "minimum power". The language as a whole is designed (whether intentionally or not) to reduce the damage done by less-than-stellar programmers, which is more important to a business than increasing the power of the superstar programmers.
Plus, you don't think Sun puts out all of the Java marketing buzz for nothing, do you? Java is sponsored by a corporation, and connections like that make a big difference to managers. While it may be a good thing for many companies to standardize on Java, they're not doing it because Java has an ounce of technical superiority.
I haven't done any personal testing, but I'm under the impression that speed-wise C/C++ stack > Java (everything is on the heap) > C/C++ heap. Since realtime Java code seems to encourage disabling garbage collection, that seems consistent. So yeah, you might be able to tweak out your speed by avoiding the heap in some cases, but I'm not sure. Maybe someone in the hard-real-time environment can enlighten us on that.
I dunno, but if you find one, please share with the rest of us!
Yeah, because without ads, sites like Amazon.com wouldn't make a bajillion dollars selling things online in a trans-national market. It's ad revenue alone that keeps them alive. Yup.
You know what? Sites like The Krib are a relic nowadays... that's the sort of content that most of the interesting parts of the WWW used to contain. I was happy with it back then! "Shoot the monkey" advertisements and selfishly duplicated content (uhh... wikipedia text showing up on hundreds of different ad-laden sites?) don't add any value.
Yeah, slicing sucks... but slicing, dangling pointers, and reference counting are all entirely orthogonal to the concept of abstract-classes-as-interfaces. Java could have implemented interface Foo { void doFoo(); } as abstract class Foo { void doFoo(); } or class Foo { void doFoo() = 0; } without changing how they work.
Actually, stock operator overloading is a prime example for the Curiously Recurring Template Pattern. Boost probably has a library somewhere that does this already, but you can do something like
The main benefit of C++ abstract classes is that you can have a single class inherit from multiple abstract classes without having to resort to something like Java's interfaces.
You think multiply inheriting from a bunch of C++ abstract classes is somehow worse than implementing multiple Java interfaces? Abstract classes are interfaces, and inheriting from an abstract class is identical to implementing an interface. All of the problems you hear about for the evils of multiple inheritance go away when you start talking about pure abstract classes. There's no worrying about "which parent class method will be active when they have identical signatures" since there aren no parent methods.
Personally, that's why I avoid PEAR... Any PEAR solution is general enough to work for most people, but far bulkier than a hand-tailored solution, and generally notorious for dividing code out into about 5 bajillion scripts. If you want to generalize something and keep it fast, do it in C and export it as a PHP module like PECL. In any case, the cost of excess mandatory includes can be significantly reduced by a script-caching engine like APC.
Typical PHP apps pretty basic, and pretty easy to parallelize. The "hard" concurrency is all in DB land, and it doesn't matter if 100 different processes are connecting or one process is connecting 100 times; it's going to look the same to the DB (minus TCP overhead, but if you're worrying about TCP overhead, stop using scripting language!). Throwing more servers at the problem will scale it very well, provided the DB is fast enough. It's not the same as more CPUs on a single server; there's much less contention between processes on a server farm than processes on a single megalomonster computer.
It may brighten your day to discover that a well-optimized site can still include a lot of scripts and avoid latency due to script caching engines like APC. Actually, the best-case scenario for something like APC is a script that performs 0 conditional includes: everything up at the top, always the same, so that it can precompile as much as possible. It's the same notion as using Precompiled Headers in MS Visual Studio to speed up your build time. Rasmus Lerdorf works like a fiend to optimize syscall count in PHP, particularly with APC and initial script loading.
Remember all that about premature optimization being the root of all evil. If you haven't measured the relative cost of all of those includes, you can't make a blanket statement about HOW HORRIBLE IT IS!!!!
- it's easy to verify that they are correct (if the test suite runs, they are correct)
- they provide a wealth of examples of how to use a piece of code, likely moreso than any comment will
The things that you can't capture in code or tests is semantics. Who cares what the syntax of a function is, if I don't understand its purpose? Someone's inline comments aren't going to do that. It's going to be a combination ofCalling massed Carriers a rush is like calling a Beowulf cluster your laptop.
I Am Not A Go Player, but I'm under the impression that it's rather hard to solve Go automatically. The search space in a game of Go is so huge that it's akin to brute-forcing cryptography (^:
Also, you should add Connect 4 to that list. A computer algorithm (or a perfect player) that starts the game can be guaranteed to win.
I wouldn't say camera makers have dropped the ball... I'd say you're just looking at the wrong ball. Canon, Nikon et al are coming out with fantastic low-end DSLRs with "easy intuitive" controls for ISO, aperture, shutter, white balance... things that are important for taking pictures. Adding tagging directly to the camera would either mean a clunky typing interface (not enough buttons), an expensive and fragile touchscreen, or an expensive (both $$$ and electricity) speech recognition chip.
I'm happy with a camera that does a really good job at taking pictures. Leave the tagging for some software "image productivity" suite.
The grandparent is referring to the idiom Resource Acquisition Is Initialization, which is common in C++ (and other languages with deterministic destruction) for helping a programmer to manage resources without having to think too hard about it. The cost of RAII is that it takes more time to plan resource management in the first place; in this example, you'd have to create a wrapper class that handles opening and closing /etc/passwd.
The benefit is that when you go to use that wrapper class, you can think about problem you're supposed to solve, since the resource management is already taken care of. As a programmer, I don't want to be thinking about these low-level details when I'm working with the high-level behavior. I even specifically use a RAII wrapper around glPushMatrix() and glPopMatrix() in OpenGL so I don't have to worry about the low-level details. Even though it sounds like more planning, it's more shallow planning, and it really does help with my mental workload.
Actually, unpredictability is what makes something random. If you could devise an algorithm to predict future bits in an infinite sequence, the success of that prediction would imply that the sequence lacks randomness. Randomness = Unpredictability = Incompressibility
The same could be said of C (vs. Lisp). The subject has been talked about plenty before, under the label Worse is Better. The general idea is similar to time-to-market. A product (in this case, a language / compiler) doesn't have to be perfect, it just has to be good enough. The perfect solution will always fail to be the popular solution, because of the effort required to produce it.
Now, that doesn't mean that the popular solution really is better. Paul Graham made a killing with Lisp specifically because he went against the popular solution at the time. It's no wonder that Lisp and Smalltalk are more popular in the academic community than in the professional (where Java is the order of the day... blechhh).