Yeah. I run screaming from any system that doesn't have intellectual owners (the people who wrote it, or current developers enhancing it,) or has owners that don't like it. I'm trying to kill off one of these beasts right now - the users hate it, the only developers left are $1000/day "consultants," and it's 5 years out of date with respect to business needs. I feel a little bad for all the people who have built a "career" around supporting this hell-spawned beast.
I've seen a number of private sector firms with coding standards. Some are just a few pages of common sense rules (naming conventions, etc) while others were book-length horrors created by people so incompetent that management didn't trust them to write code. I've seen requirements forbidding constants in code (correct practice was #define THIRTY_SEVEN 37, believe it or not,) and crazy Hungarian style naming conventions (nothing like several characters of line noise at the end of every function name.
My current firm's approach is pretty simple: 1. Write clear, understandable code 2. Make it look like all the other code in our system 3. Use the standard IDE 4. The entire codebase is visible to all developers 5. If you code does not conform, an annotated screenshot of it will be posted to our main developer chatroom 6. People will then discuss your code publicly 7. If the code is truly awful, a senior developer will declare it unacceptable, and delete it from the system
A high-level air force officer can easily waste 5 or 6 hours a week trying to get a good hookup with his secretary.
This fuck-capsule idea is brilliant, and cost-saving to boot. It's got the bed, the porn-screen, and the full-length mirror. Just need a carry-on for the DVDs, lingerie, and booze.
This is the sort of outside-the-box thinking that made me happy to vote Bush the last two elections.
I think the article actually hints at a deeper problem. If we broadly divide programmers into categories:
1. Code monkeys. Write code, happy when it kind of does what is required. 2. Architects. Design and implement libraries and their APIs to make stuff easily usable. 3. Ontologists. Design and implement philosophical frameworks that make big systems work.
then we can put LISP macros somewhere between levels 2 and 3.
In terms of reuse, level 1 code should just be ignored, level 2 code is a good candidate, and level 3 ideas will be automatically reused.
Unfortunately, it is natural for programmers to want to crawl up the scale: code monkeys create bad APIs; architects create bad ontological systems; ontologists wander off into category theory. Sometimes, the developer gets it right, but 90% of the time she just leaves an attractive nuisance lying around.
Given a big system (say 1m+ LOC,) I want something like 3 ontologies, 100 subsystem APIs, and 3000 enduser things (reports, feeds, GUIs, etc.) If I see another 5m LOC system with hundreds of AbstractFactories and XXXFacades and YYYAdaptors, I am going to start shooting people.
Agreed on all parts but the last. How do you know what is unimportant talk, before it happens? You often learn more ( about their approach to code, their level of understanding of the system, their assumptions) by having developers describe their solution to you. The drink nights are a good idea, but you can't kill that kind of in the moment spontaneous idea swapping, with out a good reason.
I usually just ask if my answer to question X will have any effect on what happens in the next 8 hours. If yes, we get a high-cost meeting fast, if no, the programmer looks sheepish and goes back to work.
I'm getting hit with spontaneous idea swapping 20+ times a day: I rule on the easy stuff, defer the unimportant, propose a guess on some stuff, ask for more info on the hard stuff. And send a lot of mail apologizing for getting some things wrong and changing my mind.
Off hours drinks is where we set direction and plan strategy. I agree things are probably quite different when you aren't deploying new code to production every ten minutes or so.
bosses that think they know it all. What happens when some smart alek know it all type kid blows you away with something simplistic that you couldn't figure out / passed over / etc.
To blow someone off like that shows your own idiocy.
If it's "simplistic," it's definitely not going out. If it's "simple," it probably will, and the kid is on the fast track to good money.
If I (and my peers) can't figure out what it's doing, it's of no use to us. "Gee, sorry we lost a billion dollars, the code was too clever for us to figure out" is not a great defense.
Just because he was offering to tell you doesn't mean it wasn't obvious. He was probably saving time, especially if you interrupted him, to let you know that it wasn't an intrusive change and, instead of you taking the time to analyze it yourself, he was just going to tell you.
You have good insight. That, I think, was largely the state of his mind at that time. To flesh out my anecdote: 1. I knew what the change was supposed to do: I, he, and two other people had discussed it at length. 2. I wanted to show him the criteria for success in his role: good, clear, strong code. 3. I wanted him to understand certain parts of the system he is working on - so fine if he spends 80 hours on a 30 min fix. 4. I wanted him to understand that unimportant talk costs us several dollars per minute. That's why we often have drinks nights for informal Q&A and general philosophical BS.
1. it doesn't fix the problem it claims to fix 2. it was personnally installed by the CEO of the vendor's firm 3. it was only installed on a subset of machines (and those in democratic strongholds)
alarm bells should be going off all over the place.
If, at my bank, we tried to push a change that hit even one of the above, ten people would be on the phone to in-house lawyers, compliance, management, etc.
Had one of my new guys yesterday wanting to push a change. "I'll tell you what it does," he said. "Don't bother," I said, "if what it's doing is not obvious, it's not going anywhere."
Simple linear interpolation proves circumcision reduces HIV:
1. Uncut males may acquire HIV. 2. Remove that nasty wedding tackle at birth: no possibility of future HIV acquistion. 3. Remove X% - reduces HIV risk by some amount.
More studies are needed, but a good start would be the surgical reduction of male penises by various amounts (say 10%, 40%, and 80%.) We could then correlate these reductions with rates of future HIV infection.
Naturally, we should do these studies in Africa because those people have a lot of AIDS, and it's only ethical to help them as much as we can.
For now I'm more interested to know how they quantify these improvements.
Quantification is fun field in itself, and by no means trivial. As other posters have noted, there are many leave-n-out approaches: basically, divide the dataset into a training set and a test set, and rank by how accurately the code predicts the test set given the training set.
These types of tests are good in that they are easy to understand by the judges and participants. The problem, of course, is that over repeated trials, information about the test set leaks out in the scoring, and the participants slowly overfit their algorithms to the test set based on scoring feedback (in the extreme case, there is no training data, only test data - the winning algorithms are just maps of matched test inputs to correct outputs.)
Even if you manage to ameliorate this problem (e.g by requiring submission of a function that will be applied to an unknown training set to produce a set of predictions,) there is still the risk that the high scoring functions are not very useful (e.g. predicting someones rating of "The Matrix" is easy and has a low RMS error, but do you even care about error from most peoples rating of "Mr Lucky," most have never heard of it?)
So, to be really useful, you want your rating (objective) function to be weighted by usefulness from the point of view of your business (e.g. yes, everyone like the current blockbuster, but will John Q Random be happy geting "Bringing Up Baby" instead?) Here, "happy" is defined as maximizing profits for the firm:)
So, you often a prize with a simple (but wrong) objective function. Then offer the winners a chance a real money if they work on the actual hard problems the firm is facing (this is what we do on Wall St, anyway;)
If you want to do corporate programming, experience in a corporation is much more important than the actual day-to-day work. You have to learn how these environments function. All to many slashdotters dismiss the entire eco-system as "lots of stupid, pointy-haired bosses."
Bad firms have bad bosses, good firms have good bosses, etc. It's hard when you're inexperienced, but aim for the good firms: being a genius at a bad firm is just damaging to your health.
1. Inventory your skills: are you a programming god or just good? do you want to work long hours, or are just willing to? do you want to build relationships or just write code? does meeting clients excite you or seem a distraction? Answer honestly, and you've got a good cover letter.
2. Hit personal relationships. No hard sell needed, just point out you're looking for a summer job and ask the person to keep you in mind. Mention the points in 1, so he'll feel comfortable in making a recommendation (last thing I want is a person telling me he wants to write code, I refer him to a peer, and the applicant spends all summer trying to meet clients, etc.)
3. Do the usual sending resume stuff. It doesn't hurt and you might find a match.
4. Write code, build on-line relationships w/ other tech people, contribute to open source projects, etc. Sure, it's not a job, but it's better than nothing. I've hired a lot of people based on their OSS participation or academic work.
It's really not that much of a problem. Supercomputers have very different hardware vs support cost trade-offs compared to consumer devices.
True story: a few months ago, my program was running slowly, and I needed a lot more CPUs. Yelled to the guy a few desks away, and he gave me the names of a few idle compute farms. Job was 50% complete after 10 minutes, I thanked him, and laughingly said that I like to measure my compute power in megawatts rather than MIPS.
Now, a couple of metawatts of compute don't sit below your desk: a platoon of sys-admins, building support staff, guards, external liasons, etc, are managing those facilities. When I grabbed them, I didn't worry about minor hardware failures: there are people with full-time jobs who hot-swap failed hardware.
Completely agree. Training is all about making the common-sense response automatic. Many untrained people have the brains to figure out what to do, and most of them will actually do it. Many flail around, though, trying to evaluate competing priorities, and some actually manage to kill themselves as well by executing a good plan while missing some vital piece of knowledge or information (e.g. aviate, navigate, communicate, in that order; turn the power off before helping the guy getting fried; don't jump in the water unless the simpler save-the-drowning-guy plans are inapplicable.)
I use a lot of compute (multiple megawatts, globally distributed.) Even with an in-house support team, I don't see even 99% uptime: in the last two years, I've lost compute twice due to natural disasters, and several more times due to operator error or hardware misconfiguration.
I agree we aren't there yet, but I'll switch to an external compute provider as soon as their perceived reliability and scaling exceeds what I have in-house. I expect that will happen in 2009.
Google, etc, seem to know what they are doing. I'd trust them more than an internal team for my compute needs.
I actually spent a while thinking about this case after posting.
I think it's really a non-issue: allocating, but never writing, a memory area is essentially a fiction. I could just not do it, and the algorithm remains unchanged.
I might just as well have a function called alloc_n_to_the_five - calling it doesn't change the mem usage any more than calling a function called kill_n_to_the_five_elephants kills elephants.
Big O notation requires we do stuff, not call functions that assert they are doing stuff, and then accepting their O() claims. If we allow that, proving N=NP is quite easy.
It's like a computer scientists claiming their new algorithm is always superior as it runs in O(n) times compared to O(n^2) but not realizing that his memory usage is O(n^5) compared to O(n).
Um, no. If mem usage is O(n^5), by definition, the algorithm runs in no better than O(n^5) time.
So, the first 1500 pages seem to be one or two columns of data on the pilots involved (# of flight hours?) The next 1000 pages are incident reports (planes 1 thru 6, but mostly 1 or 2 planes,) with so few columns you can't tell who, what, or when the incident occurred.
Hey, NASA, thanks a lot.
(oh, and if you're worried about people using a modified/hacked data set, publish a hash on your website.)
Every OS service you mention was a feature added to OSes sometime between 1950 and 1985. All good things, I agree, but all over 20 years old.
As to the doing two things.
1. Yes, developers don't have to reinvent the wheel for simple stuff, but Linux, for example, still makes us reimplement a lot of things. Why no automatic persistence? Why no automatic rollback? Why no automatic compute farm distribution? Why no refinable auto-generated GUIs? Why no intelligent files that load as objects by default? There are a lot of cool ideas from the last two decades that have been starved for developers.
2. Isolating individual programs from each other and protecting against rogue software. This is a great example of how stuck in the past we are. The linux, and most OS's, model is that the computer and its OS are the important things that should be protected, while users should just manage their own stuff. This made sense in 1980, when computers and OSes were expensive, sensitive user data was rare, networking was rare, and third-party and malicious software was almost non-existant. Now the situation has changed 180 degrees: computers and OSes are practically free, networking is ubiquitous, user data is sensitive, and malware abounds. A model of "trust X or don't trust X" is just outdated and wrong. There are way better data/program models for the current world, but most FOSS hackers are working on the old model, not the better ones. I don't think FOSS is totally to blame here: Windows is just as bad, and the fact that bot-nets and owned boxes are so common is just a sign that we've lost a lot of smart people to engineering rather than innovation.
That's a bit like saying "that's that computer languge is." Under the hood 6502 assembly and LISP ae the same, but that doesn't have much to do with anything.
As you say, it might change incrementally, and that is what JL is complaining about! We've got a very nice bit of polished 1970's tech called Linux, and now we are changing it incrementally when we should be seeking better paradigms.
"why won't the OS auto-save each document I'm working on every 1-5 minutes so I can recover from mistakenly overwriting a file or saving it when I intended to discard changes?"
Because the OS has no idea which chunk of memory corresponds to which chunk of which file and how to convert the memory chunk to the file chunk. That is what the application that you are working on the document with knows; thus it is the application's job to save it.
This is largely what JL is complaining about. We have a mindset of what the OS is, the apps are, etc. This mindset is very 1970s. Really innovative stuff breaks the current paradigm and frees people from the mundane trivia they think is required.
For example, the OS/app thingie I'm running right now has ten or so 'magic' features at the OS level (e.g. worldwide, transactional filesystem, full timetravel, callbackless GUI framework, seamless compute farm distribution.)
As you say, even if I open-sourced it, most developers would just ignore it, and keep doing what they are used to. In the closed source world, things are sometimes different: a manager sends a geek out to look at X, after a few weeks of immersion, the geek reports that the system is seriously cool, meeting are set up to address scalability and support, and then millions of dollars are committed to the effort.
Contrast that with, say, Smalltalk (a seriously cool system) that is still limping along in the FOSS world.
Christie's spokesman Rik Pike stood behind the authenticity of the auction and said the disgruntled buyer's case had no merit.
Nor did you read the actual article:
According to the lawsuit, Spiner recognized the visor as the one that had been sold by Christie's and told Moustakis that it wasn't the real deal. The actual visor had been sold by the actor himself some time ago.
Regardless of any indemnification on Christi's part on their website, by stating publicly that you stand behind the authenticity, they are de-facto guaranteeing the authenticity.
I did read the post, and article. Note that the Christie's spokesman carefully avoided standing behind the authenticity of the item - he only said the auction itself was authentic.
They'll claim they did due diligence. It doesn't matter if the item eventually proved to be fake. At worst, they'll unwind the sale.
No judge is going to find fraud here, unless they made some serious misrepresentation. These guys have two hundred years experience selling art, etc, with questionable history coming out of war-torn countries. You really think this visor is going to blindside them in a fraud suit?
In general, the auction house is just selling stuff, not standing behind its authenticity.
For art, and other one of a kind items, they rely on provenance - essentially a chain of ownerswhip back to the original source. For some items, they may rely on an outside expert (e.g. for a newly "discovered" Picasso.)
If they've done this, they are assumed to be acting in good faith, and you have little chance of collecting damages for fraud - be happy the transaction is cancelled, and you get your money back.
That dial technology does sound cool, modulo the adding detergent thing (has that been solved?)
If truth be known, I probably wouldn't even buy an iDishwasher. My current dishwasher setup is hi-tech enough that I need only place the used plate, etc, in a visible location, and the kitchen system whisks it away, cleans it, and returns it to the correct cupboard. My hi-tech stove is a similar marvel: it often detects that I am hungry, and asks me what I want to eat (my wife has to translate because it lacks an English language module,) then, a little while later, it produces the requested food item. Quite cool, actually. I'm surprised these things haven't caught on more.
Designing a good dishwasher is pretty damn simple, and cellphones are definitely not involved.
1. It should have a button marked "WASH" - that causes the dishes to get washed. That's the whole point of the fucking machine. 2. For extra credit, it can have a button marked "WASH CHEAPLY IN THE NEXT 24 HOURS" - I can understand that, and might press it before going to work some days. 3. It should have a big hole in the top where I can pour several pounds of dishwashing detergent. When it starts running low, it could even have a light that says "PLEASE ADD MORE DETERGENT."
Slashdot Mirror
Yeah. I run screaming from any system that doesn't have intellectual owners (the people who wrote it, or current developers enhancing it,) or has owners that don't like it. I'm trying to kill off one of these beasts right now - the users hate it, the only developers left are $1000/day "consultants," and it's 5 years out of date with respect to business needs. I feel a little bad for all the people who have built a "career" around supporting this hell-spawned beast.
I've seen a number of private sector firms with coding standards. Some are just a few pages of common sense rules (naming conventions, etc) while others were book-length horrors created by people so incompetent that management didn't trust them to write code. I've seen requirements forbidding constants in code (correct practice was #define THIRTY_SEVEN 37, believe it or not,) and crazy Hungarian style naming conventions (nothing like several characters of line noise at the end of every function name.
My current firm's approach is pretty simple:
1. Write clear, understandable code
2. Make it look like all the other code in our system
3. Use the standard IDE
4. The entire codebase is visible to all developers
5. If you code does not conform, an annotated screenshot of it will be posted to our main developer chatroom
6. People will then discuss your code publicly
7. If the code is truly awful, a senior developer will declare it unacceptable, and delete it from the system
A high-level air force officer can easily waste 5 or 6 hours a week trying to get a good hookup with his secretary.
This fuck-capsule idea is brilliant, and cost-saving to boot. It's got the bed, the porn-screen, and the full-length mirror. Just need a carry-on for the DVDs, lingerie, and booze.
This is the sort of outside-the-box thinking that made me happy to vote Bush the last two elections.
I think the article actually hints at a deeper problem. If we broadly divide programmers into categories:
1. Code monkeys. Write code, happy when it kind of does what is required.
2. Architects. Design and implement libraries and their APIs to make stuff easily usable.
3. Ontologists. Design and implement philosophical frameworks that make big systems work.
then we can put LISP macros somewhere between levels 2 and 3.
In terms of reuse, level 1 code should just be ignored, level 2 code is a good candidate, and level 3 ideas will be automatically reused.
Unfortunately, it is natural for programmers to want to crawl up the scale: code monkeys create bad APIs; architects create bad ontological systems; ontologists wander off into category theory. Sometimes, the developer gets it right, but 90% of the time she just leaves an attractive nuisance lying around.
Given a big system (say 1m+ LOC,) I want something like 3 ontologies, 100 subsystem APIs, and 3000 enduser things (reports, feeds, GUIs, etc.) If I see another 5m LOC system with hundreds of AbstractFactories and XXXFacades and YYYAdaptors, I am going to start shooting people.
I usually just ask if my answer to question X will have any effect on what happens in the next 8 hours. If yes, we get a high-cost meeting fast, if no, the programmer looks sheepish and goes back to work.
I'm getting hit with spontaneous idea swapping 20+ times a day: I rule on the easy stuff, defer the unimportant, propose a guess on some stuff, ask for more info on the hard stuff. And send a lot of mail apologizing for getting some things wrong and changing my mind.
Off hours drinks is where we set direction and plan strategy. I agree things are probably quite different when you aren't deploying new code to production every ten minutes or so.
If it's "simplistic," it's definitely not going out. If it's "simple," it probably will, and the kid is on the fast track to good money.
If I (and my peers) can't figure out what it's doing, it's of no use to us. "Gee, sorry we lost a billion dollars, the code was too clever for us to figure out" is not a great defense.
You have good insight. That, I think, was largely the state of his mind at that time. To flesh out my anecdote:
1. I knew what the change was supposed to do: I, he, and two other people had discussed it at length.
2. I wanted to show him the criteria for success in his role: good, clear, strong code.
3. I wanted him to understand certain parts of the system he is working on - so fine if he spends 80 hours on a 30 min fix.
4. I wanted him to understand that unimportant talk costs us several dollars per minute. That's why we often have drinks nights for informal Q&A and general philosophical BS.
But if:
1. it doesn't fix the problem it claims to fix
2. it was personnally installed by the CEO of the vendor's firm
3. it was only installed on a subset of machines (and those in democratic strongholds)
alarm bells should be going off all over the place.
If, at my bank, we tried to push a change that hit even one of the above, ten people would be on the phone to in-house lawyers, compliance, management, etc.
Had one of my new guys yesterday wanting to push a change. "I'll tell you what it does," he said. "Don't bother," I said, "if what it's doing is not obvious, it's not going anywhere."
Simple linear interpolation proves circumcision reduces HIV:
1. Uncut males may acquire HIV.
2. Remove that nasty wedding tackle at birth: no possibility of future HIV acquistion.
3. Remove X% - reduces HIV risk by some amount.
More studies are needed, but a good start would be the surgical reduction of male penises by various amounts (say 10%, 40%, and 80%.) We could then correlate these reductions with rates of future HIV infection.
Naturally, we should do these studies in Africa because those people have a lot of AIDS, and it's only ethical to help them as much as we can.
Google "god kills a kitten" and you will understand.
For now I'm more interested to know how they quantify these improvements.
:)
;)
Quantification is fun field in itself, and by no means trivial. As other posters have noted, there are many leave-n-out approaches: basically, divide the dataset into a training set and a test set, and rank by how accurately the code predicts the test set given the training set.
These types of tests are good in that they are easy to understand by the judges and participants. The problem, of course, is that over repeated trials, information about the test set leaks out in the scoring, and the participants slowly overfit their algorithms to the test set based on scoring feedback (in the extreme case, there is no training data, only test data - the winning algorithms are just maps of matched test inputs to correct outputs.)
Even if you manage to ameliorate this problem (e.g by requiring submission of a function that will be applied to an unknown training set to produce a set of predictions,) there is still the risk that the high scoring functions are not very useful (e.g. predicting someones rating of "The Matrix" is easy and has a low RMS error, but do you even care about error from most peoples rating of "Mr Lucky," most have never heard of it?)
So, to be really useful, you want your rating (objective) function to be weighted by usefulness from the point of view of your business (e.g. yes, everyone like the current blockbuster, but will John Q Random be happy geting "Bringing Up Baby" instead?) Here, "happy" is defined as maximizing profits for the firm
So, you often a prize with a simple (but wrong) objective function. Then offer the winners a chance a real money if they work on the actual hard problems the firm is facing (this is what we do on Wall St, anyway
If you want to do corporate programming, experience in a corporation is much more important than the actual day-to-day work. You have to learn how these environments function. All to many slashdotters dismiss the entire eco-system as "lots of stupid, pointy-haired bosses."
Bad firms have bad bosses, good firms have good bosses, etc. It's hard when you're inexperienced, but aim for the good firms: being a genius at a bad firm is just damaging to your health.
1. Inventory your skills: are you a programming god or just good? do you want to work long hours, or are just willing to? do you want to build relationships or just write code? does meeting clients excite you or seem a distraction? Answer honestly, and you've got a good cover letter.
2. Hit personal relationships. No hard sell needed, just point out you're looking for a summer job and ask the person to keep you in mind. Mention the points in 1, so he'll feel comfortable in making a recommendation (last thing I want is a person telling me he wants to write code, I refer him to a peer, and the applicant spends all summer trying to meet clients, etc.)
3. Do the usual sending resume stuff. It doesn't hurt and you might find a match.
4. Write code, build on-line relationships w/ other tech people, contribute to open source projects, etc. Sure, it's not a job, but it's better than nothing. I've hired a lot of people based on their OSS participation or academic work.
It's really not that much of a problem. Supercomputers have very different hardware vs support cost trade-offs compared to consumer devices.
True story: a few months ago, my program was running slowly, and I needed a lot more CPUs. Yelled to the guy a few desks away, and he gave me the names of a few idle compute farms. Job was 50% complete after 10 minutes, I thanked him, and laughingly said that I like to measure my compute power in megawatts rather than MIPS.
Now, a couple of metawatts of compute don't sit below your desk: a platoon of sys-admins, building support staff, guards, external liasons, etc, are managing those facilities. When I grabbed them, I didn't worry about minor hardware failures: there are people with full-time jobs who hot-swap failed hardware.
Completely agree. Training is all about making the common-sense response automatic. Many untrained people have the brains to figure out what to do, and most of them will actually do it. Many flail around, though, trying to evaluate competing priorities, and some actually manage to kill themselves as well by executing a good plan while missing some vital piece of knowledge or information (e.g. aviate, navigate, communicate, in that order; turn the power off before helping the guy getting fried; don't jump in the water unless the simpler save-the-drowning-guy plans are inapplicable.)
Well, I'll take the other side...
I use a lot of compute (multiple megawatts, globally distributed.) Even with an in-house support team, I don't see even 99% uptime: in the last two years, I've lost compute twice due to natural disasters, and several more times due to operator error or hardware misconfiguration.
I agree we aren't there yet, but I'll switch to an external compute provider as soon as their perceived reliability and scaling exceeds what I have in-house. I expect that will happen in 2009.
Google, etc, seem to know what they are doing. I'd trust them more than an internal team for my compute needs.
I actually spent a while thinking about this case after posting.
I think it's really a non-issue: allocating, but never writing, a memory area is essentially a fiction. I could just not do it, and the algorithm remains unchanged.
I might just as well have a function called alloc_n_to_the_five - calling it doesn't change the mem usage any more than calling a function called kill_n_to_the_five_elephants kills elephants.
Big O notation requires we do stuff, not call functions that assert they are doing stuff, and then accepting their O() claims. If we allow that, proving N=NP is quite easy.
It's like a computer scientists claiming their new algorithm is always superior as it runs in O(n) times compared to O(n^2) but not realizing that his memory usage is O(n^5) compared to O(n).
Um, no. If mem usage is O(n^5), by definition, the algorithm runs in no better than O(n^5) time.
So, the first 1500 pages seem to be one or two columns of data on the pilots involved (# of flight hours?) The next 1000 pages are incident reports (planes 1 thru 6, but mostly 1 or 2 planes,) with so few columns you can't tell who, what, or when the incident occurred.
Hey, NASA, thanks a lot.
(oh, and if you're worried about people using a modified/hacked data set, publish a hash on your website.)
Every OS service you mention was a feature added to OSes sometime between 1950 and 1985. All good things, I agree, but all over 20 years old.
As to the doing two things.
1. Yes, developers don't have to reinvent the wheel for simple stuff, but Linux, for example, still makes us reimplement a lot of things. Why no automatic persistence? Why no automatic rollback? Why no automatic compute farm distribution? Why no refinable auto-generated GUIs? Why no intelligent files that load as objects by default? There are a lot of cool ideas from the last two decades that have been starved for developers.
2. Isolating individual programs from each other and protecting against rogue software. This is a great example of how stuck in the past we are. The linux, and most OS's, model is that the computer and its OS are the important things that should be protected, while users should just manage their own stuff. This made sense in 1980, when computers and OSes were expensive, sensitive user data was rare, networking was rare, and third-party and malicious software was almost non-existant. Now the situation has changed 180 degrees: computers and OSes are practically free, networking is ubiquitous, user data is sensitive, and malware abounds. A model of "trust X or don't trust X" is just outdated and wrong. There are way better data/program models for the current world, but most FOSS hackers are working on the old model, not the better ones. I don't think FOSS is totally to blame here: Windows is just as bad, and the fact that bot-nets and owned boxes are so common is just a sign that we've lost a lot of smart people to engineering rather than innovation.
That's a bit like saying "that's that computer languge is." Under the hood 6502 assembly and LISP ae the same, but that doesn't have much to do with anything.
As you say, it might change incrementally, and that is what JL is complaining about! We've got a very nice bit of polished 1970's tech called Linux, and now we are changing it incrementally when we should be seeking better paradigms.
"why won't the OS auto-save each document I'm working on every 1-5 minutes so I can recover from mistakenly overwriting a file or saving it when I intended to discard changes?"
Because the OS has no idea which chunk of memory corresponds to which chunk of which file and how to convert the memory chunk to the file chunk. That is what the application that you are working on the document with knows; thus it is the application's job to save it.
This is largely what JL is complaining about. We have a mindset of what the OS is, the apps are, etc. This mindset is very 1970s. Really innovative stuff breaks the current paradigm and frees people from the mundane trivia they think is required.
For example, the OS/app thingie I'm running right now has ten or so 'magic' features at the OS level (e.g. worldwide, transactional filesystem, full timetravel, callbackless GUI framework, seamless compute farm distribution.)
As you say, even if I open-sourced it, most developers would just ignore it, and keep doing what they are used to. In the closed source world, things are sometimes different: a manager sends a geek out to look at X, after a few weeks of immersion, the geek reports that the system is seriously cool, meeting are set up to address scalability and support, and then millions of dollars are committed to the effort.
Contrast that with, say, Smalltalk (a seriously cool system) that is still limping along in the FOSS world.
Didn't even read the full post did you?
Christie's spokesman Rik Pike stood behind the authenticity of the auction and said the disgruntled buyer's case had no merit.
Nor did you read the actual article:
According to the lawsuit, Spiner recognized the visor as the one that had been sold by Christie's and told Moustakis that it wasn't the real deal. The actual visor had been sold by the actor himself some time ago.
Regardless of any indemnification on Christi's part on their website, by stating publicly that you stand behind the authenticity, they are de-facto guaranteeing the authenticity.
I did read the post, and article. Note that the Christie's spokesman carefully avoided standing behind the authenticity of the item - he only said the auction itself was authentic.
They'll claim they did due diligence. It doesn't matter if the item eventually proved to be fake. At worst, they'll unwind the sale.
No judge is going to find fraud here, unless they made some serious misrepresentation. These guys have two hundred years experience selling art, etc, with questionable history coming out of war-torn countries. You really think this visor is going to blindside them in a fraud suit?
In general, the auction house is just selling stuff, not standing behind its authenticity.
For art, and other one of a kind items, they rely on provenance - essentially a chain of ownerswhip back to the original source. For some items, they may rely on an outside expert (e.g. for a newly "discovered" Picasso.)
If they've done this, they are assumed to be acting in good faith, and you have little chance of collecting damages for fraud - be happy the transaction is cancelled, and you get your money back.
That dial technology does sound cool, modulo the adding detergent thing (has that been solved?)
If truth be known, I probably wouldn't even buy an iDishwasher. My current dishwasher setup is hi-tech enough that I need only place the used plate, etc, in a visible location, and the kitchen system whisks it away, cleans it, and returns it to the correct cupboard. My hi-tech stove is a similar marvel: it often detects that I am hungry, and asks me what I want to eat (my wife has to translate because it lacks an English language module,) then, a little while later, it produces the requested food item. Quite cool, actually. I'm surprised these things haven't caught on more.
Agreed.
Designing a good dishwasher is pretty damn simple, and cellphones are definitely not involved.
1. It should have a button marked "WASH" - that causes the dishes to get washed. That's the whole point of the fucking machine.
2. For extra credit, it can have a button marked "WASH CHEAPLY IN THE NEXT 24 HOURS" - I can understand that, and might press it before going to work some days.
3. It should have a big hole in the top where I can pour several pounds of dishwashing detergent. When it starts running low, it could even have a light that says "PLEASE ADD MORE DETERGENT."
I'll wait for the iDishwaher.