EJB is a scheme for writing complex business logic in Java. Basically you write the code that does the interesting bits yourself, and then deploy the code into an application called an EJB container which handles most of the boring difficult bits like database integration, transaction management, user authentication and authorization, load balancing, multi-protocol serialization, object discovery, etc.
The proof that the halting problem is undecidable comes about through constructing a program that says it halts only if it doesn't halt. This is trivially easy to do if you have a finite program that computes whether a program halts (exercise for the reader) so the only conclusion is that there cannot be any such finite program. This result is well-known; every so often some crackpot comes along and claims it is false, but that's usually just an indication that they were asleep in their CS logic class...
However, it is possible to prove that virtually all normal finite programs halt (or not). Horrendously non-trivial - trust me on that as someone who has worked on state-space enumeration engines and model checkers - but possible.
Infinite programs are more interesting; you tend to need exotic theoretical machinery to tackle that sort of thing...
What we have here is a library that comes in several bits. The numeric and units handling parts are all very neat, but rather special-purpose (I just don't need them at all in my Java programs), and the stuff to allocate things on the stack for improved realtime performance is rather risky for non-experts to use (e.g. stack space tends to be much smaller than heap space, so you have to be careful with how much stuff you actually allocate on the stack). The RT bits also look (from a casual glance) like they'd need an update to the JVM and bytecodes to actually work...
JVM and bytecode updates are painful (can you say "Porting and Deployment" without winceing?) so those bits are a non-starter for general use, and the rest of it could (theoretically; I don't know how much it depends on the parts I've just rejected out of hand) just as happily be in a third-party lib, and they're something that Java's really good at.
Valgrind doesn't solve all problems. It doesn't even find all problems (unless you're extremely good at test suite authoring). It's a really cool tool, but let's not oversell it.
One of the requirements shaping the implementation of GCC is that it be bootstrappable on many systems, even on some UNIX(tm) systems shipped by their vendors with a half-broken C compiler (enough to recompile the kernel but not much more) and no C++ compiler.
Speaking as a maintainer of software that gets ported to some really odd environments, GCC's general policy in this area is a godsend (it lets the rest of the software toolchain stop worrying quite so much about every kind of bizarre compiler bug out there). If GCC was rewritten in C++, the first step would be to make a bootstrap C++ compiler in C (preferably K&R-stype C too; there are *very* crufty systems out there!) so you could build the main compiler.
(As a bootstrap compiler it would have the advantage of not needing to implement the entire language or do significant optimization. It just needs to build a working compiler...)
There is no doubt in my mind -- as someone who uses mathematical concepts with overloaded operators in C++ all day -- that a judicious use of overloading can make for much more readable code than the unnatural, prefixified mess you get without it.
As long as the basic semantics of the operators are maintained, overloading isn't too evil (being able to add and multiply additional numeric types is a good thing after all), but anything that does complete replacement of semantics is evil. Which is why the person who decided to allow operator= and the casting operators needs relocating to Shrub's Cuban Holiday Camp...
hmm, if there was a lot of processing power required for this, im sure some of us would lend our CPU cycles seti@home style:)
Short Version: That's unlikely to work well for technical reasons.
Longer Version: Weather predictions are done by having a large weather model (basically a massive simulation) that you seed with the current observations and then run forward for however many hours that you are interested in. Then you look at the results, add in effects of local topology (like cities and mountains), and try to work out what's going on from that. There has even been work on doing this sort of thing on the Grid.
But it doesn't work well as a highly distributed application. The problem is that this type of problem is much more highly coupled; effects in one part of the simulation tend to spread (which is kind-of obvious when you think about it!) Although you could use (what is in effect) a distributed cluster to do the computation, the communications costs would ensure that your performance would be absolutely shite, and adding more computers would not help. You'd be drowning in a sea of messages instead of doing real work. (The same is true for other kinds of fluid dynamics apps, btw.)
It's this sort of thing where supercomputers really come into their own. Those machines have disgustingly expensive architectures but they don't really have much competition. But if you want to build one, better start thinking about how you are going to provide space to house them, electricity to power them, and AC to keep them cool. As well as the obvious stuff like high performance networking, massive disk arrays, etc.:^)
Absorbing everything except the wavelengths that the projector produces (and which the human visual system will still perceive as the full spectrum of colours) is *very* clever. If only the ambient light wasn't from massed banks of computer monitors...
The problem with smokers only really starts when those smokers exhale. If they want to screw themselves up, well, it's their body and their life. If they want to make my life hell when I'm just going to/from work (never mind going into bars), it's then I have a problem with smoking.
I don't wish to inhale smoke (I'm not keen on many other kinds of fumes either; pet hates are diesel exhaust and scent departments in stores.) I cannot see why I shouldn't have the right to not inhale smoke when I'm just walking along the street, waiting for a train at a station, or shopping in a mall.
Flying monkeys come from Australia. Everyone knows that. There's even been a natural history film made about them, though modern entertainment demands some extra "reality drama" hokum be added with a tornado transportation system, yellow brick roads and a melting witch...
He's got that rant about software patents too. So the odds on him having something to say apart from the GNU/Linux stuff, well, I'd say they were exactly 100%.:^)
The GPL doesn't force anyone to do anything. If you don't want to contribute your code to a GPL project, then don't distribute any modifications you've made. You're always able to use it for yourself or within your organization as you see fit. And of course, you're free not to use it at all
I go one better than that. I don't even submit bug reports relating to GPL software. Sure I might know of significant faults (including in some cases deep security problems) but I won't contribute my knowledge on these matters to political causes I disagree with.
I want the software I contribute to to be free. This includes the freedom for assholes to use it (I'm better than they are, so my software is free for them to use whatever they do) as well as commercial uses which just don't fit in (either positively or negatively) to the world view espoused by RMS and the FSF. Canned software isn't just canned to keep hobbyists from having a look...
Grid computing is still very new, and there is a lot of disagreement over what it means. Is it any wonder that the IBM guy just glosses over all that stuff to make a story that is journalistically stronger (but ultimately an utter crock, as you spotted.)
The distinguishing factor about Grids is that they operate across organizational boundaries. There's no point in doing a single organization Grid. Beowulf clusters? You might have them on the grid as single nodes.
BTW, there is one very well known (in the US) Grid system and there is one production-ready Grid system, and they are not the same.
Nobody complains that useful libraries like GNU readline are under the GPL
That's only because everyone knows that the FSF refuses to listen to the complaints (and yes, this has come up a lot in relation to readline and open-source non-GPL software.) No sense talking to a brick wall after all.
Excellent advice. Those of you looking for the Java term for this sort of thing should be looking for PreparedStatement. If your DB doesn't support anything like that, get a better DB.
We're not doing some kind of bizarre scientific experiment here. Traffic diversion, road pricing, better regulation of buses (a particular problem round here AFAICT), and promotion of alternate forms of transport are all techniques that should be applied. Maybe there are others too; I'm no expert...
Push-bikes aren't a good solution in all cities BTW. Some places are very steep, and unsuprisingly people don't like cycling there very much. Well, except for the velofanatics of course (you know, the people who wear full racing kit for cycling half a mile down the road to work.)
Slashdot Mirror
However, it is possible to prove that virtually all normal finite programs halt (or not). Horrendously non-trivial - trust me on that as someone who has worked on state-space enumeration engines and model checkers - but possible.
Infinite programs are more interesting; you tend to need exotic theoretical machinery to tackle that sort of thing...
What we have here is a library that comes in several bits. The numeric and units handling parts are all very neat, but rather special-purpose (I just don't need them at all in my Java programs), and the stuff to allocate things on the stack for improved realtime performance is rather risky for non-experts to use (e.g. stack space tends to be much smaller than heap space, so you have to be careful with how much stuff you actually allocate on the stack). The RT bits also look (from a casual glance) like they'd need an update to the JVM and bytecodes to actually work...
JVM and bytecode updates are painful (can you say "Porting and Deployment" without winceing?) so those bits are a non-starter for general use, and the rest of it could (theoretically; I don't know how much it depends on the parts I've just rejected out of hand) just as happily be in a third-party lib, and they're something that Java's really good at.
Valgrind doesn't solve all problems. It doesn't even find all problems (unless you're extremely good at test suite authoring). It's a really cool tool, but let's not oversell it.
That title makes me wonder what sort of nut would have that shell. Coconut's too small...
(As a bootstrap compiler it would have the advantage of not needing to implement the entire language or do significant optimization. It just needs to build a working compiler...)
As long as the basic semantics of the operators are maintained, overloading isn't too evil (being able to add and multiply additional numeric types is a good thing after all), but anything that does complete replacement of semantics is evil. Which is why the person who decided to allow operator= and the casting operators needs relocating to Shrub's Cuban Holiday Camp...
Sounds like you've got a business case for buying the additional access.
Short Version: That's unlikely to work well for technical reasons.
Longer Version: Weather predictions are done by having a large weather model (basically a massive simulation) that you seed with the current observations and then run forward for however many hours that you are interested in. Then you look at the results, add in effects of local topology (like cities and mountains), and try to work out what's going on from that. There has even been work on doing this sort of thing on the Grid.
But it doesn't work well as a highly distributed application. The problem is that this type of problem is much more highly coupled; effects in one part of the simulation tend to spread (which is kind-of obvious when you think about it!) Although you could use (what is in effect) a distributed cluster to do the computation, the communications costs would ensure that your performance would be absolutely shite, and adding more computers would not help. You'd be drowning in a sea of messages instead of doing real work. (The same is true for other kinds of fluid dynamics apps, btw.)
It's this sort of thing where supercomputers really come into their own. Those machines have disgustingly expensive architectures but they don't really have much competition. But if you want to build one, better start thinking about how you are going to provide space to house them, electricity to power them, and AC to keep them cool. As well as the obvious stuff like high performance networking, massive disk arrays, etc. :^)
Absorbing everything except the wavelengths that the projector produces (and which the human visual system will still perceive as the full spectrum of colours) is *very* clever. If only the ambient light wasn't from massed banks of computer monitors...
On the plus side, he's a goner either way. ;^)
I don't wish to inhale smoke (I'm not keen on many other kinds of fumes either; pet hates are diesel exhaust and scent departments in stores.) I cannot see why I shouldn't have the right to not inhale smoke when I'm just walking along the street, waiting for a train at a station, or shopping in a mall.
Flying monkeys come from Australia. Everyone knows that. There's even been a natural history film made about them, though modern entertainment demands some extra "reality drama" hokum be added with a tornado transportation system, yellow brick roads and a melting witch...
Whether there's been any good high quality strategy games on consoles recently is a better question.
He's got that rant about software patents too. So the odds on him having something to say apart from the GNU/Linux stuff, well, I'd say they were exactly 100%. :^)
I want the software I contribute to to be free. This includes the freedom for assholes to use it (I'm better than they are, so my software is free for them to use whatever they do) as well as commercial uses which just don't fit in (either positively or negatively) to the world view espoused by RMS and the FSF. Canned software isn't just canned to keep hobbyists from having a look...
Oh, you said Mormon, not Moron. Well, I wouldn't know about that bit...
Grid computing is still very new, and there is a lot of disagreement over what it means. Is it any wonder that the IBM guy just glosses over all that stuff to make a story that is journalistically stronger (but ultimately an utter crock, as you spotted.)
The distinguishing factor about Grids is that they operate across organizational boundaries. There's no point in doing a single organization Grid. Beowulf clusters? You might have them on the grid as single nodes.
BTW, there is one very well known (in the US) Grid system and there is one production-ready Grid system, and they are not the same.
Like that you'll at least always see where the link is going before you go there.
> Use placeholders.
Excellent advice. Those of you looking for the Java term for this sort of thing should be looking for PreparedStatement. If your DB doesn't support anything like that, get a better DB.
We're not doing some kind of bizarre scientific experiment here. Traffic diversion, road pricing, better regulation of buses (a particular problem round here AFAICT), and promotion of alternate forms of transport are all techniques that should be applied. Maybe there are others too; I'm no expert...
Push-bikes aren't a good solution in all cities BTW. Some places are very steep, and unsuprisingly people don't like cycling there very much. Well, except for the velofanatics of course (you know, the people who wear full racing kit for cycling half a mile down the road to work.)