Did he really make a mistake? He already has one version out and is now finding out what the software really needs to do. That sounds pretty damn successful to me. Now he's dithering about rewriting and replacing some of the libraries, which he would have had to do anyway even if they were custom-written.
If he had written everything from scratch:
Would he even be done coding?
Would his custom code be any more adaptable to the new requests than the existing libraries that he used?
Would he have ended up coding custom libraries for functionality where his needs were actually quite typical, and well-served by existing libraries?
His original choice was correct. As far as replacing Hibernate, he's in just as good a position now as he would have been if he had written his own persistence layer. Remember, he chose Hibernate, which turned out to be unsuitable, because didn't know the requirements when he started. He would have been damn lucky if he had just happened to develop a custom persistance layer that neatly anticipated the unknown requirements. So, ripping out or rewriting the persistence layer was inevitable. If you're going to throw code away, it might as well be code that you got for free, instead of code that you sweated and toiled over.
If you're really dead set against replacing or rewriting any libraries, the only way to improve your odds is to use the biggest, oldest, kitchen-sinkiest, most bloatiest library you can find.
Amen! Daylight savings time just isn't that hard. It would be harder to try to seasonally adjust EVERY schedule I deal with: my work schedule, my girlfriend's work schedule, happy hour, free swim at the pool, class times.... What about people who have recurring appointments: housekeepers, physical therapists, and psychotherapists? Would they shift everyone's appointments seasonally, or would their first morning appointment get moved to the late afternoon in the fall, and then back to the morning in the spring?
I find it ironic (yet predictable) that Slashdotters, the people who can't figure out why Grandma isn't interested in learning grep, cringe at the terrible burden of remembering to change their clocks twice a year. I also find it predictable that so many Slashdotters are clamoring to propose their own radical, complicated, onerous schemes as remedies for a tiny inconvenience.
I went to school in southeastern Ohio and always wondered if the Native Americans who lived there had a word for the sun. Nah, I thought, they probably just thought that clouds glowed in the daytime and stopped glowing at night. They would have to have advanced statistical techniques and many years of astronomical observations before they realized that there was a slightly brighter patch in the clouds that appeared in the east every morning and traveled westward during the day. Then, maybe some clever guy could hypothesize that the bright patch was caused by a big ball of fire somewhere behind the clouds, and everyone would laugh at him.
I am so glad I don't live there anymore. I grew up in the blazing sun, so even though my skin is poorly adapted to it, I'm dependent on it for my sanity. Between dying early of skin cancer and spending 95% of every year deeply depressed by the lack of sunlight, I'll take skin cancer, thank you very much.
I know, I should have bought a broad-spectrum lamp. Too late. My skin is fucked, so I might as well embrace the sunlight.
"Ubuntu" -- an African word, meaning "I'm sick of fucking with Linux in order to get it to do what I want but I really don't like the alternatives."
Quite. Or, alternatively:
"Ubuntu" -- an African word meaning, "I'm paid to make my code run efficiently on other people's computers, not to dick around making other people's code run efficiently on my computer."
sure consumer/home PCs existed. i never denied this (if you'd bothered to actually read my original post). but they were not used by the average person. they were a niche product for a niche market. early computer users usually needed to know how to program, or at least have a strong grasp of DOS/Unix commands. therefore, they weren't basic appliance that everyone owned.
Home computers were used by "average" people long before 1995, and most didn't require any knowledge of programming or operating system commands. Back before multitasking operating systems, there was no need for most people to interact with the operating system at all. Switching between programs could be accomplished by quitting one program, putting in the disk for another program, and rebooting.
I lived in a small, mixed-income town, and lots of teachers from elementary school up to high school learned to use the school's Apple IIe and Apple IIc computers for editing documents, making posters and calendars, and tracking their grades. The ones who could afford to bought one for their homes. In the business world, the same trickle-down effect was happening with PC compatibles, though more slowly and perhaps more limited to technically inclined folks.
Remember that the Atari 2600 sold like gangbusters at (consulting Wikipedia...) two hundred bucks in the 1970s. In the 1980s, computers were acknowledged as "the next big thing" and everyone was buying one "for the kids" so they wouldn't be left behind and left out. People who were willing to shell out 200 bucks for pure entertainment did not hesitate to shell out three or four times that amount to ensure that their kids had every educational advantage. Of course a lot of those machines got used for gaming and personal finances, not just Carmen Sandiego.
The people buying those early home computers may not have been "average" in an economic sense -- they were probably mostly middle class and upper middle class, and mostly well educated and forward-thinking, while the "average" person in the US at that time probably had a high school education and struggled hard to fit the "middle class" label -- but many of the buyers were not tech-savvy at all. Some of them bought a computer expecting to struggle with it, but believing that they had no choice in a world that was more and more permeated by computers. Some bought one because they felt left behind and obsolete and were determined that their children wouldn't be the same way.
A few of those people got more deeply interested in the technical side. They learned to program, or they bought a modem and explored MUDs and bulletin boards. The people who got deeply interested and mucked around with DOS commands were the minority. Most people just used applications, saw zero code, and didn't really know what an OS was.
Sorry, no. It sounded like a lot of work (even more than installing Linux) so I didn't try it.
However, last time I looked (a couple of years ago) there were Fujitsu tablets for sale on Ebay with Windows 95 installed. You might find someone there who can help you.
Actually, the question should be, "Which desktop environment, and which applications?" The desktop environment and applications will eat more resources and have a much bigger impact on performance than the OS.
For Windows, the desktop environment and the OS are pretty thoroughly linked. With Linux, on the other hand, even if you limit yourself to a single major distro such as Ubuntu or Fedora, you can run any desktop environment you like. Lately I've been trying to get acquainted with Fluxbox, which runs just fine (and fast) on my Kubuntu box.
Because the sheer idea of Unix inspires a computer torun more efficiently? I kid, mostly.
A couple years ago I was thinking along the same lines as vigmeister (i.e., getting a Fujitsu tablet for light usage around the house, maybe play go online on the couch.) Reports around the internet were that XP Tablet (or is it just Windows Tablet?) was a dog on old Fujitsus. Windows 2000 was more popular, and some people were even recommending using Windows 95, which required finding Windows tablet functionality that had been backported to 95.
At the time, it sounded like a bit of a project to get Linux working on a Fujitsu tablet. I wonder if anything has changed since then?
Yeah, definitely. One team I'm working with produces software that they sell as a service, but each client pays for different features, and has different customizations. They manage that all through allowing for configuration and localization.
I could see configuration management being perfect for code customization if you had a nice plugin system a la Eclipse. I have done some Eclipse RCP work and am completely sold on the plugin model for customizing and extending applications. I believe Qt provides some support for building plugin-based apps, too.
Unfortunately, we didn't have a plugin system, so that didn't work for us. Either the feature was compiled in (which broke confidentiality even if it wasn't enabled) or it wasn't. Build-time configuration at the #ifdef level or the Makefile level would definitely have worked, but we had all had bad experiences with those techniques and were keen to avoid them.
As for the config files and templates not being in version control, how did you achieve reproducibility for your builds?
You'll need advance permission from the customer for a change like that.
Yeah, that's why I have a product manager in the room, often within arm's reach. They represent the customer fully, and are empowered to make those decisions.
What do you do when the customer rep says: "This time is extremely critical for us. It will be very expensive for us if your changes reveal any bugs in our code or our business processes. Therefore we want no new features, no enhancements, and no bugfixes except this one."
I know there are some kinds of software where you don't hear this kind of thing. I worked on a desktop app where we sometimes rolled out major new features without any notice and sat at our desks with big grins waiting for the excited calls of gratitude to come in:-)
I've also delivered software to a customer whose normal procedure for receiving new software was to spend a week on integration testing and roll out the new version to all their sites over a couple of weeks. Bypassing that process for an urgent bug fix was a really big deal and it would have been entirely unacceptable to ship anything more than a minimal bug fix applied to the version that was already in production.
Also, thinking of that customer brought an entirely different argument to mind, which is that there are times when you have to keep a feature exclusive to one customer, because two of your customers compete against each other and are obsessive about secrecy. When customer A was planning a significant change to their operations, or had a big new deal in the works, any development we did to support those changes was considered confidential. We had to keep it exclusive to them to help ensure that customer B couldn't figure out their plans.
That might be a pretty rare scenario, but I imagine that temporary exclusivity is common practice when a customer contributes money or expertise to the development a new feature.
Which way do you want it? Paid for by advertising, or paid for by you? If it's paid for by advertising, then not only will they go for the biggest possible audience, they will try to attract an audience that works for their advertisers. That is, they will narrowly pitch each show to an advertising segment (say, explosions for the 18-35yo male) instead of to an interest segment.
Hopefully the economic and regulatory climate will make it possible for us to buy well-produced television content or at least buy cable channels a la carte. That way a group of people who share an interest could attract attention from TV producers simply by having money and desiring to buy content, instead of needing to be a known target for an identifiable segment of advertising.
As for public/philanthropic funding, I don't understand why the BBC and PBS consistently produce a trickle of worthwhile television, so I'm somewhat suspicious of that model, but I'll continue to support them given their track record, even if they produce a lot of bland drivel along with the good stuff.
Putting experimental, disabled code in your stable release is a really ugly hack.
Amen! As well as the potential for mistakes in switching, it makes code navigation harder (on the file or directory level) and makes it hard for new developers to get a feel for the code.
Also, when you introduce switching, you commit yourself to the future cost and risk of ripping out the old code. The temptation to bail on that responsibility is high. Here's a simple heuristic: if your team doesn't produce thorough API documentation, they probably won't do a good job of ripping out obsolete code. You'll end up paying the mental code complexity overhead of code you don't even use.
This is true only when you think your changes have a substantial chance of introducing bugs.
You do have a substantial chance of introducing bugs. Or maybe not, but that's how the customer will see it. Good luck convincing them otherwise if they have any experience with software.
Plus, unplanned changes in the software, even enhancements, can be extremely unwelcome for some kinds of software. Theoretically, only the customer knows whether the enhancements will require training, process changes, or integration work (of the "oops, it turns out our code calls your buggy undocumented private API" kind.) In practice, sometimes even the customer is surprised. The customer only wants the potential for surprises when and if there is time budgeted for dealing with them, not with every bug fix.
Even a bug fix can require retraining personnel whose original training took the bug for granted. You'll need advance permission from the customer for a change like that. I.e., you can't just roll out all the changes on TOT without running each change by the customer, even if all the changes are just bug fixes. They might have a good reason for demanding one fix urgently and asking you to hold off on another.
The biggest problem with Java is the kind of work done in it, the style of software required to make that stuff work, and the aesthetics of the resulting systems. In other words, nobody gets turned on by massive, hairy, boring business systems.
The second biggest problem with Java is that it has attracted 95% of this generation's architecture astronauts.
The third biggest problem with Java is that everyone expected a linguistically forward-looking language, and instead they got a fairly conservative one with some obvious warts.
When you look at those problems in perspective, there's nothing so wrong with the language or platform itself. In fact, the platform is pretty damn cool, and one of the coolest new languages (Scala) is a first-class citizen on the platform. Sun is investing money in making the JVM more language-agnostic, which provides language designers with a built-in standard library and a built-in fallback where ther
I really hate it when programmers get architectural ideas.
Ah, the irony. As a Slashdotter, you should know that different kinds of programmers variously care about radical language design, "real programming," trendy application domains, and individual (or small-team) programming. Java is the opposite of a programmer-designed language. As a language and as a platform, it was designed for maximum acceptance by conservative career programmers, easy usage by mediocre (i.e., non-"real") programmers, boring domains (originally set-top boxes, then business middleware,) and large-scale bureaucracy-requiring projects.
Americans have a greater taste for McDonalds fast food and 20th Century Fox entertainment. Freedom, not so much.
It doesn't have to be true to be effective rhetoric that leads us to support better policies, just like, "We are _____, not Americans, and we don't like crappy fast food," is a lie that many countries tell themselves to help them eat less fast food and preserve their own food culture.
A flattering lie is very useful as long as it inspires people to live up to it, instead of inspiring complacency.
It's a naive principle. (I'm not the AC, by the way.) A system of law is like a piece of business software. At first glance, every piece of business software seems unnecessarily elaborate. Then, when you start building systems, you realize that every simple set of rules generates completely insane decisions in a nonnegligible set of cases. The ultimate way to solve this is by allowing a human to override or reinterpret the decisions of the system. However, to minimize abuse and maximize efficiency, it is desirable to reduce the number of cases in which a human intervenes. So you start adding complexity. In the end, a system of law, like a software system, ends up balancing correctness against complexity.
Also, the system has to evolve in a controlled way, because changes require the consent of stakeholders. Engineers (the lobbyists and congressional aides who actually draft legislation) don't have the power to unilateratally impose simplifications that change the behavior of the system. They have to persuade the stakeholders (that's us.) This is good. Otherwise, even if the engineers have the best of intentions (ha!), you get a system that makes sense to the engineers and no one else. Then you get disorientation, discouragement, and disengagement: Kafka's The Castle or, more accessibly, Yakov Smirnoff. (It's no coincidence that the societies with the best tales of surreal bureaucratic insanity are the ones where bureaucrats, or "social engineers" as they have sometimes been called, had the power to "rationalize" society in the name of efficiency.) However, the cost of giving power to stakeholders is that they may demand certain behavior without regard to its implementation complexity. Plus, the inefficiency and imprecision of the process leaves its mark on the product in the form of cruft.
If you think you know a better way, you should test it in the software business first, and then when you've made a few million bucks, bring your insight to politics Ross Perot-style:-)
That's no joke. US intelligence agencies don't bother asking for permission; they just do whatever is technologically and economically feasible without our cooperation. I'm scared about what they might be doing right now. It's not because I'm paranoid; I think there are plenty of people in the intelligence agencies who would leak information about surveillance programs -- IF they thought they were acting contrary to the values of typical Americans.
Unfortunately, our cowardly response to 9/11, following the paranoid and anxious example set by our leaders(*), has surely made it easy for those in the intelligence agencies to believe that Americans, deep down, really don't believe in our national rhetoric of liberty, and we really want to be taken care of by a strong national security apparatus acting outside of law and morality. In other words, we want the government to act like a loving, protective parent, in whom the safety of its children overrides any concern for propriety or morality.
Could we blame them for thinking that way? Can we even blame our leaders for encouraging paranoia and unreasonable anxiety? We have proved our appetite for "scare" news stories about child abduction and Alar on apples. Television news has long been just another horror genre for a species that loves to be scared. Politics has been that way even longer.
I don't think we really want to be that way, though. Maybe in the movie theater, but not on serious issues like our freedom. I hope that if we are asked to face the issue seriously when we are not caught up in a national panic, we will follow the lead of politicians who stand up and say that everybody balances freedom against security, and Americans have a greater taste for freedom than most. If that means allowing a few more serial killers, teenage mass murderers, and terrorists to slip through the cracks and wreak havoc, so be it.
Don't get me wrong, it's obviously unacceptable that a dozen pissed off people can wreak havoc on the scale of 9/11. We should structure our society so that a few pissed off people can't cause such massive disruption. But once we reduce the amount of damage a terrorist can do down to a tolerable level, such as by mandating armored cockpit doors and good cockpit security protocols, and making it sufficiently difficult to bring explosives onto planes, we should relax and treat terrorist attacks like tornadoes. Meh, they're gonna happen, let's do what we reasonably can to make our buildings resistant, educate people to react sensibly, and react to help people after the fact. Terrorists want to affect our government policies and social mores, and we don't want to satisfy them, right? Hurricanes and tornadoes have been killing us for years, and they haven't succeeded in rolling back feminism, ending our support for Israel, or undermining our civil liberties. (Perhaps that second part is unfortunate, but....)
Anyway, we're obviously on the wrong track. Instead of treating terrorist attacks as just another hazard of life on earth, like hurricanes and tornadoes, we've given them a special power over our psyche -- exactly the special power that terrorists want. Instead of repenting of our naive vulnerability, and preparing ourselves to withstand future attacks with minimal damage and loss of life, we have taken for granted that every terrorist poses a terrible, awesome, shattering threat and must be detected and stopped at any expense.
"Safety at any cost" -- that attitude is what Americans have embraced and must now disavow.
(*) Obviously the Bush administration set the initial tone, but members of both parties followed his lead enthusiastically.
I have to say I'm surprised that so many in the MSM seem to think she did a good job.
She set expectations so low. I didn't watch the debate, but my friends who did were really depressed afterwards, because they expected her to humiliate herself again. She delivered a controlled, heavily scripted, marginally competent performance, which is exactly what VP candidates are expected to do.
Come to think of it, controlled, heavily scripted, and marginally competent is exactly what VP candidates are expected to be, so if she keeps this up, she won't hurt McCain at all. Unfortunately.
Developed by Astea in collaboration with Impara GmbH (http://www.impara.de/) of Magdeburg, Germany, and a team of the worldâ(TM)s leading Squeak experts, Sophie is the Instituteâ(TM)s premiere effort.
Why is a team of the world's leading Squeak experts involved in a Java rewrite? The article summary may turn out to be a bigger troll than the one I'm replying to.
The company's "About" page says, Astea has focused its initial activities on the open source market segment with a special focus on university, publishing, and research-oriented applications.
It sounds like the original developers are suffering from jealousy or control issues. Why try to revive a project that he admits is "buggy and slow" when someone else has a grant to rewrite it from scratch? Why get upset over the death of a project that had already stalled out in an (apparently) unusable state? Maybe making an exact copy is a poor use of the Mellon Foundation's money, but then again, it might be a wise idea. Having a reference implementation simplifies development immensely.
When a Grand Master plays a game, there are certainly situations where they are working out a game tree that is a few layers deep. But the limitations of the human brain simply won't allow him to work out an entire tree, or even every move in one layer.
This is a very misleading description of how human chess players work. Humans rarely use exhaustive search further than one move ahead, but they spend a great deal of time during games calculating variations. Even a mediocre player calculates a few moves ahead every time he moves, and many moves ahead in some instances, using heuristics to prune his search tree. Grandmasters use their superior intuition to allow them to look more deeply into the variations, not less. In a complicated position, a grandmaster might identify several key variations, each leading to a different position, and then calculate variations proceeding from those positions, and so on up to the limit of their brains.
As a mediocre amateur (~1600 on a scale where 1000 is a sucky beginner and 2400 is a grandmaster) I routinely calculated the way you described: an incomplete search tree several layers deep. Granted, I tended to miss some important variations, and sometimes my imagination was fuzzy, but I was applying my intuition to the positions that might arise five or six moves ahead, not just to positions that were one or two moves ahead.
Also, even mediocre players have the ability to reason forward ten or fifteen moves in simple endgame situations with lots of forcing moves.
Limiting the release of information from a court case can be appropriate. According to Appel, the judge suppressed the report after Sequoia "grossly mischaracterized" the report, which I bet means they claimed it gratuitously revealed trade secrets. If lawsuits could be used to fish for information about trade secrets, that would be very bad news for small companies trying to compete with rich ones like Microsoft and IBM.
Hopefully the judge only suppressed the report to give herself time to examine the merit of Sequoia's claim. (Also, hopefully she rejects their claim and releases the report quickly enough to make a difference in this election.)
Slashdot Mirror
Did he really make a mistake? He already has one version out and is now finding out what the software really needs to do. That sounds pretty damn successful to me. Now he's dithering about rewriting and replacing some of the libraries, which he would have had to do anyway even if they were custom-written.
If he had written everything from scratch:
His original choice was correct. As far as replacing Hibernate, he's in just as good a position now as he would have been if he had written his own persistence layer. Remember, he chose Hibernate, which turned out to be unsuitable, because didn't know the requirements when he started. He would have been damn lucky if he had just happened to develop a custom persistance layer that neatly anticipated the unknown requirements. So, ripping out or rewriting the persistence layer was inevitable. If you're going to throw code away, it might as well be code that you got for free, instead of code that you sweated and toiled over.
If you're really dead set against replacing or rewriting any libraries, the only way to improve your odds is to use the biggest, oldest, kitchen-sinkiest, most bloatiest library you can find.
Amen! Daylight savings time just isn't that hard. It would be harder to try to seasonally adjust EVERY schedule I deal with: my work schedule, my girlfriend's work schedule, happy hour, free swim at the pool, class times.... What about people who have recurring appointments: housekeepers, physical therapists, and psychotherapists? Would they shift everyone's appointments seasonally, or would their first morning appointment get moved to the late afternoon in the fall, and then back to the morning in the spring?
I find it ironic (yet predictable) that Slashdotters, the people who can't figure out why Grandma isn't interested in learning grep, cringe at the terrible burden of remembering to change their clocks twice a year. I also find it predictable that so many Slashdotters are clamoring to propose their own radical, complicated, onerous schemes as remedies for a tiny inconvenience.
I went to school in southeastern Ohio and always wondered if the Native Americans who lived there had a word for the sun. Nah, I thought, they probably just thought that clouds glowed in the daytime and stopped glowing at night. They would have to have advanced statistical techniques and many years of astronomical observations before they realized that there was a slightly brighter patch in the clouds that appeared in the east every morning and traveled westward during the day. Then, maybe some clever guy could hypothesize that the bright patch was caused by a big ball of fire somewhere behind the clouds, and everyone would laugh at him.
I am so glad I don't live there anymore. I grew up in the blazing sun, so even though my skin is poorly adapted to it, I'm dependent on it for my sanity. Between dying early of skin cancer and spending 95% of every year deeply depressed by the lack of sunlight, I'll take skin cancer, thank you very much.
I know, I should have bought a broad-spectrum lamp. Too late. My skin is fucked, so I might as well embrace the sunlight.
"Ubuntu" -- an African word, meaning "I'm sick of fucking with Linux in order to get it to do what I want but I really don't like the alternatives."
Quite. Or, alternatively:
"Ubuntu" -- an African word meaning, "I'm paid to make my code run efficiently on other people's computers, not to dick around making other people's code run efficiently on my computer."
sure consumer/home PCs existed. i never denied this (if you'd bothered to actually read my original post). but they were not used by the average person. they were a niche product for a niche market. early computer users usually needed to know how to program, or at least have a strong grasp of DOS/Unix commands. therefore, they weren't basic appliance that everyone owned.
Home computers were used by "average" people long before 1995, and most didn't require any knowledge of programming or operating system commands. Back before multitasking operating systems, there was no need for most people to interact with the operating system at all. Switching between programs could be accomplished by quitting one program, putting in the disk for another program, and rebooting.
I lived in a small, mixed-income town, and lots of teachers from elementary school up to high school learned to use the school's Apple IIe and Apple IIc computers for editing documents, making posters and calendars, and tracking their grades. The ones who could afford to bought one for their homes. In the business world, the same trickle-down effect was happening with PC compatibles, though more slowly and perhaps more limited to technically inclined folks.
Remember that the Atari 2600 sold like gangbusters at (consulting Wikipedia...) two hundred bucks in the 1970s. In the 1980s, computers were acknowledged as "the next big thing" and everyone was buying one "for the kids" so they wouldn't be left behind and left out. People who were willing to shell out 200 bucks for pure entertainment did not hesitate to shell out three or four times that amount to ensure that their kids had every educational advantage. Of course a lot of those machines got used for gaming and personal finances, not just Carmen Sandiego.
The people buying those early home computers may not have been "average" in an economic sense -- they were probably mostly middle class and upper middle class, and mostly well educated and forward-thinking, while the "average" person in the US at that time probably had a high school education and struggled hard to fit the "middle class" label -- but many of the buyers were not tech-savvy at all. Some of them bought a computer expecting to struggle with it, but believing that they had no choice in a world that was more and more permeated by computers. Some bought one because they felt left behind and obsolete and were determined that their children wouldn't be the same way.
A few of those people got more deeply interested in the technical side. They learned to program, or they bought a modem and explored MUDs and bulletin boards. The people who got deeply interested and mucked around with DOS commands were the minority. Most people just used applications, saw zero code, and didn't really know what an OS was.
Sorry, no. It sounded like a lot of work (even more than installing Linux) so I didn't try it.
However, last time I looked (a couple of years ago) there were Fujitsu tablets for sale on Ebay with Windows 95 installed. You might find someone there who can help you.
Actually, the question should be, "Which desktop environment, and which applications?" The desktop environment and applications will eat more resources and have a much bigger impact on performance than the OS.
For Windows, the desktop environment and the OS are pretty thoroughly linked. With Linux, on the other hand, even if you limit yourself to a single major distro such as Ubuntu or Fedora, you can run any desktop environment you like. Lately I've been trying to get acquainted with Fluxbox, which runs just fine (and fast) on my Kubuntu box.
Something *nix, for sure
Because the sheer idea of Unix inspires a computer torun more efficiently? I kid, mostly.
A couple years ago I was thinking along the same lines as vigmeister (i.e., getting a Fujitsu tablet for light usage around the house, maybe play go online on the couch.) Reports around the internet were that XP Tablet (or is it just Windows Tablet?) was a dog on old Fujitsus. Windows 2000 was more popular, and some people were even recommending using Windows 95, which required finding Windows tablet functionality that had been backported to 95.
At the time, it sounded like a bit of a project to get Linux working on a Fujitsu tablet. I wonder if anything has changed since then?
Yeah, definitely. One team I'm working with produces software that they sell as a service, but each client pays for different features, and has different customizations. They manage that all through allowing for configuration and localization.
I could see configuration management being perfect for code customization if you had a nice plugin system a la Eclipse. I have done some Eclipse RCP work and am completely sold on the plugin model for customizing and extending applications. I believe Qt provides some support for building plugin-based apps, too.
Unfortunately, we didn't have a plugin system, so that didn't work for us. Either the feature was compiled in (which broke confidentiality even if it wasn't enabled) or it wasn't. Build-time configuration at the #ifdef level or the Makefile level would definitely have worked, but we had all had bad experiences with those techniques and were keen to avoid them.
As for the config files and templates not being in version control, how did you achieve reproducibility for your builds?
You'll need advance permission from the customer for a change like that.
Yeah, that's why I have a product manager in the room, often within arm's reach. They represent the customer fully, and are empowered to make those decisions.
What do you do when the customer rep says: "This time is extremely critical for us. It will be very expensive for us if your changes reveal any bugs in our code or our business processes. Therefore we want no new features, no enhancements, and no bugfixes except this one."
I know there are some kinds of software where you don't hear this kind of thing. I worked on a desktop app where we sometimes rolled out major new features without any notice and sat at our desks with big grins waiting for the excited calls of gratitude to come in :-)
I've also delivered software to a customer whose normal procedure for receiving new software was to spend a week on integration testing and roll out the new version to all their sites over a couple of weeks. Bypassing that process for an urgent bug fix was a really big deal and it would have been entirely unacceptable to ship anything more than a minimal bug fix applied to the version that was already in production.
Also, thinking of that customer brought an entirely different argument to mind, which is that there are times when you have to keep a feature exclusive to one customer, because two of your customers compete against each other and are obsessive about secrecy. When customer A was planning a significant change to their operations, or had a big new deal in the works, any development we did to support those changes was considered confidential. We had to keep it exclusive to them to help ensure that customer B couldn't figure out their plans.
That might be a pretty rare scenario, but I imagine that temporary exclusivity is common practice when a customer contributes money or expertise to the development a new feature.
And what, exactly, would that fab breakthrough look like?
I suspect it would come in pink and look really super with a scarf!
Which way do you want it? Paid for by advertising, or paid for by you? If it's paid for by advertising, then not only will they go for the biggest possible audience, they will try to attract an audience that works for their advertisers. That is, they will narrowly pitch each show to an advertising segment (say, explosions for the 18-35yo male) instead of to an interest segment.
Hopefully the economic and regulatory climate will make it possible for us to buy well-produced television content or at least buy cable channels a la carte. That way a group of people who share an interest could attract attention from TV producers simply by having money and desiring to buy content, instead of needing to be a known target for an identifiable segment of advertising.
As for public/philanthropic funding, I don't understand why the BBC and PBS consistently produce a trickle of worthwhile television, so I'm somewhat suspicious of that model, but I'll continue to support them given their track record, even if they produce a lot of bland drivel along with the good stuff.
Amen! As well as the potential for mistakes in switching, it makes code navigation harder (on the file or directory level) and makes it hard for new developers to get a feel for the code.
Also, when you introduce switching, you commit yourself to the future cost and risk of ripping out the old code. The temptation to bail on that responsibility is high. Here's a simple heuristic: if your team doesn't produce thorough API documentation, they probably won't do a good job of ripping out obsolete code. You'll end up paying the mental code complexity overhead of code you don't even use.
You do have a substantial chance of introducing bugs. Or maybe not, but that's how the customer will see it. Good luck convincing them otherwise if they have any experience with software.
Plus, unplanned changes in the software, even enhancements, can be extremely unwelcome for some kinds of software. Theoretically, only the customer knows whether the enhancements will require training, process changes, or integration work (of the "oops, it turns out our code calls your buggy undocumented private API" kind.) In practice, sometimes even the customer is surprised. The customer only wants the potential for surprises when and if there is time budgeted for dealing with them, not with every bug fix.
Even a bug fix can require retraining personnel whose original training took the bug for granted. You'll need advance permission from the customer for a change like that. I.e., you can't just roll out all the changes on TOT without running each change by the customer, even if all the changes are just bug fixes. They might have a good reason for demanding one fix urgently and asking you to hold off on another.
Could my digits be more significant to me than my girlfriend? Nah, sex isn't everything.
The biggest problem with Java is the kind of work done in it, the style of software required to make that stuff work, and the aesthetics of the resulting systems. In other words, nobody gets turned on by massive, hairy, boring business systems.
The second biggest problem with Java is that it has attracted 95% of this generation's architecture astronauts.
The third biggest problem with Java is that everyone expected a linguistically forward-looking language, and instead they got a fairly conservative one with some obvious warts.
When you look at those problems in perspective, there's nothing so wrong with the language or platform itself. In fact, the platform is pretty damn cool, and one of the coolest new languages (Scala) is a first-class citizen on the platform. Sun is investing money in making the JVM more language-agnostic, which provides language designers with a built-in standard library and a built-in fallback where ther
Ah, the irony. As a Slashdotter, you should know that different kinds of programmers variously care about radical language design, "real programming," trendy application domains, and individual (or small-team) programming. Java is the opposite of a programmer-designed language. As a language and as a platform, it was designed for maximum acceptance by conservative career programmers, easy usage by mediocre (i.e., non-"real") programmers, boring domains (originally set-top boxes, then business middleware,) and large-scale bureaucracy-requiring projects.
It doesn't have to be true to be effective rhetoric that leads us to support better policies, just like, "We are _____, not Americans, and we don't like crappy fast food," is a lie that many countries tell themselves to help them eat less fast food and preserve their own food culture.
A flattering lie is very useful as long as it inspires people to live up to it, instead of inspiring complacency.
It's a naive principle. (I'm not the AC, by the way.) A system of law is like a piece of business software. At first glance, every piece of business software seems unnecessarily elaborate. Then, when you start building systems, you realize that every simple set of rules generates completely insane decisions in a nonnegligible set of cases. The ultimate way to solve this is by allowing a human to override or reinterpret the decisions of the system. However, to minimize abuse and maximize efficiency, it is desirable to reduce the number of cases in which a human intervenes. So you start adding complexity. In the end, a system of law, like a software system, ends up balancing correctness against complexity.
Also, the system has to evolve in a controlled way, because changes require the consent of stakeholders. Engineers (the lobbyists and congressional aides who actually draft legislation) don't have the power to unilateratally impose simplifications that change the behavior of the system. They have to persuade the stakeholders (that's us.) This is good. Otherwise, even if the engineers have the best of intentions (ha!), you get a system that makes sense to the engineers and no one else. Then you get disorientation, discouragement, and disengagement: Kafka's The Castle or, more accessibly, Yakov Smirnoff. (It's no coincidence that the societies with the best tales of surreal bureaucratic insanity are the ones where bureaucrats, or "social engineers" as they have sometimes been called, had the power to "rationalize" society in the name of efficiency.) However, the cost of giving power to stakeholders is that they may demand certain behavior without regard to its implementation complexity. Plus, the inefficiency and imprecision of the process leaves its mark on the product in the form of cruft.
If you think you know a better way, you should test it in the software business first, and then when you've made a few million bucks, bring your insight to politics Ross Perot-style :-)
That's no joke. US intelligence agencies don't bother asking for permission; they just do whatever is technologically and economically feasible without our cooperation. I'm scared about what they might be doing right now. It's not because I'm paranoid; I think there are plenty of people in the intelligence agencies who would leak information about surveillance programs -- IF they thought they were acting contrary to the values of typical Americans.
Unfortunately, our cowardly response to 9/11, following the paranoid and anxious example set by our leaders(*), has surely made it easy for those in the intelligence agencies to believe that Americans, deep down, really don't believe in our national rhetoric of liberty, and we really want to be taken care of by a strong national security apparatus acting outside of law and morality. In other words, we want the government to act like a loving, protective parent, in whom the safety of its children overrides any concern for propriety or morality.
Could we blame them for thinking that way? Can we even blame our leaders for encouraging paranoia and unreasonable anxiety? We have proved our appetite for "scare" news stories about child abduction and Alar on apples. Television news has long been just another horror genre for a species that loves to be scared. Politics has been that way even longer.
I don't think we really want to be that way, though. Maybe in the movie theater, but not on serious issues like our freedom. I hope that if we are asked to face the issue seriously when we are not caught up in a national panic, we will follow the lead of politicians who stand up and say that everybody balances freedom against security, and Americans have a greater taste for freedom than most. If that means allowing a few more serial killers, teenage mass murderers, and terrorists to slip through the cracks and wreak havoc, so be it.
Don't get me wrong, it's obviously unacceptable that a dozen pissed off people can wreak havoc on the scale of 9/11. We should structure our society so that a few pissed off people can't cause such massive disruption. But once we reduce the amount of damage a terrorist can do down to a tolerable level, such as by mandating armored cockpit doors and good cockpit security protocols, and making it sufficiently difficult to bring explosives onto planes, we should relax and treat terrorist attacks like tornadoes. Meh, they're gonna happen, let's do what we reasonably can to make our buildings resistant, educate people to react sensibly, and react to help people after the fact. Terrorists want to affect our government policies and social mores, and we don't want to satisfy them, right? Hurricanes and tornadoes have been killing us for years, and they haven't succeeded in rolling back feminism, ending our support for Israel, or undermining our civil liberties. (Perhaps that second part is unfortunate, but....)
Anyway, we're obviously on the wrong track. Instead of treating terrorist attacks as just another hazard of life on earth, like hurricanes and tornadoes, we've given them a special power over our psyche -- exactly the special power that terrorists want. Instead of repenting of our naive vulnerability, and preparing ourselves to withstand future attacks with minimal damage and loss of life, we have taken for granted that every terrorist poses a terrible, awesome, shattering threat and must be detected and stopped at any expense.
"Safety at any cost" -- that attitude is what Americans have embraced and must now disavow.
(*) Obviously the Bush administration set the initial tone, but members of both parties followed his lead enthusiastically.
Not to mention high RTTs.
She set expectations so low. I didn't watch the debate, but my friends who did were really depressed afterwards, because they expected her to humiliate herself again. She delivered a controlled, heavily scripted, marginally competent performance, which is exactly what VP candidates are expected to do.
Come to think of it, controlled, heavily scripted, and marginally competent is exactly what VP candidates are expected to be, so if she keeps this up, she won't hurt McCain at all. Unfortunately.
From Astea's web site:
Why is a team of the world's leading Squeak experts involved in a Java rewrite? The article summary may turn out to be a bigger troll than the one I'm replying to.
The company's "About" page says, Astea has focused its initial activities on the open source market segment with a special focus on university, publishing, and research-oriented applications.
It sounds like the original developers are suffering from jealousy or control issues. Why try to revive a project that he admits is "buggy and slow" when someone else has a grant to rewrite it from scratch? Why get upset over the death of a project that had already stalled out in an (apparently) unusable state? Maybe making an exact copy is a poor use of the Mellon Foundation's money, but then again, it might be a wise idea. Having a reference implementation simplifies development immensely.
This is a very misleading description of how human chess players work. Humans rarely use exhaustive search further than one move ahead, but they spend a great deal of time during games calculating variations. Even a mediocre player calculates a few moves ahead every time he moves, and many moves ahead in some instances, using heuristics to prune his search tree. Grandmasters use their superior intuition to allow them to look more deeply into the variations, not less. In a complicated position, a grandmaster might identify several key variations, each leading to a different position, and then calculate variations proceeding from those positions, and so on up to the limit of their brains.
As a mediocre amateur (~1600 on a scale where 1000 is a sucky beginner and 2400 is a grandmaster) I routinely calculated the way you described: an incomplete search tree several layers deep. Granted, I tended to miss some important variations, and sometimes my imagination was fuzzy, but I was applying my intuition to the positions that might arise five or six moves ahead, not just to positions that were one or two moves ahead.
Also, even mediocre players have the ability to reason forward ten or fifteen moves in simple endgame situations with lots of forcing moves.
Limiting the release of information from a court case can be appropriate. According to Appel, the judge suppressed the report after Sequoia "grossly mischaracterized" the report, which I bet means they claimed it gratuitously revealed trade secrets. If lawsuits could be used to fish for information about trade secrets, that would be very bad news for small companies trying to compete with rich ones like Microsoft and IBM.
Hopefully the judge only suppressed the report to give herself time to examine the merit of Sequoia's claim. (Also, hopefully she rejects their claim and releases the report quickly enough to make a difference in this election.)