Comment Re:Do the cops (Score 1) 145
Jails in many cities in California now require you to pay for your stay
At least if you don't like the accommodations, you can pay a little extra for an upgrade.
Jails in many cities in California now require you to pay for your stay
At least if you don't like the accommodations, you can pay a little extra for an upgrade.
How is this a Troll? Because it goes against the groupthink?
GMO is different, it's a fundamentally different approach to breeding plants which goes way beyond breeding, and it permits outcomes which were not feasible or even possible before. That is cause for alarm. It's not reason not to experiment, of course. Science is how we progress as a species. I object to using the wide world for these experiments, not to doing the science.
This is a perfectly reasonable point of view. It is objectively true that GMO is different from traditional breeding methods. How many generations of selective breeding would it take to breed a glow-in-the dark strawberry plant? I have no idea, but I bet if you started at the dawn of agriculture you still wouldn't have one. What would you even select for? But now we can do that directly with genetic engineering, in one generation. Genetic engineering of crops is a second agricultural revolution, except with even more potential impact both to human health and the health of ecosystems.
And what effect did the first agricultural revolution have on human health? It was good, right? Not necessarily:
When populations around the globe started turning to agriculture around 10,000 years ago, regardless of their locations and type of crops, a similar trend occurred: The height and health of the people declined.
... Many people have this image of the rise of agriculture and the dawn of modern civilization, and they just assume that a more stable food source makes you healthier," Mummert says. "But early agriculturalists experienced nutritional deficiencies and had a harder time adapting to stress, probably because they became dependent on particular food crops, rather than having a more significantly diverse diet.
Sound familiar?
... "Culturally, we're agricultural chauvinists. We tend to think that producing food is always beneficial, but the picture is much more complex than that," says Emory anthropologist George Armelagos, co-author of the review. "Humans paid a heavy biological cost for agriculture, especially when it came to the variety of nutrients. Even now, about 60 percent of our calories come from corn, rice and wheat."
... "I think it's important to consider what exactly 'good health' means," Mummert says. "The modernization and commercialization of food may be helping us by providing more calories, but those calories may not be good for us. You need calories to grow bones long, but you need rich nutrients to grow bones strong."
People have become healthier because of agriculture, but not because the food is healthier--it probably isn't healthier. Rather, we've become healthier in the long run because agriculture allowed us to produce enough food to have doctors and clean water and sanitation. In the short term, agricultural food made us less healthy.
In principle, a genetically engineered food supply could be overall better, maybe even incredibly better. But in practice it isn't clear we're getting that, or even if that's what we're trying to get. Instead, we're just continuing to make food even cheaper, not necessarily healthier, with even more dependence on particular crops.
Agriculture freed enough people from the burden feeding themselves to create modern civilization. But today almost nobody is a farmer--we're just making agriculture more profitable, but at what cost? Genetic engineering so far has mostly been used to maximize crop yield over nutrition and diversity, just like we've always done.
Which is to say nothing about the potential ecological implications. "The picture is much more complex than that" is an understatement. This won't be the first time we've forged ahead with some technology completely oblivious to the ecological impacts.
Style guidelines should be about avoiding pitfalls of the language, using appropriate idioms, and not making life miserable for maintainers, not about where you put spaces and braces.
Use a diff tool that can ignore formatting changes. I'm a fan of Beyond Compare, but there are plenty of others.
The basic misunderstanding here is the idea that the screen lock in old X was designed for security, and usable as such; it was just a screensaver with a password
What use is a screensaver with a password that isn't designed for security? Why is the password even there? So it looks secure? Lets just admit it was poorly designed from a security standpoint. That's fine, most stuff designed at that time was not secure. MS-DOS had no security at all. Pointing out that NT occasionally has some good ideas is not an indictment against Unix.
IE was well optimized for Sunspider already, so there is not much of a change there. Google Octane 2.0 however has always been terrible in IE, and now it comes in roughly the same as Chrome, for a massive 81.8% increase over the old rendering engine. Kraken continues this with a 45% jump in performance. It is a big change, and a welcome one too.
It would help if they mentioned what the hell these benchmarks are supposed to measure. Out of Sunspider, Octane 2.0, Kraken 1.1, WebXPRT, Oort Online, and HTML5Test, only HTML5Test has a name that means anything to me. Most of them are easy enough to google, but I didn't find anything searching for oort online benchmark. Isn't this supposed to be the author's job?
That's just it, products aren't supposed to be released with code names, that's the whole damn point. For decades code names were used just to give the people working on a project something to call it, because coming up with a real product name takes time (market research, trademark search, considering how it sounds in other languages, etc.) Ridiculous names were chosen on purpose so that they wouldn't be mistaken for actual product names. I guess some marketing genius didn't get the memo.
Developing a useful, general framework for expressing the relations among different types of entities (what philosophers call ``ontology'') seems intractably difficult. [...] a variety of inadequate ontological theories have been embodied in a plethora of correspondingly inadequate programming languages.
My favorite example of that is the Circle-ellipse problem. It seems so natural that a circle is-an ellipse, but it doesn't map to OO heirarchies the way we expect it to. The ontologies offered by OOP languages are always presented as if they were perfectly natural and universal without a hint of the lurking problems. It's not until you come up against some of these problems (hopefully early, before you've drank the coolaid) that you start to realize something's wrong.
[...] In fact, we suspect that these problems cannot be adequately addressed in terms of computer-language design alone, without also drawing on work in knowledge representation and automated reasoning.
Ok, fine, but I'd settle for less inadequate.
I think power consumption has brought back an emphasis on performance. With desktop software we were at a point where even the most inefficient languages wouldn't make a noticeable difference, except maybe in memory usage. Inefficient software won't necessarily seem slower to the user, but they will notice the power consumption. Mobile chips are narcoleptic. The faster you can get stuff done, the faster the chip can go back into lower power mode.
And on the data center side, it is kind of surprising when you see the massive amount of power consumed. Energy is already a big chunk of the costs of running data centers, and energy is probably just going to get more expensive in the future. More efficient means fewer servers. Facebook is doing a lot of stuff in C++ nowadays, and I believe power consumption is one of the driving factors there.
I'm nowhere near smart enough to do C++ well.
This is a bit of an illusion. If it would benefit you to know C++ better, I'd encourage you to not give up easily.
First, it's an illusion because when you read some template code by an expert like Andrei Alexandrescu, it's easy to imagine that this code flowed out for him as easily as writing Python is for you. But writing that kind of code is a slow thoughtful process even for experts, and even they get it wrong sometimes.
Second, it's an illusion because you're comparing your limited experience with C++ programming to people who have been doing it for decades. C++ just takes longer to learn that the languages you mentioned. Even when you feel you're starting to get the hang of it, a few years later you'll look back and realize you're still learning a lot. It isn't a matter of intelligence so much as persistence and continuing to expand your knowledge rather than settling down on some habits that work well enough but don't really take advantage of the full language.
And finally it's an illusion because other languages that have the expressive power of C++ aren't really simpler except in syntax. Consider for example a generic version of the useless function mul(a,b) which returns a times b, in C++, D, and Standard ML:
C++
template<typename A, typename B>
auto mul(const A& a, const B& b) -> decltype(a*b)
{
return a * b;
}
D
auto mul(A, B)(A a, B b)
{
return a * b;
}
Standard ML
fun mul(a, b) = a * b;
It appears that SML is simpler than D which is simpler that C++, but that's really just syntax. All of these are strongly typed, compile-time type checked, and work for arbitrary types. For example if a is a float and b is a vector of integers, then a*b is a vector of floats, which is a different type than a or b. Another example is if a is a 2x3 matrix and b is a 3x2 matrix, the return value is a 2x2 matrix. Generic programming requires you to think abstractly about operations where you don't know what the types are going to be. mul(a,b) is trivial, but if you imagine a more complex algorithm, you can see it's going to require careful thinking. It's just harder than working with concrete types, regardless of the language. Dealing with the syntax is just an annoyance.
The reward is that you get very powerful code that can be reused in many more situations without compromising type safety or performance.
I used generic programming as an example, but the same kind of arguments apply for object oriented, procedural or even functional programming. The real beauty of C++ (and D) is that you can combine these styles of programming according to what's appropriate for the task at hand. But you shouldn't expect that to be as easy as learning OOP in Java or procedural programming in C.
The lack of a built-in string is a red herring. One of the design goals of C++ is that user defined types can be fully integrated with the type system so you don't need to have special built-in types can can't be implemented as a user-defined type. It doesn't have a built-in complex number type either, but again a special built-in type is not supposed to be necessary, by design.
I completely agree with the rest of your comment. Templates are complicated, but that is getting better with recent language changes. Concepts are going to help a lot if we can ever get them into the standard. Couldn't agree more on the legacy C crud and #include. Hopefully we'll get modules in C++ soon.
These things are all better in D, especially build times. D has it's own issues though.
Nothing happens.
