I don't know what pletorah of things they taught you in CS school, but much of the wisdom they taught some of us can be summarized:
- Big O matters. Optimization of constants is an expensive luxury. - Reimplementing the wheel for the sake of marginal efficiency is a sure way to get a square and inefficient wheel.
Most algorithms of any common use are provided in the standard libraries of each language. If not there, any algorithm can be implemented in any language by virtue of its Turing-completeness. This guarantees you bigO efficiency, which is what matters in the long run.
The article complains about Java being slow for the sake of its pcode nature. That's a constant factor, not bigO. It's automatically defeated by "CPU is cheap, RAM is cheap", i.e.: constant factor acceleration is cheap.
You better have a good reason to worry about constant factors: if your program demands so much from the machine that the constants make the difference on whether it's practical or not, you better be experimenting with the 'bleeding edge' or there's something really wrong with your program.
Efficient algorithms are used on every language by any programmer worth 2 bucks. Java has the advantage of implementing a bunch of them on standard libraries that work quite well, thank you. Someone who uses bubblesort in Java outside of a classroom is not lazy, he's an idiot. Implementing bubblesort is more complex and expensive than calling Arrays.sort().The same thing actually applies to any programming language.
If your concerns about speed as a typical sysadmin (servers and workstations) or even worse, as a developer, are dominated by constant factors, it's time to go back to take data structures and algorithm analysis at CS school.
Is this really a Good Idea (TM)?
on
Legacy-Free PCs
·
· Score: 3, Interesting
I'm all for abandoning useless legacy features in "typical" PCs if they make them cheaper and more stable.
For example, abandoning the ISA standard in favor of PCI was overall a good, if a bit late (and contrived, with VESA and EISA, etc), development. Although I regretted losing a few good expansion cards, there was really not much lost beyond sentimental value.
PCI is showing its age, and the transition to PCI-Express (or whatever name it ends up having) will be welcome.
Serial ATA, once it's mature, will be also a welcome change. No need for those big cables in the case, at least.
I've been operating without a floppy disk drive for years now, with only minor inconveniences whenever some BIOS update, old DOS driver or utility demands a "boot disk" the old-fashioned way. There's no reason to assume it's there anymore, and it's a useless expense in both money and space.
Those are good changes. But this is not always the case.
Case 1: Legacy Ports
No more PS/2 ports, no more serial ports? USB and Firewire all the way!!
Sure, sounds great if it works. Except that it almost never does.
USB support in PCs is "decent" now, but it's not 100% reliable, and one can't afford to be left with no input device because the BIOS/OS/random-thing-I-don't-know-of has problems with USB today.
My current PC has a bunch of unused USB ports, but I'm still sticking to PS/2 mouse and keyboards. The reason is that every week or so someone calls me because they have a problem with their computer and it happens to be the USB mouse and/or keyboard which just stops working.
I reduced my "family technical support" calls by 50% just by putting a USB->Serial adapter on my father's keyboards and mouses.
I have the same problem one or twice a month with almost all USB devices I use: printers, cameras, etc. I use USB for them because they need the bandwidth, and because I can afford to tinker with them every so often.
Sometimes all it requires is plugging and unplugging. Sometimes turning the device on or off (printers and wireless devices). Sometimes rebooting the machine. Sometimes it just starts working again without a clear cause. It rarely takes more than 2 minutes, so it's not a problem (if you have a traditional mouse/keyboard with you).
This doesn't apply to basic input devices:
I don't need MB/s of bandwidth to type or move a cursor, and I certainly can't afford to lose my input devices because the USB controller, or BIOS, or the OS, or whatever causes the problem had a bad hair day. Particularly because it can take more than 2 minutes to fix when you have no input devices to figure what's going on.
On the other hand, if my PS/2 keyboard stops responding, I know it's a hardware issue. Replace keyboard, or, at worst, replace port.
This is just within the Windows world. I had enough trouble getting USB support working in a few Linux installations not to bother trying anymore, as I haven't really needed to.
Maybe it works flawlessly and automatically from some distributions now, but I wouldn't risk anything going wrong there.
Basic I/O has to work flawlessly, and in PCs, even in brand-new machines, I just don't trust USB that much. Maybe it's precisely because of the legacy support, I don't know, but I think it's been long enough for BIOS/OSes/etc to get it right.
Case 2: Legacy BIOS
They want to make the BIOS an OS? What happened to small and simple?
I guess having it programmed in C would be an advantage, and I'm sure there are technical limitations with the current BIOS technology that could use an update, but I'm worried about this approach.
If you need an OS, that's what the OS is for. If you need diagnostic utilities et al, get an OS and run diagnostic utilities on it.
Why do you need to put this in the firmware layer? Firmware should be small and stable. If something fails in firmware, you're normally in deep trouble.
That naive (at best) attitude is part of what has kept them jumping from corrupt government to corrupt government in the first place.
Every disturbingly corrupt government begins with a "clean-up", accompained by excessive trust on the new party and further centralization of government (dramatic changes require power), and sometimes with a period of real honesty that doesn't magically fix the country. Then skepticism and cynicism sinks in, and people realize there are no effective barriers or control on the government since whatever control was not eliminated now rests essentially in layers of trust, usually on members of the same party.
Development has to be fixed at the structural level. It's not a matter of "good intentions", "sensibility", "hard work" and "good will".
Corrupt governments are almost unavoidable when you concentrate money and power in a centralized government with tight control of the economy (and hece competing economic power); all of which are necessary qualities for a protectionist, "nationalistic capitalism" (or whatever term is fashionable these days, "humanist capitalism" is another one).
Corruption is a symptom, not a problem.
Developed countries have had their share of corruption. Massive corruption sometimes, since these days it's a matter of corporations, not isolated greedy individuals. It has been a problem for them too, but it has not been crippling. Somehow, it has been kept under control and things keep working.
On the other hand, third world countries have had their share of honest or relatively honest governments that have failed utterly, destroyed economies, messed up foreign relations, reduced civil liberties, and in general lowered the standards of life.
The problems of the third world cannot be glimpsed from bad American movies with mexican actors, and cannot be fixed by JUST putting honest people in power, just like democracy cannot be brought by JUST having general elections.
These are misconceptions the US, as a nation, is learning (or should be learning) ever since the end of the Cold War. These are misconceptions that no US citizen, because of their role as citizens and electors of the US, or simply as a matter of basic education, should keep either. Misconceptions are worse than ignorance, they have deeper consequences.
Excuse the little rant, but your statement is sweeping and absolutely wrong.
While modern books have been modified to fit a superficial concept of "readable" and "children-friendly", they are no more understandable than they used to be, so what's the point?
Schoolbooks now are full of pretty pictures, silly (and unfunny) jokes and puns, and all sorts of "didactic help" that provide no new approach, no new understanding, nothing to dry collection of facts but distractions.
It reminds me of Word's infamous Paperclip: it rarely helps, often annoys, and doesn't make the underlying cluttered product any better. At least Word users have the excuse that, if following the wizards' instructions somehow solves their problem, they don't need to understand anything. This should not be true of education, where the primary goal is to get the "user" to understand a process.
This teacher's approach to "readability" seems to be different. It's not a matter of included comics, social activities, etc. It's a difference of approach: and the narrative approach IS powerful in building core understandings of concepts.
I don't think the approach for "reference" books should be abandoned. But it shouldn't be the main, let alone the only one, approach used to teach the basics of science... or anything in particular.
The thing that the "reference book" approach lacks is perspective. Perspective is necessary to engage in discourse (history, science, etc) with a sense of direction. Perspective can be grasped implicitely from a collection of facts, but it requires effort, time and a lot of discrimination on the facts. The problem is we have a lot of facts, and they're moving quickly. Education should help build the basic perspective just as it provides the basic facts.
At least in my experience, getting an historic perspective of science was a major part of understanding it. It's the best way to grasp the following: - Why theory/idea/experiment X is important now (what was discovered because of X, what depends on X). - Why theory/idea/experiment Y was considered revolutionary (how did Y change our worldview). - How did we come to think of X/Y/Z, what did we reject in the process, and why... from this, how science progresses and by what criteria does it replace its theories with new ones. - What difference can Z, as obscure, abstract and purely theoretical as it may seem, have on real life. - How completely different theories X and Y and Z can and have been linked together by people trying to understand them better.
Knowing the narrative behind quantum theory will not help me understand its equations (and least, it hasn't helped me enough). But it helps me understand that science is willing to throw away its core framework if it doesn't meet experimental results, that our modern understanding of the world depends on quantum theory (even if we use Newton's as an approximation, mostly), that science is about meeting empirical data even if the theory seems absurd.
Knowing the narrative behind mathematics, computation and linguistics may or may not help me to understand the discipline better directly. But it will help me to understand how something as patently abstract and "ivory tower" as Number Theory has had dramatic effects on Real Life (TM), as well as on the thoery itself.
Knowing both narratives will not help me understand, directly, how you can try to explain physics as information theory and vice versa. But it will let me know that you can, who has been involved, and where to get more information; and more generally, that metaphors are considered so valuable in science that once a new one has been found in a theory, it's worthwhile to see what it can say if used in other theories.
Knowing that X is important is the first step to knowing X. It prompts us to ask the right questions, to look for the right references, to "get it" much more quickly, and to relate it to Y.
Views? They are for people who don't want their users/clients to write their own queries. Foreign keys? They are for people who don't like their users/clients messing up the data. Full Outer Joins? They are for people who actually have use for a database. Subqueries? They are for people who ask from the complex daemon program that handles persistence, data integrity and relations to handle the menialities of a loop and give the damn data back. Set operations? They are for people who understand there are more elegant solutions than producing and then butchering cartesian products.
Although it is possible to overuse Design Patterns, it is rather difficult and I have yet to see the case where this is a problem.
What you say about them not being useful to frame up user requirementes, however, is completely true. Neither are flow diagrams. Why should they? Neither tool is supposed to be about "framing up user requirements".
Design Patterns is something to be used at design/implementation level. It's a set of higher-level idioms that stand at different levels above the "source code idioms" (like classes, functions, control structures, etc) and actually connects them.
They are meant to be used when you're looking for ways to solve a problem, which means you already figured out what problem you need to solve.
How or why should they be useful when creating the requirement specification escapes me.
Programming is to Computer Science as plumbing is to hydrodynamics
I posted the previous comment hoping to remind you that "Programming" is creating a program, NOT typing up an implementation on a particular computer language in a particular computing platform.
It doesn't matter if it's in your head, in paper, in a screen or in memory. It doesn't matter if it's expressed as a set of graphs, diagrams, mathematical symbols and numbers, strings of text in C/Java/COBOL/English, binary numbers that represent machine code, mechanical or electric operations....
A program is an algorithm is computation is symbol-manipulation is a program.
I see that I failed.
AI typically starts with the question "What is intelligence?". This should lead to psychology, philosophy, theology, language, symbolic logic, information theory, game theory and so on.
AI starts with an implicit question: "Is Intelligence Computation?"
For which it gives an implicit answer: "Yes".
All inquiries on the nature of intelligence after that have to do with which kinds of computation are we talking about.
Sure, this will inevitably lead to psychology, philosophy, and an area of knowledge and education that most engineers and scientists don't know as well as they should.
But don't forget that you're asking about Intelligence, to begin with, because you're studying/working on ARTIFICIAL Intelligence, which means you have a goal, "to simulate/replicate/create intelligence", and a fundamental method/metaphor to use, Computation. Philosophers study intelligence from a different POV.
Design. Yes it leads to a program, it can also lead to virtually anything else.
Define "virtually anything else".
When I learned design, I learned all the methods you mention to achieve specifically two things necessary to solve problems: model knowledge (represent data), and model processes (represent algorithms).
That is computation.
Yes, you do the same thing in other fields of engineering. Yes, we can always learn more from their techniques. But what they're doing in that case is also computation, which is programming in the strict sense.
Computation is a very very VERY general concept. That's the reason we can even dare to talk about AI in CS and imply that cognitive process are basically computation (as Turing believed) or at least largely defined by computation.
That's the whole reason we invented a fundamental science (not engineering) to deal with the subject.
Testing. Again doesn't doesn't have to be for programming could be compliance, risk assessment etc.
Yes, testing can be applied to other subjects. So can writing. And reading. And the ability to count. And they're all useful out of context.
But the reason CS people learn about testing instead of political science (also useful to understand) is because they need the first in order to test programs, not the second.
Formal Specification - "I have proved the above to be true but haven't tested it" Donald Knuth. Rigours of maths. Useful for the few who go into chip design, satellite code etc.
Yes, the rigours of math. The ability to know, when given a program, exactly what it does.
Except that this only applies to software, math, and formal languages which are... yep, symbol manipulation == computation.
You learn this to compute.
When I was an undergrad we were told that if we spent more than 10% of our time coding we were doing something wrong. It's true (for computer scientist, pro programmers are obviously different).
Of course.
Coding is literally writing code, and is to Programming what laying bricks is to civil engineering and architecture.
If you spend more than 10% of your "programming" time typing the code, even
I'm a bit confused by that statement. What is CS supposed to be about, then?
I'm even more confused by the fact that every other apparently more important thing in CS you mention is accesory to programming:
- AI: how to program a machine to make its own decisions. - Design: how to plan what you're going to program, before you program, so that it is a GOOD program. - Testing: how to make sure your program works, by defining what it means "it works" and forcing it to comply. - Formal Specifications: how to define formally your program, so other people can understand it and tell you whether it was the program they wanted or not. - Project Management: how to make it possible (if improbable) that you'll finish your ambitious and complicated group of programs.
I don't care if you're "programming" a Windows client in C++ with MFC libs, on a Unix machine running LISP, or on a "pen-and-paper-human-assisted" platform where you trace your program to get your results.
If you're executing an algorithm, you're executing a program, and you're computing.
If you're writing an algorithm, you're programming, and you're preparing instructions to compute. Peferably good, efficient instructions that give good results.
This "computing" thing, incidentally, is what gives "Computer/Computing" Science its name. Or so I thought until your post. Now I'm baffled trying to figure out what CS means.
Forgive me if your commented was intended along the lines of "learning a particular programming language is not what CS is about". I would agree completely with that comment, for the same reasons I think assembling and dissasembling cars does not a mechanical engineer make.
But your comment, if taken literally, sounded more like "Physics is not what Mechanical Engineering is about".
It's good to know that Garcia Marquez won his prize for his strict journalistic integrity and realistic portrayal of life in Macondo in "One Hundred Years of Solitude".
It was all part of the ".NET revolution", and was hyped for some time. It seemed a nice idea from the marketish resources, as a matter of fact. One of the things about.NET that could be considered substance.
Of course the new version of Windows will do this, because it includes and is based on.NET.
But in case you haven't noticed, the blasted thing has been available for years now.
Am I wrong in thinking this was included from the beginning?
From my point of view, 70-80% of the time technical or formal arguments are better expressed in written format.
This is perhaps even a higher percentage in the case of code, or even pseudocode. This is partly because talking about "{ i+=p/w*x; print("@poit"); i^=2;}" is inconvenient, but also because it avoids confusions by forcing people to put things clearly before "opening their mouths".
Saying "Linux spends almost no money" in R&D is incorrect. Or rather, vacuously correct. There is no "Linux" entity, therefore it cannot itself spend money.
The correct statement would be "The Linux community's investment in R&D is impossible to estimate in monetary terms, but is likely to be less than Sun's".
Just because the research effort is not centralized, paid for from a single source, and is difficult to account for, doesn't mean that "the community" doesn't still spend a lot of man-hours, hardware and software in R&D.
That includes individuals contributing their time and resources for free. But it also includes companies and corporations invest money, to earn more money: from Linux distributors to corporations like IBM (whose investment in Linux has a lot to do with R&D).
I'm not saying that the Linux approach is better, but to pretend that just because no single company is paying the bills there was no investment is incorrect.
Hmmm... I partially agree with you. I liked the show from the start, but I also mocked the show frequently, and particularly some of the misplaced fans who took it far more seriously than the show took itself. Sometimes good-heartedly, sometimes not so.
The thing is I think both the publicity and the more vocal fans gave the wrong impression of the show to typical viewers.
The publicity made it seem like the "next big thing in fantasy/B-movie-inspired/overambitious-cheap-sci-f i in the age of Hercules and Xena".
This was the wrong approach. Buffy is proudly B-moveish, but eminently aware of its B-movieshness and is covered by a deep layer of irony and sarcasm. The characters were just as aware of the absurdities as the viewer, and dealt with it with a mixture of cynicism and naivete that resonated with the intended demographic.
It's not the high-production values that redeemed it (just like it never redeemed Xena et al), it's the fact these enrich the irony.
The fans could usually be classified in:
A) 'Hardcore geek fanboys/girls', with pseudo-Goth (and if you think Buffy is goth, the pseudo is necessary), comic-book-or-Trekkie-style, and OMG-characterX-is-so-hot-let's-write-erotica-on-us enet subgroups.
These people took it so seriously that other people thought the series took itself just as seriously. B) Teen-drama geeks.
These people made such a big deal of the indicental dramatic plots (that any show with character development is bound to have) that it seemed like Dawson's Creek with demons and vampires.
Perhaps I'm biased because I saw the original movie. Yes, it was bad. Really bad. And it knew it was bad, and strecthed its B-movie-crappiness-in-joke just a bit too far.
But it set the tone for the series, which did a much better job at telling the same joke.
It's a story of a typical TEEN CHEERLEADER VAMPIRE SLAYER, for Christ sake. And she's named BUFFY!
Nasty stuff? I assume you mean doing OO C for a TCP/IP stack.
Of the many things I consider nasty of C, struct is most definitely not one of them.
And I'm a Java OO-hype weenie that thinks everything in a project has to apply at least one Pattern and the Javadoc has to cite at least a book by the GoF or Fowler.
(I'm assuming it's a typo, because I have no idea what "alterior" means).
As precious as information on Mac users software installations may be, I think it's a bit paranoid to think that MS is going to buy Virtual PC for something like this...
I mean, follow the logic: - Spend a considerable amount of money to get software technology from Connectix. - Substantially alter Virtual PC to force it to use Windows Update to send all the data they want on the Mac software. - Sell this new version of Virtual PC to Mac users. - Get interesting information from a subset of Virtual PC users (the ones that get the new version or upgrade), who are a small subset of Mac users, who are a relatively tiny subset of computer users. - Profit?
It seems like too much work for peanuts.
Consider the alternative: - Alter the new version of Internet Explorer for Mac, software they already have complete control and knowledge of, so that it has to use Windows Update to get patches and security fixes, and checks often and automatically by default (for all I know, it might do this already). - Provide the corresponding Windows Update client for the Mac. - Get interesting information from all Mac users using a recent version of Internet Explorer, i.e.: most Mac users. - Profit.
By analogy there is a segment of the market that really has a competent TCP/IP stack among its top priorities. But that segment of the market is mostly going for other OSes. That's why Linuxes do well.
People buy different cars for different reasons. If SUV owners really start demanding safety (and switching to Volvos), then perhaps we'll have safe SUVs. But they don't show any interest on that.
When the TCP/IP stack is a user-issue MS will do something about it, although not before they lose users directly because of that.
That's what they did with stability (although it took them some time). Win98 users that want crash-reduction have already switched to Win2K or will soon.
That's like saying 'having a faster, more reliable car won't make a driver happy', while having an extra cup-holder will.
Exactly.
Which is why more people are willing to pay extra for that fancy stereo system than for fuel efficiency, safety, speed or reliability.
Heck, more people are happier with the theoretical ability to drive accross arctic tundra in their unsafe, oversized, incredibly expensive and inefficient urban SUVs.
I'll quote from the comment you replied to, since you seem to have missed it:
For example, for a Windows user it's more important that the Media Player works perfectly than having an efficient TCP/IP stack. Even on the server side it's not a big issue on their market. It's under so many layers of software, appearances and priorities that their clients would never notice if they made it better anyway.
Now, I don't know what makes you happy as a user, but I do know that having a better TCP/IP stack wouldn't make any Windows users I know much happier, while having a better instant messenger, for example, would.
Aye. It could be that the TCP/IP stack that the article mentioned has "flourished" (become better software) because the people who develop it are VERY MUCH using it.
Linux geeks grok TCP/IP networking, and Linux users DEPEND on TCP/IP (not 'it would be nice to have web access and surf porn while I type this memo') for practically all of its market share. Like gcc, TCP/IP is part of the Linux deal.
It would be biased to regard this as conclusive evidence of the superiority of open-source unless other, less sexy areas of Linux development are compared to their commercial counterparts in the same way.
As evidence that certain commercial companies have not put priority on the TCP/IP stack of their OS, this could very well be good evidence.
But this doesn't necessarily mean the commercial companies are inferior; they may very well be right in having different priorities.
For example, for a Windows user it's more important that the Media Player works perfectly than having an efficient TCP/IP stack. Even on the server side it's not a big issue on their market. It's under so many layers of software, appearances and priorities that their clients would never notice if they made it better anyway.
Although whether the gorilla is subjectively creative when he's high is not something I could deny (I don't know that many gorillas). It makes no difference, though, without communication.
Also, there can be, and have been, crazy artistic shamans without magic mushrooms.
They're often not the most psychologically stable individuals, and they may often end up discovering and eating more magic mushrooms than they should, though.
The gorilla may or may not have a creative spasm after getting high (I doubt it). But without complex communication skills they cannot let others know, it cannot become a social activity, and it cannot spark more complex behavior.
Although Reziac's narrative interpretation is a bit more entertaining.
First, I said the genes would have to be simultaneously "normal" on the specimen, not that they should simultaneously arrive there.
Except in a somewhat geological scale of simultaneous, perhaps. The "short", "recent" period they're talking about is anywhere between 10,000 and 50,000 years, at least 50,000 ago.
Second, genes by definition have no distinct purpose, before or after mutation. They just happen to have effects, happy accidents which keep them around, or unhappy accidents that remove them from the pool.
What they can do, and whether it's good or bad, is very much influenced by historical circumstances.
For example, I understand cystic fibrosis is pretty common as a single recessive gene among europeans and their descendants, because its presence decreased risk of dehydration by the Black Death (through intestinal inefficiency and other 'health problems', I think). Two recessives can be, and often is, quite fatal.
In the rest of the world the gene is extremely rare because for thousands of years that gene was a BAD THING. The Black Plague made it, at a particular point in history (less than a century), a good thing (with some risks, two-recessive children often died). It hasn't been 'good' since then, but humans still carry that legacy.
Third, who says there's no reason for us to stop evolving? There's a very good reason: if the design works better than the improvement, we don't 'evolve'. And who says we haven't? Evolution is not a constant rate game. Have you heard of punctuated equilibrium?
Fourth, no one is saying "creativity" will be pinpointed to 10,000 genes yet. They're saying the language and communication skills that allow "creativity" to work could be pinpointed to a set of genes. Big difference. "Creativity" is a complex process that is not even properly defined, while individual language skills can be more specificied and defined, each with its own evolutive advantages.
If you have problems thinking of 10,000 genes happily meeting and achieving "creativity" at once, think rather of 100 language skills, each linked to 100 genes, and each useful in its own sense, happily meeting over a short time and accumulating into an infrastructure that's more useful than each alone.
I don't know what pletorah of things they taught you in CS school, but much of the wisdom they taught some of us can be summarized:
- Big O matters. Optimization of constants is an expensive luxury.
- Reimplementing the wheel for the sake of marginal efficiency is a sure way to get a square and inefficient wheel.
Most algorithms of any common use are provided in the standard libraries of each language. If not there, any algorithm can be implemented in any language by virtue of its Turing-completeness. This guarantees you bigO efficiency, which is what matters in the long run.
The article complains about Java being slow for the sake of its pcode nature. That's a constant factor, not bigO. It's automatically defeated by "CPU is cheap, RAM is cheap", i.e.: constant factor acceleration is cheap.
You better have a good reason to worry about constant factors: if your program demands so much from the machine that the constants make the difference on whether it's practical or not, you better be experimenting with the 'bleeding edge' or there's something really wrong with your program.
Efficient algorithms are used on every language by any programmer worth 2 bucks. Java has the advantage of implementing a bunch of them on standard libraries that work quite well, thank you. Someone who uses bubblesort in Java outside of a classroom is not lazy, he's an idiot. Implementing bubblesort is more complex and expensive than calling Arrays.sort().The same thing actually applies to any programming language.
If your concerns about speed as a typical sysadmin (servers and workstations) or even worse, as a developer, are dominated by constant factors, it's time to go back to take data structures and algorithm analysis at CS school.
I'm all for abandoning useless legacy features in "typical" PCs if they make them cheaper and more stable.
For example, abandoning the ISA standard in favor of PCI was overall a good, if a bit late (and contrived, with VESA and EISA, etc), development. Although I regretted losing a few good expansion cards, there was really not much lost beyond sentimental value.
PCI is showing its age, and the transition to PCI-Express (or whatever name it ends up having) will be welcome.
Serial ATA, once it's mature, will be also a welcome change. No need for those big cables in the case, at least.
I've been operating without a floppy disk drive for years now, with only minor inconveniences whenever some BIOS update, old DOS driver or utility demands a "boot disk" the old-fashioned way. There's no reason to assume it's there anymore, and it's a useless expense in both money and space.
Those are good changes. But this is not always the case.
Case 1: Legacy Ports
No more PS/2 ports, no more serial ports? USB and Firewire all the way!!
Sure, sounds great if it works. Except that it almost never does.
USB support in PCs is "decent" now, but it's not 100% reliable, and one can't afford to be left with no input device because the BIOS/OS/random-thing-I-don't-know-of has problems with USB today.
My current PC has a bunch of unused USB ports, but I'm still sticking to PS/2 mouse and keyboards. The reason is that every week or so someone calls me because they have a problem with their computer and it happens to be the USB mouse and/or keyboard which just stops working.
I reduced my "family technical support" calls by 50% just by putting a USB->Serial adapter on my father's keyboards and mouses.
I have the same problem one or twice a month with almost all USB devices I use: printers, cameras, etc. I use USB for them because they need the bandwidth, and because I can afford to tinker with them every so often.
Sometimes all it requires is plugging and unplugging. Sometimes turning the device on or off (printers and wireless devices). Sometimes rebooting the machine. Sometimes it just starts working again without a clear cause. It rarely takes more than 2 minutes, so it's not a problem (if you have a traditional mouse/keyboard with you).
This doesn't apply to basic input devices:
I don't need MB/s of bandwidth to type or move a cursor, and I certainly can't afford to lose my input devices because the USB controller, or BIOS, or the OS, or whatever causes the problem had a bad hair day. Particularly because it can take more than 2 minutes to fix when you have no input devices to figure what's going on.
On the other hand, if my PS/2 keyboard stops responding, I know it's a hardware issue. Replace keyboard, or, at worst, replace port.
This is just within the Windows world. I had enough trouble getting USB support working in a few Linux installations not to bother trying anymore, as I haven't really needed to.
Maybe it works flawlessly and automatically from some distributions now, but I wouldn't risk anything going wrong there.
Basic I/O has to work flawlessly, and in PCs, even in brand-new machines, I just don't trust USB that much. Maybe it's precisely because of the legacy support, I don't know, but I think it's been long enough for BIOS/OSes/etc to get it right.
Case 2: Legacy BIOS
They want to make the BIOS an OS? What happened to small and simple?
I guess having it programmed in C would be an advantage, and I'm sure there are technical limitations with the current BIOS technology that could use an update, but I'm worried about this approach.
If you need an OS, that's what the OS is for. If you need diagnostic utilities et al, get an OS and run diagnostic utilities on it.
Why do you need to put this in the firmware layer? Firmware should be small and stable. If something fails in firmware, you're normally in deep trouble.
A BIOS is not something
No, not really.
That naive (at best) attitude is part of what has kept them jumping from corrupt government to corrupt government in the first place.
Every disturbingly corrupt government begins with a "clean-up", accompained by excessive trust on the new party and further centralization of government (dramatic changes require power), and sometimes with a period of real honesty that doesn't magically fix the country. Then skepticism and cynicism sinks in, and people realize there are no effective barriers or control on the government since whatever control was not eliminated now rests essentially in layers of trust, usually on members of the same party.
Development has to be fixed at the structural level. It's not a matter of "good intentions", "sensibility", "hard work" and "good will".
Corrupt governments are almost unavoidable when you concentrate money and power in a centralized government with tight control of the economy (and hece competing economic power); all of which are necessary qualities for a protectionist, "nationalistic capitalism" (or whatever term is fashionable these days, "humanist capitalism" is another one).
Corruption is a symptom, not a problem.
Developed countries have had their share of corruption. Massive corruption sometimes, since these days it's a matter of corporations, not isolated greedy individuals. It has been a problem for them too, but it has not been crippling. Somehow, it has been kept under control and things keep working.
On the other hand, third world countries have had their share of honest or relatively honest governments that have failed utterly, destroyed economies, messed up foreign relations, reduced civil liberties, and in general lowered the standards of life.
The problems of the third world cannot be glimpsed from bad American movies with mexican actors, and cannot be fixed by JUST putting honest people in power, just like democracy cannot be brought by JUST having general elections.
These are misconceptions the US, as a nation, is learning (or should be learning) ever since the end of the Cold War. These are misconceptions that no US citizen, because of their role as citizens and electors of the US, or simply as a matter of basic education, should keep either. Misconceptions are worse than ignorance, they have deeper consequences.
Excuse the little rant, but your statement is sweeping and absolutely wrong.
You don't know much about Mexico or Argentina, do you?
Or almost any almost-developed-but-never-quite-made-it country in Latin America?
Because as far as I understand they didn't get into that situation through deep respect for liberal economics.
Care to point to the Java pull-based A
PIs?
While modern books have been modified to fit a superficial concept of "readable" and "children-friendly", they are no more understandable than they used to be, so what's the point?
Schoolbooks now are full of pretty pictures, silly (and unfunny) jokes and puns, and all sorts of "didactic help" that provide no new approach, no new understanding, nothing to dry collection of facts but distractions.
It reminds me of Word's infamous Paperclip: it rarely helps, often annoys, and doesn't make the underlying cluttered product any better. At least Word users have the excuse that, if following the wizards' instructions somehow solves their problem, they don't need to understand anything. This should not be true of education, where the primary goal is to get the "user" to understand a process.
This teacher's approach to "readability" seems to be different. It's not a matter of included comics, social activities, etc. It's a difference of approach: and the narrative approach IS powerful in building core understandings of concepts.
I don't think the approach for "reference" books should be abandoned. But it shouldn't be the main, let alone the only one, approach used to teach the basics of science... or anything in particular.
The thing that the "reference book" approach lacks is perspective. Perspective is necessary to engage in discourse (history, science, etc) with a sense of direction. Perspective can be grasped implicitely from a collection of facts, but it requires effort, time and a lot of discrimination on the facts. The problem is we have a lot of facts, and they're moving quickly. Education should help build the basic perspective just as it provides the basic facts.
At least in my experience, getting an historic perspective of science was a major part of understanding it. It's the best way to grasp the following:
- Why theory/idea/experiment X is important now (what was discovered because of X, what depends on X).
- Why theory/idea/experiment Y was considered revolutionary (how did Y change our worldview).
- How did we come to think of X/Y/Z, what did we reject in the process, and why... from this, how science progresses and by what criteria does it replace its theories with new ones.
- What difference can Z, as obscure, abstract and purely theoretical as it may seem, have on real life.
- How completely different theories X and Y and Z can and have been linked together by people trying to understand them better.
Knowing the narrative behind quantum theory will not help me understand its equations (and least, it hasn't helped me enough). But it helps me understand that science is willing to throw away its core framework if it doesn't meet experimental results, that our modern understanding of the world depends on quantum theory (even if we use Newton's as an approximation, mostly), that science is about meeting empirical data even if the theory seems absurd.
Knowing the narrative behind mathematics, computation and linguistics may or may not help me to understand the discipline better directly. But it will help me to understand how something as patently abstract and "ivory tower" as Number Theory has had dramatic effects on Real Life (TM), as well as on the thoery itself.
Knowing both narratives will not help me understand, directly, how you can try to explain physics as information theory and vice versa. But it will let me know that you can, who has been involved, and where to get more information; and more generally, that metaphors are considered so valuable in science that once a new one has been found in a theory, it's worthwhile to see what it can say if used in other theories.
Knowing that X is important is the first step to knowing X. It prompts us to ask the right questions, to look for the right references, to "get it" much more quickly, and to relate it to Y.
Views? They are for people who don't want their users/clients to write their own queries.
Foreign keys? They are for people who don't like their users/clients messing up the data.
Full Outer Joins? They are for people who actually have use for a database.
Subqueries? They are for people who ask from the complex daemon program that handles persistence, data integrity and relations to handle the menialities of a loop and give the damn data back.
Set operations? They are for people who understand there are more elegant solutions than producing and then butchering cartesian products.
Although it is possible to overuse Design Patterns, it is rather difficult and I have yet to see the case where this is a problem.
What you say about them not being useful to frame up user requirementes, however, is completely true. Neither are flow diagrams. Why should they? Neither tool is supposed to be about "framing up user requirements".
Design Patterns is something to be used at design/implementation level. It's a set of higher-level idioms that stand at different levels above the "source code idioms" (like classes, functions, control structures, etc) and actually connects them.
They are meant to be used when you're looking for ways to solve a problem, which means you already figured out what problem you need to solve.
How or why should they be useful when creating the requirement specification escapes me.
I posted the previous comment hoping to remind you that "Programming" is creating a program, NOT typing up an implementation on a particular computer language in a particular computing platform.
It doesn't matter if it's in your head, in paper, in a screen or in memory. It doesn't matter if it's expressed as a set of graphs, diagrams, mathematical symbols and numbers, strings of text in C/Java/COBOL/English, binary numbers that represent machine code, mechanical or electric operations....
A program is an algorithm is computation is symbol-manipulation is a program.
I see that I failed.
AI starts with an implicit question: "Is Intelligence Computation?"
For which it gives an implicit answer: "Yes".
All inquiries on the nature of intelligence after that have to do with which kinds of computation are we talking about.
Sure, this will inevitably lead to psychology, philosophy, and an area of knowledge and education that most engineers and scientists don't know as well as they should.
But don't forget that you're asking about Intelligence, to begin with, because you're studying/working on ARTIFICIAL Intelligence, which means you have a goal, "to simulate/replicate/create intelligence", and a fundamental method/metaphor to use, Computation. Philosophers study intelligence from a different POV.
Define "virtually anything else".
When I learned design, I learned all the methods you mention to achieve specifically two things necessary to solve problems: model knowledge (represent data), and model processes (represent algorithms).
That is computation.
Yes, you do the same thing in other fields of engineering. Yes, we can always learn more from their techniques. But what they're doing in that case is also computation, which is programming in the strict sense.
Computation is a very very VERY general concept. That's the reason we can even dare to talk about AI in CS and imply that cognitive process are basically computation (as Turing believed) or at least largely defined by computation.
That's the whole reason we invented a fundamental science (not engineering) to deal with the subject.
Yes, testing can be applied to other subjects. So can writing. And reading. And the ability to count. And they're all useful out of context.
But the reason CS people learn about testing instead of political science (also useful to understand) is because they need the first in order to test programs, not the second.
Yes, the rigours of math. The ability to know, when given a program, exactly what it does.
Except that this only applies to software, math, and formal languages which are... yep, symbol manipulation == computation.
You learn this to compute.
Of course.
Coding is literally writing code, and is to Programming what laying bricks is to civil engineering and architecture.
If you spend more than 10% of your "programming" time typing the code, even
I'm a bit confused by that statement. What is CS supposed to be about, then?
I'm even more confused by the fact that every other apparently more important thing in CS you mention is accesory to programming:
- AI: how to program a machine to make its own decisions.
- Design: how to plan what you're going to program, before you program, so that it is a GOOD program.
- Testing: how to make sure your program works, by defining what it means "it works" and forcing it to comply.
- Formal Specifications: how to define formally your program, so other people can understand it and tell you whether it was the program they wanted or not.
- Project Management: how to make it possible (if improbable) that you'll finish your ambitious and complicated group of programs.
I don't care if you're "programming" a Windows client in C++ with MFC libs, on a Unix machine running LISP, or on a "pen-and-paper-human-assisted" platform where you trace your program to get your results.
If you're executing an algorithm, you're executing a program, and you're computing.
If you're writing an algorithm, you're programming, and you're preparing instructions to compute. Peferably good, efficient instructions that give good results.
This "computing" thing, incidentally, is what gives "Computer/Computing" Science its name. Or so I thought until your post. Now I'm baffled trying to figure out what CS means.
Forgive me if your commented was intended along the lines of "learning a particular programming language is not what CS is about". I would agree completely with that comment, for the same reasons I think assembling and dissasembling cars does not a mechanical engineer make.
But your comment, if taken literally, sounded more like "Physics is not what Mechanical Engineering is about".
It's good to know that Garcia Marquez won his prize for his strict journalistic integrity and realistic portrayal of life in Macondo in "One Hundred Years of Solitude".
I remember hearing, reading, and watching demos about this before Visual Studio .NET was released.
.NET that could be considered substance.
.NET.
It was all part of the ".NET revolution", and was hyped for some time. It seemed a nice idea from the marketish resources, as a matter of fact. One of the things about
Of course the new version of Windows will do this, because it includes and is based on
But in case you haven't noticed, the blasted thing has been available for years now.
Am I wrong in thinking this was included from the beginning?
From my point of view, 70-80% of the time technical or formal arguments are better expressed in written format.
This is perhaps even a higher percentage in the case of code, or even pseudocode. This is partly because talking about "{ i+=p/w*x; print("@poit"); i^=2;}" is inconvenient, but also because it avoids confusions by forcing people to put things clearly before "opening their mouths".
Saying "Linux spends almost no money" in R&D is incorrect. Or rather, vacuously correct. There is no "Linux" entity, therefore it cannot itself spend money.
The correct statement would be "The Linux community's investment in R&D is impossible to estimate in monetary terms, but is likely to be less than Sun's".
Just because the research effort is not centralized, paid for from a single source, and is difficult to account for, doesn't mean that "the community" doesn't still spend a lot of man-hours, hardware and software in R&D.
That includes individuals contributing their time and resources for free. But it also includes companies and corporations invest money, to earn more money: from Linux distributors to corporations like IBM (whose investment in Linux has a lot to do with R&D).
I'm not saying that the Linux approach is better, but to pretend that just because no single company is paying the bills there was no investment is incorrect.
Rewrite indeed. But cleanup? That's argueable.
Hmmm... I partially agree with you. I liked the show from the start, but I also mocked the show frequently, and particularly some of the misplaced fans who took it far more seriously than the show took itself. Sometimes good-heartedly, sometimes not so.
f i in the age of Hercules and Xena".
s enet subgroups.
The thing is I think both the publicity and the more vocal fans gave the wrong impression of the show to typical viewers.
The publicity made it seem like the "next big thing in fantasy/B-movie-inspired/overambitious-cheap-sci-
This was the wrong approach. Buffy is proudly B-moveish, but eminently aware of its B-movieshness and is covered by a deep layer of irony and sarcasm. The characters were just as aware of the absurdities as the viewer, and dealt with it with a mixture of cynicism and naivete that resonated with the intended demographic.
It's not the high-production values that redeemed it (just like it never redeemed Xena et al), it's the fact these enrich the irony.
The fans could usually be classified in:
A) 'Hardcore geek fanboys/girls', with pseudo-Goth (and if you think Buffy is goth, the pseudo is necessary), comic-book-or-Trekkie-style, and OMG-characterX-is-so-hot-let's-write-erotica-on-u
These people took it so seriously that other people thought the series took itself just as seriously.
B) Teen-drama geeks.
These people made such a big deal of the indicental dramatic plots (that any show with character development is bound to have) that it seemed like Dawson's Creek with demons and vampires.
Perhaps I'm biased because I saw the original movie. Yes, it was bad. Really bad. And it knew it was bad, and strecthed its B-movie-crappiness-in-joke just a bit too far.
But it set the tone for the series, which did a much better job at telling the same joke.
It's a story of a typical TEEN CHEERLEADER VAMPIRE SLAYER, for Christ sake. And she's named BUFFY!
Nasty stuff? I assume you mean doing OO C for a TCP/IP stack.
Of the many things I consider nasty of C, struct is most definitely not one of them.
And I'm a Java OO-hype weenie that thinks everything in a project has to apply at least one Pattern and the Javadoc has to cite at least a book by the GoF or Fowler.
(I'm assuming it's a typo, because I have no idea what "alterior" means).
As precious as information on Mac users software installations may be, I think it's a bit paranoid to think that MS is going to buy Virtual PC for something like this...
I mean, follow the logic:
- Spend a considerable amount of money to get software technology from Connectix.
- Substantially alter Virtual PC to force it to use Windows Update to send all the data they want on the Mac software.
- Sell this new version of Virtual PC to Mac users.
- Get interesting information from a subset of Virtual PC users (the ones that get the new version or upgrade), who are a small subset of Mac users, who are a relatively tiny subset of computer users.
- Profit?
It seems like too much work for peanuts.
Consider the alternative:
- Alter the new version of Internet Explorer for Mac, software they already have complete control and knowledge of, so that it has to use Windows Update to get patches and security fixes, and checks often and automatically by default (for all I know, it might do this already).
- Provide the corresponding Windows Update client for the Mac.
- Get interesting information from all Mac users using a recent version of Internet Explorer, i.e.: most Mac users.
- Profit.
No.
By analogy there is a segment of the market that really has a competent TCP/IP stack among its top priorities. But that segment of the market is mostly going for other OSes. That's why Linuxes do well.
People buy different cars for different reasons. If SUV owners really start demanding safety (and switching to Volvos), then perhaps we'll have safe SUVs. But they don't show any interest on that.
When the TCP/IP stack is a user-issue MS will do something about it, although not before they lose users directly because of that.
That's what they did with stability (although it took them some time). Win98 users that want crash-reduction have already switched to Win2K or will soon.
Exactly.
Which is why more people are willing to pay extra for that fancy stereo system than for fuel efficiency, safety, speed or reliability.
Heck, more people are happier with the theoretical ability to drive accross arctic tundra in their unsafe, oversized, incredibly expensive and inefficient urban SUVs.
Now, I don't know what makes you happy as a user, but I do know that having a better TCP/IP stack wouldn't make any Windows users I know much happier, while having a better instant messenger, for example, would.
Aye. It could be that the TCP/IP stack that the article mentioned has "flourished" (become better software) because the people who develop it are VERY MUCH using it.
Linux geeks grok TCP/IP networking, and Linux users DEPEND on TCP/IP (not 'it would be nice to have web access and surf porn while I type this memo') for practically all of its market share. Like gcc, TCP/IP is part of the Linux deal.
It would be biased to regard this as conclusive evidence of the superiority of open-source unless other, less sexy areas of Linux development are compared to their commercial counterparts in the same way.
As evidence that certain commercial companies have not put priority on the TCP/IP stack of their OS, this could very well be good evidence.
But this doesn't necessarily mean the commercial companies are inferior; they may very well be right in having different priorities.
For example, for a Windows user it's more important that the Media Player works perfectly than having an efficient TCP/IP stack. Even on the server side it's not a big issue on their market. It's under so many layers of software, appearances and priorities that their clients would never notice if they made it better anyway.
Yes, that's pretty much what I'm saying.
Although whether the gorilla is subjectively creative when he's high is not something I could deny (I don't know that many gorillas). It makes no difference, though, without communication.
Also, there can be, and have been, crazy artistic shamans without magic mushrooms.
They're often not the most psychologically stable individuals, and they may often end up discovering and eating more magic mushrooms than they should, though.
Yup, that's it.
The gorilla may or may not have a creative spasm after getting high (I doubt it). But without complex communication skills they cannot let others know, it cannot become a social activity, and it cannot spark more complex behavior.
Although Reziac's narrative interpretation is a bit more entertaining.
First, I said the genes would have to be simultaneously "normal" on the specimen, not that they should simultaneously arrive there.
Except in a somewhat geological scale of simultaneous, perhaps. The "short", "recent" period they're talking about is anywhere between 10,000 and 50,000 years, at least 50,000 ago.
Second, genes by definition have no distinct purpose, before or after mutation. They just happen to have effects, happy accidents which keep them around, or unhappy accidents that remove them from the pool.
What they can do, and whether it's good or bad, is very much influenced by historical circumstances.
For example, I understand cystic fibrosis is pretty common as a single recessive gene among europeans and their descendants, because its presence decreased risk of dehydration by the Black Death (through intestinal inefficiency and other 'health problems', I think). Two recessives can be, and often is, quite fatal.
In the rest of the world the gene is extremely rare because for thousands of years that gene was a BAD THING. The Black Plague made it, at a particular point in history (less than a century), a good thing (with some risks, two-recessive children often died). It hasn't been 'good' since then, but humans still carry that legacy.
Third, who says there's no reason for us to stop evolving? There's a very good reason: if the design works better than the improvement, we don't 'evolve'. And who says we haven't? Evolution is not a constant rate game. Have you heard of punctuated equilibrium?
Fourth, no one is saying "creativity" will be pinpointed to 10,000 genes yet. They're saying the language and communication skills that allow "creativity" to work could be pinpointed to a set of genes. Big difference. "Creativity" is a complex process that is not even properly defined, while individual language skills can be more specificied and defined, each with its own evolutive advantages.
If you have problems thinking of 10,000 genes happily meeting and achieving "creativity" at once, think rather of 100 language skills, each linked to 100 genes, and each useful in its own sense, happily meeting over a short time and accumulating into an infrastructure that's more useful than each alone.