Regarding your sig: you know, there's no "unmount" command. You may be thinking of "umount".
Re:Languages for the Java VM...
on
The Future of Java?
·
· Score: 2, Informative
You're joking, right? There are tons of static and dynamic compilers from Java or bytecode to native code. There's IBM's HPCJ and gcj just to name two static compilers, plus (of course) the hundreds of JIT compilers out there.
I'm sorry, this is one of the most confusing submissions I have ever read. Almost every sentence is a run-on sentence, and phrases like "gaining you a lot of time, sweat and money" make me wonder just why I would want to gain a lot of sweat.
Writing is like coding: keep it simple. Spend some time on it, and have pity on your poor readers. There's more to writing than just spelling and grammar.
(My appologies if you are not a native English speaker---your spelling and grammar are good enough that it's hard to tell.)
VM is not just for paging, which is what happens when you run out of RAM. It's a level of indirection between a memory address and a RAM chip. That level of indirection allows you to do all kinds of cool things.
Ok, now we're finally getting into some concrete arguments that I can rebut.
Your comment is apparently based on the notion that the most important aspect of a programming language is what it can make the computer do. I think that notion is the single biggest mistake that programmers make today.
A programming language is an expressive medium for algorithms (that happens to be sufficiently unambiguous to be executed by a machine), while an operating system is a collection of software services. Programming languages come with libraries; and if you squint really hard, you could see those as part of the language; and since libraries do much the same as OSes, you could conclude that languages are the same as OSes. However, to me, this similarity is incidental, and the difference between a language and an OS is everything.
To continue the surgeon-and-scalpel analogy: you wouldn't compare scalpels based on their experience and expertise. Similarly, you don't rely on your OS to be an elegant expressive medium for your ideas. That's just not its job.
So what Mr Flat is really saying is that he hasn't looked at Eiffel, Ada, OCL or any design by contract work.
Well, I know a thing or two about Eiffel and contracts, so let's start there. Are you talking about the fact that Eiffel has no "private" features? I can't speak for Mr. Flat, but in my mind, that's fine because Eiffel provides an even more flexible and powerful way for the superstar to set the rules: contracts.
Your lack of ability to argue it kinda shows how you were also unable to see the similarities.
Granted. However, I don't care how many similarities you find between the surgeon and the scalpel. Even if they are both made of matter, and both cut through skin, and whatever, they are still totally different.
The interface that an OS offers is exactly the same as with languages, i.e. system calls.
If you think the primary purpose of a language is to give access to system calls, then we have nothing more to discuss. I don't have the energy or inclination to argue otherwise.
And I also disagree with the mythical man-month remark. The other nine should have their license to code revoked.
The one superstar simply can't type quickly enough to get products to market in time to beat the competition. You can't build houses very quickly if you insist on hiring nothing but architects.
That's like saying doctors and scalpels are really the same thing because they both perform surgeries.
OSes and programming languages have some superficial features in common, but they are totally different concepts. This is so manifestly obvious that I'm not even sure how to argue the point.
However, Mr. Flat's suggestion that languages need better isolation capabilities is a good one. It all goes back to Fred Brooks' point that one in ten programmers is a superstar. I think isolation facilities in a programming language allow the superstar to set the rules that the other nine programmers must follow, making the system more coherent by the guidance of one mind.
If you depend on a secret for your security, what do you do when the secret is discovered? If it is easy to change, like a cryptographic key, you do so.
People aren't as committed to their keys as they are to their algorithms or their operating systems. So secret keys are better than secret algorithms or secret OSes. That's all he's saying.
And, if the situations you listed are accurate, and those secrets really are hard to change, then yes, I think Mr. Diffie would agree with you that those systems are vulnerable.
Good lord, what companies have you been working for?
All the projects I have worked on professionally have been released except two, one of which involved a one-line change to an existing product that never ended up being needed, and the other was a "first draft" of a product I ended up rewriting from scratch. That means well over 50% of my professionally-written code has been actually used, especially if you include scripts and things that were intended just to be used by me.
Forget plug-ins. In gdb, you can just code up whatever debug facilities you want, either as a script (is possible), or even by adding it to the gdb code itself. If you have never tried the latter before, you should--it's remarkably easy.
...yet they have made it still work on its own -- you don't need to buy the first edition to have a complete understanding of Linux security.
When do you ever need to read a 1st edition to understand the 2nd edition? Does that ever actually happen? It's not like we're talking about a sequel here.
It's not even close to entrapment. Look it up. Here is one reference:
The legal term to suggest that while you may have engaged in an illegal act, you would not have done so but for the illegal actions by a government agent enticing you to do so... a valid defense to a criminal charge of solicitation.
I'm sure you can find any number of further references to confirm this. So first of all, our honeypot (not "honeypit") owner is not a government agent; and second, the spammer would have a really tough time arguing that he would not have abused the honeypot but for the illegal actions of the honeypot owner.
Well, when their "theories" predict things better than traditional "facts" then I'm prepared to listen.
(Oh, and do you believe that these scientists are such knuckle-dragging dimwits that they wouldn't double-check their equipment, and also have other researchers independently verify their results on different equipment, and then scrutinize their conclusions? You seem to think they're a bunch of individual clowns with no common sense jumping to wild conclusions. But that's just my opinion.)
Slashdot Mirror
This is about the dumbest thing I have ever seen here, and that is saying a lot. A 6-lane highway in Antarctica? Rocks? Pavement? Paint? Good grief.
Regarding your sig: you know, there's no "unmount" command. You may be thinking of "umount".
Writing is like coding: keep it simple. Spend some time on it, and have pity on your poor readers. There's more to writing than just spelling and grammar.
(My appologies if you are not a native English speaker---your spelling and grammar are good enough that it's hard to tell.)
Asymmetric capacitors don't work in a vacuum.
Java+JVM is both a language and an OS, in that sense. There's a very clean, unambiguous separation: the JVM is the OS, and Java is the language.
VM is not just for paging, which is what happens when you run out of RAM. It's a level of indirection between a memory address and a RAM chip. That level of indirection allows you to do all kinds of cool things.
Your comment is apparently based on the notion that the most important aspect of a programming language is what it can make the computer do. I think that notion is the single biggest mistake that programmers make today.
A programming language is an expressive medium for algorithms (that happens to be sufficiently unambiguous to be executed by a machine), while an operating system is a collection of software services. Programming languages come with libraries; and if you squint really hard, you could see those as part of the language; and since libraries do much the same as OSes, you could conclude that languages are the same as OSes. However, to me, this similarity is incidental, and the difference between a language and an OS is everything.
To continue the surgeon-and-scalpel analogy: you wouldn't compare scalpels based on their experience and expertise. Similarly, you don't rely on your OS to be an elegant expressive medium for your ideas. That's just not its job.
OSes and programming languages have some superficial features in common, but they are totally different concepts. This is so manifestly obvious that I'm not even sure how to argue the point.
However, Mr. Flat's suggestion that languages need better isolation capabilities is a good one. It all goes back to Fred Brooks' point that one in ten programmers is a superstar. I think isolation facilities in a programming language allow the superstar to set the rules that the other nine programmers must follow, making the system more coherent by the guidance of one mind.
Have some imagination. They could register with the front desk to have their calls sent directly to them.
And, if the situations you listed are accurate, and those secrets really are hard to change, then yes, I think Mr. Diffie would agree with you that those systems are vulnerable.
Man, I hope you still get paid for those cancelled projects.
Take another look at the parent post. It was all about professional work.
All the projects I have worked on professionally have been released except two, one of which involved a one-line change to an existing product that never ended up being needed, and the other was a "first draft" of a product I ended up rewriting from scratch. That means well over 50% of my professionally-written code has been actually used, especially if you include scripts and things that were intended just to be used by me.
What a great book. Lots of common sense in there.
When stuff gets hot, it glows.
Yay for Free software.
Well, if you can make more accurate predictions, and create new useful devices, that must come as some consolation.
(Oh, and do you believe that these scientists are such knuckle-dragging dimwits that they wouldn't double-check their equipment, and also have other researchers independently verify their results on different equipment, and then scrutinize their conclusions? You seem to think they're a bunch of individual clowns with no common sense jumping to wild conclusions. But that's just my opinion.)