Yes, you _can_ do those things, but what you get is a RDBMS-centric application design. Suitable for some tasks, less so for others.
If you want to do proper object-oriented design, the RDBMS worldview really gets in the way, and it is often better to abstract away it all away as a persistence layer, that just happens to be implemented using an RDBMS. In that case, you need to have your business logic in your application. You can use some of the integrity-checking in the DB for extra security, but you cannot rely on it to implement your core functionality.
Aha! The US government is behind it. Learning from the hideous expenses of Iraq, and the the simple fact that they've got no soldiers left, they finally started listening to analysts and realized that if you can convince enough people that the war has happened, it will have the same effect as if it had.
Code generation tends to look like it will save you time, but it usually only does so for the first five minutes, then it starts costing.
A code generator is in fact a compiler (or a compiler is a code generator, if you will), and should be specced a such. That means:
1) Unless the compiled code runs as reliably as that from established 'proper' compilers, it really is worse than useless. This is impossible unless your architecture and OS is fixed and known at compile time. For Java and similar, the VM is the architecture and the standard libraries are the OS. For javascript the architecture is the interpreter, but the OS includes is the browser's API.
2) When things go wrong, you need to be able to track directly back to the source to develop efficiently. Java and pals retain enough in in the bytecode to do this well, and in C ou compile with debug symbols. Most code generators to Java and javascript dop nothing in this area, and cannot be debugged efficiently.
The biggest problems with js aren't really problems with the language design, they're problems with the lack of standardization in the interface to the browser. Not so. It is a problem you run into sooner, certainly, but it can be remedied with libraries, as all the ajax libraries do. The fundamental language design problems, however, are inevitable every time your code grows into a large system with several authors.
Granted, the need for libraries means your system _does_ grow into that state sooner than strictly necessary, but it's still only a difference in degree. You really do need good support complex systems and multiple libraries.
That's what TFA and Javascript 2 is about: JS1 is the way it is because it was meant to be small and simple. Usage has changed and thus requirements, and JS2 is the first opportunity to fix the big things.
I had completely forgotten I used dream about this, but finally it is here: Scenery eerily similar to Myst (even the tree models), but raytraced in real time.
Most of us cannot see more than about 1 million colors,
Bollocks. It all depends on the contrast and mapping curve.
1mill combos from 3 channels is only 100 levels per channel, i.e. around 7 bit per channel.
Sure, on a cheap monitor where the difference between how much light the lightest and the darkest pixel send toward your eye is not really that big, you don't need many steps in between either, since they will be very close together.
But even then you will see clear banding in a smooth sweep with 1-bit intervals.
If you look at something like real life, we can handle enormous dynamic range. Some of it is illusion because we adjust the aperture and possibly other parameters to suit what we are focusing on, but even in a frozen gaze you can see dust on your speedometer and subtle shading on the sunny road outside at the same time. Try quantizing that sort of range into 24 bit, and it would look silly.
But we don't need to get that hypothetical. There are media that we can control digitally and that posses very high contrast (low compared to reality, but huge compared to a normal monitor): Print. Use a top-of-the line color printer and print out sheets with either half filled with 'adjacent' colors in your chosen color model. You'll need a _lot_ more than 24 bits before it becomes even remotely difficult for a person with good eyesight to see the split.
They will be a passing phenomenon anyway, their function soon usurped by phones.
For that matter, forget about flexible displays, fabrics, printed circuitry and persistent display state too. Sure, nice to have, but no more.
What I want is a normal notebook with a high-contrast reflective display, that actually becomes better to use in good light, like paper does.
I want it so much I'd even buy a separate clip-on monochrome screen to plug into the external display port, if only you could buy such a thing. Being able to work comfortably outside in full sun would still be fantastic.
Of course, most people would not buy such a thing: the killer app for e-paper is color, and that's not here yet. But I do hope that someone can lift the silly and premature focus on all other paper-like qualities you can think of, and thus speed up development of speedy, full color, high-contrast display, even if ends up rigid, several milllimeters thick and as power-hungry as LCD. IT WOULD STILL BE A GREAT PRODUCT! GIMME!
Philips' electrowetting stuff looks extremely promising; I hope the powers that be can be made to see that it doesn't have to compete in the 'standard' e-paper niche to succeed; it has other strengths that those can never match.
There is no way anything less than _really_ good coders would get something like this to work with any semblance of efficiency. If you still evaluate coders by which language they use, chances are you're not really that good a programmer.
Slashdot Mirror
Yes, you _can_ do those things, but what you get is a RDBMS-centric application design. Suitable for some tasks, less so for others.
If you want to do proper object-oriented design, the RDBMS worldview really gets in the way, and it is often better to abstract away it all away as a persistence layer, that just happens to be implemented using an RDBMS. In that case, you need to have your business logic in your application. You can use some of the integrity-checking in the DB for extra security, but you cannot rely on it to implement your core functionality.
Will all the leading-zero whiners please take 0.5 fucking seconds to think about what a "millennium clock" might be?
Seriously, get your act together, people. This is supposed to be news for nerds, here.
Don't worry. It's just an in-joke for those who read _and_ understood the summary.
Just carve in a really big version of the normal skull-and-bones poison symbol, only replace the human skull with an ape skull.
Score: +few interesting
Is that a metric shit-load or an imperial shitload?
Aha! The US government is behind it. Learning from the hideous expenses of Iraq, and the the simple fact that they've got no soldiers left, they finally started listening to analysts and realized that if you can convince enough people that the war has happened, it will have the same effect as if it had.
No, that was the long of it.
This is the short:
Now for the medium:
Granted, the need for libraries means your system _does_ grow into that state sooner than strictly necessary, but it's still only a difference in degree. You really do need good support complex systems and multiple libraries.
That's what TFA and Javascript 2 is about: JS1 is the way it is because it was meant to be small and simple. Usage has changed and thus requirements, and JS2 is the first opportunity to fix the big things.
So we don't need to jump through the hoops that they do?
_possible_, they're supposed to make them easier too.
Are you sure you know the difference between the language and the proprietarty APIs the browsers expose to it?
Nuh-uh. You need orbital velocity too, or it will simply fall down again.
I had completely forgotten I used dream about this, but finally it is here:
Scenery eerily similar to Myst (even the tree models), but raytraced in real time.
The only part of it I use actively is the bookmarks sync, which is, although slightly buggy, very useful
So what other bookmark-sync should I switch to?
I'm not intersted in thos bookmark sharing services, just having my own bookmarks synced between the computers I use regularly.
Most of us cannot see more than about 1 million colors,
Bollocks. It all depends on the contrast and mapping curve.
1mill combos from 3 channels is only 100 levels per channel, i.e.
around 7 bit per channel.
Sure, on a cheap monitor where the difference between how much light the lightest and the darkest pixel send toward your eye is not really that big, you don't need many steps in between either, since they will be very close together.
But even then you will see clear banding in a smooth sweep with 1-bit intervals.
If you look at something like real life, we can handle enormous dynamic range. Some of it is illusion because we adjust the aperture and possibly other parameters to suit what we are focusing on, but even in a frozen gaze you can see dust on your speedometer and subtle shading on the sunny road outside at the same time. Try quantizing that sort of range into 24 bit, and it would look silly.
But we don't need to get that hypothetical. There are media that we can control digitally
and that posses very high contrast (low compared to reality, but huge compared to a normal monitor): Print. Use a top-of-the line color printer and print out sheets with either half filled with 'adjacent' colors in your chosen color model. You'll need a _lot_ more than 24 bits before it becomes even remotely difficult for a person with good eyesight to see the split.
Chuck Norris can mount a man-in-the-middle attack by chewing the fibre in two and aiming one end into each eye.
They will be a passing phenomenon anyway, their function soon usurped by phones.
For that matter, forget about flexible displays, fabrics, printed circuitry and persistent display state too. Sure, nice to have, but no more.
What I want is a normal notebook with a high-contrast reflective display,
that actually becomes better to use in good light, like paper does.
I want it so much I'd even buy a separate clip-on monochrome screen to plug into
the external display port, if only you could buy such a thing. Being able to work comfortably
outside in full sun would still be fantastic.
Of course, most people would not buy such a thing: the killer app for e-paper is color, and that's
not here yet. But I do hope that someone can lift the silly and premature focus
on all other paper-like qualities you can think of, and thus speed up development
of speedy, full color, high-contrast display, even if ends up rigid, several
milllimeters thick and as power-hungry as LCD. IT WOULD STILL BE A GREAT PRODUCT!
GIMME!
Philips' electrowetting stuff looks extremely promising; I hope the powers that be can be made to see
that it doesn't have to compete in the 'standard' e-paper niche to succeed; it has other strengths that those can never match.
Gods appear.
No reason to assume we would control them or that they would even bother much more with us than with the other stuff that surround them.
In fact, natural selection would eventually winnow out those that let themselves be hindered by human interests.
700 threads in JAVA? Why not use C++,
To get the work done and working correctly before the hardware is obsolete.
There is no way anything less than _really_ good coders would get something like this to work with any semblance of efficiency. If you still evaluate coders by which language they use, chances are you're not really that good a programmer.
Besides, what dope thinks fusion causes dangerous radiation to begin with?
Are you saying you have a realistic design that doesn't?
You've got it the wrong way around. You drink beer to make your own wii.
I would feel it opened my eyes to the unfathomable hollowness of what I have been spending my time on and investing my pride in.