That's pretty much exactly backwards. Without physical security, it's extremely hard to provide any further security assurances. How much money and time has Apple spent trying to lock down their custom phone designs? This company doesn't have the advantage of designing everything from the CPU to the overall system, so they're going to inevitably rely on good behavior to minimize security compromises.
I'm not sure what the standard is in Europe for in-home heat generation, but in the US, water heaters (which need to direct heat to a relatively small vessel) are separate from central heating systems and space heaters (which both want to distribute heat to the general indoor "environment"). How were you thinking this would work? Like an electric kettle, or hooked into the home's hot water system? Neither seems very practical, given the vessel vs environment heating problem.
Turning half your installed equipment off for a third to half of the year seems like it will really stretch out the time to break even on it -- I don't think margins on cloud computing are that fat.
If I could think of that in half a second after thinking that maybe they'd just turn things of during the summer, maybe you could too.
I know the French take a vacation in August, but it seems like you wouldn't want a space heater running during any of the summer. Even if you have air conditioning, you'd have to pay more to pump the generated great out of your home.
I stand by my comment. Look at any of the studies discussing work breakdowns in serious software engineering projects: the amount that can be fairly called documentation will be less than the amount of other design work (thinking, analysis, experimentation, etc.) plus implementation, to say nothing about requirements development or verification or the other odds and ends of a development cycle. You wrote that "doing it right" meant that documentation takes a majority of the time, and that is simply wrong.
Again, I said documentation is distinct from those other things, not that it was optional. You're continuing to misread plain English. You recognize that someone might design or create a thing without documenting what they did. That means the documentation is distinct. We agree that the documentation still needs to be done.
This is one of the problems: sloppy commenters like to read ideas into statements that contradict those ideas.
Creating documentation is sharply distinct from design and implementation. It requires a different skill set and attitude, although it must be done in harmony with the rest of the development effort. I did not suggest it was not important. I only pointed out that it is different, and explained why developers should spend most of their time on things besides documentation.
Something that works poorly will not work any better just because it comes with great documentation, and people tend to think that "lots of documentation" is automatically "good documentation"; see also the well-deserved comments in this thread about explanation-free Doxygen output.
If you're spending more time on documentation than on design or implementation, you're either doing safety-critical work, or you're doing it wrong. 95% of software should use design elements that are familiar to the users in a way that makes it easy to discover how to do what they want.
There will always be uncommon tasks or unusual users such that some documentation is necessary (and that needs to be clear and effective), but end-user documentation should never be that big a chunk of the development effort. If it is, you're designing something that is too hard to use.
The solution to Python having problems is not to pancake more awful ideas (like ORMs) on top of its rotten foundation, making an ever-more-precarious edifice of fail stacked upon fail. What are you, a Python programmer?
Data comes over the network, and sometimes it's not in the representation you want. SELECT smallint_column FROM mysql_table, and Python's bindings give you a string. The language accommodates the mistake up front, and raises an exception long after the initial mistake. Yes, this is a fault in the language.
As the saying goes, "move fast and break things", but it should also tell you to expect your end users to find another tool when you break their stuff.
Python's type-related problems are not because of duck typing. They are because it uses a damaged mix of strong and weak dynamic typing. You get None when you read an undefined field of an object, no error if you store to a field nobody ever reads, no warning if you store a string like '123' to a variable that normally holds a number, and an exception if you try to divide that variable by 3.
And don't get me started on the egregious breakages between Python 2 and 3, like changing the definition of the / operator solely to save a bit of typing (or alternatively, error checking) by one constituency while making the language less consistent.
People complain about semantic whitespace in Python because that's a pants-on-head stupid detail to make people pay attention to. There are enough things that need attention that invisible characters shouldn't be one of them.
That's a silly generalization, because most characters are printing. But the real problem isn't that changing whitespace will make Python code not run; the worst case is that it silently changes the behavior of the code. I've lost track of how many times Python code at my workplace has had long-standing bugs because of simple typos.
Slashdot Mirror
That's pretty much exactly backwards. Without physical security, it's extremely hard to provide any further security assurances. How much money and time has Apple spent trying to lock down their custom phone designs? This company doesn't have the advantage of designing everything from the CPU to the overall system, so they're going to inevitably rely on good behavior to minimize security compromises.
I'm not sure what the standard is in Europe for in-home heat generation, but in the US, water heaters (which need to direct heat to a relatively small vessel) are separate from central heating systems and space heaters (which both want to distribute heat to the general indoor "environment"). How were you thinking this would work? Like an electric kettle, or hooked into the home's hot water system? Neither seems very practical, given the vessel vs environment heating problem.
Turning half your installed equipment off for a third to half of the year seems like it will really stretch out the time to break even on it -- I don't think margins on cloud computing are that fat.
If I could think of that in half a second after thinking that maybe they'd just turn things of during the summer, maybe you could too.
I know the French take a vacation in August, but it seems like you wouldn't want a space heater running during any of the summer. Even if you have air conditioning, you'd have to pay more to pump the generated great out of your home.
Don't take it up with me, take it up with your dictionary.
I stand by my comment. Look at any of the studies discussing work breakdowns in serious software engineering projects: the amount that can be fairly called documentation will be less than the amount of other design work (thinking, analysis, experimentation, etc.) plus implementation, to say nothing about requirements development or verification or the other odds and ends of a development cycle. You wrote that "doing it right" meant that documentation takes a majority of the time, and that is simply wrong.
Again, I said documentation is distinct from those other things, not that it was optional. You're continuing to misread plain English. You recognize that someone might design or create a thing without documenting what they did. That means the documentation is distinct. We agree that the documentation still needs to be done.
BetaNews is exercising a new paradigm: aspect-oriented reporting.
This is one of the problems: sloppy commenters like to read ideas into statements that contradict those ideas.
Creating documentation is sharply distinct from design and implementation. It requires a different skill set and attitude, although it must be done in harmony with the rest of the development effort. I did not suggest it was not important. I only pointed out that it is different, and explained why developers should spend most of their time on things besides documentation.
Something that works poorly will not work any better just because it comes with great documentation, and people tend to think that "lots of documentation" is automatically "good documentation"; see also the well-deserved comments in this thread about explanation-free Doxygen output.
When you're running an open source development effort, the developers you're trying to enlist are the target "end users" of your efforts.
If you're spending more time on documentation than on design or implementation, you're either doing safety-critical work, or you're doing it wrong. 95% of software should use design elements that are familiar to the users in a way that makes it easy to discover how to do what they want.
There will always be uncommon tasks or unusual users such that some documentation is necessary (and that needs to be clear and effective), but end-user documentation should never be that big a chunk of the development effort. If it is, you're designing something that is too hard to use.
Using positioning to indicate structure isn't necessarily bad. Using it to determine structure is.
The solution to Python having problems is not to pancake more awful ideas (like ORMs) on top of its rotten foundation, making an ever-more-precarious edifice of fail stacked upon fail. What are you, a Python programmer?
Data comes over the network, and sometimes it's not in the representation you want. SELECT smallint_column FROM mysql_table, and Python's bindings give you a string. The language accommodates the mistake up front, and raises an exception long after the initial mistake. Yes, this is a fault in the language.
His psychologist also claims that Love's eczema is a reason he shouldn't be extradited, so I think we know how seriously to take the general argument.
If Python is for people who want to do things right the first time, why Python 2, much less Python 3?
As the saying goes, "move fast and break things", but it should also tell you to expect your end users to find another tool when you break their stuff.
I disagree. LaTeX can make printouts of *anything* look good, even if your source material is something like lemonparty or tubgirl.
Python's type-related problems are not because of duck typing. They are because it uses a damaged mix of strong and weak dynamic typing. You get None when you read an undefined field of an object, no error if you store to a field nobody ever reads, no warning if you store a string like '123' to a variable that normally holds a number, and an exception if you try to divide that variable by 3.
And don't get me started on the egregious breakages between Python 2 and 3, like changing the definition of the / operator solely to save a bit of typing (or alternatively, error checking) by one constituency while making the language less consistent.
People complain about semantic whitespace in Python because that's a pants-on-head stupid detail to make people pay attention to. There are enough things that need attention that invisible characters shouldn't be one of them.
That's a silly generalization, because most characters are printing. But the real problem isn't that changing whitespace will make Python code not run; the worst case is that it silently changes the behavior of the code. I've lost track of how many times Python code at my workplace has had long-standing bugs because of simple typos.
It takes Microsoft-class, Apple-style courage to rename "grep" to "select-string-path" and call the result a PowerShell.
Warning: Eurocrats are known to the state of California to cause cancer, birth defects, or other reproductive harm.
Now they will need to add "speak their mind" to that list.
Please, tell us more about how Google, Facebook, Amazon, and the other big corporations are part of the right-wing fascist conspiracy.