At the end of my college career, I noticed my hands and wrists were getting strained, so I spent my last semester switching to Dvorak, Emacs and the Kinesis Ergo Contoured keyboard from qwerty, vi and the Microsoft Natural keyboard.
There's endless debate about these things, and apparently some questions about Dvorak's research methods. There's also new keyboard layouts that are supposedly about as good as Dvorak without sacrificing usability and faster to learn (I'm talking about the Colemak specifically). Ultimately it is very hard to make a strong recommendation for any of these switches based on a solid, unarguably scientific basis.
However, there is a lot of anecdotal evidence that most people who switch to Dvorak and the Kinesis keyboard experience some combination of reduced hand strain and faster typing. My personal impression is that the Kinesis does more for strain and Dvorak does more for speed and comfort. I personally had reached a plateau in the 75-90 WPM range with qwerty and now I think I'm in the 110-125 WPM range. I don't think Emacs had anything to do with the changes. The control/alt/etc. keys are hit with the thumbs on the Kinesis, and the escape key is still in Siberia, but in practice I don't think either one has any tangible ergonomic charm once you're using Dvorak.
Lately I have noticed that there are some keys which I type strangely. But I was taught on a typewriter and I learned the classical method--I even continue to find use for the caps lock key, a victim of a lot of unnecessary derision in the programming community. I sometimes hit keys that should be hit with the pinky with my ring fingers. I don't think it's worth worrying about too much if you're not looking at the keyboard, it doesn't feel uncomfortable, and it's not slowing you down. The greatest danger, IMO, is discomfort, followed by speed and accuracy problems. Accuracy is the least of my concerns, really. I can usually feel when I've typed something wrong and I correct it often without looking at it.
If you're looking at the keyboard, you would probably benefit from starting over from scratch, and if you're going to do that, it would probably help to switch keyboard layouts at the same time. It'll prevent you from getting more frustrated at the relearning process.
I think this is exactly where the Austrian and Keynesian theories diverge. Unfortunately I don't have any background in Keynesian economics so I stick to what I know. But unlike many around here I am actually quite interested in his philosophy.
Sure it does. Printing money steals from everyone else with the currency. If you have some amount of value or wealth in your country in terms of goods and land, and suddenly there's twice as much money in circulation, everything would suddenly have to cost twice as much for the same amount of value to be exchanged. In essence, by introducing twice as much money into circulation, the money printer has just stolen half the wealth from all users of the currency. The same thing happens for trivial amounts of money, the effect just isn't as pronounced. The first time it's used the money has the same value as it used to. So the effect is especially nasty because it takes a while to materialize.
I actually knew someone whose job was to negotiate with dictators in African countries to trade $1M for some large quantity of newly printed money in the local currency. He'd then take that money and spend it on as much stuff as he could, take it to America and sell it at a profit. The dictator is happy to have a big pile of almost universally accepted US currency and doesn't understand (or care about) economics well enough to understand that he's just helped someone steal both goods and the intangible value of his country's currency.
The games industry as a whole treats their programmers like crap. As a matter of fact, every romanticized occupation with a ton of people lined up outside the door treats their employees poorly. Apple pays less than their Silicon Valley neighbors because they get more applications and the job has that mystique. Coveted jobs = lower pay, higher stress, worse working conditions, more hours, etc.
The difference, to me, is degree of ideology. CL's OOP is intense and powerful, and doesn't feel bolted on later; OCaml's does feel bolted on later. Both are ostensibly functional languages but lack a lot of the pedantic functional purity advocacy; they're out to please. Ruby's standard library has a lot of FP flair but it certainly isn't out to win people from the FP world over to OOP, it's out to accomodate. I can't speak to Lua.
The situation with Go is different in that the designers (I'm talking about Cox here mostly) are vehemently against OOP and I suspect they're as ornery about FP. Go doesn't have a big mishmash of features from different languages to try and get as many bullet points as it can on the box. It's striving for simplicity and to them that means a minimum of features. So you lose inheritance and curried functions and there are no continuations and the lambda syntax is wordy. Those aren't the features they want you to use.
In truth, even with OCaml they don't really push you towards using their object system. Same with PostgreSQL. In both cases, it started life as a research project and got incorporated because it was useful to some minority, but it's not the hallowed programming method. Ironically, with CL, you probably get more blank stares for using advanced FP ideas than for using CLOS. And with Ruby, well, it's all about finesse, and there doesn't seem to be much concern for the featureset you use as long as you make a DSL.
Brevity wasn't the point of the exercise, using Go was. (Although it's worth noting mine is parallel, uses one process, and is much kinder on the memory.)
I wrote a small utility for detecting duplicate files in Go back when it first came out. I haven't really kept it up to date so I'm not sure if it compiles with the current version.
It's an interesting language. Apart from its lineage, which is interesting and great if you're into Plan 9, it seems to me to be an old-school procedural shot across the bow of the current crop of compiled functional languages (ML, Haskell). It's hard to place the language in any camp, because it does furnish functional programming and object-oriented features without really committing to the dogma of either one. It gives you a ton of interesting features that seem to work really well in concert, but it's also missing some core functionality. I can live without exceptions but I'm not sure I can live without type genericity in this day and age. And a lot of other programmers have their own little nits with it.
Overall, it seems great. But I seldom need code compiled to the machine, and I'm conversant with and fond of the compiled FP languages so I tend to rely on them for these kinds of utilities. I suspect at Google this will eventually become the de-facto language for implementing protocol buffer servers. If and when that happens, the language will have a guaranteed niche for a long time to come, whether or not it wins over hearts and minds outside the giant.
I wouldn't trust MySQL's stored procedure system anyway. Last time I used it, there were copious warnings about how it could segfault your server. Also, MySQL can only optimize the outermost query, so if you're doing something with nested selects (such as, using views at all) the performance will be poor.
I know you mean that sardonically but I have to take issue with it.
Evolution does work great for making certain kinds of systems. But look at the human body from an engineering perspective. In many ways it's a marvelous success. But one way in which it isn't, is in terms of modularity.
The essence of good human engineering is decomposing a problem into smaller, more manageable pieces, and solving those one at a time. Ideally, you arrive at a set of components with well-defined purposes that are reasonably easy to replace if they break. Especially if you're interested in reliability or future-proofing.
Nothing made by nature has these properties. Your body is not modular. Your organs have a suite of strange dependencies that confounded medicine for thousands of years. There is no medicine which has no side effects. There are very few organs which can be separated from their environment well enough to admit to easy, universally working replacement. The parts of our medicine that we are best at involve removal, not replacement or augmentation.
These properties are symptomatic of evolutionary systems.
The OSS world isn't really at that extreme, in that there are interfaces created and defined and programmed to fairly often. But they also change often, and this introduces a mental burden. I think it's a trade-off: do you want the newest, most powerful technology, or do you want stability? Everyone wants some of both.
There's been a misunderstanding. I'm not talking about MS or Apple as platforms, I'm talking about them as companies for the sake of describing the way they allocate resources internally, as examples of the corporate world generally, and to compare to the way the OSS world allocates resources.
In a company, you don't have as much internal fragmentation in a company as you do in the OSS community. People regularly get into arguments about whether or not to use git or mercurial. These kinds of decisions are usually made, somewhat arbitrarily, in a corporate setting. It might not get you the best technology, but it does get you past the roadblock of that conversation. OSS often outshines the corporate world in terms of better technology, but it also has much more frivolous argumentation about that technology. I realize I'm saying that on Slashdot. In other words, from a utility perspective, the choice between git and mercurial is arbitrary, especially compared to CVS and SourceSafe. But you can waste a lot of time on it if you're not careful with your time.
I brought up filesystems as an example of the kind of behavior I'm talking about. MS and Apple have not developed dozens of filesystems, about two apiece. I'm not saying that dozens of filesystems don't exist for their platforms; they obviously do. But they weren't developed by the OS vendors themselves, because the OS vendors made their programmers work on other problems once the FS problem was basically solved. From the casual user's perspective, HFS+ and NTFS are basically the same. They both store files and seem acceptably performant, and neither one screws up at an alarming rate.
I'm also not saying that the OSS world is wrong and the corporate world is some kind of utopia. I'm merely arguing that they each have strengths. It's very hard to get volunteers to do unpleasant work. But unpleasant work is often necessary. Your point about abandonware is well taken.
The bread and butter of the open source community are not as high functioning as Linus et. al. A lot of software gets written because it's sexy to write rather than because it's needed. Windows and Mac OS X each have a single window manager and maybe two filesystems; Linux has hundreds of one and dozens of the other because they're sexy and fun to write. We have a half dozen version control systems where MS and Apple each maybe use one or two at most internally. Yet we have few working video drivers. This is a clear benefit of having paid programmers. They write fewer developer tools and spend more time improving existing user-facing stuff, because if they don't, they get fired.
Furthermore, a lot of green programmers start OSS projects to become better at programming. Very little commercial software is written entirely by new programmers. This is why it's hard to stay up-to-date in the Ruby community. A lot of the code is written by new Ruby programmers enamored with language features, and then it has to be thrown away and rewritten differently in the face of real-world demands. There's also more glory in starting projects with promise than in carrying through and maintaining older projects. Few people use FVWM2 even though it's stable, fast and highly configurable. Most Linux users today are probably using Metacity or KWM instead.
Most OSS projects reach a certain level of maturity, get stale and get abandoned, leading to this churn. That doesn't happen in the commercial world because code is perceived as having a dollar value. Sometimes, maybe even frequently, this belief is wrong or overestimated, but it does mean that commercial software is often older than OSS, which (IMO) compensates somewhat for the lack of eyeballs finding bugs. Age finds bugs too.
It's hard for me to imagine the world's most highly performing programmers not contributing to open source, but it's just as silly to expect that they aren't outnumbered by average programmers who don't have time to contribute, or that a dozen average programmers can't produce solid code. In many cases I find they produce simpler, more maintainable code because they're less inclined to the theatrics which are the chief form of compensation for OSS developers.
"Waterfall" is a myth. As this article shows, the actual methodology that created the myth was explicitly cyclic, taking a batch of requirements, specifying them, implementing them, testing them and repeating. "Waterfall" has only ever been a straw man to be attacked by agile proponents. It's easy to make people who have no methodology at all feel like they must have been doing waterfall all along, when they weren't.
Agile might "feel" better for games, but when you have to produce a product that gets pressed on a CD or DVD and run on an embedded system which may not have internet access, it seems to me you need to reach a point of correctness.
Thanks for the clarification. This stuff is so abstract, it seems like whenever someone tries to make it meaningful to the lay person they wind up utterly destroying the truth of what's going on.
Everyone who is annoyed at this article seems to be claiming that the author hasn't experienced agile as it should be practiced.
I have some experience with another methodology, cleanroom software development. The idea behind is, you make a detailed specification, you implement all the code with copious annotations, explaining each line of code. Then you have a big code review, in which each line of code is viewed and the engineers all agree that it correctly implements exactly the specification of the line above it, and that each specification performs part of the overall goal of the program.
After you do all that, you compile and run the program for the first time, and start counting how many bugs you have.
The interesting thing is that cleanroom has been proven many times to produce an order of magnitude fewer bugs. Looking at the method, it's hard to imagine how it couldn't. It has a reputation for making the maintenance phase much lighter, because there are so few problems. Yet, when most people hear about the method, their reaction is revulsion at the overhead and the perceived costs (though in practice, it's been shown that the up-front cost may be higher, the overall cost of the project usually is lower.) Why could this be?
Perhaps these different methods exist because people are different and groups have different priorities. For many people, high turnaround is more important than the lowest bug count, and thus, they choose agile. I tried it and I found it was a poor fit for me. The other partners in my company couldn't stop telling the clients that we used this method, but we never found a client proactive enough to actually make it work. They were shitty clients, sure, but they were the ones we had.
Agile belongs to the class of things which can be disliked for what it is, even by people who know what it is supposed to be like.
I'd tend to agree, but then again, to develop this kind of thing requires a lot of special information. You can't just throw somebody into developing accessibility software, and I doubt you can just wait for a community member to show up and start writing it. The target market here can get pissed off about the quality of the software without necessarily having the ability to acquire and apply the skills necessary to fix it. And as others have pointed out, the ADA makes accessibility legally mandatory rather than optional for lots of government deployment scenarios.
It sounds histrionic to me too, but I can't think of anyone qualified to write this stuff or anyone whose livelihood depends on it either. There may be reason for the outcry.
I am not the guy to answer this, but I'm going to take a stab at it.
The article says that the prior research worked by transmitting the information separately, at the speed of light. So the idea here is apparently that the energy itself can be transmitted instantly, but you can't actually transmit information this way. Just energy.
To do this legally, all Google would have to do is make it an opt-in. In a hundred years or so, everything in copyright now should be out of copyright (I agree that there should be a hard time limit to copyright, and 99 years is too long) so everything published to now could be included for that reason. Google could partner up with publishing houses to sweeten the deal; if you got a book deal, it would likely have a clause in there about Google getting to use it. If you didn't like that, you could self-publish or find another publishing house. Google could offer incentives directly to authors to get their works included. They haven't had any trouble until now making databases with absurd amounts of information in them, this wouldn't be much different. This way, your vast majority of authors get the benefits, the consumers get the benefits, and the people with something to lose don't get fucked. The main difference between these two scenarios is, it involves Google negotiating with publishers at a cost rather than the government to get a free pass. Lots of people have rights they don't use. That doesn't mean the right should go away.
Slashdot Mirror
At the end of my college career, I noticed my hands and wrists were getting strained, so I spent my last semester switching to Dvorak, Emacs and the Kinesis Ergo Contoured keyboard from qwerty, vi and the Microsoft Natural keyboard.
There's endless debate about these things, and apparently some questions about Dvorak's research methods. There's also new keyboard layouts that are supposedly about as good as Dvorak without sacrificing usability and faster to learn (I'm talking about the Colemak specifically). Ultimately it is very hard to make a strong recommendation for any of these switches based on a solid, unarguably scientific basis.
However, there is a lot of anecdotal evidence that most people who switch to Dvorak and the Kinesis keyboard experience some combination of reduced hand strain and faster typing. My personal impression is that the Kinesis does more for strain and Dvorak does more for speed and comfort. I personally had reached a plateau in the 75-90 WPM range with qwerty and now I think I'm in the 110-125 WPM range. I don't think Emacs had anything to do with the changes. The control/alt/etc. keys are hit with the thumbs on the Kinesis, and the escape key is still in Siberia, but in practice I don't think either one has any tangible ergonomic charm once you're using Dvorak.
Lately I have noticed that there are some keys which I type strangely. But I was taught on a typewriter and I learned the classical method--I even continue to find use for the caps lock key, a victim of a lot of unnecessary derision in the programming community. I sometimes hit keys that should be hit with the pinky with my ring fingers. I don't think it's worth worrying about too much if you're not looking at the keyboard, it doesn't feel uncomfortable, and it's not slowing you down. The greatest danger, IMO, is discomfort, followed by speed and accuracy problems. Accuracy is the least of my concerns, really. I can usually feel when I've typed something wrong and I correct it often without looking at it.
If you're looking at the keyboard, you would probably benefit from starting over from scratch, and if you're going to do that, it would probably help to switch keyboard layouts at the same time. It'll prevent you from getting more frustrated at the relearning process.
I think this is exactly where the Austrian and Keynesian theories diverge. Unfortunately I don't have any background in Keynesian economics so I stick to what I know. But unlike many around here I am actually quite interested in his philosophy.
Thanks. That's actually a good point.
Sure it does. Printing money steals from everyone else with the currency. If you have some amount of value or wealth in your country in terms of goods and land, and suddenly there's twice as much money in circulation, everything would suddenly have to cost twice as much for the same amount of value to be exchanged. In essence, by introducing twice as much money into circulation, the money printer has just stolen half the wealth from all users of the currency. The same thing happens for trivial amounts of money, the effect just isn't as pronounced. The first time it's used the money has the same value as it used to. So the effect is especially nasty because it takes a while to materialize.
I actually knew someone whose job was to negotiate with dictators in African countries to trade $1M for some large quantity of newly printed money in the local currency. He'd then take that money and spend it on as much stuff as he could, take it to America and sell it at a profit. The dictator is happy to have a big pile of almost universally accepted US currency and doesn't understand (or care about) economics well enough to understand that he's just helped someone steal both goods and the intangible value of his country's currency.
The games industry as a whole treats their programmers like crap. As a matter of fact, every romanticized occupation with a ton of people lined up outside the door treats their employees poorly. Apple pays less than their Silicon Valley neighbors because they get more applications and the job has that mystique. Coveted jobs = lower pay, higher stress, worse working conditions, more hours, etc.
The difference, to me, is degree of ideology. CL's OOP is intense and powerful, and doesn't feel bolted on later; OCaml's does feel bolted on later. Both are ostensibly functional languages but lack a lot of the pedantic functional purity advocacy; they're out to please. Ruby's standard library has a lot of FP flair but it certainly isn't out to win people from the FP world over to OOP, it's out to accomodate. I can't speak to Lua.
The situation with Go is different in that the designers (I'm talking about Cox here mostly) are vehemently against OOP and I suspect they're as ornery about FP. Go doesn't have a big mishmash of features from different languages to try and get as many bullet points as it can on the box. It's striving for simplicity and to them that means a minimum of features. So you lose inheritance and curried functions and there are no continuations and the lambda syntax is wordy. Those aren't the features they want you to use.
In truth, even with OCaml they don't really push you towards using their object system. Same with PostgreSQL. In both cases, it started life as a research project and got incorporated because it was useful to some minority, but it's not the hallowed programming method. Ironically, with CL, you probably get more blank stares for using advanced FP ideas than for using CLOS. And with Ruby, well, it's all about finesse, and there doesn't seem to be much concern for the featureset you use as long as you make a DSL.
Brevity wasn't the point of the exercise, using Go was. (Although it's worth noting mine is parallel, uses one process, and is much kinder on the memory.)
I wrote a small utility for detecting duplicate files in Go back when it first came out. I haven't really kept it up to date so I'm not sure if it compiles with the current version.
It's an interesting language. Apart from its lineage, which is interesting and great if you're into Plan 9, it seems to me to be an old-school procedural shot across the bow of the current crop of compiled functional languages (ML, Haskell). It's hard to place the language in any camp, because it does furnish functional programming and object-oriented features without really committing to the dogma of either one. It gives you a ton of interesting features that seem to work really well in concert, but it's also missing some core functionality. I can live without exceptions but I'm not sure I can live without type genericity in this day and age. And a lot of other programmers have their own little nits with it.
Overall, it seems great. But I seldom need code compiled to the machine, and I'm conversant with and fond of the compiled FP languages so I tend to rely on them for these kinds of utilities. I suspect at Google this will eventually become the de-facto language for implementing protocol buffer servers. If and when that happens, the language will have a guaranteed niche for a long time to come, whether or not it wins over hearts and minds outside the giant.
I wouldn't trust MySQL's stored procedure system anyway. Last time I used it, there were copious warnings about how it could segfault your server. Also, MySQL can only optimize the outermost query, so if you're doing something with nested selects (such as, using views at all) the performance will be poor.
Good points.
I know you mean that sardonically but I have to take issue with it.
Evolution does work great for making certain kinds of systems. But look at the human body from an engineering perspective. In many ways it's a marvelous success. But one way in which it isn't, is in terms of modularity.
The essence of good human engineering is decomposing a problem into smaller, more manageable pieces, and solving those one at a time. Ideally, you arrive at a set of components with well-defined purposes that are reasonably easy to replace if they break. Especially if you're interested in reliability or future-proofing.
Nothing made by nature has these properties. Your body is not modular. Your organs have a suite of strange dependencies that confounded medicine for thousands of years. There is no medicine which has no side effects. There are very few organs which can be separated from their environment well enough to admit to easy, universally working replacement. The parts of our medicine that we are best at involve removal, not replacement or augmentation.
These properties are symptomatic of evolutionary systems.
The OSS world isn't really at that extreme, in that there are interfaces created and defined and programmed to fairly often. But they also change often, and this introduces a mental burden. I think it's a trade-off: do you want the newest, most powerful technology, or do you want stability? Everyone wants some of both.
There's been a misunderstanding. I'm not talking about MS or Apple as platforms, I'm talking about them as companies for the sake of describing the way they allocate resources internally, as examples of the corporate world generally, and to compare to the way the OSS world allocates resources.
In a company, you don't have as much internal fragmentation in a company as you do in the OSS community. People regularly get into arguments about whether or not to use git or mercurial. These kinds of decisions are usually made, somewhat arbitrarily, in a corporate setting. It might not get you the best technology, but it does get you past the roadblock of that conversation. OSS often outshines the corporate world in terms of better technology, but it also has much more frivolous argumentation about that technology. I realize I'm saying that on Slashdot. In other words, from a utility perspective, the choice between git and mercurial is arbitrary, especially compared to CVS and SourceSafe. But you can waste a lot of time on it if you're not careful with your time.
I brought up filesystems as an example of the kind of behavior I'm talking about. MS and Apple have not developed dozens of filesystems, about two apiece. I'm not saying that dozens of filesystems don't exist for their platforms; they obviously do. But they weren't developed by the OS vendors themselves, because the OS vendors made their programmers work on other problems once the FS problem was basically solved. From the casual user's perspective, HFS+ and NTFS are basically the same. They both store files and seem acceptably performant, and neither one screws up at an alarming rate.
I'm also not saying that the OSS world is wrong and the corporate world is some kind of utopia. I'm merely arguing that they each have strengths. It's very hard to get volunteers to do unpleasant work. But unpleasant work is often necessary. Your point about abandonware is well taken.
The bread and butter of the open source community are not as high functioning as Linus et. al. A lot of software gets written because it's sexy to write rather than because it's needed. Windows and Mac OS X each have a single window manager and maybe two filesystems; Linux has hundreds of one and dozens of the other because they're sexy and fun to write. We have a half dozen version control systems where MS and Apple each maybe use one or two at most internally. Yet we have few working video drivers. This is a clear benefit of having paid programmers. They write fewer developer tools and spend more time improving existing user-facing stuff, because if they don't, they get fired.
Furthermore, a lot of green programmers start OSS projects to become better at programming. Very little commercial software is written entirely by new programmers. This is why it's hard to stay up-to-date in the Ruby community. A lot of the code is written by new Ruby programmers enamored with language features, and then it has to be thrown away and rewritten differently in the face of real-world demands. There's also more glory in starting projects with promise than in carrying through and maintaining older projects. Few people use FVWM2 even though it's stable, fast and highly configurable. Most Linux users today are probably using Metacity or KWM instead.
Most OSS projects reach a certain level of maturity, get stale and get abandoned, leading to this churn. That doesn't happen in the commercial world because code is perceived as having a dollar value. Sometimes, maybe even frequently, this belief is wrong or overestimated, but it does mean that commercial software is often older than OSS, which (IMO) compensates somewhat for the lack of eyeballs finding bugs. Age finds bugs too.
It's hard for me to imagine the world's most highly performing programmers not contributing to open source, but it's just as silly to expect that they aren't outnumbered by average programmers who don't have time to contribute, or that a dozen average programmers can't produce solid code. In many cases I find they produce simpler, more maintainable code because they're less inclined to the theatrics which are the chief form of compensation for OSS developers.
Thanks! I was also wondering if the author could afford a thesaurus.
Second that, emphatically. Simply knowing who the main contributors to CS and what their achievements were would get most anyone a long way forward.
The whole point of Knol was to provide source material for Wikipedia articles. Remember?
"Waterfall" is a myth. As this article shows, the actual methodology that created the myth was explicitly cyclic, taking a batch of requirements, specifying them, implementing them, testing them and repeating. "Waterfall" has only ever been a straw man to be attacked by agile proponents. It's easy to make people who have no methodology at all feel like they must have been doing waterfall all along, when they weren't.
Agile might "feel" better for games, but when you have to produce a product that gets pressed on a CD or DVD and run on an embedded system which may not have internet access, it seems to me you need to reach a point of correctness.
Thanks for the clarification. This stuff is so abstract, it seems like whenever someone tries to make it meaningful to the lay person they wind up utterly destroying the truth of what's going on.
Everyone who is annoyed at this article seems to be claiming that the author hasn't experienced agile as it should be practiced.
I have some experience with another methodology, cleanroom software development. The idea behind is, you make a detailed specification, you implement all the code with copious annotations, explaining each line of code. Then you have a big code review, in which each line of code is viewed and the engineers all agree that it correctly implements exactly the specification of the line above it, and that each specification performs part of the overall goal of the program.
After you do all that, you compile and run the program for the first time, and start counting how many bugs you have.
The interesting thing is that cleanroom has been proven many times to produce an order of magnitude fewer bugs. Looking at the method, it's hard to imagine how it couldn't. It has a reputation for making the maintenance phase much lighter, because there are so few problems. Yet, when most people hear about the method, their reaction is revulsion at the overhead and the perceived costs (though in practice, it's been shown that the up-front cost may be higher, the overall cost of the project usually is lower.) Why could this be?
Perhaps these different methods exist because people are different and groups have different priorities. For many people, high turnaround is more important than the lowest bug count, and thus, they choose agile. I tried it and I found it was a poor fit for me. The other partners in my company couldn't stop telling the clients that we used this method, but we never found a client proactive enough to actually make it work. They were shitty clients, sure, but they were the ones we had.
Agile belongs to the class of things which can be disliked for what it is, even by people who know what it is supposed to be like.
I'd tend to agree, but then again, to develop this kind of thing requires a lot of special information. You can't just throw somebody into developing accessibility software, and I doubt you can just wait for a community member to show up and start writing it. The target market here can get pissed off about the quality of the software without necessarily having the ability to acquire and apply the skills necessary to fix it. And as others have pointed out, the ADA makes accessibility legally mandatory rather than optional for lots of government deployment scenarios.
It sounds histrionic to me too, but I can't think of anyone qualified to write this stuff or anyone whose livelihood depends on it either. There may be reason for the outcry.
That's actually something they just added in 8.4. I wrote a little bit about using this functionality on my blog. The syntax is different than Oracle's though.
I am not the guy to answer this, but I'm going to take a stab at it.
The article says that the prior research worked by transmitting the information separately, at the speed of light. So the idea here is apparently that the energy itself can be transmitted instantly, but you can't actually transmit information this way. Just energy.
Still, that rocks pretty hard.
To do this legally, all Google would have to do is make it an opt-in. In a hundred years or so, everything in copyright now should be out of copyright (I agree that there should be a hard time limit to copyright, and 99 years is too long) so everything published to now could be included for that reason. Google could partner up with publishing houses to sweeten the deal; if you got a book deal, it would likely have a clause in there about Google getting to use it. If you didn't like that, you could self-publish or find another publishing house. Google could offer incentives directly to authors to get their works included. They haven't had any trouble until now making databases with absurd amounts of information in them, this wouldn't be much different. This way, your vast majority of authors get the benefits, the consumers get the benefits, and the people with something to lose don't get fucked. The main difference between these two scenarios is, it involves Google negotiating with publishers at a cost rather than the government to get a free pass. Lots of people have rights they don't use. That doesn't mean the right should go away.
You're right, but they do both use Diffie-Hellman for key exchange, so the security implications of setting up the connection are similar.
No amount of IDE intervention will save you if you try and use PHP like a real programming language.
TextMate's great for what it is. So is PHP.