Well, either you believe in static typing, or you don't. If you do, Java is a good choice. If you don't, Ruby is a good choice. C++, on the other hand, is static enough to be annoying, but not static enough to be safe.
I actually much prefer Objective-C to C++. Once again, the worse solution won.
Perhaps you can back that up with an example of where Java makes it bothersome? Then I can show you how it is done in an adult language:P (Limitation: I haven't found a good static reflection-enabled language, (I have no idea why), so reflection based examples are off-limit:) )
Because C++ is a statically typed language, which means that type errors are discovered at compile time.
Well, many type errors are discovered at compile time. Unfortunately, static typing tends to have the side effect of requiring more complex code, and often has to be worked around.
Only if said checks are broken, I believe. Do you have an example? But yes, declaring your types leads to more verbose code for sure; this is one of the trade offs for static typing.
Personally, I write mostly in Java and Ruby. Java is pedantically static to a level that would make C++ blush, while Ruby is completely duck typed. I've had situations where Java's pedantic nature has caught bugs before test runs, but I've also had situations where the code was 10x as long and harder to debug because of the inflexibility. I think it's highly debatable which approach is better, and the answer probably depends on the kind of problem you're solving.
I myself has worked extensively in C, C++, Ruby, Perl and Java and many other languages, and of those I do like both Ruby and C++. Java feels like a straightjacket to me, and it sounds like you have the same problem. Perhaps you should try a more powerful language, such as C++?
While I love the concept of concepts (sorry!), I too feel that leaving them out is for the best. Let us see an implementation first... like we have for lambdas, e.g.
Templates are what Python calls 'duck typing'. ("If it looks like a duck and quacks like a duck...") Why not just do that? You could add methods for introspection and so forth...
Because C++ is a statically typed language, which means that type errors are discovered at compile time. For C++, discover = kilobytes of error messages, which is one of the key things concepts would fix.
Generic (static) programming is one of the areas where C++ is far outshines it's competitors, though heaven knows it has enough other flaws. Sigh, someday I will get a language which satisfies my quite reasonable list of requirements for a decent language.
I am well aware of 1, and 2 + 3 is what I wrote earlier might be an explanation (but I don't believe it, personally.) Personally, I think the original claim is simply false. For one thing, I seem to recall a soldier explaining that getting hit by a shot from an assault rifle was like "getting punched", and I presume that assault rifles are even more powerful than a shotgun.
As for the time issue: Getting hit by a bullet is by no means instantaneous since the suit, the bullet and the body deforms. The area of effect if in a kevlar suit is probably similar, since those things a designed to spread out the impact. The shooter will take the shock either on the hand or on the shoulder, depending on whether he braces with the stock or not.
So it really rest upon one thing: Is there a timing issue big enough to account for the difference claimed? It would have to be a few orders of magnitude. I doubt it, but I have not found any texts about it.
Ok, I just noticed that the window buttons and stuff like that was different, so I --- naively it would seem --- assumed that the widget theme was changed, too.
Personally, as long as it wobbles, it's ok by me;)
This weekend, I was going to play a DVD on a Kubuntu install for the first time since 3.5 (don't laugh, I don't do that much). So I popped in the DVD. Got a popup in "recently plugged in something" saying that this DVD had been inserted. Clicked on the DVD, and it suggested I either ignored it, burned it, ripped it or played it. I selected play, and the it suggested I install support for reading (encrypted?) DVDs. I clicked yes, and after a bit, the DVD started playing in a window. A mouseover showed a "fullscreen" icon, after which the DVD just worked, menus and all.
A fairly nicely working expericen, working across several systems.
KDE 4.3 defaults to the Air theme these days. No idea if that theme is more or less dense than Oxygen, I don't see stuff like that.
Re:Per-desktop activities assignments
on
KDE 4.3 Released
·
· Score: 1
You could make an activity for each desktop and set the desktop wallpaper for each Activity. It would probably be closer to what you want than your 3.5 setup, but more work in setting it up. Just a suggestion...
Use another launcher then. Personally, I prefer the Run Command (Alt-f2, type three letters and get some suggestions. Doubles as calculator, unit translator and many other things), but there is also Lancelot, besides the classical kmenu (which looks much like the KDE 3.5 version.)
Momentum is conserved but doesn't break the shooter's arm because the shotgun is much heavier than the payload.
I wasn't worrying about the shutgun nor the payload. The force that knocks down the officer for 30 seconds would be opposed by an equal force which should be transferred from the gun to the shooters arm --- more actually, due to inefficiencies. If the officer cannot remain standing, neither should the shooter. Or else I am missing some detail, like perhaps a shutgun shot isn't nearly instant, but actually takes half a second before the explosion in the gun chamber is done and the payload leaves the gun, giving the shooter more time to absorb the recoil.
Not that I claim to be a gun expert. But I think the claim about the knockdown effect is false. I would expect a heavy punch-like effect, like the recoil of a gun: Enough to bruise, or even knock down an unbalanced person, but far from enough to unconditionally knock over someone. The 30 minute thing is more likely a psychological effect, and no wonder!
The real problem and issue here is that altering the systems should not be a criminal offense to begin with. Last I checked, if I want to build my own computer... or even build one and sell it for profit, I can do anything I damn well please with the hardware. Also, last I checked - the consoles were nothing more than glorified computers hooked to television screens. If I wanted to, I could theoretically build one of those from scratch too... with the necessary know-how of course.
actually, not quite. Not without the secret keys. You would be able to build a computer that could run the same stuff *if* you had the unencrypted media available. This is one of the reasons why I don't own a console.
If you go after big gangs and organized crime you end up with dead cops because those guys will defend themselves.
Cops choose to grab the helpless citizen that is beaking an obscure law that in reality is not harming others or society. It's easier to rough up a unarmed college student, less chance of having a 10gauge with a slug unloaded at your chest.
Note: if you wear kevlar, a 10gauge to your chest will put you on the ground for at least 30 minutes, thugs with shotguns scare the shit out of cops because their armor does nothing to stop kenetic energy from knocking them over and making it hard to breathe.
Honestly, cops need to be going after the hard crap that actually harms others and society, and not the harmless crap.
Wouldn't this law break the criminal's arm or something, then?
If there are companies that really feel that they struggle because people are downloading a copy rather than buying it in the officially provided format, then I humbly propose that those companies do some unbiased analysis of why people won't buy their packages. Could it be that people love the game, but hate the packaging?
Perhaps it is the packaging, I am no expert. What I know from friends --- and I think ID software also said this at one point --- is that when the same game is published for PC, XBox and PS2/3, the PC platform does not turn a profit while the latter 3 does. So the company in question is dropping the PC platform, obviously.
Of course, there will always be a market, and some games doesn't lend themselves to the consoles very well, but I fear that this is the way things are going. Of course, I might be wrong, and I'd be happy about that.
When you are looking the the market, remember to hunt for profit, not revenue. It's profit that makes companies stay in business.
My advice is for the game developers to make games that are mostly placed on a server. That would truly make piracy hard, and would even lend some limited value to the customer (no downloading patches and so on).
Of course, that means that playing without internet connectivity becomes impossible. So it is a trade-off, but I hope this way that PC gaming will endure.
I don't like piracy (check my history if you don't believe me), but I do dislike having to type a 20-digit number to play a game I bought. I think that is what is meant by "treating like thieves". For the windows-crowd, you also hear about more serious issues, like CD-burning software stopping to work. I have no first-hand experience there.
Now DVDs are pretty bad. Sometimes they force-show a movie about not copying. Hello?! If I am watching the DVD, I patently did not copy it illegally. At least, I doubt the "pirates" actually include that bit:)
I mean with thread safe that insert operation in multithreaded C++ is *undefined* (i.e. can and does crash if some other thread is reading from it at the same time).
yep, exactly like every collection in Java including Vector, provided that no sync. has been done. So? My point is that this *expensive* guarantee is usually not wanted, which is why the library designer changed course an made the collection library. To quote
Note that the fail-fast behavior of an iterator cannot be guaranteed as it is, generally speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent modification. Fail-fast iterators throw ConcurrentModificationException on a best-effort basis. Therefore, it would be wrong to write a program that depended on this exception for its correctness: the fail-fast behavior of iterators should be used only to detect bugs.
In other words, it's an expensive, best-effort mechanism that garantees nothing. Or in other words: It is broken by design. Like everyone, the designers made a (common) mistake, and endeavored to fix it. But truly fixing it is not possible because the error is in the std lib. Just like strncpy()
BTW, queue is hugely slower when most common access is read or update, especially if several threads are doing it simultaneously.
not if reading front the top and inserting somewhere well-defined is what you want... which is usually the case for such a structure *shared between threads*. Consider what insert at position 5 would mean in a multithreaded case: the inserted element could be anywhere! Find->index would be meaningless without more synching, too, since another thread might insert between the find and the read. I'm not saying that a shared vector with insert and reads never occurs, only that it is rare. Also, as you should now, sync, at the methods of vector is almost certainly the wrong place to do it.
Your only complaint is bloat into which I will not go again.
In short, it is all pain, no gain. In Java, it is a symptom of a (probably intentionally) poor support for calling C and C++ interfaces.
If you mean, don't have a lame bounds check that checks on every single array reference, I agree.
On the other hand, for many well-mannered loops (that the array index is generated by some kind of iterator or index stepping expression, one not modified from inside the loop), it should be easy enough to have an optimizing compiler/JIT/whatever that checks the bounds once on entry to the loop.
In that case, I would indeed like to have bounds checking, thank-you-very-much. There are efficient ways to do bounds checking, and why not use them?
What you propose is essentially solving the halting problem. That is not going to work in the general cases... and anyway, using indexes to iterate over an array is bad form anyway. That's what iterators or even better functional for-loops are for. E.g, from ruby:
mycollection.each_with_index do |item, index| # work you magic end
No possibility to get out of bounds there, and thus, no need to check. Note how a runtime check becomes a compile time certainty... that's what I want from my languages:)
More generally, I don't mind bounds checks as an option... e.g, I use valgrind extensively for that for C++, and STLport is also very nice for that sort of stuff. Having them as an compiler feature would also be cool... then I could simply turn them on with --enable-bounds-check. But I do not want them in production code! There is simply no way for the compiler to guess whether those checks are bad for performance while being completely superfluous.
I humbly disagree, I am a strong supporter of big standard libraries.
For example let's take Python. There is no standard GUI library (Tk, IMHO, is not good enough - and nobody uses it). Therefore e.g. Meld is impossible(?) to get to work in Windows. Not good.
Thread::stop() is deprecated, AWT is not designed to be used (directly). Vector, OTOH, is better than C++ Vector (e.g. insert is thread safe) and I fail to find big problems in it WHEN USED FOR WHAT IT IS DESIGNED FOR. It is not an array nor a Map.
Nobody forces you to use the standard libraries if they are not appropriate for your use case! Sure they add to bloat but that is with todays computers completely immaterial.
I agree the Java class loader is idiotic although it has improved.
As for Python: It doesn't matter whether it is a standard library. I do not know or use python much, but for C++ and ruby there is Qt, which is cross-platform and much better than anything Java has to offer (I lie: Qt is available for Java, too). It might be available for Python, too, who knows.
One of the problems is that even if I discard the entire standard library, I still pay the price for loading that huge, steaming pile of junk! And for what? What is the advantage of a standard library compared to just a library? That you save 10 minutes in the beginning of developing an application? Who cares?
As to the specific points:
AWT was designed to be used, directly. It is simply a steaming pile of crap, as is both SWT and Swing (havn't actually tried QtJambi, but then that is not a standard library). A lot of it is, I admit, due to the fact that Java does not really lend itself to GUI programming, because it lacks resource management support, and GUI programming has a lot of resources. That leaves you with either a lot of anonymous derivations which is Java's excuse for lambdas, or the finally hell. Or you can go the Qt route and build a parallel graph for managing those resources.
Vector: How often do you really need thread synchronized vectors? In the few cases where you might be tempted, a n-ary or binomial queue is probably a better choice anyway. Much better to have thread synchronization to be an option, which is also the route that the Java standard library developers chose later on.. But the cannot remove Vector now, without breaking existing programs. Fun, eh? So now every newbie has to be told: You want a vector? Look at ArrayList. CRUFT. This could have been avoided by having this functionality as a perfectly normal library: Old programs would depend on libcollection.so.1 and new ones on libcollection.so.2. Package management would handle the dependencies and everything would just work, without the cruft. As a bonus, porting to small-factor devices wouldn't have required a scaled-down standard library.
Sorry, I do go on. In any case, once you get to know and learn 5-10 languages and their standard library or so, I'm sure you will see my point.
Slashdot Mirror
the needs we've so far only successfully addressed with religion
And what needs would those be?
I can't think of any "need" which can ONLY be addressed with religion.
The need to built pointy buildings unused for 6 out of 7 days?
If what you say is true, the green revolution didn't happen ;)
scientific american, perhaps?
Well, either you believe in static typing, or you don't. If you do, Java is a good choice. If you don't, Ruby is a good choice. C++, on the other hand, is static enough to be annoying, but not static enough to be safe.
I actually much prefer Objective-C to C++. Once again, the worse solution won.
Perhaps you can back that up with an example of where Java makes it bothersome? Then I can show you how it is done in an adult language :P (Limitation: I haven't found a good static reflection-enabled language, (I have no idea why), so reflection based examples are off-limit :) )
Well, many type errors are discovered at compile time. Unfortunately, static typing tends to have the side effect of requiring more complex code, and often has to be worked around. Only if said checks are broken, I believe. Do you have an example? But yes, declaring your types leads to more verbose code for sure; this is one of the trade offs for static typing.
Personally, I write mostly in Java and Ruby. Java is pedantically static to a level that would make C++ blush, while Ruby is completely duck typed. I've had situations where Java's pedantic nature has caught bugs before test runs, but I've also had situations where the code was 10x as long and harder to debug because of the inflexibility. I think it's highly debatable which approach is better, and the answer probably depends on the kind of problem you're solving.
I myself has worked extensively in C, C++, Ruby, Perl and Java and many other languages, and of those I do like both Ruby and C++. Java feels like a straightjacket to me, and it sounds like you have the same problem. Perhaps you should try a more powerful language, such as C++?
Actually, it would seem that the is an implementation, a fork of gcc. Well.
While I love the concept of concepts (sorry!), I too feel that leaving them out is for the best. Let us see an implementation first... like we have for lambdas, e.g.
Templates are what Python calls 'duck typing'. ("If it looks like a duck and quacks like a duck...") Why not just do that? You could add methods for introspection and so forth...
Because C++ is a statically typed language, which means that type errors are discovered at compile time. For C++, discover = kilobytes of error messages, which is one of the key things concepts would fix.
Generic (static) programming is one of the areas where C++ is far outshines it's competitors, though heaven knows it has enough other flaws. Sigh, someday I will get a language which satisfies my quite reasonable list of requirements for a decent language.
It runs alright on this laptop with an intel chip running Debian... pretty hearts and stuff. In Konqueror, though, not firefox.
I am well aware of 1, and 2 + 3 is what I wrote earlier might be an explanation (but I don't believe it, personally.) Personally, I think the original claim is simply false. For one thing, I seem to recall a soldier explaining that getting hit by a shot from an assault rifle was like "getting punched", and I presume that assault rifles are even more powerful than a shotgun.
As for the time issue: Getting hit by a bullet is by no means instantaneous since the suit, the bullet and the body deforms. The area of effect if in a kevlar suit is probably similar, since those things a designed to spread out the impact. The shooter will take the shock either on the hand or on the shoulder, depending on whether he braces with the stock or not.
So it really rest upon one thing: Is there a timing issue big enough to account for the difference claimed? It would have to be a few orders of magnitude. I doubt it, but I have not found any texts about it.
Ok, I just noticed that the window buttons and stuff like that was different, so I --- naively it would seem --- assumed that the widget theme was changed, too.
Personally, as long as it wobbles, it's ok by me ;)
Which use cases are these?
This weekend, I was going to play a DVD on a Kubuntu install for the first time since 3.5 (don't laugh, I don't do that much). So I popped in the DVD. Got a popup in "recently plugged in something" saying that this DVD had been inserted. Clicked on the DVD, and it suggested I either ignored it, burned it, ripped it or played it. I selected play, and the it suggested I install support for reading (encrypted?) DVDs. I clicked yes, and after a bit, the DVD started playing in a window. A mouseover showed a "fullscreen" icon, after which the DVD just worked, menus and all.
A fairly nicely working expericen, working across several systems.
Use one of the alternatives, then: Classic or Lancelot. Personally, I prefer Alt-f2 these days: Quicker and sleeker if you know what you want.
KDE 4.3 defaults to the Air theme these days. No idea if that theme is more or less dense than Oxygen, I don't see stuff like that.
You could make an activity for each desktop and set the desktop wallpaper for each Activity. It would probably be closer to what you want than your 3.5 setup, but more work in setting it up. Just a suggestion...
Use another launcher then. Personally, I prefer the Run Command (Alt-f2, type three letters and get some suggestions. Doubles as calculator, unit translator and many other things), but there is also Lancelot, besides the classical kmenu (which looks much like the KDE 3.5 version.)
Momentum is conserved but doesn't break the shooter's arm because the shotgun is much heavier than the payload.
I wasn't worrying about the shutgun nor the payload. The force that knocks down the officer for 30 seconds would be opposed by an equal force which should be transferred from the gun to the shooters arm --- more actually, due to inefficiencies. If the officer cannot remain standing, neither should the shooter. Or else I am missing some detail, like perhaps a shutgun shot isn't nearly instant, but actually takes half a second before the explosion in the gun chamber is done and the payload leaves the gun, giving the shooter more time to absorb the recoil.
Not that I claim to be a gun expert. But I think the claim about the knockdown effect is false. I would expect a heavy punch-like effect, like the recoil of a gun: Enough to bruise, or even knock down an unbalanced person, but far from enough to unconditionally knock over someone. The 30 minute thing is more likely a psychological effect, and no wonder!
The real problem and issue here is that altering the systems should not be a criminal offense to begin with. Last I checked, if I want to build my own computer... or even build one and sell it for profit, I can do anything I damn well please with the hardware. Also, last I checked - the consoles were nothing more than glorified computers hooked to television screens. If I wanted to, I could theoretically build one of those from scratch too... with the necessary know-how of course.
actually, not quite. Not without the secret keys. You would be able to build a computer that could run the same stuff *if* you had the unencrypted media available. This is one of the reasons why I don't own a console.
You actually hit it on the head.
If you go after big gangs and organized crime you end up with dead cops because those guys will defend themselves.
Cops choose to grab the helpless citizen that is beaking an obscure law that in reality is not harming others or society. It's easier to rough up a unarmed college student, less chance of having a 10gauge with a slug unloaded at your chest.
Note: if you wear kevlar, a 10gauge to your chest will put you on the ground for at least 30 minutes, thugs with shotguns scare the shit out of cops because their armor does nothing to stop kenetic energy from knocking them over and making it hard to breathe.
Honestly, cops need to be going after the hard crap that actually harms others and society, and not the harmless crap.
Wouldn't this law break the criminal's arm or something, then?
If there are companies that really feel that they struggle because people are downloading a copy rather than buying it in the officially provided format, then I humbly propose that those companies do some unbiased analysis of why people won't buy their packages. Could it be that people love the game, but hate the packaging?
Perhaps it is the packaging, I am no expert. What I know from friends --- and I think ID software also said this at one point --- is that when the same game is published for PC, XBox and PS2/3, the PC platform does not turn a profit while the latter 3 does. So the company in question is dropping the PC platform, obviously.
Of course, there will always be a market, and some games doesn't lend themselves to the consoles very well, but I fear that this is the way things are going. Of course, I might be wrong, and I'd be happy about that.
When you are looking the the market, remember to hunt for profit, not revenue. It's profit that makes companies stay in business.
My advice is for the game developers to make games that are mostly placed on a server. That would truly make piracy hard, and would even lend some limited value to the customer (no downloading patches and so on).
Of course, that means that playing without internet connectivity becomes impossible. So it is a trade-off, but I hope this way that PC gaming will endure.
I don't like piracy (check my history if you don't believe me), but I do dislike having to type a 20-digit number to play a game I bought. I think that is what is meant by "treating like thieves". For the windows-crowd, you also hear about more serious issues, like CD-burning software stopping to work. I have no first-hand experience there.
Now DVDs are pretty bad. Sometimes they force-show a movie about not copying. Hello?! If I am watching the DVD, I patently did not copy it illegally. At least, I doubt the "pirates" actually include that bit :)
I mean with thread safe that insert operation in multithreaded C++ is *undefined* (i.e. can and does crash if some other thread is reading from it at the same time).
yep, exactly like every collection in Java including Vector, provided that no sync. has been done. So? My point is that this *expensive* guarantee is usually not wanted, which is why the library designer changed course an made the collection library. To quote
Note that the fail-fast behavior of an iterator cannot be guaranteed as it is, generally speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent modification. Fail-fast iterators throw ConcurrentModificationException on a best-effort basis. Therefore, it would be wrong to write a program that depended on this exception for its correctness: the fail-fast behavior of iterators should be used only to detect bugs.
In other words, it's an expensive, best-effort mechanism that garantees nothing. Or in other words: It is broken by design. Like everyone, the designers made a (common) mistake, and endeavored to fix it. But truly fixing it is not possible because the error is in the std lib. Just like strncpy()
BTW, queue is hugely slower when most common access is read or update, especially if several threads are doing it simultaneously.
not if reading front the top and inserting somewhere well-defined is what you want... which is usually the case for such a structure *shared between threads*. Consider what insert at position 5 would mean in a multithreaded case: the inserted element could be anywhere! Find->index would be meaningless without more synching, too, since another thread might insert between the find and the read. I'm not saying that a shared vector with insert and reads never occurs, only that it is rare. Also, as you should now, sync, at the methods of vector is almost certainly the wrong place to do it.
Your only complaint is bloat into which I will not go again.
In short, it is all pain, no gain. In Java, it is a symptom of a (probably intentionally) poor support for calling C and C++ interfaces.
If you mean, don't have a lame bounds check that checks on every single array reference, I agree.
On the other hand, for many well-mannered loops (that the array index is generated by some kind of iterator or index stepping expression, one not modified from inside the loop), it should be easy enough to have an optimizing compiler/JIT/whatever that checks the bounds once on entry to the loop.
In that case, I would indeed like to have bounds checking, thank-you-very-much. There are efficient ways to do bounds checking, and why not use them?
What you propose is essentially solving the halting problem. That is not going to work in the general cases... and anyway, using indexes to iterate over an array is bad form anyway. That's what iterators or even better functional for-loops are for. E.g, from ruby:
No possibility to get out of bounds there, and thus, no need to check. Note how a runtime check becomes a compile time certainty... that's what I want from my languages :)
More generally, I don't mind bounds checks as an option... e.g, I use valgrind extensively for that for C++, and STLport is also very nice for that sort of stuff. Having them as an compiler feature would also be cool... then I could simply turn them on with --enable-bounds-check. But I do not want them in production code! There is simply no way for the compiler to guess whether those checks are bad for performance while being completely superfluous.
I humbly disagree, I am a strong supporter of big standard libraries.
For example let's take Python. There is no standard GUI library (Tk, IMHO, is not good enough - and nobody uses it). Therefore e.g. Meld is impossible(?) to get to work in Windows. Not good.
Thread::stop() is deprecated, AWT is not designed to be used (directly). Vector, OTOH, is better than C++ Vector (e.g. insert is thread safe) and I fail to find big problems in it WHEN USED FOR WHAT IT IS DESIGNED FOR. It is not an array nor a Map.
Nobody forces you to use the standard libraries if they are not appropriate for your use case! Sure they add to bloat but that is with todays computers completely immaterial.
I agree the Java class loader is idiotic although it has improved.
As for Python: It doesn't matter whether it is a standard library. I do not know or use python much, but for C++ and ruby there is Qt, which is cross-platform and much better than anything Java has to offer (I lie: Qt is available for Java, too). It might be available for Python, too, who knows.
One of the problems is that even if I discard the entire standard library, I still pay the price for loading that huge, steaming pile of junk! And for what? What is the advantage of a standard library compared to just a library? That you save 10 minutes in the beginning of developing an application? Who cares?
As to the specific points:
AWT was designed to be used, directly. It is simply a steaming pile of crap, as is both SWT and Swing (havn't actually tried QtJambi, but then that is not a standard library). A lot of it is, I admit, due to the fact that Java does not really lend itself to GUI programming, because it lacks resource management support, and GUI programming has a lot of resources. That leaves you with either a lot of anonymous derivations which is Java's excuse for lambdas, or the finally hell. Or you can go the Qt route and build a parallel graph for managing those resources.
Vector: How often do you really need thread synchronized vectors? In the few cases where you might be tempted, a n-ary or binomial queue is probably a better choice anyway. Much better to have thread synchronization to be an option, which is also the route that the Java standard library developers chose later on.. But the cannot remove Vector now, without breaking existing programs. Fun, eh? So now every newbie has to be told: You want a vector? Look at ArrayList. CRUFT. This could have been avoided by having this functionality as a perfectly normal library: Old programs would depend on libcollection.so.1 and new ones on libcollection.so.2. Package management would handle the dependencies and everything would just work, without the cruft. As a bonus, porting to small-factor devices wouldn't have required a scaled-down standard library.
Sorry, I do go on. In any case, once you get to know and learn 5-10 languages and their standard library or so, I'm sure you will see my point.