Separate names with a comma.
Discussion in 'Indie Basics' started by Mashew, May 16, 2007.
Where did you get "Java" from my post?
I've started another thread on this.
Sorry, that was the language a few of us were debating. What language(s) did you have in mind?
Python or Ruby. Common Lisp perhaps.
Love Python, but I'd have to disagree with your previous assessment that we can get "exactly the same" results with these as C++. Acceptable, sure, but as much as I love Python it will never execute like C++.
The assumptions made by older low-level languages are largely out of date from a pure performance context. The reason why C/C++ is fast today is more because we've sunk time and money into making great optimizing compilers for it than because of the inherent properties of this family of languages.
See this article for some weight behind that point.
So there's no reason to use C/C++ if you haven't got a serious performance need right now. Plus with today's computing environments being increasingly virtualized and parallelized, it's better not to have to assume too much about the architecture if you can.
Of course, that doesn't change the facts of the matter today - that there's a mountain of momentum behind C/C++, and so they happen to be fastest most of the time. But it's probably only going to get harder to maintain an advantage due to diminishing returns.
We deal with the real world of who has actually shipped and improved what.
I'm not impressed. The article's points are pretty well debunked by the article's comments. I mean come on, whining about aliasing semantics?
Sure there is. Money.
Bunch of baloney. No reason to be planning for virtualization and parallelization unless you know for fact you need to do it. Speculative design in general is just dumb.
Java is a managed language. That alone makes it more high level than C++.
It's also very easy to identify bugs on the client side, which is imo a big plus. Eg during the webstart beta phase you don't have to do anything special. If it crashes people only need to paste/send the logs and then you know the kind of error and the exact location.
Whereas a similar thing for Inkscape (an open source vector drawing application written in C++) looks like this:
-find a way to crash it (if it isn't reproducible you have a problem)
-download the symbols file for this build
-start gdb with a ~250mb symbols file
-wait even more
-reproduce the crash (performance is heavily degraded and ram usage is very high)
And then you get some backtrace which may or may not give you some indication where the problem might be. What a massive waste of time.
Read the thread again. If you can reach your performance goal (eg 6 year old hardware) with less effort, then you get more money per hour. That's very simple math.
I think we have different definitions of what "high-level" means. I roughly equate it to the amount of code one has to write to accomplish a task. Machine code is the lowest level. Then comes assembly, C, C++/Java/C#/Pascal/etc., then the scripting languages like Ruby, Python, Lua, etc.
If you want to argue that Java has more features built into the core language and libraries, that's a fair point. But if I give two competent programmers a task to complete -- one in Java, one in C++ -- I would expect that both would be done in roughly the same amount of time. It's just that the C++ programmer would be using 3rd party libraries to accomplish some tasks.
That's a very platform-specific argument. I can write a C++ program that uses the Windows Event Log, and reporting problems is even easier than what you just described. That is not a language feature at all.
Sure. I think he's saying that you're much more likely to reach older hardware platforms using C++.
You don't believe that yourself, do you? Nice try tho.
It's xplatform with Java. And yea, if you write a handful extra lines you can automatically send those stacktraces over. Very easy and xplatform.
But even if you don't do those extra steps you get an easy way to pinpoint problems, which happened on the other side of the globe.
Just for repeating myself again... if it runs fine on 6 years old hardware, it's fast enough. Making it work on even older hardware won't offset the additional costs and it will even result in a massive loss (in comparison) if you don't port it over to Mac. D'uh.
Read the thread again yourself. The vast majority of game industry jobs are C++. Core middleware technologies like 3d and physics engines are done in C++. You need to consider how you're going to pay your bills. The speed of your personal development isn't the only consideration. Does your personal development pay the bills? If not, do you want to write web servers?
Why are you so combative about this? I'm wondering if you have much experience with C++ when you make statements like this.
So? A different task requires a different tool. What makes it so hard to understand?
I'm not. It's just... one cannot take arguments like that seriously. Are you aware of all major factors, which make you more productive with Java?
Here is a quick rundown:
1. Memory management. No memory leaks, no dangling pointers, no hard to track glitches etc.
2. Good error messages from the compiler. (Yes, I pretty much started with C... I know how bad error messages look like. Thank you.)
3. Very helpful error messages if something goes wrong at runtime.
4. Code conventions, which are actually used by pretty much everyone and his dog.
5. Standardized documentation. And again most people follow those (sensible) guidelines.
7. Cutting the edge IDEs for free.
8. Security. There simply are no buffer over-/underruns. (It's a very nice side effect of point #1. But that alone saves so much time that it's worth an extra bullet.)
9. A very powerful standard API, which is actually used by everyone.
10. It's xplatform.
[11. Embedding scripting languages is a piece of cake and there is no glue code required.]
[12. Compiling is quicker.]
The usual reported productivity gain ranges from a factor of 2 to 5. And yea, those figures are from very experienced C/C++ programmers.
Sun pumped a lot of money into it and they made excellent choices most of the time. It's nowadays truly a great language, which corrects most mistakes of older programming languages.
Feel free to try it for yourself.
Java programmers still have to worry about leaked references and null pointer exceptions. Resource leaks, too. C++ programmers can use garbage collectors if they like, smart pointers, RAII, STL containers, etc. I favor C++ because of its flexibility in this regard.
These are tool qualities, not language qualities.
Are you suggesting that the C++ community doesn't have documented best practices?
Eclipse is a bloated piggy application, although it is feature rich. But of course it has plugins for C++, Python, etc. And CodeBlocks for C++ gets rave reviews from the C++ community, and Dev-C++ did before it. Both free. Anyway, I'm far less productive in and IDE than I am in GVim. I'll debug in an IDE, but when it's time to type in code, I can't stand the small windows, point/click/type, hints and command completion, etc. They just get in my way.
That is nice, but it's One Size Fits All and leads to a bloated, ever-changing platform.
That's a spurious claim. I'd like to see what kinds of problems were being solved by whom.
Used it for years at several client sites. I prefer C++ by a large margin. You prefer Java. And yet, the world still spins.
Yes, you can write lots of non-standard extra code and you get some stone age gc-scheme. Reference leaks are rarely an issue and if a NPE is thrown, you know where it happens. Easy to fix.
It's default with Java. And it's a nice advantage.
There are many different styles and conventions in use (the same is true for many other languages). And Java... well, 99% use Sun's conventions, because it's more effective if everyone uses the same (reasonable) conventions.
Again there is no standard. The documentation looks different everywhere. This costs time.
Dev-C++ was bloody awful.
The Eclipse plugins for other languages aren't as advanced afaik.
Btw the nice thing about powerful IDEs is the refactoring stuff. Doing that kind of thing manually is lots of error prone work.
Yes, it's a bit bloated (but it's very organized... you'll rarely take a look at stuff you don't need). No, it isn't ever changing.
The bloat will be addressed with the client vm tho.
Google for: java productivity
But even with no productivity gain at all you'll still get xplatform support and C++ still loses the ROI battle.
Well, it's a breeze to work with. So far it's (by far) the nicest language I've ever used.
I just think that wanting to using C++ for everything is a bit silly. It's like always using a Ferrari (which takes lots of gas and maintenance), because it's so fast... well, it isn't any faster in a city. If you catch my drift.
I don't use C++ for everything - that's why God invented Python. ;-)
I'm not going to keep going point-counterpoint. It's obvious we're both happy with and productive with the languages we choose. I'm also fairly certain, given the short history of programming, that there's plenty of room for several languages to co-exist for a long, long time.
I wouldn't call MS Visual Studio lean and mean.
Code::Blocks holds promise, but it's not commerically viable yet. Its developers can't even manage to put together a proper binary release. In this respect, comparing it to Eclipse is specious. Eclipse is industrially proven and has huge amounts of money dumped into it from big companies. Nobody's going to trust enterprise development to Code::Blocks, but they can certainly pick between Eclipse and MS Visual Studio.
Compared to Eclipse it is.
Today. While I was playing Runescape. (Oh no! Not Runescape!), I thought of something. Here it is: "Wow. This whole game is made in Java." That just shows how expansive and powerful Java is. Sure, not very good graphics but, still pretty amazing.
Java wins. hehe.
(C++ is for later. )