I've started Eclipse and tried to use it. Even without having anything loaded the thing's VM footprint is 700M. So don't try to tell me you can get away with less than a gigabyte of memory if you want it to run reasonably.
And don't even get me started about Java's complete inability to do reasonable lambda expressions of having to go through the clunky reflection API to even think about treating classes as objects. I can even get that kind of power in C++, which is a significantly older language with tools that can run in a reasonable amount of space.
Java is a horrible ugly monstrosity that only exists because of some manager's wet dream about no longer having memory errors and not having to retrain legions of C and C++ programmers. Programming in it even induces COBOL fingers because of an obsessive devotion to ridiculouslyLongMethodNamesBecauseSomehowThatMakes ThemEasierToUnderstand and an insitutional inability to make useful utility facades for common tasks like creating a buffered output stream for a file.
And the worst part is, people boot an OS (some people call it a VM) every time they want to start an app. The biggest deal I've seen in the systems level Java shops I've worked in is how to write your programs in such a way that you can just start up threads in existing VMs instead of going through the pain of starting a new one. Lets just pray for synchronization errors that have threads stomping on eachother why don't we?
Python is a much better language. It isn't a slow bloated monstrosity with a development environment that takes at least a gigabyte of RAM to run reasonably. Additionally, you don't have a compile, edit, link cycle to worry about. It's easy to prototype out your function on the command line before putting it into your code.
Java is a big mistake. I liked it once, but I've grown to loathe it and its stupid runtime environment. It's the most overhyped piece of garbage in the IT industry today. It will be remembered in the future with the same fondness now reserved for COBOL.
I visited Australia in 1997, and I know a lot of people from other parts of Asia. Australia is nothing like any of the parts of Asia I've had described to me. It was like going to Canada.
So, culturally speaking, Australia is not Asian. It's western. Perhaps not like the US exactly, but it certainly bears much more of a resemblance to Europe as a whole than any part of Asia.
I do know that Australia was seeing a lot of Asian immigration, and there's a lot of commerce with Asia that goes on in Australia. Perhaps over time this will change things. Personally, it seemed to me that many Australians felt this to be deeply scary, even if they wanted to ride it instead of fight it.
And they still think the same thing today - because Newton's Laws still hold.
The equations and ideas are still around, sure. But, we know they're wrong. Not wrong enough to be important much of the time, but they are still wrong. For example, they presume that we live in a 3 dimensional space that has no curvature in any other dimensions. And numerous experiments in the past few decades have confirmed that this is definitely not the case.
So, Newton is wrong. Einstein likely is too. All these ideas are just the best approximation we have for modeling various phenomena. That's all.
Now, I personally am extremely skeptical of anybody who claims they've managed to contruct a device that violates such a cherised and well-tested principle of physics as the conservation of energy. But if they can provide a repeatable demonstration of this, then I'll be forced to change my view of the world.
I think the people mentioned in the article above are little more than snake oil vendors conning unwise investors out of their money. I think that's much more likely than the idea that they've found some interesting bit of physics which everybody was heretefor unaware. Especially physics involving magnets, which have been studied very carefully for a long time. But, I could be wrong. And any true scientist would admit that though one possibility was far more likely than the other, the chance for the other is not 0.
I wish I had mod-points. That's a really interesting proposition. I have no opinion on its correctness (other than to think it has some small chance of being true) though, just its interestingness.
Nope, I'm not saying that at all. I'm saying that corporations who take advantage of this are partly at fault and should be held to task for it. So should the politicians and ourselves for supporting the behavior by buying products from the companies that do it or voting for the politicians that do it.
The GPL has always been about principle, and it's never been about winning. I'm not sure I agree with the principle here, but I don't think an argument based on winning is very relevant.
So, before I come up with a new use for a red swingline stapler, or feature one in some piece of media, I have to get the permission of the company who makes them? That argument just doesn't fly. I don't care what relationship that company had with Blizzard's product and business model, Blizzard had no right to do what they did. Or rather, they were granted a right by a stupid law that shouldn't exist and they should've had the sense not to invoke.
Can you sue your sewage treatment company for selling your processed feces to a farm that grows GMO food? I didn't think so. You have a pretty intimate relationship with that stuff. Your own body made it.
And I don't care what you say about corporate ethics. If corporations have no ethics, we should punish them to make sure they behave properly when they do stupid things like buy bad legislation and use it for evil purposes. And if they do have ethics, they should be punished for violating them by buying bad legislation and using it for evil purposes.
I will fault the corporation because it's the corporation's money that causes legislators to pass this stupid garbage in the first place. So, when corporations stop hiring lobbyists and donating to political campaigns I will stop punishing them for bad laws.
I don't know if simply hunting down a witness for someone is sufficient. I suspect that they would have to prove that he knew that the person who hired him intended harm to the witness.
The revealed details certainly don't justify a conviction, but they definitely do justify an arrest if there's sufficient evidence to warrant a trial. I was withholding judgement of the FBI's tactics until I learned what he was accused of. Now that I know, I'm not unhappy with them.
And never mind that Google, being a private enterprise, can present its results any way it wants (assuming that the claims are accurate), so that there's no grounds for a lawsuit. This whole incident smells frivolous.
This is only mostly true. If google is using their market dominance of the search engine market in an attempt to surpress the rise of any other search engine, then they are doing something wrong. And if they actually have over 80% of the search engine market, it is likely even illegal. Using your monopoly position to maintain your monopoly is illegal, and it should be illegal. It's an anti-free market situation.
I really doubt google is doing this, and it will be hard to prove if they are. But it is a question that's worthy of paying attention to, whereas the first ammendment argument is clearly completely bogus on a whole number of grounds, the least of which is the google is a private enterprise and has no responsibility to uphold the fist ammendment.
it only appears so. The GIOP protocol itself is completely asynchronous, invocations can be arbitrarily interleaved, results don't even need to be reported in the same order the requests came in. What is synchronous, however, are the language bindings. Then again, how else would you embed remote invocations into C and similar languages? Without first class functions is is simply too cumbersome to compose a program out of parallel invocations and continuations. The only way out are threads, and multithreading should properly be written multithreating.
So, it appears you agree with me. I wasn't making a point about the underlying protocol. I was making a point about the idea of RPC. Sure, if you want to stop dealing with RPC in C as a function call you can start treating it as a message that you're sending and set up the appropriate stuff to wait for a reply. But then you've broken the whole procedure call semantics for C.
My point is that procedure call semantics are entirely the wrong model for a network message. Code should treat a network message in a fundamentally different way. Ideally, of course, the underlying protocol support asynchronousness by having tags in replies that can be used to match them up with previous requests and such. But that's a side issue here.
But consider a functional language. It would be ridiculously easy to define a language mapping where you could explicitly set off parallel invocations, or you could call each invocation with a continuation that tells it what to do when it eventually returns. Nobody did this, and the only explanation is that the guys at OMD did not know Standard ML. That explains some other major blunders, like missing recursive structures, but I digress...
Perhaps in a language in which procedure calls no longer have the same semantics it would make sense for network messages to be modeled as procedure calls. I was also thinking of an experimental language I heard of long ago for programming for massively parallel systems. I believe it was called Actor (and I know there was an unrelated commercial language of the same name, but this isn't it). In it, every single message you sent to an object was asynchronous. And of course, modeling a network message there as a procedure call doesn't encourage bad assumptions about synchronousness.
But, if you make a function call in your code, not knowing that it is remote, you don't expect 90% of the time making the call to be in simply getting the arguments to the call or getting the result back. That is why I think RPC isn't the right thing. Request response sure, but don't try to hide it as an innocent function function call in your code.
Twisted has deferreds. Those are a great abstraction. And if every remote function call were done as a deferred, that would be fine with me. But I'd no longer call it RPC because one of the fundamental assumptions in calling a procedure, that it is done when you get back control, is no longer true.
And most people don't put a lot of thought into their APIs, and designing a good network API is even harder. Ideally a good network API should survive complete re-writes of either side without having to change at all. Most people don't put enough thought into designing function APIs for that to be true if they apply the same care and discipline into designing a network API.
I guess what I'm saying is that pretending a network message is the same as a function call leads people down a couple of paths that are very bad and lead to systems that are slow and not robust with regards to change. There are ways to code carefully to avoid these paths, but that means you can no longer treat network messages as function calls in the strictest sense. So I don't think they deserve to be called RPC anymore.
The speed of light is a constant. Latency will never improve beyond a certain point. For all but the simplest things, RPC is the wrong model for dealing with the problem of communicating with other systems.
Also, the abstraction layer of function calls is the wrong place to put the communication of disparate, unrelated systems. It encourages too many assumptions about the implementation of either side. There is too much hidden state in the caller and reciever of the messages.
If I need somebody to go out and conduct a bunch of interviews (like TFA, but let me reiterate that TFA is not an InfoWorld article, it was published by eWeek) then I hire somebody who is fundamentally a reporter. I need somebody who knows how to reach somebody on the phone, ask some questions, and transcribe the results. A lot of people with deeper technical background won't do that. Believe it or not, they talk tough (like the grandparent) but when the chips are down and they have the floor they not only fail to ask "the tough questions," in fact they often stare at their shoes, fiddle with a pen, and say nothing. I do not exaggerate; some of my writers, though they are highly competent and intelligent people, would need threat of guerilla dental surgery in order to actually call somebody on the phone and get a quote. So I don't use them for those types of articles.
This, I can easily see.:-)
Your comments have been most informative and worth reading. Thanks a lot for taking the time to respond to a random irritating flame in this forum. I learned a lot.
In my opinion, I think the base problem is people's current attitudes towards their workplaces combined with a broken incentive structure in the publishing industry.
For the first, people need to start seeing corporations as a form of governance, who's activities need to be viewed with the same level of suspicion and scrutiny. People need to feel proud to say real things about the companies at which they work instead of scared and vaguely dirty.
For the second, while the pernicious effect of being sponsored by the very people you report on is well recognized, the pernicious effect of being reliant on them for the material you publish isn't. If it becomes known that you would rather publish things that contained bias rather than not have anything to publish at all, that becomes a lever that can be used to affect the slant of the articles in your magazine.
The first and the second force combined make sure that nobody ever steps forward with the real story, and the reporter never looks very hard for it.
I too have noticed a tendency in the trade press to post advertisements as news. I also had a fairly simple-minded view of why this was the case. Thanks for educating me.
They certainly aren't required to. But if they want people to take their commitment to the openness of CLR and C#, then they had better. Otherwise, the OSS community is perfectly justified in being suspicious.
So, do the kids get to have a trial where the facts are aired publicly by both parties before they are punished? This is about lack of due process, not about a lack of privacy.
Now, I don't necessarily think that due process is needed for the school to govern behavior of students on school grounds. But I definitely think it's needed before the school can punish students for behavior that's so undisruptive to the school that the only way they can find out about it is reading a blog.
The first set of things are not things I'm willing to do. I only allow RSA authentication on most of my boxes. I allow passwords on one, and I give logins and mail accounts to friends who may travel without informing me. And I feel that not responding to pings is rude, and breaks an important diagnostic tool.
On the second set of things, I've done all those except for the one box that I still allow password authentication from.
I think, what I may do, is set up an iptables rule that throttles new connections on a per IP hash bucket basis. My problem is that sometimes I run things over ssh that like making a bunch of connections. It would be really nice to just throttle unsuccessful login attempts on a per-IP basis. I am really surprised that ssh hasn't grown this feature.
The above poster's comment is probably the most important in this thread. Unit testing is helpful no matter what you do or where or in what language. Some frameworks and tools make it easier than others. But an approach that involves a lot of rigorous unit tests is going to make your development go much faster and more surely. It's a good idea no matter what tools you use.
In fact, regardless of whether or not you make the ill-advised leap from C++ to Java, a rigorous set of unit tests of your system will help you. You should write them even if you're just going to be re-architecting your existing C++ code.
As for changing programming languages...
I despise Java. I think booting a whole OS just to run a program is silly. I think the fact that people invent all kinds of new ways to make sure they can start new Java things from an existing VM so they don't have to boot the OS (otherwise known as a VM) again in order to run a new program is amusing and telling. Java is a 'joiner' virus technology that encourages you to do everything in Java and makes it really hard not to.
I was a big Java fan when it first came out. Experience has taught me how icky it is.
People tell you Java is more productive because you don't have pointer problems or the complex and arcane syntax of C++. These claims are vastly overblown. In truth, the language is nearly as verbose as COBOL, and for as little reason. It lacks the expressive power of C++, Python, Ruby, Lisp or Perl, and that will lead to you writing a lot of stupid vaguely repetitive code for no purpose than to provide thunking layers in the rather incapable and inexpressive type system. The only thing Java got right was packages, and Python and Perl (and possibly Ruby) do them just as well.
Slashdot Mirror
Well, here's the output of top on my system.
I've started Eclipse and tried to use it. Even without having anything loaded the thing's VM footprint is 700M. So don't try to tell me you can get away with less than a gigabyte of memory if you want it to run reasonably.
And don't even get me started about Java's complete inability to do reasonable lambda expressions of having to go through the clunky reflection API to even think about treating classes as objects. I can even get that kind of power in C++, which is a significantly older language with tools that can run in a reasonable amount of space.
Java is a horrible ugly monstrosity that only exists because of some manager's wet dream about no longer having memory errors and not having to retrain legions of C and C++ programmers. Programming in it even induces COBOL fingers because of an obsessive devotion to ridiculouslyLongMethodNamesBecauseSomehowThatMakes ThemEasierToUnderstand and an insitutional inability to make useful utility facades for common tasks like creating a buffered output stream for a file.
And the worst part is, people boot an OS (some people call it a VM) every time they want to start an app. The biggest deal I've seen in the systems level Java shops I've worked in is how to write your programs in such a way that you can just start up threads in existing VMs instead of going through the pain of starting a new one. Lets just pray for synchronization errors that have threads stomping on eachother why don't we?
Python is a much better language. It isn't a slow bloated monstrosity with a development environment that takes at least a gigabyte of RAM to run reasonably. Additionally, you don't have a compile, edit, link cycle to worry about. It's easy to prototype out your function on the command line before putting it into your code.
Java is a big mistake. I liked it once, but I've grown to loathe it and its stupid runtime environment. It's the most overhyped piece of garbage in the IT industry today. It will be remembered in the future with the same fondness now reserved for COBOL.
I visited Australia in 1997, and I know a lot of people from other parts of Asia. Australia is nothing like any of the parts of Asia I've had described to me. It was like going to Canada.
So, culturally speaking, Australia is not Asian. It's western. Perhaps not like the US exactly, but it certainly bears much more of a resemblance to Europe as a whole than any part of Asia.
I do know that Australia was seeing a lot of Asian immigration, and there's a lot of commerce with Asia that goes on in Australia. Perhaps over time this will change things. Personally, it seemed to me that many Australians felt this to be deeply scary, even if they wanted to ride it instead of fight it.
You can only get away with doing that if you're involved in national level politics in some deeply icky way.
The equations and ideas are still around, sure. But, we know they're wrong. Not wrong enough to be important much of the time, but they are still wrong. For example, they presume that we live in a 3 dimensional space that has no curvature in any other dimensions. And numerous experiments in the past few decades have confirmed that this is definitely not the case.
So, Newton is wrong. Einstein likely is too. All these ideas are just the best approximation we have for modeling various phenomena. That's all.
Now, I personally am extremely skeptical of anybody who claims they've managed to contruct a device that violates such a cherised and well-tested principle of physics as the conservation of energy. But if they can provide a repeatable demonstration of this, then I'll be forced to change my view of the world.
I think the people mentioned in the article above are little more than snake oil vendors conning unwise investors out of their money. I think that's much more likely than the idea that they've found some interesting bit of physics which everybody was heretefor unaware. Especially physics involving magnets, which have been studied very carefully for a long time. But, I could be wrong. And any true scientist would admit that though one possibility was far more likely than the other, the chance for the other is not 0.
I wish I had mod-points. That's a really interesting proposition. I have no opinion on its correctness (other than to think it has some small chance of being true) though, just its interestingness.
Nope, I'm not saying that at all. I'm saying that corporations who take advantage of this are partly at fault and should be held to task for it. So should the politicians and ourselves for supporting the behavior by buying products from the companies that do it or voting for the politicians that do it.
The GPL has always been about principle, and it's never been about winning. I'm not sure I agree with the principle here, but I don't think an argument based on winning is very relevant.
So, before I come up with a new use for a red swingline stapler, or feature one in some piece of media, I have to get the permission of the company who makes them? That argument just doesn't fly. I don't care what relationship that company had with Blizzard's product and business model, Blizzard had no right to do what they did. Or rather, they were granted a right by a stupid law that shouldn't exist and they should've had the sense not to invoke.
Can you sue your sewage treatment company for selling your processed feces to a farm that grows GMO food? I didn't think so. You have a pretty intimate relationship with that stuff. Your own body made it.
And I don't care what you say about corporate ethics. If corporations have no ethics, we should punish them to make sure they behave properly when they do stupid things like buy bad legislation and use it for evil purposes. And if they do have ethics, they should be punished for violating them by buying bad legislation and using it for evil purposes.
I will fault the corporation because it's the corporation's money that causes legislators to pass this stupid garbage in the first place. So, when corporations stop hiring lobbyists and donating to political campaigns I will stop punishing them for bad laws.
It would've been really nice if they had let him give his talk first though. :-) But yes, I agree.
I don't know if simply hunting down a witness for someone is sufficient. I suspect that they would have to prove that he knew that the person who hired him intended harm to the witness.
The revealed details certainly don't justify a conviction, but they definitely do justify an arrest if there's sufficient evidence to warrant a trial. I was withholding judgement of the FBI's tactics until I learned what he was accused of. Now that I know, I'm not unhappy with them.
You aren't disagreeing with me, and I think you're perfectly correct and have an excellent point. So, why is the tone of your message adversarial?
This is only mostly true. If google is using their market dominance of the search engine market in an attempt to surpress the rise of any other search engine, then they are doing something wrong. And if they actually have over 80% of the search engine market, it is likely even illegal. Using your monopoly position to maintain your monopoly is illegal, and it should be illegal. It's an anti-free market situation.
I really doubt google is doing this, and it will be hard to prove if they are. But it is a question that's worthy of paying attention to, whereas the first ammendment argument is clearly completely bogus on a whole number of grounds, the least of which is the google is a private enterprise and has no responsibility to uphold the fist ammendment.
So, it appears you agree with me. I wasn't making a point about the underlying protocol. I was making a point about the idea of RPC. Sure, if you want to stop dealing with RPC in C as a function call you can start treating it as a message that you're sending and set up the appropriate stuff to wait for a reply. But then you've broken the whole procedure call semantics for C.
My point is that procedure call semantics are entirely the wrong model for a network message. Code should treat a network message in a fundamentally different way. Ideally, of course, the underlying protocol support asynchronousness by having tags in replies that can be used to match them up with previous requests and such. But that's a side issue here.
Perhaps in a language in which procedure calls no longer have the same semantics it would make sense for network messages to be modeled as procedure calls. I was also thinking of an experimental language I heard of long ago for programming for massively parallel systems. I believe it was called Actor (and I know there was an unrelated commercial language of the same name, but this isn't it). In it, every single message you sent to an object was asynchronous. And of course, modeling a network message there as a procedure call doesn't encourage bad assumptions about synchronousness.
But, if you make a function call in your code, not knowing that it is remote, you don't expect 90% of the time making the call to be in simply getting the arguments to the call or getting the result back. That is why I think RPC isn't the right thing. Request response sure, but don't try to hide it as an innocent function function call in your code.
Twisted has deferreds. Those are a great abstraction. And if every remote function call were done as a deferred, that would be fine with me. But I'd no longer call it RPC because one of the fundamental assumptions in calling a procedure, that it is done when you get back control, is no longer true.
And most people don't put a lot of thought into their APIs, and designing a good network API is even harder. Ideally a good network API should survive complete re-writes of either side without having to change at all. Most people don't put enough thought into designing function APIs for that to be true if they apply the same care and discipline into designing a network API.
I guess what I'm saying is that pretending a network message is the same as a function call leads people down a couple of paths that are very bad and lead to systems that are slow and not robust with regards to change. There are ways to code carefully to avoid these paths, but that means you can no longer treat network messages as function calls in the strictest sense. So I don't think they deserve to be called RPC anymore.
Why I think CORBA and other forms of RPC are a bad idea.
Here is the paper in brief...
The speed of light is a constant. Latency will never improve beyond a certain point. For all but the simplest things, RPC is the wrong model for dealing with the problem of communicating with other systems.
Also, the abstraction layer of function calls is the wrong place to put the communication of disparate, unrelated systems. It encourages too many assumptions about the implementation of either side. There is too much hidden state in the caller and reciever of the messages.
This, I can easily see. :-)
Your comments have been most informative and worth reading. Thanks a lot for taking the time to respond to a random irritating flame in this forum. I learned a lot.
In my opinion, I think the base problem is people's current attitudes towards their workplaces combined with a broken incentive structure in the publishing industry.
For the first, people need to start seeing corporations as a form of governance, who's activities need to be viewed with the same level of suspicion and scrutiny. People need to feel proud to say real things about the companies at which they work instead of scared and vaguely dirty.
For the second, while the pernicious effect of being sponsored by the very people you report on is well recognized, the pernicious effect of being reliant on them for the material you publish isn't. If it becomes known that you would rather publish things that contained bias rather than not have anything to publish at all, that becomes a lever that can be used to affect the slant of the articles in your magazine.
The first and the second force combined make sure that nobody ever steps forward with the real story, and the reporter never looks very hard for it.
I too have noticed a tendency in the trade press to post advertisements as news. I also had a fairly simple-minded view of why this was the case. Thanks for educating me.
They certainly aren't required to. But if they want people to take their commitment to the openness of CLR and C#, then they had better. Otherwise, the OSS community is perfectly justified in being suspicious.
So, do the kids get to have a trial where the facts are aired publicly by both parties before they are punished? This is about lack of due process, not about a lack of privacy.
Now, I don't necessarily think that due process is needed for the school to govern behavior of students on school grounds. But I definitely think it's needed before the school can punish students for behavior that's so undisruptive to the school that the only way they can find out about it is reading a blog.
The first set of things are not things I'm willing to do. I only allow RSA authentication on most of my boxes. I allow passwords on one, and I give logins and mail accounts to friends who may travel without informing me. And I feel that not responding to pings is rude, and breaks an important diagnostic tool.
On the second set of things, I've done all those except for the one box that I still allow password authentication from.
I think, what I may do, is set up an iptables rule that throttles new connections on a per IP hash bucket basis. My problem is that sometimes I run things over ssh that like making a bunch of connections. It would be really nice to just throttle unsuccessful login attempts on a per-IP basis. I am really surprised that ssh hasn't grown this feature.
I haven't succumbed to any of those attacks yet, and I'm not likely to. But I would like to know what to do to reduce their frequency.
The above poster's comment is probably the most important in this thread. Unit testing is helpful no matter what you do or where or in what language. Some frameworks and tools make it easier than others. But an approach that involves a lot of rigorous unit tests is going to make your development go much faster and more surely. It's a good idea no matter what tools you use.
In fact, regardless of whether or not you make the ill-advised leap from C++ to Java, a rigorous set of unit tests of your system will help you. You should write them even if you're just going to be re-architecting your existing C++ code.
As for changing programming languages...
I despise Java. I think booting a whole OS just to run a program is silly. I think the fact that people invent all kinds of new ways to make sure they can start new Java things from an existing VM so they don't have to boot the OS (otherwise known as a VM) again in order to run a new program is amusing and telling. Java is a 'joiner' virus technology that encourages you to do everything in Java and makes it really hard not to.
I was a big Java fan when it first came out. Experience has taught me how icky it is.
People tell you Java is more productive because you don't have pointer problems or the complex and arcane syntax of C++. These claims are vastly overblown. In truth, the language is nearly as verbose as COBOL, and for as little reason. It lacks the expressive power of C++, Python, Ruby, Lisp or Perl, and that will lead to you writing a lot of stupid vaguely repetitive code for no purpose than to provide thunking layers in the rather incapable and inexpressive type system. The only thing Java got right was packages, and Python and Perl (and possibly Ruby) do them just as well.