It, for example, allows you to do evil things like modify variables labeled as "const" among other things. I had the damnedest time getting the contractors I was responsible for to get themselves out of THAT habit of Windows programming.:-Â )
You've obviously not done a lot of systems programming or you've not tried to broaden your horizons. I've written code for systems that do things like drive Opto-22 I/O, etc. and they all are cross platform (Unix and NT) with minimal differences between the actual code bodies doing the work. If you have to do a lot of differing coding for the differing platforms, you're doing something wrong with your abstractions.
Systems programming: Driving hardware with software and/or providing interfaces to system resource (i.e. Your OS itself). This includes industrial I/O stuff like you'd see with an energy management system. It's often timing critical with delays causing no end to problems with things working let alone working right.
Applications programming: Just about everything else.
Just because Java does a bang-up job of doing one, doesn't mean it works well for the other. For an energy management system, down to even the UI, the results must always be predictable and consistent for it to be of any use. For the UI, there's some slack for things like GC causing a second or so delay- and at seemingly random intervals. Java's a decent candidate for that. The flipside is that the controls underneath the UI don't want, don't need, can ill afford random delays like that because you could get into oscillations of operation that burn up any advantage you had by the management system in the first place.
I'll bet the customer knows about/knows C/C++ and understands that they can get systems (key word there...) programmers using that language.
Java isn't a great systems language- it's a great applications language and doesn't pretend to be anything more. You can do systems programming in an applications language, but the results are often less than stellar and a rough beast to maintain.
This is systems level programming and you need more than an applications tool to do the work right.
And the code's collecting some 10-30K per day at a major international airport in parking and ground trans fees. Part of the system runs on NT (Not MY choice) and part of it runs on an embedded platform running Linux. Same codebase, some 200-500kloc of complext client-server code that compiles cleanly w/no warnings or errors on either GCC or VC++.
Its all in what you do/don't do coding-wise. And, I'd probably have a few horror stories to swap w/the people on comp.lang.c++.moderated over VC++ because I DO this sort of thing for a living and have done so for 6-7 years now.
Java, as it currently is used, is likely to be a poor choice of a tool for this task.
An energy management system more often than not has to deal with industrial I/O systems such as an Opto-22 interface or a ModBus interface. This often requires system level coding resources Java doesn't provide in any way, shape, or form (because it's not part of it's model of how things should be). To claim that you can code those portions in C or C++ and interface them is silly- it's inserting needless complexity (in the form of having to support two differing languages and having to maintain interfaces suitable for JNI.) for no good reason. If you have to resort to using C or C++ for something, it's more often than not better to code the whole thing in one of those languages.
Coding the UI in Java is an arguable task. On the one hand, you've got the nice API designed for doing UI coding. On the other hand, you're back to adding needless complexities into the system in the form of multiple languages and RPC interfaces unless you're using CORBA between the UI and the energy management system engine. Again, you may be better off, based on my personal experience as a software engineer of 12+ years of experience in the industry as a whole, to code the thing entirely in the base language- it'd be simpler for the whole source tree.
And this doesn't even get into what the customer wants. If they want C/C++, then they get it.
Just don't use VC++'s "features" such as many of the wizards. Don't use MFC for UI development- use something like Fltk, WX, etc. And, don't use COM/DCOM if at all possible, using CORBA or XPCOM when you need something like that.
If they're doing a lot of I/O device control directly with the app (Uh, this is an energy management system- which, by definition is going to be tickling things like Opto-22 panels, reading from sensors, etc...) then Java's only truely useful as a UI choice as they're going to have to come up with native interface code to drive the Opto-22 stuff.
They not only have to do network programming and serial comms, they have to deal with industrial I/O that may/may not have a serial interface. If it does all have serial interfaces, they're going to have to come up with APIs for those devices- which isn't always easy.
Java meets only part of the criteria- the ones they needed help with answers on. It doesn't magically meet the other criteria- what are they working with and what does the customer want. I suspect that Java doesn't make the grade here for some reason. I code in Java as well as C, C++, and Forth. I'd be using Forth or C/C++ for this sort of thing with maybe a CORBA driven UI coded in Java unless the customer requirements insisted on C/C++ for everything. Then I'd be using C/C++ because it's close enough to cross-platform to matter little if you pay close attention to your code. I know, I've been doing this sort of thing professionally for 7 years now.
And TAO that sits atop ACE, providing a real-time capable CORBA ORB atop it can't be beat either. Its use is less quirky than ACE and made possible a massively distributable financial and access control system that is in use at DFW International Airport and other locations. This system runs on both NT and Linux, with exception handling, etc. across both platforms working well.
MMC's nice if you're looking for just storage in a palmtop, but if you're looking to do things like GPS tied to a database for GIS in a handheld unit, then you need PCMCIA or CF (because USB won't work as well in this case and makes it a LOT more clumsy...)
It was a topic of discussion in my undergrad classes in the early 80's and showed up in books as early as 1979 in our library. They said that using 2 digits for dates was a problem then and that it shouldn't be done- ever.
People knew about the Y2k "problem" two decades before the drop-dead date. Whether or not businesses were listening is something completely different- why spend all this time and money "fixing" something that's not broke (as in, it's working right now...), right?
Just like they did with Y2k, they'll do with this. Everyone knew about Y2k for several decades before they started worrying about it. What makes you think that many businesses will connect the pain they had over that with their delay in dealing with the problem and not do so now?
Since you're going to the trouble to buy silver laquer (in either the bottle like Tom's used, or in an applicator pen) you might as well go to the trouble of buying conformal coating material in a bottle or applicator pen- it's not THAT much more expensive. While it's cure time is a lot longer than superglue's, it's designed for this sort of thing and it's at least a little easier if you fsck things up with your end run around AMD's overclock blocks (because it's laquer and will give you some options to carefully scrape any overflow off of the lands.).
By the by, this all seems like a lot of effort for little payback. Some of you may not want to do this.
This was a flight that was destined for the Dominican Republic and other destinations in the Caribbean. According to FAA reports, the plane was booked to capacity and may well have had all it's booked passengers on board.
They use a unique one-piece resistive scheme on mylar strips that covers the entire finger. The VPL DataGlove happens to use fiber-optic flexion sensors at each knuckle joint- which is more precise but much, much more expensive. The link you offer says as much- and indicated that it's pedigree was from the DataGlove but didn't say that it WAS the same.
Doesn't matter if the exploit is disclosed or not- people still find them, more often than not before they're announced. All the announcement does is put it in the open (open disclosure isn't a script kiddie's friend- it often times means that the exploit's hole is plugged and they can't use their toys on some or most machines anymore...).
There's loopholes in any system. They will be exploited. It's whether or not you know about the loophole and can fix it that makes all the difference between being 0wn3d or not.
Microsoft made PC vendors deals they couldn't refuse (and when they accepted, couldn't afford to get out of) to put their stuff on machines. If it's already on the machine, most people won't bother to get a different program unless it's so atrocious as to be unusable. Doesn't matter if it's free- it'd have to be 100 times better for the average person to bother with getting it. Once you're in that position, it's very difficult to shift the player in place because of network effect- it's nothing at all to do with how "good" a program is.
In order to be useful most applications, etc. have to be compiled with the least common denominator- period. This translates into something that will not assume that you've got seperate pipelines for execution for the FP and MMX/3DNow type instructions because they want it to run on all those K6-2/3's and Pentium MMX/II machines as well as the Pentium III machines. Backwards compatibility's a double-edged sword.
Remember that RIAA threatened Felten over the potential publication of his proof that all of the watermarking schemes proposed for SDMI could be scrubbed out of a file and not degrade quality any more than the watermark did. Watermarking has NOT been proven to really work- it's a nice idea, but so far, the practice thereof has not panned out like people thought it would.
Slashdot Mirror
http://www.w3.org/Graphics/PNG/ is the page on the W3C's site on the subject.
F log
R elentlessly
A nd
G rind
I nto
L imp
E xtinction
But to say "deficiencies" is to put it lightly.
:-Â )
It, for example, allows you to do evil things like modify variables labeled as "const" among other things. I had the damnedest time getting the contractors I was responsible for to get themselves out of THAT habit of Windows programming.
You've obviously not done a lot of systems programming or you've not tried to broaden your horizons. I've written code for systems that do things like drive Opto-22 I/O, etc. and they all are cross platform (Unix and NT) with minimal differences between the actual code bodies doing the work. If you have to do a lot of differing coding for the differing platforms, you're doing something wrong with your abstractions.
Some definitions:
Systems programming: Driving hardware with software and/or providing interfaces to system resource (i.e. Your OS itself). This includes industrial I/O stuff like you'd see with an energy management system. It's often timing critical with delays causing no end to problems with things working let alone working right.
Applications programming: Just about everything else.
Just because Java does a bang-up job of doing one, doesn't mean it works well for the other. For an energy management system, down to even the UI, the results must always be predictable and consistent for it to be of any use. For the UI, there's some slack for things like GC causing a second or so delay- and at seemingly random intervals. Java's a decent candidate for that. The flipside is that the controls underneath the UI don't want, don't need, can ill afford random delays like that because you could get into oscillations of operation that burn up any advantage you had by the management system in the first place.
I'll bet the customer knows about/knows C/C++ and understands that they can get systems (key word there...) programmers using that language.
Java isn't a great systems language- it's a great applications language and doesn't pretend to be anything more. You can do systems programming in an applications language, but the results are often less than stellar and a rough beast to maintain.
This is systems level programming and you need more than an applications tool to do the work right.
And the code's collecting some 10-30K per day at a major international airport in parking and ground trans fees. Part of the system runs on NT (Not MY choice) and part of it runs on an embedded platform running Linux. Same codebase, some 200-500kloc of complext client-server code that compiles cleanly w/no warnings or errors on either GCC or VC++.
Its all in what you do/don't do coding-wise. And, I'd probably have a few horror stories to swap w/the people on comp.lang.c++.moderated over VC++ because I DO this sort of thing for a living and have done so for 6-7 years now.
Java, as it currently is used, is likely to be a poor choice of a tool for this task.
An energy management system more often than not has to deal with industrial I/O systems such as an Opto-22 interface or a ModBus interface. This often requires system level coding resources Java doesn't provide in any way, shape, or form (because it's not part of it's model of how things should be). To claim that you can code those portions in C or C++ and interface them is silly- it's inserting needless complexity (in the form of having to support two differing languages and having to maintain interfaces suitable for JNI.) for no good reason. If you have to resort to using C or C++ for something, it's more often than not better to code the whole thing in one of those languages.
Coding the UI in Java is an arguable task. On the one hand, you've got the nice API designed for doing UI coding. On the other hand, you're back to adding needless complexities into the system in the form of multiple languages and RPC interfaces unless you're using CORBA between the UI and the energy management system engine. Again, you may be better off, based on my personal experience as a software engineer of 12+ years of experience in the industry as a whole, to code the thing entirely in the base language- it'd be simpler for the whole source tree.
And this doesn't even get into what the customer wants. If they want C/C++, then they get it.
Ever thought about that one, hm?
You claim that the poster's claimns are utterly wrong. PROVE IT.
My own personal experience indicates that he's much, much closer to the truth than you'd like to admit.
Just don't use VC++'s "features" such as many of the wizards. Don't use MFC for UI development- use something like Fltk, WX, etc. And, don't use COM/DCOM if at all possible, using CORBA or XPCOM when you need something like that.
If they're doing a lot of I/O device control directly with the app (Uh, this is an energy management system- which, by definition is going to be tickling things like Opto-22 panels, reading from sensors, etc...) then Java's only truely useful as a UI choice as they're going to have to come up with native interface code to drive the Opto-22 stuff.
They not only have to do network programming and serial comms, they have to deal with industrial I/O that may/may not have a serial interface. If it does all have serial interfaces, they're going to have to come up with APIs for those devices- which isn't always easy.
Java meets only part of the criteria- the ones they needed help with answers on. It doesn't magically meet the other criteria- what are they working with and what does the customer want. I suspect that Java doesn't make the grade here for some reason. I code in Java as well as C, C++, and Forth. I'd be using Forth or C/C++ for this sort of thing with maybe a CORBA driven UI coded in Java unless the customer requirements insisted on C/C++ for everything. Then I'd be using C/C++ because it's close enough to cross-platform to matter little if you pay close attention to your code. I know, I've been doing this sort of thing professionally for 7 years now.
Indeed.
And TAO that sits atop ACE, providing a real-time capable CORBA ORB atop it can't be beat either. Its use is less quirky than ACE and made possible a massively distributable financial and access control system that is in use at DFW International Airport and other locations. This system runs on both NT and Linux, with exception handling, etc. across both platforms working well.
MMC's nice if you're looking for just storage in a palmtop, but if you're looking to do things like GPS tied to a database for GIS in a handheld unit, then you need PCMCIA or CF (because USB won't work as well in this case and makes it a LOT more clumsy...)
It was a topic of discussion in my undergrad classes in the early 80's and showed up in books as early as 1979 in our library. They said that using 2 digits for dates was a problem then and that it shouldn't be done- ever.
People knew about the Y2k "problem" two decades before the drop-dead date. Whether or not businesses were listening is something completely different- why spend all this time and money "fixing" something that's not broke (as in, it's working right now...), right?
Just like they did with Y2k, they'll do with this. Everyone knew about Y2k for several decades before they started worrying about it. What makes you think that many businesses will connect the pain they had over that with their delay in dealing with the problem and not do so now?
Many of them are infix. Just some of thier high-end calcs are RPN.
Since you're going to the trouble to buy silver laquer (in either the bottle like Tom's used, or in an applicator pen) you might as well go to the trouble of buying conformal coating material in a bottle or applicator pen- it's not THAT much more expensive. While it's cure time is a lot longer than superglue's, it's designed for this sort of thing and it's at least a little easier if you fsck things up with your end run around AMD's overclock blocks (because it's laquer and will give you some options to carefully scrape any overflow off of the lands.).
By the by, this all seems like a lot of effort for little payback. Some of you may not want to do this.
This was a flight that was destined for the Dominican Republic and other destinations in the Caribbean. According to FAA reports, the plane was booked to capacity and may well have had all it's booked passengers on board.
Check your design details of the PowerGlove.
They use a unique one-piece resistive scheme on mylar strips that covers the entire finger. The VPL DataGlove happens to use fiber-optic flexion sensors at each knuckle joint- which is more precise but much, much more expensive. The link you offer says as much- and indicated that it's pedigree was from the DataGlove but didn't say that it WAS the same.
Doesn't matter if the exploit is disclosed or not- people still find them, more often than not before they're announced. All the announcement does is put it in the open (open disclosure isn't a script kiddie's friend- it often times means that the exploit's hole is plugged and they can't use their toys on some or most machines anymore...).
There's loopholes in any system. They will be exploited. It's whether or not you know about the loophole and can fix it that makes all the difference between being 0wn3d or not.
Here's a reality check...
Microsoft made PC vendors deals they couldn't refuse (and when they accepted, couldn't afford to get out of) to put their stuff on machines. If it's already on the machine, most people won't bother to get a different program unless it's so atrocious as to be unusable. Doesn't matter if it's free- it'd have to be 100 times better for the average person to bother with getting it. Once you're in that position, it's very difficult to shift the player in place because of network effect- it's nothing at all to do with how "good" a program is.
In order to be useful most applications, etc. have to be compiled with the least common denominator- period. This translates into something that will not assume that you've got seperate pipelines for execution for the FP and MMX/3DNow type instructions because they want it to run on all those K6-2/3's and Pentium MMX/II machines as well as the Pentium III machines. Backwards compatibility's a double-edged sword.
Remember that RIAA threatened Felten over the potential publication of his proof that all of the watermarking schemes proposed for SDMI could be scrubbed out of a file and not degrade quality any more than the watermark did. Watermarking has NOT been proven to really work- it's a nice idea, but so far, the practice thereof has not panned out like people thought it would.
There's always a better way to clue-by-four people- what you just did isn't it...