I'm not sure your point, you might be correct in that there are ways to commingle the two, the easiest being, do whatever you want to the code, just never release it, and there are no limitations. In that case the code you got was GPLed, the code you created is not, and it's undistributable.
My comment was about a distributor like SCO, and in the clearest way to make my point (good or bad) is to quote the section of the GPL that leads me to think this. It's below.
>7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.
copyright law allows you to use an illegal copy? No. The GPL clearly states it does not apply when commingled with royalty generating code. It's SCO's position that it's commingled with royalty generating code. If they are right, then the GPL does not apply, and you have an unlicensed copy. It doesn't matter what the GPL says or does not say, as you have an unlicensed copy, the GPL does not pertain, only copyright law.
Copyright law says you may not use the product unless given permission by the copyright holder.
I've been posting much the same, I basically agree with you, but I think some of the applications they will get away with. It mostly is the KERNEL that is in question.
>Of course, they can fix this in a heartbeat -- just take their FTP server down.
I think they also have to recall all the distributions they have made that are in violation.
They told their customers "we won't sue you", but those distros are still not covered by the GPL anymore, because they cannot be under GPL and comingled with royalty generating IP, so other people could sue those customers for using IP that they do not actually have a licence for.
Since SCO indemnified them, it sanctioned their violation, and as the original distributor, that puts them in violation of the GPL too. They have to recall all violating distributions to get out of this.
I think SCO might plead stupidity about that part (hopefully not getting away with it), but even so, I think there is another part.
They "indemnified" their current Linux customers. They said, "you go ahead and keep it!" But all the kernel and linux code that SCO doesn't own is there only under GPL. The GPL does not apply for the reason you stated. Those customers cannot have the non-SCO part of linux, but SCO has distributed it to them and told them they can keep it! SCO has therefore violated the GPL even based on the distributions prior to the suit.
SCO would have had to RECALL their Linux distributions!
These guys are too stupid to believe, they are probably just setting up a "but we ARE that stupid" defense for the SEC hearings.
I see 12 replies, so maybe this will be redundant.
The thing is, the GPL says you cannot have royalty generating IP in a GPL covered product. When SCO found out their IP was in there, they had to remove it. They had to RECALL IT! That's right, they had to recall their shipped copies of linux, not because their customers had no right to SCO IP, but because they don't have a right to everything else. E.g. you can't have GNOME because you have that under GPL, the violating IP means you don't have the GPL, and therefore SCO can't ship linux because of all the IP in there that does not belong to them. Of course the best example is not GNOME, but the parts of the kernel that are comingled with supposed SCO IP.
So when SCO indemnifies SCO Linux customers, they were saying SCO wouldn't sue them, but in reality, IBM now can! Those customers are using IBM IP without a license (because the GPL doesn't apply while SCO's royalty generating IP is in there with it!)
I mean, they have not read the GPL. I'm serious, this is not meant as a zealous snipe... really, they must not have read it. Of course they know there is a lot of IP in there. Of course they know it's not all theirs. If they read the GPL they would know they CAN charge for their IP, but in that case, it isn't under the GPL, it cannot be a part of linux. In that case they lose their right to use IBM, et al, code. It's as simple as can be, I mean, the GPL is not a long document. They have not thought about what allows them to make the distribution? The GPL? It's amazing. Of course, we know their theory is that the GPL is unenforceable, that it's really public domain.
Further, it's pretty clear they also don't understand software, I mean, linux has a lot more code than what they claimed is theirs, even if you give them JFS, etc..
Oh wait... they're just lying bastards. They have to set up a really strong "but I'm just stupid" argument for the SEC.
too bad the elitist douchebags are where all the good ideas come from. no, the trick is keeping the elitist douchebags around but tricking all the power away from the... of course, corporate America already solved that problem, and now they have OSS on their hands. You just can't keep an elitist douchebag down.
Carly truly killed the HP-way, we'll see if the HP brand follows, but I think it has a lot of staying power.
The calculator research center was shut down years ago, I keep expecting calculators to stop coming out, but I stupid that way, just improvements have stopped coming out I guess. I still see the for sale.
Oh well, I think the HP calculator is something that was evolving toward PDA from a scientific/engineering point of view, which would be cool.
you bring up a lot of interesting issues but some of them are more important to address than others.
C++ is many time inappropriate precisely because it lacks a standard class system as complete as Java's. High-level mean abstraction. Abstraction requires libraries.
I think you are saying that no standard library means the libraries that are available are not high level. No, if you can't find sufficient libraries, then fine, no argument, the Java one is better. I do not believe 100% of them are better.
I did read about a Java debugger that will go backwards... that's cool. Algorithm is more important. A lot of the optimizations for Java are just arranging things the same way you would have to to optimize in C++.
I think I see where you are coming from. I have a disposition to cross platform myself. And I admit C++ GUI stuff can trap you platform independence. C++ as a standard changes more slowly than a Java can, driven by Sun. C++ is at the WORA stage for console applications!
But C++ developers themselves are not stuck, because the design is open to a lot of different add ons, things that can almost redefine the language itself, like the Standard Template Library. The most efficient and fastest systems are pretty much still C/C++ applications. The generic programming and the way it compiles is really exceptional.
The linked list example has long ago been changed to, "you can't touch the collection in C++".
STL, the Standard Template Library from HP has been absorbed into the C++ Standard Library. There is nothing like generic programming for some good list linking. I admit, I had been one of the list-linkers you allude to, linking lists and writing special collections all the time, casting my void pointer, much to the scorn of other programmers who had gone in from the jungle. But no more!
The STL handles lists, maps, hashes, deques, vectors, even strings! Much of the indirection compiles away with templates.
Java now has generic programming syntax, but I do not believe it compiles away because the type system in Java, but I could be mistaken as I have not use Java generic programming. I do think that is a good addition to Java anyway as it's a powerful idiom.
In fact, I think C++ and Java can really share a big space, I'm fine with Java tying business servers together (many written in C++, probably). But C++ is not going to stay out of GUI's because speed will always matter in GUIs.
well, one, I bet you someone does have a class system to abstract differences between Oracle, Sybase, MySQL, etc. etc. Without checking, I would still bet that.
One reason there are not standard solutions integrated into the language is it's not necessarry, right, the solutions provided by third parties integrate just fine. Yes, it's nice to have a standard library everyone can learn and commit to memory, that is going to be available on every platform the language is available on.
However, one reason that doesn't happen is because there is no perfect solution. Garbage Collection is an example. There is no compelling single solution for that, and having a company like Sun just choose one is not the problem. The problem is there are multiple competing solutions. Sun choosing Swing for me is NOT BETTER than me getting to choose my own control system.
I WANT to think about what is the appropriate algorithm, library, or class. I'm supposed to learn these things to be a software engineer. If you chose for me, you need to make sure you have something with real staying power, thus the STL is now a part of C++, but no GUI toolkit is. The STL will always be useful, from now on. Who can say what GUI approach will win in the end yet?
The idea with C++ is not to have everything in the standard library, really, though I think stream IO is a big exception, it's only for very common things any program does. Very useful things like regex parsing is supposed to be in libraries. It's not hard to find good candidates. And if you don't care to look too deeply and judge the alternatives on low level merits, it's not to hard to find out the most commonly used, or best supported library, and use that.
It does make C++ complex. That is, a Java book covers really everything you need (but not in detail, of course), but it can point you in the direction, it can say, "use AWT or SWING". A C++ book can't do that. It is telling you about a language, and you still need to find the classes and toolkits you will rely on for a lot of parts.
To me that's fine, that's C++ matching the real (not ideal) world, with the real (and ideal) chaos of the practical world.
One last metaphor: A multiple-choice test is easier to write, easier to take, and easier to grade, but it's not a "better test" than an essay based test. The chaos of essay answers, their unpredicability, their potential to give a valid answer the author of the test didn't anticipate, these all make the essay test the "better" type of test.
PS: I think this has been a very interesting conversation, thank you for sharing your ideas. I hope you understand my comments in the same vien. I am sure of myself, but I am sure I might be wrong too. And there is a great deal of room for Java to mature and me to become convinced it's all I need anymore. But by then it will have operator overload.
Ok, I love a good metaphor--- wait, I mean, I even love bad metaphor... but I just don't see Java as the power tools to C++ swiss army knife. I see Java as the kind of quick construction mechanism. Like staple guns, where C++ would be the nail gun.
Regardless, that's probably pushing the metaphor too far. Basically, Java is great if it really is faster to develop or deploy. I have not seen that yet. I've inherited Java programs with bad memory management problems. The code is very C++ like in that I don't see how it's quicker to write than C++. It needs to be compiled. I just don't see the advantage. For me to believe in a VM type solution or scripting language, I need to see the programming metaphor change or at least to see it handle a special problem domain.
I see that java is getting the kind of support needed to support the B2B problem frame. I see how it has things making it nice to develop custom business systems. Not because of Java, mind you, but because of it's standard class system and the support of Sun, IBM, HP, etc. to make it fully featured in that area.
Judging as a language, I don't see the benefits. As a platform... of course I see the massive support and some working solutions which is all it takes to convince me Java is worthwhile.
Where we really disagree is C++ inappropriateness for high level work. I don't believe that. You can have automatic garbage collection if you want, in C++, you can use pointer-free paradigms (though I think that's overkill, best to limit pointer handling, but allow it), you can get as high level as you like.
The only wrench in the works there is that there are too many choices, there are messy and even bad paradigms available in C++. Perhaps it's personal, but I don't mind the jungle. I think it's possible and worthwhile to have a lot of options and have to learn the meaning of each option before attempting to use it.
e.g. if it's a big problem that the C++ stdlib does not have a GUI library... then I'd say, standardize one, you dont' need a whole new language for that, imho.
ok, I see what you meant about the database API, not across hardware, accross database vendors. Surely someone abstracts that, otherwise you write your own classes in such a way as to be able to add support for other DBs.
I think you are onto something, this is a niche of Java, it's a product built to fit the business integration crowd, a big crowd to be sure, and it's better than COBOL, and it's VB-done-right and it's a good thing.
We agree actually about the no-language-is-perfect idea.
And also, I think exceptions are quite good things, and they can save lines of code. I really was just guessing as to what the grandparent might have meant about the extra lines of code. I can't really think of anything else.
No, I meant a couple years ago, but it's wonderful I can map memory in Java now. I suppose I serialize my object in there if I want to use it to store an object's properties?
The C/C++ thing, thanks for asking, I say that C/C++ is a single language which is distinct from C and this is because C/C++ is a multiparadigmed language. One of the paradigms is traditional C.
C++ alone is another question. I go by what I see in language benchmarks and note that C++ apps invariably use streamio, I don't. I've used C++ since 1994 and always felt that stream classes were sort of an example of how to make something object oriented, and to make the example succinct, simultaneously acting as an example of how NOT to make one.
I don't like using stream classes to do IO, therefore I must be talking not about C but C/C++. Indeed, you cannot know what kind of language I really use until you know the paradigm I prefer. Do you doubt there is an excellent paradigm in C++? There are paradigms in C++ where you do not use pointers!
This is the scary thing about C++, isn't it? The unknown, it immediately implies that it will be hard to understand, doesn't it? Any ole paradigm he wants!?! Scary.
universal database API: well, I have not worked very much with databases, my work with Sybase gave me the impression that they had libraries for any platform, at least they did the platforms I needed.
Posix threads? GUI? There is a lot of GUI toolkit--- OH. UNIVERSAL!!!! I get it. Show me all the choices Sun has made for me in C++? No they havn't. IBM made XML/XSLT parsers though, except they merged it with Xerces/Xalan now.
RPC? Well, the was CORBA... and there will be CORBA in the future. But I'm not advocating it. Frankly, I think RPC is not a great thing. Why exactly do you want to impose a function call idiom on a message send, exactly? I mean, messages and function calls can be handled differently with great success, because they are very different things... basically can be well handled asynchronously, messages are by their nature asynchronous. I had to work on a Java application which was using RPC (CORBA actually) and it had a dead lock. It took a while to find it. It was a totally different program with an infinite loop. Because the programmer liked thinking about the message as a function call, ther program had no way to react to a non-responsive application that did not reply to a message. Modern RPC now generally provides a timeout mechanism. So you can handle the call as a message. See, after the time out, what if the application answers... well, the function is over, I'm sorry, too late! But it's really just a message. Handle messages, it's fun. That's my advice.
I do like RPC for desktop plugin type functionality. It's good then because the idea is you are designing for local calling (LPC), and the use of RPC just means that you can actually have plugins remotely located. Cool.
Like a desktop clock that really is the same clock for the whole company ---no, the whole WORLD! Yes, that's it! But if you are designing something meant to be distributed and not provide a single experience like a desktop with remote parts, then it's actually easier to handle communication as communication rather than as a function call.
C/C++ is a Swiss Army Knife because it's multiparadigmed. You therefore have multiple blades, they all work differently.
There are libraries for everything and class libraries for everything you care to name.
Furthermore, these days there is probably an OSS solution that is free as in decently-done, or possibly done by IBM.
Hell, even the creator of C++ thinks there should be a garbage collector in C++.
No he doesn't.
he says:
I'd like to see the C++ standards committee explicitly acknowledge that garbage collection is a valid implementation technique for C++, but I don't want to make the C++ semantics dependent on a garbage coll
Slashdot Mirror
I'm not sure your point, you might be correct in that there are ways to commingle the two, the easiest being, do whatever you want to the code, just never release it, and there are no limitations. In that case the code you got was GPLed, the code you created is not, and it's undistributable.
My comment was about a distributor like SCO, and in the clearest way to make my point (good or bad) is to quote the section of the GPL that leads me to think this. It's below.
>7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.
copyright law allows you to use an illegal copy? No. The GPL clearly states it does not apply when commingled with royalty generating code. It's SCO's position that it's commingled with royalty generating code. If they are right, then the GPL does not apply, and you have an unlicensed copy. It doesn't matter what the GPL says or does not say, as you have an unlicensed copy, the GPL does not pertain, only copyright law.
Copyright law says you may not use the product unless given permission by the copyright holder.
no?
??? Is SCO baby godzilla where you stomp his tail to get fire? after all, he did burn Microsoft last time around the courthouse...?
Or is sco MOTHRA? Ok, I only said that cause I don't remember the names of the other monsters.
I've been posting much the same, I basically agree with you, but I think some of the applications they will get away with. It mostly is the KERNEL that is in question.
>Of course, they can fix this in a heartbeat -- just take their FTP server down.
I think they also have to recall all the distributions they have made that are in violation.
They told their customers "we won't sue you", but those distros are still not covered by the GPL anymore, because they cannot be under GPL and comingled with royalty generating IP, so other people could sue those customers for using IP that they do not actually have a licence for.
Since SCO indemnified them, it sanctioned their violation, and as the original distributor, that puts them in violation of the GPL too. They have to recall all violating distributions to get out of this.
At least, that's my analysis.
I think SCO might plead stupidity about that part (hopefully not getting away with it), but even so, I think there is another part.
They "indemnified" their current Linux customers. They said, "you go ahead and keep it!" But all the kernel and linux code that SCO doesn't own is there only under GPL. The GPL does not apply for the reason you stated. Those customers cannot have the non-SCO part of linux, but SCO has distributed it to them and told them they can keep it! SCO has therefore violated the GPL even based on the distributions prior to the suit.
SCO would have had to RECALL their Linux distributions!
These guys are too stupid to believe, they are probably just setting up a "but we ARE that stupid" defense for the SEC hearings.
I see 12 replies, so maybe this will be redundant.
The thing is, the GPL says you cannot have royalty generating IP in a GPL covered product. When SCO found out their IP was in there, they had to remove it. They had to RECALL IT! That's right, they had to recall their shipped copies of linux, not because their customers had no right to SCO IP, but because they don't have a right to everything else. E.g. you can't have GNOME because you have that under GPL, the violating IP means you don't have the GPL, and therefore SCO can't ship linux because of all the IP in there that does not belong to them. Of course the best example is not GNOME, but the parts of the kernel that are comingled with supposed SCO IP.
So when SCO indemnifies SCO Linux customers, they were saying SCO wouldn't sue them, but in reality, IBM now can! Those customers are using IBM IP without a license (because the GPL doesn't apply while SCO's royalty generating IP is in there with it!)
I mean, they have not read the GPL. I'm serious, this is not meant as a zealous snipe... really, they must not have read it. Of course they know there is a lot of IP in there. Of course they know it's not all theirs. If they read the GPL they would know they CAN charge for their IP, but in that case, it isn't under the GPL, it cannot be a part of linux. In that case they lose their right to use IBM, et al, code. It's as simple as can be, I mean, the GPL is not a long document. They have not thought about what allows them to make the distribution? The GPL? It's amazing. Of course, we know their theory is that the GPL is unenforceable, that it's really public domain.
Further, it's pretty clear they also don't understand software, I mean, linux has a lot more code than what they claimed is theirs, even if you give them JFS, etc..
Oh wait... they're just lying bastards. They have to set up a really strong "but I'm just stupid" argument for the SEC.
> I'm tired of people hashing out their stupid little pet peeves on the basis of 'national security'.
in that case I suppose the Terrorists Have Already Won!(tm)
man, I HATE it when you subconsciouly do an integration! Arg!
... witness on the one side, thin clients, on the other, vendor lock in. Go forth and destroy!
too bad the elitist douchebags are where all the good ideas come from. no, the trick is keeping the elitist douchebags around but tricking all the power away from the... of course, corporate America already solved that problem, and now they have OSS on their hands. You just can't keep an elitist douchebag down.
Carly truly killed the HP-way, we'll see if the HP brand follows, but I think it has a lot of staying power.
The calculator research center was shut down years ago, I keep expecting calculators to stop coming out, but I stupid that way, just improvements have stopped coming out I guess. I still see the for sale.
Oh well, I think the HP calculator is something that was evolving toward PDA from a scientific/engineering point of view, which would be cool.
It's the kind of thinking one associats with HP.
But there is a major flaw in your plan. Fiorina. She's mad I tell you!
you bring up a lot of interesting issues but some of them are more important to address than others.
C++ is many time inappropriate precisely because it lacks a standard class system as complete as Java's. High-level mean abstraction. Abstraction requires libraries.
I think you are saying that no standard library means the libraries that are available are not high level. No, if you can't find sufficient libraries, then fine, no argument, the Java one is better. I do not believe 100% of them are better.
I did read about a Java debugger that will go backwards... that's cool. Algorithm is more important. A lot of the optimizations for Java are just arranging things the same way you would have to to optimize in C++.
I think I see where you are coming from. I have a disposition to cross platform myself. And I admit C++ GUI stuff can trap you platform independence. C++ as a standard changes more slowly than a Java can, driven by Sun. C++ is at the WORA stage for console applications!
But C++ developers themselves are not stuck, because the design is open to a lot of different add ons, things that can almost redefine the language itself, like the Standard Template Library. The most efficient and fastest systems are pretty much still C/C++ applications. The generic programming and the way it compiles is really exceptional.
The linked list example has long ago been changed to, "you can't touch the collection in C++".
STL, the Standard Template Library from HP has been absorbed into the C++ Standard Library. There is nothing like generic programming for some good list linking. I admit, I had been one of the list-linkers you allude to, linking lists and writing special collections all the time, casting my void pointer, much to the scorn of other programmers who had gone in from the jungle. But no more!
The STL handles lists, maps, hashes, deques, vectors, even strings! Much of the indirection compiles away with templates.
Java now has generic programming syntax, but I do not believe it compiles away because the type system in Java, but I could be mistaken as I have not use Java generic programming. I do think that is a good addition to Java anyway as it's a powerful idiom.
In fact, I think C++ and Java can really share a big space, I'm fine with Java tying business servers together (many written in C++, probably). But C++ is not going to stay out of GUI's because speed will always matter in GUIs.
well, one, I bet you someone does have a class system to abstract differences between Oracle, Sybase, MySQL, etc. etc. Without checking, I would still bet that.
One reason there are not standard solutions integrated into the language is it's not necessarry, right, the solutions provided by third parties integrate just fine. Yes, it's nice to have a standard library everyone can learn and commit to memory, that is going to be available on every platform the language is available on.
However, one reason that doesn't happen is because there is no perfect solution. Garbage Collection is an example. There is no compelling single solution for that, and having a company like Sun just choose one is not the problem. The problem is there are multiple competing solutions. Sun choosing Swing for me is NOT BETTER than me getting to choose my own control system.
I WANT to think about what is the appropriate algorithm, library, or class. I'm supposed to learn these things to be a software engineer. If you chose for me, you need to make sure you have something with real staying power, thus the STL is now a part of C++, but no GUI toolkit is. The STL will always be useful, from now on. Who can say what GUI approach will win in the end yet?
The idea with C++ is not to have everything in the standard library, really, though I think stream IO is a big exception, it's only for very common things any program does. Very useful things like regex parsing is supposed to be in libraries. It's not hard to find good candidates. And if you don't care to look too deeply and judge the alternatives on low level merits, it's not to hard to find out the most commonly used, or best supported library, and use that.
It does make C++ complex. That is, a Java book covers really everything you need (but not in detail, of course), but it can point you in the direction, it can say, "use AWT or SWING". A C++ book can't do that. It is telling you about a language, and you still need to find the classes and toolkits you will rely on for a lot of parts.
To me that's fine, that's C++ matching the real (not ideal) world, with the real (and ideal) chaos of the practical world.
One last metaphor: A multiple-choice test is easier to write, easier to take, and easier to grade, but it's not a "better test" than an essay based test. The chaos of essay answers, their unpredicability, their potential to give a valid answer the author of the test didn't anticipate, these all make the essay test the "better" type of test.
PS: I think this has been a very interesting conversation, thank you for sharing your ideas. I hope you understand my comments in the same vien.
I am sure of myself, but I am sure I might be wrong too. And there is a great deal of room for Java to mature and me to become convinced it's all I need anymore. But by then it will have operator overload.
Ok, I love a good metaphor--- wait, I mean, I even love bad metaphor... but I just don't see Java as the power tools to C++ swiss army knife. I see Java as the kind of quick construction mechanism. Like staple guns, where C++ would be the nail gun.
Regardless, that's probably pushing the metaphor too far. Basically, Java is great if it really is faster to develop or deploy. I have not seen that yet. I've inherited Java programs with bad memory management problems. The code is very C++ like in that I don't see how it's quicker to write than C++. It needs to be compiled. I just don't see the advantage. For me to believe in a VM type solution or scripting language, I need to see the programming metaphor change or at least to see it handle a special problem domain.
I see that java is getting the kind of support needed to support the B2B problem frame. I see how it has things making it nice to develop custom business systems. Not because of Java, mind you, but because of it's standard class system and the support of Sun, IBM, HP, etc. to make it fully featured in that area.
Judging as a language, I don't see the benefits. As a platform... of course I see the massive support and some working solutions which is all it takes to convince me Java is worthwhile.
Where we really disagree is C++ inappropriateness for high level work. I don't believe that. You can have automatic garbage collection if you want, in C++, you can use pointer-free paradigms (though I think that's overkill, best to limit pointer handling, but allow it), you can get as high level as you like.
The only wrench in the works there is that there are too many choices, there are messy and even bad paradigms available in C++. Perhaps it's personal, but I don't mind the jungle. I think it's possible and worthwhile to have a lot of options and have to learn the meaning of each option before attempting to use it.
e.g. if it's a big problem that the C++ stdlib does not have a GUI library... then I'd say, standardize one, you dont' need a whole new language for that, imho.
ok, I see what you meant about the database API, not across hardware, accross database vendors. Surely someone abstracts that, otherwise you write your own classes in such a way as to be able to add support for other DBs.
I think you are onto something, this is a niche of Java, it's a product built to fit the business integration crowd, a big crowd to be sure, and it's better than COBOL, and it's VB-done-right and it's a good thing.
We agree actually about the no-language-is-perfect idea.
And also, I think exceptions are quite good things, and they can save lines of code. I really was just guessing as to what the grandparent might have meant about the extra lines of code. I can't really think of anything else.
No, I meant a couple years ago, but it's wonderful I can map memory in Java now. I suppose I serialize my object in there if I want to use it to store an object's properties?
The C/C++ thing, thanks for asking, I say that C/C++ is a single language which is distinct from C and this is because C/C++ is a multiparadigmed language. One of the paradigms is traditional C.
C++ alone is another question. I go by what I see in language benchmarks and note that C++ apps invariably use streamio, I don't. I've used C++ since 1994 and always felt that stream classes were sort of an example of how to make something object oriented, and to make the example succinct, simultaneously acting as an example of how NOT to make one.
I don't like using stream classes to do IO, therefore I must be talking not about C but C/C++. Indeed, you cannot know what kind of language I really use until you know the paradigm I prefer. Do you doubt there is an excellent paradigm in C++? There are paradigms in C++ where you do not use pointers!
This is the scary thing about C++, isn't it? The unknown, it immediately implies that it will be hard to understand, doesn't it? Any ole paradigm he wants!?! Scary.
universal database API: well, I have not worked very much with databases, my work with Sybase gave me the impression that they had libraries for any platform, at least they did the platforms I needed.
Posix threads? GUI? There is a lot of GUI toolkit--- OH. UNIVERSAL!!!! I get it. Show me all the choices Sun has made for me in C++? No they havn't. IBM made XML/XSLT parsers though, except they merged it with Xerces/Xalan now.
RPC? Well, the
was
CORBA... and there
will be
CORBA in the future. But I'm not advocating it. Frankly, I think RPC is not a great thing. Why exactly do you want to impose a function call idiom on a message send, exactly? I mean, messages and function calls can be handled differently with great success, because they are very different things... basically can be well handled asynchronously, messages are by their nature asynchronous. I had to work on a Java application which was using RPC (CORBA actually) and it had a dead lock. It took a while to find it. It was a totally different program with an infinite loop. Because the programmer liked thinking about the message as a function call, ther program had no way to react to a non-responsive application that did not reply to a message. Modern RPC now generally provides a timeout mechanism. So you can handle the call as a message. See, after the time out, what if the application answers... well, the function is over, I'm sorry, too late! But it's really just a message. Handle messages, it's fun. That's my advice.
I do like RPC for desktop plugin type functionality. It's good then because the idea is you are designing for local calling (LPC), and the use of RPC just means that you can actually have plugins remotely located. Cool.
Like a desktop clock that really is the same clock for the whole company ---no, the whole WORLD! Yes, that's it! But if you are designing something meant to be distributed and not provide a single experience like a desktop with remote parts, then it's actually easier to handle communication as communication rather than as a function call.
C/C++ is a Swiss Army Knife because it's multiparadigmed. You therefore have multiple blades, they all work differently.
There are libraries for everything and class libraries for everything you care to name.
Furthermore, these days there is probably an OSS solution that is free as in decently-done, or possibly done by IBM.
Hell, even the creator of C++ thinks there should be a garbage collector in C++.
No he doesn't.
he says:
I'd like to see the C++ standards committee explicitly acknowledge that garbage collection is a valid implementation technique for C++, but I don't want to make the C++ semantics dependent on a garbage coll
works well in politics... when you do something malicious, always be prepared to assign it to your "stupidity".
Step one: elect a president everyone thinks is stupid.
Step two: do whatever
Step three: oops! we're just so stupid! Innocent harmless stupid person over here, bless our hearts!
...people do. Stupid people.
>With a good modern garbage collector, the overhead and pause time is minimal.
they are obsessively worried about dangling pointers --- hello!?!
Java vs. C++, I keep hearing about "rapid development"... is there something about rapid development that makes it hard to do things quick-n-dirty?
... just a guess.