Dark energy is just the latest name for the Cosmological Constant - I guess it's a better name if it's not actually constant, but the cosmologists I've seen talking about it don't like the new name either (not that anyone has a better suggestion, really). The key thing about it is that the energy density of it is insanely low - I suspect that on the quantum scale it actually "rounds to 0" the way things can in QM, where no measurement is possible at that scale. I think even at the scale of our galaxy it's a very tiny effect. It's a testament to how sparse matter really is in the universe that dark matter is the dominant effect overall.
Slashdot videos: Now with more Slashdot!
Funny, in my world, classes called "XManager" are expected to have the "single responsibility" of X, but in a way that needs it's own thread or something to do it right - more separation than the usual class boundary. If X is too broad, expect complaints in code review.
How in the world? Trivially. They're doing it in an O(n^2) way - it's the only explanation.
If you use string concat library code naively, you can end up "copy the string, add one byte, repeat" easily enough in languages like Java. And it's not exactly breakthrough research to discover that O(n) disk can be faster than O(n^2) memory for large enough n.
Are you doing your part? Click here to learn more.
I see "semantic content" all over the place - but the words are all linked to advertisements, not explanations. Sad, really.
Maybe I'm still not getting your point. Sure, if you need to understand the details of Unicode character composition and such because you're the one rendering the output glyphs, or you want to sort or search across different encodings of the same word, that's rough, but there's no excuse for a security failure while doing those tasks.
On your other point: the notion of "sanitizing input" is fundamentally flawed to begin with. You can never know what future framework that user data will be interacting with, and what might be interpreted as an escape sequence in that mysterious future, but you can assume that the guy doing that future work will just assume "the input was sanitized", and you're screwed. Instead, don't go there. If e.g. you need to store a user string in a SQL DB, do it in such a way that there's no possible problematic string (perhaps the DB has a way of doing queries that's guaranteed safe, for example). If e.g. you need to send a user sting inside an XML blob, just convert the user string to a hex/base64/whatever representation first - guaranteed safe.
What usecase were you thinking of that makes any of this hard at all?
A contract would have prevented that just as well as a law, is the thing. Engineering a shortage in an attempt to corner a market is hardly a new idea - it's older than the idea of commodities markets, for sure. That's why commodities contracts are carefully written, backed up by especially brutal contract law, and market rules prevent any one entity from controlling too large a position.
All of this is centuries-old best practices, and none of it requires price-fixing.
There are plenty of laws around modern markets. That's how they evolved. Trying to make some sort of anarchist strawman really doesn't make you look smart, you know.
What there aren't are prices fixed by law. It's really not that complicated a concept: government regulating product quality, fraud, and contracts: good; government setting prices or granting monopolies: bad.
You miss the point. The exact problem with retail price controls and a wholesale free market is that it's vulnerable to gaming, Enron-style. Proper markets expect every participant to be gaming the system as hard as they can. They're built on it from the start, have evolved for centuries to cope, and they work nicely for most commodities in the world - just a few government-granted monopolies left over causing problems.
Well, when a state school didn't come with a crushing debt burden, it was much less of an issue (compared to even 10 years ago it's nuts). My own solutions was to get that first job in my home city, paying peanuts, then once I had enough experience to be credible, move away. That first job wasn't so hard to get because everyone else was doing the same thing, so they were constantly hiring.
With you on the home economics. I was such a moron with money for almost the first 10 years.
Ha! That's been happening continuously since the beginning - better languages, better frameworks, etc. You almost never need to write a toolkit these days, or a script to refactor code in some simple way. I started with assembly, and for all Java's many problems, it's several times as productive. Turns out the need for programmers is mostly limited by budget, not by the universe of problems that need to be solved, and so more companies started hiring developers as the better tools made the payoff better.
Have you ever developed any system more complicated than a college project?
One or two; one or two. Somehow I've never managed to develop one that would crash due to malformed input, however.
You might be right, but it's such an old problem - it was a big deal 10 years ago in the Windows world as UCS2 didn't handle it. C# was actually UTF from the start, like Java, of course.
Still, crashing because of, what, a null in the input? I could certainly understand truncation (just like other incorrect display problems), but a crash?
UTF8 has nothing to do with it.
The problem commonly is: people try to "clean" input with some stupid regex, rather than treating all user-provided strings as permanently dirty. You can do anything you need to, risk-free, with this attitude. You have to understand the encoding you use for storage/transmission (if your framework doesn't provide a way to safely, blindly store/transmit any string, then just encode the string in some way first), but that's a much, much smaller world than the universe of possible user string.
As soon as you try to render, parse or even only compare anything besides standard ASCII, you are screwed.
Render? Displaying a glyph incorrectly is one thing, but crashing or leaving some exploit open is raw incompetence. Parse? If you need to parse user input, you likely have bigger issues (if you're running user scripts or whatever). Compare? Again, you might get the order wrong (is there even a defined order for pictographic languages?), but crashing is inexcusable.
They're just bytes for fuck's sake. What kind of moron can't process them safely in this day and age?
But then, this is Chrome we're talking about - the initial release would crash with a 2-character string (";=" was it?), due to an error that never should have made it past code review - subtracting 1 from an unsigned value, then using the result as a limit in a for loop IIRC. Might as well be checking your passwords into github.
its an h1b market and will get worse and worse as time marches on. immigrants can and will work cheaper than americans, employers know this and employers know the reason for the h1b push.
Total bullshit in every way. It's like you can't think beyond your hatred of brown people. Programming is a world market, and you compete with the world for jobs. Every H1B is a person who is paid more than they would be to do the very same job in their home country! And they pay US taxes, besides. The tragedy of the H1B program is that we should just be giving them green cards instead - we surely need to tax revenue in the coming years!
The nice thing is: there are still plenty of jobs world-wide. There was a time when the labor pool in programming was increasing exponentially as every country with a CompSci program was opened to outsourcing for the first time, but that's all explored now. The world's supply of coders is expanding linearly now, as all the worlds universities crank out coders at a steady rate (plus the few like me who make it without the degree). The demand is growing faster.
The US economy just went through a long-ass downturn, nothing programming-specific about it (blame the banks and the politicians that enable them). But the big software companies are hiring like crazy now (my team has 9 open positions, it's nuts), and while you may have to move away from Arkansas to where the jobs are, that's pretty much win-win.