The truth is that I made a Yahoo in an hour of programming PHP, but people can freely add categories themselves and add content to the
categories. There is even a 'rank this item' community rating system that averages the individual votes.
And I'm sure it scales to tens upon tens of users--bah, who needs this worldwide presence?! Congrats!
I'm going to snap if I hear another "Bring back the old games, they were so much better". Sheesh--it's just a matter of time before somebody mentions _Elite_ as the end-all/be-all space trading game.
The fact is that progress is good. Nobody mentions how hard it was to orient yourself while docking with non-texture mapped polys in _Elite_, along with nobody ever mentioning how the end of _Wasteland_ could have been more fufilling with a short movie.
Sigh, it's easy for people's psyche to wash away thousands of crappy C-64/2600 games, but then unforgivable for a new game to be too complicated.
I have to admit that I always thought the old school RPGs were the best, these unassailable, unimpeachable titans of the field: _Bard's Tale 3_, _Wasteland_, _System Shock_, but then I played _Planescape: Torment_. Not "along them same lines", not "just as good", but "better". That in itself has revived my belief that things really do get better.
Java isn't platform independent, it is a platform unto itself, and a proprietary one at that. Just try making use of OS-specific features from a Java program, or doing platform-appropriate things that weren't envisioned by the original designers of the Java platform.
First of all, we should be clear what we're discussing: Java the language, or Java the platform. Obviously the language is platform independent, with the VM running on each machine being tied to a platform.
And on that note: lowest common denominator is the tradeoff for portability. And yes, there's unix-isms like System.out and System.err which irk the Mac people, but it still works for the most part, even if it's a little weird in spots. I haven't seen hordes of Mac java programmers screaming for blood because there's some Unixy stuff in Java.
For example, the javax.comm package for serial communications has an API for enumerating the names of the serial ports.... But on Macintosh, you get the words "printer" and "modem".
So? For the most part, "javax." is platform dependent. "java." is platform independent. While pure java is preferable in terms of portability, native code is fine as well, which is the point of the javax system. If lowest common denominator isn't good enough, use javax: but then don't be so quick to complain when it returns platform specific values.
If you want to see true platform independence, check out the ZooLib cross-platform application framework. ZooLib allows you to write a single set of C++ sources and compile them to native executables on Mac OS, Windows, BeOS and Posix flavors with XWindows such as Linux.
While this sounds cute, there's no programmer reference available so I can quickly compare the available APIs between it and JDK1.3. The high level feature list has some nice things (the threads), but really, most of that stuff has come for free since Java 1.0, and more: 2D/3D graphic APIs, impressive international support, CORBA, _and_ it runs in a browser.
Your basic philosophy should be that it's impossible to convince yourself of the correctness of the synchronization through testing. If you can't prove that your synchronization is right, it's most likely wrong. And if it's not wrong, it's so complicated that you'll break it later because you don't understand it.
These are the words that should be written above the gates to the hell of multithreaded programming. Do not pass beyond these walls without understanding what they mean.
Simplicity is paramount to this. If there is only one place that requires a lock, and everything is firewalled behind it, then you only need to ensure that single place works for all threads. The nastiness comes when threading is pervasive throughout the system, where there is no clear concept of object ownership between threads.
The VS debugger is nice, yes, and it'll beat GDB or DDD in a feature comparison anyday. However, for 95% of the debugging tasks that I need to do, they're equivalent. Set breakpoints, set watches, get stack traces--the other stuff is nice but hardly necessary.
Looks to me like it is still in beta. I strongly doubt that we would have more platforms if we had used Java.
Certainly, if you require JDK1.2/JDK1.3 features, you'll be limited somewhat. Although, IBM lists AIX, OS/2, OS/390, and AS/400 as JDK1.3 capable. (http://www.ibm.com/java/jdk/index.html). Of course, Solaris runs 1.3. HP/UX is 1.3 capable, as well. If you can get by with JDK1.1 features, that opens up far more platforms (IRIX 5, IRIX 6, NetBSD, OpenBSD, VM, MVS, etc)--and I'd venture to say that's pretty close to the edge of "runs everywhere"
Sadly, yes, there is no FreeBSD port for Java 1.3 yet. It's a bummer, I agree.
This is not even counting the fact that we developed faster in Python than we would have in Java
Please, no offense meant, but I think the important thing is that you've implemented something faster in Python, where that 'something' has the qualities: runs on 4 platforms, has a Web UI, and a relatively difficult setup/install. Time will tell if those given qualities will yield the Next Killer App (I, of course, hope it is).
And this isn't counting the fact that the standard libraries that we used are in C/C++ and are very mature and widely supported than their Java equivalents.
I'd be interested to know how much time Mojonation spends doing crypto vrs how much time is spent in I/O. (I really am wondering--not trying to be offensive here) My mojonation python processes (on my ppro200) never seem to spike badly. Is there some point where the native code/interpreted code tradeoff wouldn't be so bad?
As to your comments about UI, I have to defer to your authority as a user. Personally, I like the HTML UI, and I would much rather have an HTML UI than an actual widget UI, but apparently most users in this world disagree, so you are right -- we should provide the latter.
I think MojoNation should be as simple to use as Napster: Click here to share Porn & MP3s. People will love it, and I think that's what drives user acceptance.
In any event, I think that this has been constructive. I've learned some more about Python, at the very least. This definately highlights the need for keeping abreast of other technologies, as to see what features they can bring your application. (I for one, didn't know about the extent of Python's dynamic loading capabilities)
I firmly believe that we hackers at Evil Geniuses For A Better Tomorrow could not have implemented Mojo Nation as quickly as we did if we had been using Java instead of Python.
I'm going into Computer Engineering, so I'll only be programming drivers.
Thank god. The software engineering field dodges another bullet.
Re:Mozilla going after the Net-appliance market?
on
Mozilla .6 Released
·
· Score: 1
But is it plausable they included it all because they were looking at it more with the intention of it being used in Net-appliances that don't really have a native OS GUI, and to have the web, news, mail, irc as ONE monolithic piece of software for the appliance?
Yeah, as soon as you get a net appliance with 128MB of memory, plus some disk for swapping, then cool! You can browse the web!
Well its nice that you mention that garbage collection is available in C++: that means two things. For those who want it- its there. For those who dont- you dont have to take its overhead.
Boehm also lists some nice papers on GC overhead. For example, check out Detlefs, Dosser and Zorn's Memory Allocation
Costs in Large C and C++ Programs. Boehm brings up the point that most of the overhead is caused by a GC replacing a traditional new/delete pair, and that possibly you'd get back all of that hit if you just write programs that take advantage of the GC rather than using it as a simple new() replacement.
I'm not sure what you mean by two instances in one chunk of memory- I do however use shared buffers with reference counts.
Say you have an object with a couple pointers to dynamically allocated memory. If you
make a copy of that object (say you pass by value instead of pass by reference), then you'll have 2 copies of the pointer to the one dynamically allocated chunk of memory. If that happens, you won't know when to safely delete the memory.
Could even be a little template class if you fancy having all types of shared objects. I never get into massive amounts of overloaded operators.
I like Myer's More Effective C++ book's treatment of these. I use them too.
About "your program doesnt work"- the idea was that the developer would use leak detectors, to verify that his disciplined code does not actually leak. Even if it does have a leak in a strange place- that will hardly make it crash or anything- you may just have to restart it after a long time running. And while this buggy program runs it will probably be fast.
Certainly true, but leak detection isn't the easiest thing to do all the time, right? I like Purify as much as the next guy, but while it does a ton for you, it's difficult to verify that in all cases, with all input, your program won't leak. And come on, since when did restarting a program to fix a bug become fashionable?;)
And while this buggy program runs it will probably be fast.
You honestly don't think that this is a good thing, right? Don't ever tell this to a customer.
About memory bloat: its choosing between caching lots of objects that you may or may not use again and constantly creating them anew. Either way has a draw back and an advantage.
Java recently added a very nice soft-reference system (a hook into the GC), which allows you to make memory-sensitive caches. This gives you the best of both worlds: you can keep a cache of objects around, but if your heap size runs low, the GC will throw out objects out of your cache first (to allow new objects to have some memory).
The new() operator itself in C++ isn't 'free' either (pardon the pun). Creating objects is an expensive proposition. You should cache objects and reuse them in C++, as well.
Another nice advantage of C++ programming: many programs dont even need to use the heap whatsoever Everything on the stack and maybe a static global or two. In java you have references on the stack to things that are on the heap- needed or not.
It is nice to make little mini-stack objects, on occasion, yes. However, there is also some comfort in having a single creation point for objects (Java's new()): you never have to worry about returning references to local objects. You never have to worry about mistakenly creating objects during method calls (if you pass by value, or if a conversion constructor is called). In java, a reference to an object is always valid (or, of course, it's null). By letting object scope be global always (rather than C++ allowing you to choose between global or local scope), you eliminate a bunch of nasty little errors. Plus, you can apply the same GC optimization strategies to this as well: if you'd like a local object, simply pull one out of the pool/cache that you've created, and use it. Return it to the cache when done. Or, maybe you don't want to return it until a later point--you can easily do that, as well.
you can fix them in development time by detecting them.
Isn't this the same as saying "To write bug-free software, merely write software with no bugs in it?"
Especially easy to avoid if you confine new/delete to constr/destr. Makes it much easier to find memory leaks than in classic C, because you only have to consider class scope for the use of that memory. Toughest part is when destructors dont get called properly- but you get used to that one.
Yes, yes, it's nicer than C, but then what if you need to share objects? Two instances of an object, but only one chunk of memory? You don't want to double-free, nor do you want to free out memory that the other copy is using. Ah, that's when you pull out the reference counted smart pointers. But those aren't so great all the time either: every pointer access (method & fields!) requires extra steps, the bookkeeping is expensive itself, and if you like hiding the fact that you're ref counting behind a envelope/letter structure, it fucks up your inheritence tree (since you have a handle->implementation pair for every class, where normally you'd just have an implementation). All this time, be sure to pass all objects by reference so that ctors aren't called during method calls, and don't return references to local objects from methods. What a pain! And lets not even mention the hellish nature of exception handling or thread safety. auto_ptr, anyone?
Compare that to the memory bloat problem: no real way to duck that one without taking a hit somewhere else.
Explain. Just don't create objects as much. Re-use them. Make pools and caches.
Sure you program works- but what is people biggest complaint about it now: slowness.
Isn't this a far better complaint than "Your program doesn't work"?
To optimize the memory handling of a GC'd language program is tough and non-trivial. And since the code is all technically correct- there is no objective way to know that you have really fixed the problem.
How so? You see where all objects are created--you see where they're stored--simply cache frequently new()'ed objects. OptimizeIt for Java has a very fine heap analysis program which shows which objects are taking up most of the heap, and where they were allocated (all the while, remember: it's not finding bugs, your program is working the whole time). And for an objective way to tell if you've fixed the problem: what's wrong with vmstat or top?
Whereas with a typical compiled program, once there are no memory leaks, any optimizations are pure bonus- and usually very easy to figure out how to do/implement.
I'd say it's much easier to optimize GC'ed languages. Need a local reference to an object, but don't want to worry about memory leaks? Go ahead, copy the reference. Want to cache objects, but don't want to run Purify again? No problem: just create a pool and hold onto another reference. Sling pointers (oops, references) around with wild abandon: it'll all be fine. Once you're freed from having to worry about memory lossage, you'll have a bunch of time to work on the important optimizations: your algorithms. And that's what's really important, right?
You don't even need to resort to Java in order to bask in the luxury of Letting The Computer Work For You. Try the Boehm collector for C/C++. It compiles for Linux & Win32 among others. Just subclass your objects from 'GC', and then just new() new() new(). And don't worry about delete(), ever again.
Unfortunately, you kind of get screwed on requiring double the memory, which could really hurt for a Java VM (for example). We run our servers close to the GC edge with 256 MB heaps. Though, to be fair, we run with big heaps to minimize GC thrashing, which hopefully copying collection would help with.
I don't know if you can hack a copying collection scheme onto a pointer dirty language like C/C++ though, since you'd need to twiddle pointers during cleanup (AFAIK). That's one definate advantage of a mark/sweep system.
Most of them learn one language well, and think its the solution to all problems.
A simple adjustable wrench is the solution for tightening and loosening just about every nut. For the hard to reach nuts, or the ones with a weird shape, you pull out the special wrench. Once done, you put that special wrench away and go back to the simple one that works the best.
How could you not win everyone over with such a persuasive and well reasoned argument?
When are people going to learn that language advocacy is half about pushing your favorite language, and half about the gorgeous flame wars?
Oh, and by the way, such _devastating_ sarcasm from you. It's almost as if you didn't learn it last week in your remedial lit classes. Congrats!
Barney's a little on the looney side. His predictions have all fallen flat, and I detect hints of sour grapes that his baby is getting wailed on ("Denouncing all code written in languages other than Java as "contamination" is insulting to programmers") I still use C++, but only when I really, really need to. For general purpose applications (servers, clients, tools), there's no reason not to use Java. It takes less time to get it done.
I hate to argue against opening something up for standardization, but Sun controlling Java might help out steering the language better--control by fiat. I would argue that C++ was screwed by the ANSI committee, and by how many implementations and versions were propagated before the "final" ANSI version. Namespaces, exceptions, even templates have been severely hampered by this slow standardization process. Check out what C++ features Mozilla uses (answer: just about none). The reason? Varying levels of C++ compliance, from lots and lots of different compilers. I don't think that's happening to Java with Sun at the helm.
Evolution? Gee, all I see is a trendoid trying to follow the Next Big Thing. Way to go! (And such kudos the U of Rochester should get for pumping out such "enlightened" souls as yourself)
When I program in C++ I can imagine what the assembly created will look like- and what it will do, and how it will do it.
Is that true anymore? Say you have a class with some type conversion constructors. Now insert them into a container template. Maybe it's a doubly templated container, like a map. Now throw an exception out of one of the container template's methods. Do you really know what's going on? I don't. C++ does a lot of funky shit for you now, if you haven't noticed.
And another thing- Garbage collection. When you dont have it you may have to hunt down memory leaks. But when you do have it you must hunt down memory bloat- the converse problem. Many java programs bloat up is size because uneeded large objects are left laying around referenced. This is a problem I consider equivalent to memory leaks, but much harder to detect and debug.
Are you really going to argue that unused references are worse than memory leaks? Answer: don't keep around references. Create new objects. If it's a performance problem creating new objects, cache them (and be careful not to hold them around as much). In all cases, your program works (in a possibly degraded state). With memory leaks, your program will not work--it'll bail out with a failure.
In practice, this doesn't happen. Yes, people make too many objects sometimes (creating some memory problems), but still: the program works. The logic is correct. With more memory, it'll work better. How much memory do you need to add in order to correct a C/C++ memory leak?
As for portability, Java is only as portable as its VM.
I hope you realize that I'm laughing at you, even now. Here's a big 'DUH' coming from me, to you, partner.
Having autoconf and being able to./configure; make; make install on any Unix-like system is a lot easier than Java, which allways seems ad-hoc and painful.
That's right, there's all these magical elves who automatically write the autoconf stuff, and handle all the portability issues for poor little you! All you have to do is type "./configure ; make ; make install". How nice of them! I wonder where the "AutoMakePortable" script is on freshmeat...
Garbage collection. This is a *bad* thing. It encourages people to write bad code and not clean up after themselves.
Did you ever stop to think that, hey, maybe you shouldn't have to worry about cleaning up objects? I bet you don't like using inheritence, either, since vtables add so much overhead. Read some papers (Boehm/Weiser have some good ones) about garbage collection not sucking. Your other points about "how does the VM know this object is garbage" are irrelevant, as any decent GC'ed language doesn't let you do pointer manipulation where you could hide a reference. So yes. It knows. It knows all. (And if you use the Boehm/Weiser/Moore GC for C/C++: Don't Hide Your Pointers. 'nuff said.)
Browser VMs suck. Agreed. If you can, use the Sun 1.3 VM or the IBM VM. This may mean not using a Mac. Remember that Sun says "Write Once, Run Anywhere", not "Write One, Rocks Everywhere"
The rest of your whines: jesus, get out from under your shell. Repeat after me: higher level languages make things easier (i.e.: you have to do less work), sometimes at the expense of performance. Repeat until you understand. If it's not clear immediately, write a non trivial application in both C and Java, and see how much easier it is in Java. I suggest writing a simple TCP proxy.
Suppose somebody writes a library, and the library requires you to supply it an object, and will call it back when needed. Then the library is suddenly forced to know what exception that YOUR method will throw (but of course it doesn't)---or to say that it "throws Exception", or to force you to throw only unchecked exceptions.
Why is that a bad thing? Either don't throw exceptions from your callbacks, or use library methods that can handle the exception thrown. Anything less wouldn't be safe.
Python's great as long as you compile it into Java bytecodes. Sun and IBM have done all this work making the Java VM fast & portable, and it's great if other languages can take advantage of that. Running Python standalone? Blah, why bother? Will "native" Python's Win32 support ever be as good as Java's Win32 support? Never. Why fight it?
Slashdot Mirror
And I'm sure it scales to tens upon tens of users--bah, who needs this worldwide presence?! Congrats!
I'm going to snap if I hear another "Bring back the old games, they were so much better". Sheesh--it's just a matter of time before somebody mentions _Elite_ as the end-all/be-all space trading game.
The fact is that progress is good. Nobody mentions how hard it was to orient yourself while docking with non-texture mapped polys in _Elite_, along with nobody ever mentioning how the end of _Wasteland_ could have been more fufilling with a short movie.
Sigh, it's easy for people's psyche to wash away thousands of crappy C-64/2600 games, but then unforgivable for a new game to be too complicated.
I have to admit that I always thought the old school RPGs were the best, these unassailable, unimpeachable titans of the field: _Bard's Tale 3_, _Wasteland_, _System Shock_, but then I played _Planescape: Torment_. Not "along them same lines", not "just as good", but "better". That in itself has revived my belief that things really do get better.
First of all, we should be clear what we're discussing: Java the language, or Java the platform. Obviously the language is platform independent, with the VM running on each machine being tied to a platform.
And on that note: lowest common denominator is the tradeoff for portability. And yes, there's unix-isms like System.out and System.err which irk the Mac people, but it still works for the most part, even if it's a little weird in spots. I haven't seen hordes of Mac java programmers screaming for blood because there's some Unixy stuff in Java.
For example, the javax.comm package for serial communications has an API for enumerating the names of the serial ports. ... But on Macintosh, you get the words "printer" and "modem".
So? For the most part, "javax." is platform dependent. "java." is platform independent. While pure java is preferable in terms of portability, native code is fine as well, which is the point of the javax system. If lowest common denominator isn't good enough, use javax: but then don't be so quick to complain when it returns platform specific values.
If you want to see true platform independence, check out the ZooLib cross-platform application framework. ZooLib allows you to write a single set of C++ sources and compile them to native executables on Mac OS, Windows, BeOS and Posix flavors with XWindows such as Linux.
While this sounds cute, there's no programmer reference available so I can quickly compare the available APIs between it and JDK1.3. The high level feature list has some nice things (the threads), but really, most of that stuff has come for free since Java 1.0, and more: 2D/3D graphic APIs, impressive international support, CORBA, _and_ it runs in a browser.
What is necessary? 10 xterms running tail -f, 1 running the editor, 1 the debugger, 1 running xman and 1 running netscape 4.7?
What's the difference between this and running a few command shells, Visual Studio, MSDN, and Internet Explorer?
These are the words that should be written above the gates to the hell of multithreaded programming. Do not pass beyond these walls without understanding what they mean.
Simplicity is paramount to this. If there is only one place that requires a lock, and everything is firewalled behind it, then you only need to ensure that single place works for all threads. The nastiness comes when threading is pervasive throughout the system, where there is no clear concept of object ownership between threads.
Maybe if they signed a name to it.
The VS debugger is nice, yes, and it'll beat GDB or DDD in a feature comparison anyday. However, for 95% of the debugging tasks that I need to do, they're equivalent. Set breakpoints, set watches, get stack traces--the other stuff is nice but hardly necessary.
Certainly, if you require JDK1.2/JDK1.3 features, you'll be limited somewhat. Although, IBM lists AIX, OS/2, OS/390, and AS/400 as JDK1.3 capable. (http://www.ibm.com/java/jdk/index.html). Of course, Solaris runs 1.3. HP/UX is 1.3 capable, as well. If you can get by with JDK1.1 features, that opens up far more platforms (IRIX 5, IRIX 6, NetBSD, OpenBSD, VM, MVS, etc)--and I'd venture to say that's pretty close to the edge of "runs everywhere"
Sadly, yes, there is no FreeBSD port for Java 1.3 yet. It's a bummer, I agree.
Please, no offense meant, but I think the important thing is that you've implemented something faster in Python, where that 'something' has the qualities: runs on 4 platforms, has a Web UI, and a relatively difficult setup/install. Time will tell if those given qualities will yield the Next Killer App (I, of course, hope it is).
I'd be interested to know how much time Mojonation spends doing crypto vrs how much time is spent in I/O. (I really am wondering--not trying to be offensive here) My mojonation python processes (on my ppro200) never seem to spike badly. Is there some point where the native code/interpreted code tradeoff wouldn't be so bad?
I think MojoNation should be as simple to use as Napster: Click here to share Porn & MP3s. People will love it, and I think that's what drives user acceptance.
In any event, I think that this has been constructive. I've learned some more about Python, at the very least. This definately highlights the need for keeping abreast of other technologies, as to see what features they can bring your application. (I for one, didn't know about the extent of Python's dynamic loading capabilities)
But then again, maybe if you did, your cross platform support would have been better and you'd have a much better UI using Swing than what you have now.
Thank god. The software engineering field dodges another bullet.
Yeah, as soon as you get a net appliance with 128MB of memory, plus some disk for swapping, then cool! You can browse the web!
Boehm also lists some nice papers on GC overhead. For example, check out Detlefs, Dosser and Zorn's Memory Allocation Costs in Large C and C++ Programs. Boehm brings up the point that most of the overhead is caused by a GC replacing a traditional new/delete pair, and that possibly you'd get back all of that hit if you just write programs that take advantage of the GC rather than using it as a simple new() replacement.
I'm not sure what you mean by two instances in one chunk of memory- I do however use shared buffers with reference counts.
Say you have an object with a couple pointers to dynamically allocated memory. If you make a copy of that object (say you pass by value instead of pass by reference), then you'll have 2 copies of the pointer to the one dynamically allocated chunk of memory. If that happens, you won't know when to safely delete the memory.
Could even be a little template class if you fancy having all types of shared objects. I never get into massive amounts of overloaded operators.
I like Myer's More Effective C++ book's treatment of these. I use them too.
About "your program doesnt work"- the idea was that the developer would use leak detectors, to verify that his disciplined code does not actually leak. Even if it does have a leak in a strange place- that will hardly make it crash or anything- you may just have to restart it after a long time running. And while this buggy program runs it will probably be fast.
Certainly true, but leak detection isn't the easiest thing to do all the time, right? I like Purify as much as the next guy, but while it does a ton for you, it's difficult to verify that in all cases, with all input, your program won't leak. And come on, since when did restarting a program to fix a bug become fashionable? ;)
And while this buggy program runs it will probably be fast.
You honestly don't think that this is a good thing, right? Don't ever tell this to a customer.
About memory bloat: its choosing between caching lots of objects that you may or may not use again and constantly creating them anew. Either way has a draw back and an advantage.
Java recently added a very nice soft-reference system (a hook into the GC), which allows you to make memory-sensitive caches. This gives you the best of both worlds: you can keep a cache of objects around, but if your heap size runs low, the GC will throw out objects out of your cache first (to allow new objects to have some memory).
The new() operator itself in C++ isn't 'free' either (pardon the pun). Creating objects is an expensive proposition. You should cache objects and reuse them in C++, as well.
Another nice advantage of C++ programming: many programs dont even need to use the heap whatsoever Everything on the stack and maybe a static global or two. In java you have references on the stack to things that are on the heap- needed or not.
It is nice to make little mini-stack objects, on occasion, yes. However, there is also some comfort in having a single creation point for objects (Java's new()): you never have to worry about returning references to local objects. You never have to worry about mistakenly creating objects during method calls (if you pass by value, or if a conversion constructor is called). In java, a reference to an object is always valid (or, of course, it's null). By letting object scope be global always (rather than C++ allowing you to choose between global or local scope), you eliminate a bunch of nasty little errors. Plus, you can apply the same GC optimization strategies to this as well: if you'd like a local object, simply pull one out of the pool/cache that you've created, and use it. Return it to the cache when done. Or, maybe you don't want to return it until a later point--you can easily do that, as well.
Isn't this the same as saying "To write bug-free software, merely write software with no bugs in it?"
Especially easy to avoid if you confine new/delete to constr/destr. Makes it much easier to find memory leaks than in classic C, because you only have to consider class scope for the use of that memory. Toughest part is when destructors dont get called properly- but you get used to that one.
Yes, yes, it's nicer than C, but then what if you need to share objects? Two instances of an object, but only one chunk of memory? You don't want to double-free, nor do you want to free out memory that the other copy is using. Ah, that's when you pull out the reference counted smart pointers. But those aren't so great all the time either: every pointer access (method & fields!) requires extra steps, the bookkeeping is expensive itself, and if you like hiding the fact that you're ref counting behind a envelope/letter structure, it fucks up your inheritence tree (since you have a handle->implementation pair for every class, where normally you'd just have an implementation). All this time, be sure to pass all objects by reference so that ctors aren't called during method calls, and don't return references to local objects from methods. What a pain! And lets not even mention the hellish nature of exception handling or thread safety. auto_ptr, anyone?
Compare that to the memory bloat problem: no real way to duck that one without taking a hit somewhere else.
Explain. Just don't create objects as much. Re-use them. Make pools and caches.
Sure you program works- but what is people biggest complaint about it now: slowness.
Isn't this a far better complaint than "Your program doesn't work"?
To optimize the memory handling of a GC'd language program is tough and non-trivial. And since the code is all technically correct- there is no objective way to know that you have really fixed the problem.How so? You see where all objects are created--you see where they're stored--simply cache frequently new()'ed objects. OptimizeIt for Java has a very fine heap analysis program which shows which objects are taking up most of the heap, and where they were allocated (all the while, remember: it's not finding bugs, your program is working the whole time). And for an objective way to tell if you've fixed the problem: what's wrong with vmstat or top?
Whereas with a typical compiled program, once there are no memory leaks, any optimizations are pure bonus- and usually very easy to figure out how to do/implement.
I'd say it's much easier to optimize GC'ed languages. Need a local reference to an object, but don't want to worry about memory leaks? Go ahead, copy the reference. Want to cache objects, but don't want to run Purify again? No problem: just create a pool and hold onto another reference. Sling pointers (oops, references) around with wild abandon: it'll all be fine. Once you're freed from having to worry about memory lossage, you'll have a bunch of time to work on the important optimizations: your algorithms. And that's what's really important, right?
You don't even need to resort to Java in order to bask in the luxury of Letting The Computer Work For You. Try the Boehm collector for C/C++. It compiles for Linux & Win32 among others. Just subclass your objects from 'GC', and then just new() new() new(). And don't worry about delete(), ever again.
I don't know if you can hack a copying collection scheme onto a pointer dirty language like C/C++ though, since you'd need to twiddle pointers during cleanup (AFAIK). That's one definate advantage of a mark/sweep system.
A simple adjustable wrench is the solution for tightening and loosening just about every nut. For the hard to reach nuts, or the ones with a weird shape, you pull out the special wrench. Once done, you put that special wrench away and go back to the simple one that works the best.
How could you not win everyone over with such a persuasive and well reasoned argument?
When are people going to learn that language advocacy is half about pushing your favorite language, and half about the gorgeous flame wars?
Oh, and by the way, such _devastating_ sarcasm from you. It's almost as if you didn't learn it last week in your remedial lit classes. Congrats!
Since then, I've become a sysadmin
"...and, I've _completely_ forgotten how to code."
and I know that java is very fragmented already
"...and I haven't been keeping up with the industry either..."
but most programmers, once they learn java, use it for everything no matter what the problem
"...I never thought that maybe it's very useful for many different things, oh, wait, a user can't print again--lemme go fix that..."
there's always a "best" tool for every job and java isn't it in a lot of cases
"I'll just pull this out of my ass because it looks so 3lit3. Oh, uh, 31it3. 31i43? 33l3t3?"
See, it's not just me!
"Me too! Me too!"
Barney's a little on the looney side. His predictions have all fallen flat, and I detect hints of sour grapes that his baby is getting wailed on ("Denouncing all code written in languages other than Java as "contamination" is insulting to programmers") I still use C++, but only when I really, really need to. For general purpose applications (servers, clients, tools), there's no reason not to use Java. It takes less time to get it done.
I hate to argue against opening something up for standardization, but Sun controlling Java might help out steering the language better--control by fiat. I would argue that C++ was screwed by the ANSI committee, and by how many implementations and versions were propagated before the "final" ANSI version. Namespaces, exceptions, even templates have been severely hampered by this slow standardization process. Check out what C++ features Mozilla uses (answer: just about none). The reason? Varying levels of C++ compliance, from lots and lots of different compilers. I don't think that's happening to Java with Sun at the helm.
Evolution? Gee, all I see is a trendoid trying to follow the Next Big Thing. Way to go! (And such kudos the U of Rochester should get for pumping out such "enlightened" souls as yourself)
Is that true anymore? Say you have a class with some type conversion constructors. Now insert them into a container template. Maybe it's a doubly templated container, like a map. Now throw an exception out of one of the container template's methods. Do you really know what's going on? I don't. C++ does a lot of funky shit for you now, if you haven't noticed.
And another thing- Garbage collection. When you dont have it you may have to hunt down memory leaks. But when you do have it you must hunt down memory bloat- the converse problem. Many java programs bloat up is size because uneeded large objects are left laying around referenced. This is a problem I consider equivalent to memory leaks, but much harder to detect and debug.
Are you really going to argue that unused references are worse than memory leaks? Answer: don't keep around references. Create new objects. If it's a performance problem creating new objects, cache them (and be careful not to hold them around as much). In all cases, your program works (in a possibly degraded state). With memory leaks, your program will not work--it'll bail out with a failure.
In practice, this doesn't happen. Yes, people make too many objects sometimes (creating some memory problems), but still: the program works. The logic is correct. With more memory, it'll work better. How much memory do you need to add in order to correct a C/C++ memory leak?
I hope you realize that I'm laughing at you, even now. Here's a big 'DUH' coming from me, to you, partner.
Having autoconf and being able to ./configure; make; make install on any Unix-like system is a lot easier than Java, which allways seems ad-hoc and painful.
That's right, there's all these magical elves who automatically write the autoconf stuff, and handle all the portability issues for poor little you! All you have to do is type "./configure ; make ; make install". How nice of them! I wonder where the "AutoMakePortable" script is on freshmeat...
Did you ever stop to think that, hey, maybe you shouldn't have to worry about cleaning up objects? I bet you don't like using inheritence, either, since vtables add so much overhead. Read some papers (Boehm/Weiser have some good ones) about garbage collection not sucking. Your other points about "how does the VM know this object is garbage" are irrelevant, as any decent GC'ed language doesn't let you do pointer manipulation where you could hide a reference. So yes. It knows. It knows all. (And if you use the Boehm/Weiser/Moore GC for C/C++: Don't Hide Your Pointers. 'nuff said.)
Browser VMs suck. Agreed. If you can, use the Sun 1.3 VM or the IBM VM. This may mean not using a Mac. Remember that Sun says "Write Once, Run Anywhere", not "Write One, Rocks Everywhere"
The rest of your whines: jesus, get out from under your shell. Repeat after me: higher level languages make things easier (i.e.: you have to do less work), sometimes at the expense of performance. Repeat until you understand. If it's not clear immediately, write a non trivial application in both C and Java, and see how much easier it is in Java. I suggest writing a simple TCP proxy.
Why is that a bad thing? Either don't throw exceptions from your callbacks, or use library methods that can handle the exception thrown. Anything less wouldn't be safe.
Python's great as long as you compile it into Java bytecodes. Sun and IBM have done all this work making the Java VM fast & portable, and it's great if other languages can take advantage of that. Running Python standalone? Blah, why bother? Will "native" Python's Win32 support ever be as good as Java's Win32 support? Never. Why fight it?