(1) yes, I understand the kinds of safety that Java promises, do you understand that this is not the only or even main kind of bug one finds with systems?
(2) I am not being macho about it because I am agreeing that higher level abstractions need to be used to ensure there is a safety net... I'm just also pointing out that these higher level abstractions are available in C++ and do not require a VM level, at all. Further the VM imposed it's own limitations and problems, so it does not compare favorably to other high level solutions.
(3) It's not so much like seat belts... I would say that C++ is already a seat belt compared to the basic starting point of machine language. It's more like Air Bags, which have the great advantage of saving drunk drivers that drive head on into a tree, but also have a way of decapitating children during fender benders, or taking someone's legs off because they unwisely put their feet on the dash while waiting for their spouse to come out of a store.
See, I think that the people traveling over 60 MPH should take the risk, and being still in a parking lot ought to be risk free.
When I am working as a professional developer, I can prepare my safety standards, use the abstractions that avoid common mistakes.
I'm waiting for the argument that these problems cannot be addressed in C++ with class systems.
Instead mostly I hear about how there is not one solution forced on all C++ developers, as if that's a bad thing! If Java really has The One Full Solution To End All Solutions, of course it'd be great! But can such a thing exist? I'm not holding my breath while it gets implemented, and I certainly have yet to see such a thing.
Well, when using Java rather than finding that I've suddenly been saved the trouble of doing things I already know how to do, I find that I'm powerless.
I needed to tell the garbage collector to collect right now, not later when I'm making another query, but right now, because since the object was part of a connection, the garbage collector caused problems when I had already created a new connection. The new connection was already allocated, according to the Java source code it was a second, totally separate, object. But because of connection pooling, I found it was not really a new object, but what partially reused, and when the previous object was cleaned, it caused problems with the new object (loss of connection mid-query).
According to the Java source, this was a different object altogether.
But since in Java I "don't care" where the memory is really coming from, the JDBC implementation could play whatever game it wanted and give me reused components. Java saves me from having to say when to delete, and prevents me from getting to say when to delete. I lose power and gain nothing.
OH, I fixed it... by setting the appropriate references to null at the appropriate time. But a different VM might break my solution, it was not based on the Java syntax, but on the peculiarities of the VM I was using. In C++ I'm sure I would have been able to dig deeper for a work around that would continue to work (that has been my experience), but in Java I had to leave it on the precipice to break again with an updated VM or different JDBC driver.
This sort of thing sucks, and it's endemic to hand-holding and treating-like-a-baby. Never in my life, in code or without, have I ever seen a system that protected people for their own good that didn't royally screw those that could protect themselves. Ok, if we are talking about railings for the tourists hiking in Yosemite, I guess I don't mind. But when we are talking about a skilled proffession that is a life long endeavor of learning and solution building... I want tools to build with. I want a fricking nail gun, I'll be safe where I point it.
What really gets me is that C++ has the best of both worlds. Any of these issues can and have been solved in C++ and probably nicely wrapped in a stable class system.
If you use a class to manage your memory, you can have all the same protections, and automagical garbage collection, etc. etc.
In fact, garbage collecting memory management schemes have been available for C++ (and C) in various forms for a long long while.
The general reason they are not used more is that the machine really cannot efficiently do that job. You know more about your use of memory, and what the semantic relationships are, than the compiler or the VM.
If a garbage collection is invented that really lives up to the promise, it will be available in C++, all without building a whole language around something that hasn't really arrives and may never arrive.
I've worked with many Java based systems now and I'm not noticing the code is easier or less buggy, at all, not even with respect to the misuse of memory. Especially considering that I could leave 1K a second and still have days and days before my C++ applications reaches the memory consumption a similar Java processes STARTS out consuming.
btw: as for these buffer overflows, etc. You can write malloc and free such that they watch for this sort of thing. It just costs a few bytes per allocation and some processing power. Debug libraries often do this already. If you do that, it's still more efficient than the VM approach.
It all reminds me of when I thought Applesoft Basic was the bees knees, it was good enough for anything... it ruled, other languages were just not nec. But then again, I was 13, it only lasted a few months... I grew up.
Which brings me to another theorem about craftsmanship. Powerful tools can be dangerous. Safe tools tend to be impotent.
>then what's so bad about not worrying about those things?
(1) what is the cost? Is the application consuming 10x the resources such as memory?
(2) does it really solve the problem? e.g. Java's memory management, you still have memory management problems and bugs which are for all intents and purposes memory leaks, but you give up the ability to address these problems (unless you use your own VM).
> Though they know they have to be careful, they still repeat the same mistakes over and over. Right?
no. I don't think they do. I think we are learning from our mistakes.
And if they want to do something to make it easier, then they encapsulate their solution in a class. Instead of the solution being, "use the magic bullet", it's "stop shooting yourself in the foot" and C++ classes are there exactly for this purpose.
The advantage is such solutions can be optimal. In spite of claims to the contrary, I don't think a VM approach could ever be optimal.
Frankly if I really believed that these bugs were the most pernicious, took the most develper time, AND that VM's and scripting languages really were faster to develop in, of course I'd be all for it.
It's more like a Fountain of Youth, however, imnsho. I.e. and attractive promise, nothing more.
I think the most dangerous over confidence at the moment is the Java, scripting, and VM backers.
They seem to think their language is doing things for them, so they don't have to worry.
At least over confident C/C++ programmers KNOW THEY HAVE TO BE CAREFUL, they just feel up to the task.
That's far less dangerous (even though some are mistaken in their abilities, I suppose) than a whole area of work where the engineers and the PHB think you don't need a skill to enjoy it.
Gee, I've heard this argument for so many years... why have I never seen a VM pull it off?
Recompiling code while it's running doesn't actually strike me as the way to build the fasted code.
But I could be convinced. But not by paper.
The biggest area where Java still loses is startup time and memory consumption. It's not the fault of the VM if the applications programmed in the language suck. I mean, yeah, most Java apps are dog slow. But when you look at their source code, it's often a horrible mess with people doing non-buffered IO, creating millions of temporary objects every second that cause major garbage collection overheads, etc. It has given the VM a much worse reputation than is warranted.
which just goes to show you: the idea that the VM would free you from worrying about the machine is a fantasy, in reality, you just have a new machine to worry about, the VM, and further, if you design your optimization to take into account how the VM works, then some other VM won't work that way. You end up having to know the internals of your abstraction, defeating the whole point.
Unless, <evil pinkie\>, the point was to slow down machines to drive new hardware sales!
>At the moment C may be faster than X, but in a lot of cases, X (where X is an interpretted or VM compiled language) will eventually over-run C in terms of performance.
this is wrong for many reasons, but perhaps the simplest is: think, the VM is probably written in C... how is it going to be faster than C?
Don't buy this crap about VM optimizations, there isn't a single one that couldn't be in a class system.
Also: you don't have to ask your client to install extra libraries... that's a VM thing, where they need to install something to extend the capabilities of the local VM... with C/C++ you can just ship the.so/.dll and or just statically link.
You're right about the priority of Data. However, you are going to have to have some proof if you want me to think it's quicker to code in Java than C/C++, I don't believe it.
I have never found that sort of thing to be the case in general. Arguments like "I can write a web server in ten lines." Um, well then, with that logic, I can do it in One Line in C++.
HttpServer httpSrv = new HttpServer;
iow: they can only "write that in ten lines" because it was already written by someone else! And there is no reason someone else can't write it for you in C/C++ too... certainly no one can argue that there is not a plethora of ready made stuff in C++...
You can overload the array operator, you can use class systems.
Hell, you can use references and eschew pointers.
If someone has the discipline to use Java and or some other magic tool (oooh magic), then they should also have the discipline to use a class library to address these issues.
The real problem seems to be that people want to be led to the One True Solution, and C++ requires that you are an expert in solutions, that you can compare solutions --- that you are competant to choose the right solution for the job at hand.
I especially like the idea that the network is the computer.
But to me that harkens back to when Sun machinery was the cheap stuff. Sun machines were smaller than the other big iron... Sun was a force in the distribution of processing power.
That is, the network is the computer meant having beefy workstations, "clients" capable of contributing to the net.
To me... having fat clients... general purpose computers that can run client software, host their own servers, etc, that is what the Network Being The Computer is really about! You don't log onto a big ass computer owned by someone else. You don't log on, so much as attach. Your computer, when attached, adds to the network. When you log on the network gets incrementally bigger and more powerful.
In the thin client wet dream when you log on you draw resources, the net becomes weaker.
All to have a better reason to charge you for that priveledge.
I'd worry, but as far as I'm concerned I've already watches this vision die a hundred times... so I'm more worried for Sun than of Sun.
>Has it ever dawned to you that some people actually like using Windows???
the hell you say!
you mean people that have used something besides Window too? People that have compared windows to other OSes? surely you jest.
Besides, there is nothing unfair about channelling all the hate people have for their computer systems onto Windows, after all, it's a disposable product and we can leave all the bad will behind us this way.
Slashdot Mirror
(1) yes, I understand the kinds of safety that Java promises, do you understand that this is not the only or even main kind of bug one finds with systems?
(2) I am not being macho about it because I am agreeing that higher level abstractions need to be used to ensure there is a safety net... I'm just also pointing out that these higher level abstractions are available in C++ and do not require a VM level, at all. Further the VM imposed it's own limitations and problems, so it does not compare favorably to other high level solutions.
(3) It's not so much like seat belts... I would say that C++ is already a seat belt compared to the basic starting point of machine language. It's more like Air Bags, which have the great advantage of saving drunk drivers that drive head on into a tree, but also have a way of decapitating children during fender benders, or taking someone's legs off because they unwisely put their feet on the dash while waiting for their spouse to come out of a store.
See, I think that the people traveling over 60 MPH should take the risk, and being still in a parking lot ought to be risk free.
When I am working as a professional developer, I can prepare my safety standards, use the abstractions that avoid common mistakes.
I'm waiting for the argument that these problems cannot be addressed in C++ with class systems.
Instead mostly I hear about how there is not one solution forced on all C++ developers, as if that's a bad thing! If Java really has The One Full Solution To End All Solutions, of course it'd be great! But can such a thing exist? I'm not holding my breath while it gets implemented, and I certainly have yet to see such a thing.
why stop with blocking port 135, why not stop all the security problems by just turning off power to the machine... all fixed!
Well, when using Java rather than finding that I've suddenly been saved the trouble of doing things I already know how to do, I find that I'm powerless.
I needed to tell the garbage collector to collect right now, not later when I'm making another query, but right now, because since the object was part of a connection, the garbage collector caused problems when I had already created a new connection. The new connection was already allocated, according to the Java source code it was a second, totally separate, object. But because of connection pooling, I found it was not really a new object, but what partially reused, and when the previous object was cleaned, it caused problems with the new object (loss of connection mid-query).
According to the Java source, this was a different object altogether.
But since in Java I "don't care" where the memory is really coming from, the JDBC implementation could play whatever game it wanted and give me reused components. Java saves me from having to say when to delete, and prevents me from getting to say when to delete. I lose power and gain nothing.
OH, I fixed it... by setting the appropriate references to null at the appropriate time. But a different VM might break my solution, it was not based on the Java syntax, but on the peculiarities of the VM I was using. In C++ I'm sure I would have been able to dig deeper for a work around that would continue to work (that has been my experience), but in Java I had to leave it on the precipice to break again with an updated VM or different JDBC driver.
This sort of thing sucks, and it's endemic to hand-holding and treating-like-a-baby. Never in my life, in code or without, have I ever seen a system that protected people for their own good that didn't royally screw those that could protect themselves. Ok, if we are talking about railings for the tourists hiking in Yosemite, I guess I don't mind. But when we are talking about a skilled proffession that is a life long endeavor of learning and solution building... I want tools to build with. I want a fricking nail gun, I'll be safe where I point it.
What really gets me is that C++ has the best of both worlds. Any of these issues can and have been solved in C++ and probably nicely wrapped in a stable class system.
If you use a class to manage your memory, you can have all the same protections, and automagical garbage collection, etc. etc.
In fact, garbage collecting memory management schemes have been available for C++ (and C) in various forms for a long long while.
The general reason they are not used more is that the machine really cannot efficiently do that job. You know more about your use of memory, and what the semantic relationships are, than the compiler or the VM.
If a garbage collection is invented that really lives up to the promise, it will be available in C++, all without building a whole language around something that hasn't really arrives and may never arrive.
I've worked with many Java based systems now and I'm not noticing the code is easier or less buggy, at all, not even with respect to the misuse of memory. Especially considering that I could leave 1K a second and still have days and days before my C++ applications reaches the memory consumption a similar Java processes STARTS out consuming.
btw: as for these buffer overflows, etc. You can write malloc and free such that they watch for this sort of thing. It just costs a few bytes per allocation and some processing power. Debug libraries often do this already. If you do that, it's still more efficient than the VM approach.
It all reminds me of when I thought Applesoft Basic was the bees knees, it was good enough for anything... it ruled, other languages were just not nec. But then again, I was 13, it only lasted a few months... I grew up.
Which brings me to another theorem about craftsmanship. Powerful tools can be dangerous. Safe tools tend to be impotent.
I believe scripting languages ar
>then what's so bad about not worrying about those things?
(1) what is the cost? Is the application consuming 10x the resources such as memory?
(2) does it really solve the problem? e.g. Java's memory management, you still have memory management problems and bugs which are for all intents and purposes memory leaks, but you give up the ability to address these problems (unless you use your own VM).
>
Though they know they have to be careful, they still repeat the same mistakes over and over. Right?
no. I don't think they do. I think we are learning from our mistakes.
And if they want to do something to make it easier, then they encapsulate their solution in a class. Instead of the solution being, "use the magic bullet", it's "stop shooting yourself in the foot" and C++ classes are there exactly for this purpose.
The advantage is such solutions can be optimal. In spite of claims to the contrary, I don't think a VM approach could ever be optimal.
Frankly if I really believed that these bugs were the most pernicious, took the most develper time, AND that VM's and scripting languages really were faster to develop in, of course I'd be all for it.
It's more like a Fountain of Youth, however, imnsho. I.e. and attractive promise, nothing more.
You don't feel that C/C++ handles where the memory is stored in RAM?
Pardon?!
Fact is, it does handle that.
The big conflict is that it allows you to dive into those issues if you need to. This freedom must not be allowed, I'm told. Over. And Over.
C++ is arbitrarily "high level", imnsho.
I think the most dangerous over confidence at the moment is the Java, scripting, and VM backers.
They seem to think their language is doing things for them, so they don't have to worry.
At least over confident C/C++ programmers KNOW THEY HAVE TO BE CAREFUL, they just feel up to the task.
That's far less dangerous (even though some are mistaken in their abilities, I suppose) than a whole area of work where the engineers and the PHB think you don't need a skill to enjoy it.
yeah, and we all know Java programs practically write themselves!
Hey!!!!
Tomatoes are not poisonous!
Gee, I've heard this argument for so many years... why have I never seen a VM pull it off?
Recompiling code while it's running doesn't actually strike me as the way to build the fasted code.
But I could be convinced. But not by paper.
The biggest area where Java still loses is startup time and memory consumption. It's not the fault of the VM if the applications programmed in the language suck. I mean, yeah, most Java apps are dog slow. But when you look at their source code, it's often a horrible mess with people doing non-buffered IO, creating millions of temporary objects every second that cause major garbage collection overheads, etc. It has given the VM a much worse reputation than is warranted.
which just goes to show you: the idea that the VM would free you from worrying about the machine is a fantasy, in reality, you just have a new machine to worry about, the VM, and further, if you design your optimization to take into account how the VM works, then some other VM won't work that way. You end up having to know the internals of your abstraction, defeating the whole point.
Unless, <evil pinkie\>, the point was to slow down machines to drive new hardware sales!
>At the moment C may be faster than X, but in a lot of cases, X (where X is an interpretted or VM compiled language) will eventually over-run C in terms of performance.
.so/.dll and or just statically link.
this is wrong for many reasons, but perhaps the simplest is: think, the VM is probably written in C... how is it going to be faster than C?
Don't buy this crap about VM optimizations, there isn't a single one that couldn't be in a class system.
Also: you don't have to ask your client to install extra libraries... that's a VM thing, where they need to install something to extend the capabilities of the local VM... with C/C++ you can just ship the
You're right about the priority of Data. However, you are going to have to have some proof if you want me to think it's quicker to code in Java than C/C++, I don't believe it.
I have never found that sort of thing to be the case in general. Arguments like "I can write a web server in ten lines." Um, well then, with that logic, I can do it in One Line in C++.
HttpServer httpSrv = new HttpServer;
iow: they can only "write that in ten lines" because it was already written by someone else! And there is no reason someone else can't write it for you in C/C++ too... certainly no one can argue that there is not a plethora of ready made stuff in C++...
and this is why C++ was invented.
You can overload the array operator, you can use class systems.
Hell, you can use references and eschew pointers.
If someone has the discipline to use Java and or some other magic tool (oooh magic), then they should also have the discipline to use a class library to address these issues.
The real problem seems to be that people want to be led to the One True Solution, and C++ requires that you are an expert in solutions, that you can compare solutions --- that you are competant to choose the right solution for the job at hand.
personally, and as a huge fan of Oakland... I never thought it was really intended as an insult.
It's because of people like you that the robots will be able to take over.
!
I especially like the idea that the network is the computer.
But to me that harkens back to when Sun machinery was the cheap stuff. Sun machines were smaller than the other big iron... Sun was a force in the distribution of processing power.
That is, the network is the computer meant having beefy workstations, "clients" capable of contributing to the net.
To me... having fat clients... general purpose computers that can run client software, host their own servers, etc, that is what the Network Being The Computer is really about! You don't log onto a big ass computer owned by someone else. You don't log on, so much as attach. Your computer, when attached, adds to the network. When you log on the network gets incrementally bigger and more powerful.
In the thin client wet dream when you log on you draw resources, the net becomes weaker.
All to have a better reason to charge you for that priveledge.
I'd worry, but as far as I'm concerned I've already watches this vision die a hundred times... so I'm more worried for Sun than of Sun.
>As I like to say, a democracy is two wolves and a sheep taking a vote on what to have for dinner.
just to be contrary, but I'd have to say it's more like two sheep and a wolf taking a vote on what to have for dinner.
Ug, I'm still stuck on what the meaning of "is" is.
Extension? Existence? Persistence? Insistence?
They are wondering that at Apple too.
*cough*Jobs*cough*
... way to give it to the whippersnappers.
But dude, you accidently defended Window 1.0! Ouch!
>Has it ever dawned to you that some people actually like using Windows???
the hell you say!
you mean people that have used something besides Window too? People that have compared windows to other OSes? surely you jest.
Besides, there is nothing unfair about channelling all the hate people have for their computer systems onto Windows, after all, it's a disposable product and we can leave all the bad will behind us this way.
why would you want to pause scrolling output every 15 seconds for?
And how often do you hit Ctrl-Q?
"preemptive non-aggression"
Orwell didn't approve the old "police-action" term, too straight forward.
if somone patented it's process of infection... it would!
ok, you win this time g4dget!
poker and Risk and both fun.
no way, really?
a disk controller will not address corruption because of a bug in your transformations.