I have a totally ridiculous theory about how to achieve desirable effects on the body. In spite of its ridiculousness, it nonetheless seems to born out by my informal experiments and sort of an exponentially weighted moving average of the various studies and what they say.
I call it "conservation of misery". If you want to avoid misery from your body falling apart and your energy being in the tank you'll have to make unpleasant commitments in some kind in terms of diet, exercise and overall lifestyle.
Diet: So, for instance, on the diet side, it could be eating more plant matter... the less appetizing the better, or a little less of everything else, or a lot less junk carbs. Or it could be some combination... the more effort you put in the better it works
Exercise: On the exercise side it could be a lot of easy work (moderate endurance work, familiar exercise), or smaller amounts of much more vigorous exercise. Varying the routine so your body can't really adjust to doing just one thing well is another way to up the misery and effectiveness.
Lifestyle: On the lifestyle side it could be including more incidental activity (walking to more things, taking the stairs... usually when you're stressed and in a rush). It might include getting to bed early (before anything good comes on the tube). It probably needs to include the discipline to eat lightly at dinner (the hardest time not to overeat) and have a good breakfast that you actually made yourself hungry for by not overeating at dinner.
As a parent of three at the moment I find starting meals with raw veg, some vigorous but relatively unvaried activity in the morning with dumbells, and throwing three kids around to play with them is about all I can fit in. Willpower is weak at dinner... that's probably the single hardest thing thing for me and not coincidentally what I need to work on the most to get better.
YMMV. But one way or another, good luck with the delayed gratification and congrats on being in the shape to do marathons... I'm certainly not, I tap out at about 10 miles.
Google is not the voice of the people. While they might have a nicer company culture for the time being, in the long term it will inevitably dilute and they will bow to the same pressures as any publicly traded company and there are plenty of signs that they're moving in that direction.
So any win here is short term at best and only if Google uses the patents defensively rather than offensively. That is more likely for now, but saying " I can't wait until they sue Apple out of existence". Really? Should we cheer if another maker of good products and the strongest android competitor goes out the business? Seems like a recipe for cell phone SUCK.
And of course, this is continuing the ingrain a dangerous rubber stamp mentality we have on green-lighting clearly anti-competitive mergers. We were frankly darn lucky to avoid the AT&T T-Mobile merger debacle. We can't apply our criteria based on who we like or pretty soon everything goes.
If I'm forced to do something in the source code that makes me ill, I grouse about it openly, give the detailed reasons behind it being where it is for now, and the TODO for the (hopefully near) future. I feel like if I don't and the code shows up on a blame as mine, it's my DUTY to the next developer to leave them some clue about {ahem} what occured.
I don't use curse words so I've only been taken to task once for doing it in 10+ years. But I LIKE seeing cursing. Part of that is a little vicarious thrill... I've got three kids and can't afford to take stupid chances. But seriously, some of the stuff you encounter deserves it so richly. Hearing the echo of the prior developer cursing gives me a little emotional validation and a little helpful context while I'm detangling the mess.
Honestly, AT&T's threat to raise rates is exactly the sort of thing that confirms that denying them was a good idea. If a company can raise their prices and expect to make more money, rather than lose customers to less petulant firms, they already have dangerously high market power(particularly for something as relatively homogenous as wireless telco services. Certain goods simply don't have much in the way of substitutes).
One could go so far as to say that, as a heuristic, anybody who could make, and make good on, such a threat if they don't get what they want, Should Not be allowed to get what they want...
Totally agreed, way too timidly stated. I would suggest that's you've identified the SINGLE BEST HEURISTIC for whether or not a competitive marketplace exists. Businesses in that position not only must not be allowed to get what they want now, but must be broken up now to help restore a competitive marketplace.
And we need to limit the scope of our interest to changes from the status quo... requests for mergers and such. A lot of things got to be very messed up in this country because real competition has been skirted effectively in a number of industries whether by big business or concerted lobbying. Start by take a look at what is ridiculously more expensive in this country vs. other similar countries, find what has reduced effective competition and DESTROY. Telco is on the list but let's start with medicine (17% of gdp and rising!? wtf).
We have a pretty terrible level of unemployment and underemployment in this country and yet, many employers claim to have difficulty finding workers.
Why??? There's such a thing as supply and demand and at a high enough price, you can find someone. Employers may not agree, but that just means that they can't wrap their head around what they actually have to pay. And of course perish the thought of hiring someone who hasn't already done the job either. There's a shift of mindset that has to occur here about the pay those who can do deserve, and the opportunities those who might be able to should be afforded.
I have really mixed feelings here because I know a lot of good people here on H1-Bs. Here's the thing, in the short term people do compete for a fixed pie, and once you're out of this business for more than 9 months it's next to impossible to re-enter... I know a lot of people who found themselves in that situation, too. So, it's hard to make the argument that H1-Bs visas increase the demand in a way that's broadly helpful to the locally resident software grunts.
Of course, that's not the whole point... we are also, with competition trying to reduce costs and create positive ripple effects that increase competitiveness and aid hiring in other industries, too. And I do understand targeting... the "give me your poor" line on lady liberty is a beautiful sentiment but not sane U.S. domestic policy so you have to be a little choosy. So why not software?
If we are trying to do targeting based on a perceived shortage, let's go back to the laws of supply and demand and figure out what they're telling us. The most objective way to measure a shortage is not based on the amount of whining, but based on prices. Most of the highest paid professions in this country are in the medical field. I'm not saying that high pay isn't deserved, I'm just saying that the eye popping character of it all should command our attention and make us think about what it's doing to say, anyone who's sick without insurance and to our deficit. Rather unlike software, we have a compelling national interest in trying to supplement this labor market.
If you think IBM isn't getting paid a ton licensing its war chest of patents you're crazy. Estimates vary, but they are LARGE.
And that's not even the primary reason companies go for patents, especially the stupid ones.
The real reason to go for as many patents as possible is to have as many legal weapons as possible to bludgeon and gut any up and comers with a competing product. A protracted legal battle against a foe with those kinds of resources, even if won, will sink most companies.
I'm not a big fan of commenting code. I prefer code possessing such clarity that it is self-commenting. If your code fails this test, no amount of commenting will improve the situation. Bad code is bad code, no matter how well-commented it is. (True, some code is truly difficult to comprehend and therefore requires comments, usually because what the code is doing is supremely complicated and difficult to comprehend itself. I'm not talking about that kind of code).
Now describing the design overall, that's another matter. But most of the designs I'm called in to fix are so bad that they are undocumentable.
In principle I agree and you should design and refactor as necessary to get your code as clear as possible. Some designs as you said, are so bad they're undocumentable anyway. (And actually, the relative ease of documenting code is the single best heuristic as to the maintainability of the design).
That said, even a nice design and code written "as clear as possible" is not good enough for the long haul.
This is irritating as hell because it seems so obvious right now... after all, you just wrote it and all the unspoken assumptions about what this is for, how it should or should not be used, and behavior in corner cases are known to you without a second thought.
Will they be when you or someone else has to come back to it months or years later? Of course not, that's what the comments are for. There's a balance to be struck here, some comments are dumb... for instance, anything auto-generated or which just restates in imprecise language an adjacent conditional. That said, the amount of commentary your should write is always greater than your expectations.
If you haven't written comments along the way please, please get a code review now. Anything you've had to explain to your reviewer that's not already in a comment, put it in a comment. It's not perfect, but it's a start.
They won't and can't understand the value in improvements in test suite results or complexity measures.
Explain very simply.
Features are assets. Lines of code are liabilities.
People confuse the two because you need some code to make a feature, but every line has a finite chance of creating a bug incurring a support cost, and whether it introduces a bug or not it makes for more code to sort through to find the bugs in other parts of the code.
The only real value of your application is in the features. If that's hard for them to quantify, that's understandable, but if that's hard for them to understand then that's insane. If you like, as a last ditch effort you might go back to the scenario oriented demonstrations that were convincing the first time but if that doesn't work, it's time to look for greener pastures.
Knuth lost his wager how many times? Of course there should be reviews.
And yes, in the short term, it would benefit the reviewer more than the reviewed. Does that make it a bad thing? Think about organizations with highly centralized expertise and trust vs. ones where it's more distributed. Which are better places to work, keep better people and do better over time? If Google doesn't they should start making him do code reviews.
Consumption taxes, when level and consistent are recognized as being really highly efficient and non-distorting in comparison to other schemes.
The thing that stinks is that those at the lower and lower middle parts economic scale generally consume just about 100% of their income. As a result, this sort of tax hits them the hardest.
In European countries, this is offset by directed government largess. I propose that instead of directed government largess with all the complexity/inefficiency and corruption that invites let's have the government's largest expenditure be transparent, no strings attached supplementation of legally earned pay, per pay period.
That supplement could start at a fixed level and then match fractionally increases in pay with a lower fractional match as these numbers rise and eventually, past a certain good upper middle class income at which point the match should go away and it just becomes a fixed figure (if the desire strikes to have the this figure decline as income rises, you haven't set your consumption tax high enough). This paired structure would work like a progressive income tax in terms of who it draws revenues from and at what rate except that it automatically captures the black market, those who legally (but still annoyingly!) mooch off others, and those who inherited money from dead relatives and do nothing to produce on their own.
If the fixed initial supplement were generous enough to bring a household just past poverty level then you could make the statement that we have no working poor anymore... which would be a amazing. And if you'd take that level and add in current minimum wage, you could abolish the minimum wage, which would make more marginal people employable and provide a path for them back toward a law abiding existence. In fact I'd wager it would more or less solve the problem of unemployment except for those with pretty severe disabilities. If you have a good system for recognizing that and caring for those people then could solve the problem of poverty in this country entirely except for the very few who are capable of work, but unwilling to do so. I'm fine with letting them go.
Anyways, just a suggestion, and yes I know the consumption tax rate would have to to be very high to do something like this. I still think it's the right way to go.
This guy is a marketing/business guy. The innovations he's going to care about in the game itself... there's nothing about angry birds as a game that would qualify.
It's the business model. So yeah, low priced cell phone games will be huge in terms of adoption, doubtless rivaling and probably eclipsing consoles and PC gaming because most everyone has a phone on them at all times. Profitability, meh, who knows. But he's resting on a wild success story so he projects into the future based on that.
But anyways, hats off to him as a marketing guy, he got us talking about Angry Birds.
Right now gas stations have obvious peak times during rush hours. Obviously, nothing so ridiculous as everyone going at the exact same time, which is the best fit to your blurb, but still, high demand times nonetheless. And if we were talking about energy delivery comparable to how and when we gas our cars, I agree you'd have a problem. However, most people will get most of their juice at home overnight, which while increasing electricity draw, doesn't demand a bigger power station than we have now.
Charging stations will predominantly serve road trippers, and there's categorically less of that sort of traffic, and from my experience on the road, the "fill up" times are much more random and better distributed than on a day with a 9-5. These charging stations would need a lot of juice and possibly some special handling by the grid, but there wouldn't have to be such a huge number of these, so I think the challenge could be dealt with reasonably well.
My major concern isn't what the consequences would be if electric vehicles became ubiquitous, but whether this, like so many other stories promising great things for electric cars right down the road, will turn out to be mostly hype. The charging time statement is pretty incredible, and deserves scrutiny... how can you charge so fast without generating a ton of heat?
haven't done this on a car, but I'll definitely recommend it for luggage. Have nice cover since I'm always travelling with my wife. Also got plaid luggage tags. When luggage gets misrouted, all you have to say is pink with plaid tags and it gets back to you 10X faster than it would otherwise.
But Perl promotes bad practices, by naming variables like $_ and @_,...
Implicit variables give some of the same convenience in programming as pronouns in natural language, except unlike pronouns, the implicit variables have the same meaning each time. I've never been a fan of Perl syntax, but if you spend any amount of time in Perl at all $_, and @_ should be old friends.
I think having form of implicit variables in the language is a great convenience feature and the only thing I'd say is that they should have names that let you know what you're dealing with without internalizing a table of (mostly) $<FOO>. But then again, we're talking about Perl here.
1. Reliability? - A responsible computer user will still need to maintain backups of SSDs in the same way that they currently do for hard disks. Sure, the failure rate of SSDs may be lower but, ultimately, every SSD will eventually fail - and because it's a new technology, people do need to be extra vigilant for previously unforeseen problems that may only appear after millions of them have been sold. The price of three hard disks (a mirrored pair and a backup disk) is still far cheaper than one SSD.
It's true that disks have been around longer and are cheaper to mirror, but proper wear leveling SSDs are the norm now, so reliability concerns are mainly FUD, and TRIM support is also the norm now, so performance degradation nearly as big a problem as it was. Importantly, there's nothing analogous to a head crash... if you loose data, it's at a much smaller granularity and more frequent than actual data loss is that blocks get marked as bad when the bits get stuck and you loose a little capacity over time.
Also, I'll say that in much much less than 30 years of experience, I've already seen RAID fail in a practical sense 2 times... that is two failures within the same drive array too close together to be replaced. One was related to ordering procedures and bureaucracy (2 weeks should be enough time to get a replacement drive), but another pairing of failures were only a day and a half apart... that's impossible unless you're getting your components from best buy. It makes sense... if you're using the same drives from the same manufacturing run in the same way, you're practically begging them to die at the same time.
Finally, I do support the notion of local nightly backups to disk for convenience sake, but the only truly safe backup is one that's distributed geographically as well as with repetition in media.
3 - Bootup/operational speed - I'd certainly be impatient waiting 5 or 6 minutes for a computer to boot up but I'm not sure my life is that busy that waiting 30 seconds for a hard disk as opposed to 3 seconds for an SSD matters that much to me. In my 30 years computing experience, machine speed comes from avoiding bottlenecks and good OS optimisations - yes, a faster SSD helps with the hard disk speed bottleneck but that still leaves things like the amount of memory, CPU power, OS bloat and fragmentation to consider.
How valuable your computer's speed is to you depends on how valuable you consider your time to be. At home, maybe it doesn't matter to you, but from your employers perspective the value of your time is quantifiable... basically: salary+benefits / expected hours of work. Other people have already run their numbers and YMMV, but to me it's pretty convincing that the payback interval in terms of time saved is pretty short... not to mention the saved aggravation. CPU is the bottleneck a small and shrinking category of applications. OS bloat is inevitable, but you can pick a slim distro if you're feeling weighed down. In your list, that leaves fragmentation which is a problem tailor made for SSDs, because random access is orders of magnitude faster.
Man in Black: All right. Where is the poison? The battle of wits has begun. It ends when you decide and we both drink, and find out who is right... and who is dead.
Vizzini: But it's so simple. All I have to do is divine from what I know of you: are you the sort of man who would put the poison into his own goblet or his enemy's? Now, a clever man would put the poison into his own goblet, because he would know that only a great fool would reach for what he was given. I am not a great fool, so I can clearly not choose the wine in front of you. But you must have known I was not a great fool, you would have counted on it, so I can clearly not choose the wine in front of me.
Man in Black: You've made your decision then?
Vizzini: Not remotely. Because iocane comes from Australia, as everyone knows, and Australia is entirely peopled with criminals, and criminals are used to having people not trust them, as you are not trusted by me, so I can clearly not choose the wine in front of you.
Man in Black: Truly, you have a dizzying intellect.
Being able to clearly make out the immediate section of road ahead (pothole vs. oil slick, to use your example) is much more important than long distance vision as long as illumination distance > braking distance(including reaction time). If you're driving faster than that, then you're an idiot.
Being blinded by oncoming cars with their high beams is a problem either way, but when I use my lights, I'm certainly not blinded for anywhere near 10s (maybe 2s) because my pupils are not nearly as dilated as yours. That, and other cars on the road can see me, so I'm less likely to be hit.
All around much, much safer to have the lights on.
Add increased stupidity (poor public education combined with broader usage) to bloat in TGMLC to get a real sense for what will really be run on this fabulous new hardware.
The ability to load and run stuff in C libraries is present in most major languages because it's too useful not to include. A lot of minor languages compile through C and make things potentially even easier (at least at run time).
There's plenty of highly dynamic languages in both of those lists that directly or indirectly could do what you're asking for here.
I will say, I'm disappointed by the comments I've seen here on slashdot.
Best comment came from an anonymous coward about the pining for an "emergent" type system, the fact that we're not wired that way, and that while more power gives some more in the way of degrees of freedom, it doesn't mean that everything can be analyzed together... you have to have some way of focusing (and a pretty darn good one to prevent unimaginable problem blowup).
Bootstrapping works well when confined to a fixed arena with observable and unambiguous criteria for selection of behaviors or incorporating a piece of knowledge and observable and unambiguous criteria for judging the success thereof. That is to say, a tight focus and goal directed behavior. Without these and a tight feedback loop, the resulting system tends to disappoint.
Having as your scope, reading the web to gain an understanding of the world is um... just a bit outside that template for success. While the big talk may be a pre-requisite for grant interest, I doubt have nearly as many illusions as the average slashdot reader. I hope their work goes well, and I hope some of their techniques for extracting information from the web prove useful. That said, it looked like their initial target was classification only. Not trivial, but a very small part of the puzzle of intelligence to say the least, especially when you consider the fact that the classifications this thing will suck in will reflect mostly the sort of classifications that we don't take for granted.
And here I'll start reflecting my bias. I am a former #$HumanCyclist (I did an internship about 10 years ago), because even though I am in some ways disappointed, I do think that the fact that they're actually building something (and along the way have been solving problems with it) and have been for a lot of years means that there's a lot to learn from them.
Among the things the Cyc project has shown, is exactly how important these sorts of unstated classifications turn out to be in the problem of doing even the most mundane things right. But there's no point dwelling on that, because even assuming you have some impossibly large beautiful graph reflecting a really solid and well thought out classification of everything, from every angle (hahaha), you're nowhere.
Facts are fuel... the engine is the rules. Reading those from free text is a very, very dicey proposition, both because the parsing is infinitely harder, and because much more so than facts, they're largely unstated and in terms of our own learning, inferred from examples. You can set up probability matrixes or the like, but only if you know what you're evaluating for (how would you program "curiosity"?). Even if you do get those matrices, reasoning with them directly is pretty much impracticable, so you have to have to make some arbitrary decisions about when you're confident enough to say you "know" something. This is just really, really hard knowledge to get in any automated fashion.
Finally, for both facts and rules, the consequences of incorporating a poorly considered one can be quite dire, and there's no practiceable way (as the amount of knowledge grows) to know whether it's consistent with what is considered true to that point.
Getting even more slippery, there is no one context or frame to consider everything in. This goes equally well for facts and rules. You could try and split hairs and say that given enough antecedents, your facts and rules are solid. However, as any kind of remotely practical matter, you need a way of accumulating and organizing these antecedents, and that's true from both from an technical (engine execution), and practical (reasoning and learning ease) perspective.
Oh, and as a minor matter, languages are difficult enough from a syntactic dimension, and the symantics of it (in order to understand a statement, you have to understand the ones prior, the context or framing that may have switched, the built up assumptions that maybe can be discarded, maybe not, etc.
Intelligence is one thing, relevant skills is another.
When was the last time you hunted in pack on foot, or fashioned, thrust, or threw a spear? What about starting a fire without a match? There's more than a bit of learning and physical conditioning necessary to be a successful "primitive".
These things time to develop, and it doesn't sound like the life expectancy on bear island is long enough.
I certainly hope China isn't the last with most of Africa in such a desperate condition. Low pay manufacturing jobs there would be far, far better than the current state of affairs.
Opening a window of opportunity for a continent matters in a way that the difference between a manufacturing and service industry wage in the U.S. does not.
You really, really, really have to narrow your question down or the whole thing is transparently a load of BS.
There's good practical advice out there, some on this thread, much more in the books referenced... but extracting advice from uncorrelated sources does not make for a phd or even necessarily anything particularly useful, because some advice applies best in some situations, and other, possibly conflicting advice applies best in other situations.
Slashdot Mirror
I have a totally ridiculous theory about how to achieve desirable effects on the body. In spite of its ridiculousness, it nonetheless seems to born out by my informal experiments and sort of an exponentially weighted moving average of the various studies and what they say.
I call it "conservation of misery". If you want to avoid misery from your body falling apart and your energy being in the tank you'll have to make unpleasant commitments in some kind in terms of diet, exercise and overall lifestyle.
Diet:
So, for instance, on the diet side, it could be eating more plant matter... the less appetizing the better, or a little less of everything else, or a lot less junk carbs. Or it could be some combination... the more effort you put in the better it works
Exercise:
On the exercise side it could be a lot of easy work (moderate endurance work, familiar exercise), or smaller amounts of much more vigorous exercise. Varying the routine so your body can't really adjust to doing just one thing well is another way to up the misery and effectiveness.
Lifestyle:
On the lifestyle side it could be including more incidental activity (walking to more things, taking the stairs... usually when you're stressed and in a rush). It might include getting to bed early (before anything good comes on the tube). It probably needs to include the discipline to eat lightly at dinner (the hardest time not to overeat) and have a good breakfast that you actually made yourself hungry for by not overeating at dinner.
As a parent of three at the moment I find starting meals with raw veg, some vigorous but relatively unvaried activity in the morning with dumbells, and throwing three kids around to play with them is about all I can fit in. Willpower is weak at dinner... that's probably the single hardest thing thing for me and not coincidentally what I need to work on the most to get better.
YMMV. But one way or another, good luck with the delayed gratification and congrats on being in the shape to do marathons... I'm certainly not, I tap out at about 10 miles.
Google is not the voice of the people. While they might have a nicer company culture for the time being, in the long term it will inevitably dilute and they will bow to the same pressures as any publicly traded company and there are plenty of signs that they're moving in that direction.
So any win here is short term at best and only if Google uses the patents defensively rather than offensively. That is more likely for now, but saying " I can't wait until they sue Apple out of existence". Really? Should we cheer if another maker of good products and the strongest android competitor goes out the business? Seems like a recipe for cell phone SUCK.
And of course, this is continuing the ingrain a dangerous rubber stamp mentality we have on green-lighting clearly anti-competitive mergers. We were frankly darn lucky to avoid the AT&T T-Mobile merger debacle. We can't apply our criteria based on who we like or pretty soon everything goes.
If I'm forced to do something in the source code that makes me ill, I grouse about it openly, give the detailed reasons behind it being where it is for now, and the TODO for the (hopefully near) future. I feel like if I don't and the code shows up on a blame as mine, it's my DUTY to the next developer to leave them some clue about {ahem} what occured.
I don't use curse words so I've only been taken to task once for doing it in 10+ years. But I LIKE seeing cursing. Part of that is a little vicarious thrill... I've got three kids and can't afford to take stupid chances. But seriously, some of the stuff you encounter deserves it so richly. Hearing the echo of the prior developer cursing gives me a little emotional validation and a little helpful context while I'm detangling the mess.
I'm shocked I tell you.
And to do so because Google isn't "social" enough. What an original thought in these days leading up to the facebook ipo!
Honestly, AT&T's threat to raise rates is exactly the sort of thing that confirms that denying them was a good idea. If a company can raise their prices and expect to make more money, rather than lose customers to less petulant firms, they already have dangerously high market power(particularly for something as relatively homogenous as wireless telco services. Certain goods simply don't have much in the way of substitutes).
One could go so far as to say that, as a heuristic, anybody who could make, and make good on, such a threat if they don't get what they want, Should Not be allowed to get what they want...
Totally agreed, way too timidly stated. I would suggest that's you've identified the SINGLE BEST HEURISTIC for whether or not a competitive marketplace exists.
Businesses in that position not only must not be allowed to get what they want now, but must be broken up now to help restore a competitive marketplace.
And we need to limit the scope of our interest to changes from the status quo... requests for mergers and such. A lot of things got to be very messed up in this country because real competition has been skirted effectively in a number of industries whether by big business or concerted lobbying. Start by take a look at what is ridiculously more expensive in this country vs. other similar countries, find what has reduced effective competition and DESTROY. Telco is on the list but let's start with medicine (17% of gdp and rising!? wtf).
We have a pretty terrible level of unemployment and underemployment in this country and yet, many employers claim to have difficulty finding workers.
Why??? There's such a thing as supply and demand and at a high enough price, you can find someone. Employers may not agree, but that just means that they can't wrap their head around what they actually have to pay. And of course perish the thought of hiring someone who hasn't already done the job either. There's a shift of mindset that has to occur here about the pay those who can do deserve, and the opportunities those who might be able to should be afforded.
I have really mixed feelings here because I know a lot of good people here on H1-Bs. Here's the thing, in the short term people do compete for a fixed pie, and once you're out of this business for more than 9 months it's next to impossible to re-enter... I know a lot of people who found themselves in that situation, too. So, it's hard to make the argument that H1-Bs visas increase the demand in a way that's broadly helpful to the locally resident software grunts.
Of course, that's not the whole point... we are also, with competition trying to reduce costs and create positive ripple effects that increase competitiveness and aid hiring in other industries, too. And I do understand targeting... the "give me your poor" line on lady liberty is a beautiful sentiment but not sane U.S. domestic policy so you have to be a little choosy. So why not software?
If we are trying to do targeting based on a perceived shortage, let's go back to the laws of supply and demand and figure out what they're telling us. The most objective way to measure a shortage is not based on the amount of whining, but based on prices. Most of the highest paid professions in this country are in the medical field. I'm not saying that high pay isn't deserved, I'm just saying that the eye popping character of it all should command our attention and make us think about what it's doing to say, anyone who's sick without insurance and to our deficit. Rather unlike software, we have a compelling national interest in trying to supplement this labor market.
If you think IBM isn't getting paid a ton licensing its war chest of patents you're crazy. Estimates vary, but they are LARGE.
And that's not even the primary reason companies go for patents, especially the stupid ones.
The real reason to go for as many patents as possible is to have as many legal weapons as possible to bludgeon and gut any up and comers with a competing product. A protracted legal battle against a foe with those kinds of resources, even if won, will sink most companies.
I'm not a big fan of commenting code. I prefer code possessing such clarity that it is self-commenting. If your code fails this test, no amount of commenting will improve the situation. Bad code is bad code, no matter how well-commented it is. (True, some code is truly difficult to comprehend and therefore requires comments, usually because what the code is doing is supremely complicated and difficult to comprehend itself. I'm not talking about that kind of code).
Now describing the design overall, that's another matter. But most of the designs I'm called in to fix are so bad that they are undocumentable.
In principle I agree and you should design and refactor as necessary to get your code as clear as possible. Some designs as you said, are so bad they're undocumentable anyway. (And actually, the relative ease of documenting code is the single best heuristic as to the maintainability of the design).
That said, even a nice design and code written "as clear as possible" is not good enough for the long haul.
This is irritating as hell because it seems so obvious right now... after all, you just wrote it and all the unspoken assumptions about what this is for, how it should or should not be used, and behavior in corner cases are known to you without a second thought.
Will they be when you or someone else has to come back to it months or years later? Of course not, that's what the comments are for.
There's a balance to be struck here, some comments are dumb... for instance, anything auto-generated or which just restates in imprecise language an adjacent conditional. That said, the amount of commentary your should write is always greater than your expectations.
If you haven't written comments along the way please, please get a code review now. Anything you've had to explain to your reviewer that's not already in a comment, put it in a comment. It's not perfect, but it's a start.
They won't and can't understand the value in improvements in test suite results or complexity measures.
Explain very simply.
Features are assets.
Lines of code are liabilities.
People confuse the two because you need some code to make a feature, but every line has a finite chance of creating a bug incurring a support cost, and whether it introduces a bug or not it makes for more code to sort through to find the bugs in other parts of the code.
The only real value of your application is in the features. If that's hard for them to quantify, that's understandable, but if that's hard for them to understand then that's insane. If you like, as a last ditch effort you might go back to the scenario oriented demonstrations that were convincing the first time but if that doesn't work, it's time to look for greener pastures.
Knuth lost his wager how many times?
Of course there should be reviews.
And yes, in the short term, it would benefit the reviewer more than the reviewed. Does that make it a bad thing?
Think about organizations with highly centralized expertise and trust vs. ones where it's more distributed.
Which are better places to work, keep better people and do better over time?
If Google doesn't they should start making him do code reviews.
Consumption taxes, when level and consistent are recognized as being really highly efficient and non-distorting in comparison to other schemes.
The thing that stinks is that those at the lower and lower middle parts economic scale generally consume just about 100% of their income.
As a result, this sort of tax hits them the hardest.
In European countries, this is offset by directed government largess. I propose that instead of directed government largess with all the complexity/inefficiency and corruption that invites let's have the government's largest expenditure be transparent, no strings attached supplementation of legally earned pay, per pay period.
That supplement could start at a fixed level and then match fractionally increases in pay with a lower fractional match as these numbers rise and eventually, past a certain good upper middle class income at which point the match should go away and it just becomes a fixed figure (if the desire strikes to have the this figure decline as income rises, you haven't set your consumption tax high enough). This paired structure would work like a progressive income tax in terms of who it draws revenues from and at what rate except that it automatically captures the black market, those who legally (but still annoyingly!) mooch off others, and those who inherited money from dead relatives and do nothing to produce on their own.
If the fixed initial supplement were generous enough to bring a household just past poverty level then you could make the statement that we have no working poor anymore... which would be a amazing. And if you'd take that level and add in current minimum wage, you could abolish the minimum wage, which would make more marginal people employable and provide a path for them back toward a law abiding existence. In fact I'd wager it would more or less solve the problem of unemployment except for those with pretty severe disabilities. If you have a good system for recognizing that and caring for those people then could solve the problem of poverty in this country entirely except for the very few who are capable of work, but unwilling to do so. I'm fine with letting them go.
Anyways, just a suggestion, and yes I know the consumption tax rate would have to to be very high to do something like this. I still think it's the right way to go.
This guy is a marketing/business guy.
The innovations he's going to care about in the game itself... there's nothing about angry birds as a game that would qualify.
It's the business model. So yeah, low priced cell phone games will be huge in terms of adoption, doubtless rivaling and probably eclipsing consoles and PC gaming because most everyone has a phone on them at all times.
Profitability, meh, who knows. But he's resting on a wild success story so he projects into the future based on that.
But anyways, hats off to him as a marketing guy, he got us talking about Angry Birds.
Right now gas stations have obvious peak times during rush hours. Obviously, nothing so ridiculous as everyone going at the exact same time, which is the best fit to your blurb, but still, high demand times nonetheless. And if we were talking about energy delivery comparable to how and when we gas our cars, I agree you'd have a problem. However, most people will get most of their juice at home overnight, which while increasing electricity draw, doesn't demand a bigger power station than we have now.
Charging stations will predominantly serve road trippers, and there's categorically less of that sort of traffic, and from my experience on the road, the "fill up" times are much more random and better distributed than on a day with a 9-5. These charging stations would need a lot of juice and possibly some special handling by the grid, but there wouldn't have to be such a huge number of these, so I think the challenge could be dealt with reasonably well.
My major concern isn't what the consequences would be if electric vehicles became ubiquitous, but whether this, like so many other stories promising great things for electric cars right down the road, will turn out to be mostly hype. The charging time statement is pretty incredible, and deserves scrutiny... how can you charge so fast without generating a ton of heat?
As are most managers.
haven't done this on a car, but I'll definitely recommend it for luggage.
Have nice cover since I'm always travelling with my wife.
Also got plaid luggage tags.
When luggage gets misrouted, all you have to say is pink with plaid tags and it gets back to you 10X faster than it would otherwise.
But Perl promotes bad practices, by naming variables like $_ and @_, ...
Implicit variables give some of the same convenience in programming as pronouns in natural language, except unlike pronouns, the implicit variables have the same meaning each time. I've never been a fan of Perl syntax, but if you spend any amount of time in Perl at all $_, and @_ should be old friends.
I think having form of implicit variables in the language is a great convenience feature and the only thing I'd say is that they should have names that let you know what you're dealing with without internalizing a table of (mostly) $<FOO>. But then again, we're talking about Perl here.
1. Reliability? - A responsible computer user will still need to maintain backups of SSDs in the same way that they currently do for hard disks. Sure, the failure rate of SSDs may be lower but, ultimately, every SSD will eventually fail - and because it's a new technology, people do need to be extra vigilant for previously unforeseen problems that may only appear after millions of them have been sold. The price of three hard disks (a mirrored pair and a backup disk) is still far cheaper than one SSD.
It's true that disks have been around longer and are cheaper to mirror, but proper wear leveling SSDs are the norm now, so reliability concerns are mainly FUD, and TRIM support is also the norm now, so performance degradation nearly as big a problem as it was. Importantly, there's nothing analogous to a head crash... if you loose data, it's at a much smaller granularity and more frequent than actual data loss is that blocks get marked as bad when the bits get stuck and you loose a little capacity over time.
Also, I'll say that in much much less than 30 years of experience, I've already seen RAID fail in a practical sense 2 times... that is two failures within the same drive array too close together to be replaced. One was related to ordering procedures and bureaucracy (2 weeks should be enough time to get a replacement drive), but another pairing of failures were only a day and a half apart... that's impossible unless you're getting your components from best buy. It makes sense... if you're using the same drives from the same manufacturing run in the same way, you're practically begging them to die at the same time.
Finally, I do support the notion of local nightly backups to disk for convenience sake, but the only truly safe backup is one that's distributed geographically as well as with repetition in media.
3 - Bootup/operational speed - I'd certainly be impatient waiting 5 or 6 minutes for a computer to boot up but I'm not sure my life is that busy that waiting 30 seconds for a hard disk as opposed to 3 seconds for an SSD matters that much to me. In my 30 years computing experience, machine speed comes from avoiding bottlenecks and good OS optimisations - yes, a faster SSD helps with the hard disk speed bottleneck but that still leaves things like the amount of memory, CPU power, OS bloat and fragmentation to consider.
How valuable your computer's speed is to you depends on how valuable you consider your time to be. At home, maybe it doesn't matter to you, but from your employers perspective the value of your time is quantifiable... basically: salary+benefits / expected hours of work. Other people have already run their numbers and YMMV, but to me it's pretty convincing that the payback interval in terms of time saved is pretty short... not to mention the saved aggravation. CPU is the bottleneck a small and shrinking category of applications. OS bloat is inevitable, but you can pick a slim distro if you're feeling weighed down. In your list, that leaves fragmentation which is a problem tailor made for SSDs, because random access is orders of magnitude faster.
Man in Black: All right. Where is the poison? The battle of wits has begun. It ends when you decide and we both drink, and find out who is right... and who is dead.
Vizzini: But it's so simple. All I have to do is divine from what I know of you: are you the sort of man who would put the poison into his own goblet or his enemy's? Now, a clever man would put the poison into his own goblet, because he would know that only a great fool would reach for what he was given. I am not a great fool, so I can clearly not choose the wine in front of you. But you must have known I was not a great fool, you would have counted on it, so I can clearly not choose the wine in front of me.
Man in Black: You've made your decision then?
Vizzini: Not remotely. Because iocane comes from Australia, as everyone knows, and Australia is entirely peopled with criminals, and criminals are used to having people not trust them, as you are not trusted by me, so I can clearly not choose the wine in front of you.
Man in Black: Truly, you have a dizzying intellect.
Vizzini: Wait til I get going! Now, where was I?
Man in Black: Australia.
Being able to clearly make out the immediate section of road ahead (pothole vs. oil slick, to use your example) is much more important than long distance vision as long as illumination distance > braking distance(including reaction time). If you're driving faster than that, then you're an idiot.
Being blinded by oncoming cars with their high beams is a problem either way, but when I use my lights, I'm certainly not blinded for anywhere near 10s (maybe 2s) because my pupils are not nearly as dilated as yours. That, and other cars on the road can see me, so I'm less likely to be hit.
All around much, much safer to have the lights on.
Pull my finger indeed.
Add increased stupidity (poor public education combined with broader usage) to bloat in TGMLC to get a real sense for what will really be run on this fabulous new hardware.
The ability to load and run stuff in C libraries is present in most major languages because it's too useful not to include. A lot of minor languages compile through C and make things potentially even easier (at least at run time).
There's plenty of highly dynamic languages in both of those lists that directly or indirectly could do what you're asking for here.
I will say, I'm disappointed by the comments I've seen here on slashdot.
Best comment came from an anonymous coward about the pining for an "emergent" type system, the fact that we're not wired that way, and that while more power gives some more in the way of degrees of freedom, it doesn't mean that everything can be analyzed together... you have to have some way of focusing (and a pretty darn good one to prevent unimaginable problem blowup).
Bootstrapping works well when confined to a fixed arena with observable and unambiguous criteria for selection of behaviors or incorporating a piece of knowledge and observable and unambiguous criteria for judging the success thereof. That is to say, a tight focus and goal directed behavior. Without these and a tight feedback loop, the resulting system tends to disappoint.
Having as your scope, reading the web to gain an understanding of the world is um... just a bit outside that template for success. While the big talk may be a pre-requisite for grant interest, I doubt have nearly as many illusions as the average slashdot reader. I hope their work goes well, and I hope some of their techniques for extracting information from the web prove useful. That said, it looked like their initial target was classification only. Not trivial, but a very small part of the puzzle of intelligence to say the least, especially when you consider the fact that the classifications this thing will suck in will reflect mostly the sort of classifications that we don't take for granted.
And here I'll start reflecting my bias. I am a former #$HumanCyclist (I did an internship about 10 years ago), because even though I am in some ways disappointed, I do think that the fact that they're actually building something (and along the way have been solving problems with it) and have been for a lot of years means that there's a lot to learn from them.
Among the things the Cyc project has shown, is exactly how important these sorts of unstated classifications turn out to be in the problem of doing even the most mundane things right. But there's no point dwelling on that, because even assuming you have some impossibly large beautiful graph reflecting a really solid and well thought out classification of everything, from every angle (hahaha), you're nowhere.
Facts are fuel... the engine is the rules. Reading those from free text is a very, very dicey proposition, both because the parsing is infinitely harder, and because much more so than facts, they're largely unstated and in terms of our own learning, inferred from examples. You can set up probability matrixes or the like, but only if you know what you're evaluating for (how would you program "curiosity"?). Even if you do get those matrices, reasoning with them directly is pretty much impracticable, so you have to have to make some arbitrary decisions about when you're confident enough to say you "know" something. This is just really, really hard knowledge to get in any automated fashion.
Finally, for both facts and rules, the consequences of incorporating a poorly considered one can be quite dire, and there's no practiceable way (as the amount of knowledge grows) to know whether it's consistent with what is considered true to that point.
Getting even more slippery, there is no one context or frame to consider everything in. This goes equally well for facts and rules. You could try and split hairs and say that given enough antecedents, your facts and rules are solid. However, as any kind of remotely practical matter, you need a way of accumulating and organizing these antecedents, and that's true from both from an technical (engine execution), and practical (reasoning and learning ease) perspective.
Oh, and as a minor matter, languages are difficult enough from a syntactic dimension, and the symantics of it (in order to understand a statement, you have to understand the ones prior, the context or framing that may have switched, the built up assumptions that maybe can be discarded, maybe not, etc.
Aha, sure.
Intelligence is one thing, relevant skills is another.
When was the last time you hunted in pack on foot, or fashioned, thrust, or threw a spear? What about starting a fire without a match? There's more than a bit of learning and physical conditioning necessary to be a successful "primitive".
These things time to develop, and it doesn't sound like the life expectancy on bear island is long enough.
I certainly hope China isn't the last with most of Africa in such a desperate condition.
Low pay manufacturing jobs there would be far, far better than the current state of affairs.
Opening a window of opportunity for a continent matters in a way that the difference between a manufacturing and service industry wage in the U.S. does not.
You really, really, really have to narrow your question down or the whole thing is transparently a load of BS.
There's good practical advice out there, some on this thread, much more in the books referenced... but extracting advice from uncorrelated sources does not make for a phd or even necessarily anything particularly useful, because some advice applies best in some situations, and other, possibly conflicting advice applies best in other situations.