Are there reasons why one would expect slightly better 3D performance under Windows than Linux, given drivers that are about equally optimized on each system? I'm interested to know if we should expect to match or even beat Windows 3D performance, or if 95% is about the best that can be done. If 95% is the best we can do, that's quite alright so long as we have good reasons (e.g. solid design, stability). I've always believed it's good to sacrifice a bit of performance to keep things manageable for software people, and stable for end-users.
It's hard to even imagine what a perfect world would be like. However, it seems to me that there'll always be a disconnect between the legal and the moral. The problem is that when you create legislation, you must be willing to enforce it. If you are going to enforce the legislation, it means you will be willing and able to impose penalties on those who violate it. If you are going to impose such penalties, you must have a clear standard that allows you to identify wrong-doers. The standard must not be subjective - you cannot expect people to abide by a law that is not clearly defined.
In a perfect world, perhaps there would be a lot more agreement about terms that are currently considered subjective (such as "offensive"). Thus, laws could be enacted that would otherwise be too subjective. I am not sure though: in a perfect world, does everyone agree on the definition of "offensive" (and other currently subjective terms)?
In our decidedly imperfect world, society's moral standards serve to keep people in line fairly well. There are positive and very negative aspects to this of course, since society's standards don't always make a lot of sense (e.g. people who are good-looking are favoured). However, if your peers judge that you are acting like an !%#-hole, or you are just plain too different from them, you will be isolated, and there are very real penalties for being isolated / marginalized in society.
"The nail that stands up gets pounded down." (Chinese proverb (I think))
I have witnessed the same thing myself - the process becomes an end in itself. People forget that what we're paid for is software, the process is only useful to the extent that it helps us to create better software.
First, I do think the process used for the FSW stuff is probably an excellent choice for that project. This is because of the following factors:
s/w failure can be very expensive in human and monetary terms
requirements aren't changing every day - in fact they hardly ever change
big budget
long schedule
The author of this article seems to be saying that if all software was developed the same way, we'd be living in some sort of bug-free software utopia. The reality is that many software software projects proceed under very different circumstances:
if the s/w fails, the user will be annoyed rather than dead
requirements are subject to constant change
very tight schedule : if you deliver later that your competitor, you lose market share and your company may even fail
Under these circumstances, you had better have some "hot shot" (!= cowboy) people on your project, or you will have a failed project. The real challenge on most software projects is to write good software in a fairly short period of time. Unfortunately, there are a lot of bad programmers and s/w project managers, and what we end with a lot of the time is shitty or mediocre software.
I thought the author's best point was that software development is unnecessarily crazy, and could benefit a lot from being done in a more relaxed atmosphere. Unfortunately, it seems beyond the ability of any one company to make this happen, given the need to compete in the marketplace. Basically, what would have to happen to make software better is for everyone to demand better software - to make quality a priority over speed. The markets currently are saying that speed is the bigger issue.
If they have a detailed record of my existence, I think I ought to have the right to see it. If I don't have that right, then I'll add this to the growing list of reasons to leave Canada. Other reasons include: o taxes are *crazy* here o I can't make as much money here o gov't is generally much more socialist, doesn't respect individual rights enough o people here continually look to gov't for answers -- to much "entitlement mentality". There are good things about being Canadian too, but right now I'm in a pissy mood:-) -VonKruel
There are indeed many interesting languages being developed. However, if you are developing systems or application software today, your choices are much more limited in practice. For all its weak points, C++ is a very powerful language. A competent programmer (who has gotten over the admittedly steep learning curve) can be very productive in it. Also, there are a lot of good supporting tools for C++, it has compilers on just about every platform, etc... These are very important considerations when you are starting a software project.
When one of these new languages shows signs of becoming the "Next Big Thing", I'll consider having a look at it. And there's the rub : a language for development of large software systems needs a critical mass of users, which it has trouble getting when it has very few users. It's a serious problem even when the new language is much better designed than the status quo. I'd like just as much as anyone for a new language to come along and kick C++'s ass and become an industry standard, but I'm not holding my breath.
(Note: I didn't say C++ was industry standard.)
Re:Best ergonomic keyboard I've used... the MS one
on
Ergonomic Keyboards
·
· Score: 1
I also really liked the original MS natural keyboard. As you point out, the Elite was a flop. But the Pro is the best yet! The extra keys on top are pretty useless, but the keys have a better tactile response. I'm typing noticeably quicker with it. Try to find one in a store that you can try out.
Parameterized types (templates) and OO are two rather different ways of writing generic code. With templates you re-use an external interface (e.g. copy constructor, assignment operator, etc. in the STL). With OO, polymorphism (via dynamic binding) is exploited to achieve re-use.
Templates have these advantages:
compile-time type safety
performance (no dynamic binding - function calls can often be expanded inline, avoiding a function call altogether)
OO has these advantages:
simpler programming - you can get some extremely long compiler errors when working with templates
less code bloat
it seems unfortunate for so much code to be in header files instead of.cpp files (circular #include's can be fun)
The craziness over template-orientation seems counter-productive to me. Templates are a great feature of C++ and they are the only reasonable way to solve some problems in C++. However, many now seem to think they should be used to solve every problem. I agree that compile-time type safety is a Good Thing, but are we making an intelligent decision given that:
dynamic_cast allows safe downward casting in an inheritance hierarchy
Moore's law is still going strong : most people writing application software really do not need to obsessively count CPU cycles any more - choosing the right algorithms is more important than an O(1) improvement. Was it Knuth who said "premature optimization is the root of all evil."?
CPU cycles are becoming more and more plentiful whereas talented designers and programmers are not. Template-orientation seems to make the wrong trade-off. I know that TO and OO can be used together in one program, but they are very different ways of achieving re-use. When should one be favoured over the other?
First, I don't think it's fair to criticize any language on the basis that it's possible to write bad code in it. You can write bad code in any language, and this fact has been proven over and over again by programmers all over the world. There's far more bad code written in Perl and C++ than there is good...
I think Perl is often a great choice for whipping up small programs such as CGI. Perl has less of a learning curve than C++, and it provides a lot of good functionality (especially for text manipulation) that makes it possible to accomplish quite a bit in very few lines of code.
However, there's nothing about the C++ language that prevents you from getting a lot done in very few lines of code... you just need the right class libraries backing you up, and having a good mind for software design won't hurt either. In Perl, you get a lot of useful stuff "out of the box", whereas in C++ you need to go "shopping" for class libraries. ANSI C++ includes the STL (Standard Template Library) but it really only covers a portion of the re-usable functionality you'll likely need. For example, it doesn't have regular expressions or socket communication classes. No big deal, just figure out what you need and go get it... C++ is a very popular language for application development, so there's been a lot of effort spent developing class libraries for it.
I think the aspects in C++ that make it hard(er) to learn are largely those that make it a far better choice for large applications. Once you get over the learning curve, you can really appreciate C++ for all the power it gives you. C++ templates are very powerful (though I think they're overused). It's also a full-featured object-oriented language, and I'm very religious about object-orientation, especially for large applications. Yet it's not a pure OO language (which motivates some criticism), so you have the freedom to do things in a procedural style if you see fit.
Another issue that's relevant in large projects is debugging support. Is there such a thing as a Perl debugger that even approaches the power available in a modern C++ debugger? For example, debugging multiple execution threads, setting conditional breakpoints, etc.?
Anyway I'm really glad Perl exists because I think it does fill a void -- it enables the rapid development of small programs without requiring a huge up-front investment of learning time. But I cringe when I see people talking about how Perl is the ultimate language of all time, because I wonder how many ill-fated, large Perl projects are being started on the basis of this hype. Perl is worthy of praise, but remember it's not always the right answer.
I found your comments very heartening. I haven't made a priority of finding a mate, because I know I wouldn't make a good partner. Why not? I spend most of my time "geeking out" and I'm not in a hurry to change my behavior. Kids? No way! I'd be a horrible father and it would really cramp my geek lifestyle. If I told a woman I'd make her my first priority, it would be a lie and we'd both pay for that lie eventually.
There's a strong social pressure to find a mate. People tend to think that if you don't have a mate, then you must be horribly flawed in some way. Oh well - there's always a price for going against the grain. Later in life my interests may change, and I may try to find a woman who can tolerate me:-)
People are often so keen to find a mate that they lie to themselves and/or their partner at the outset of a relationship. Neither person benefits from this in the long run. "Falling in love" is an irrational process anyway. At some early stage you decide "I am in *love* with this woman" and then you are willing to undertake any deception (and allow yourself to be deceived) in order to realize your romantic goal. Not being desperate for a relationship (and not rushing it) is probably the greatest key for finding a good, lasting one.
I agree that they movie makers are properly more concerned with *entertaining* people than necessarily portraying reality in every aspect of the movie. However, I think that if they would just hire a "computer technology consultant" (or whatever) on the movie, then they could pervert the truth in ways that serve the director's purpose without pissing off and/or alienating so many geeks. For example, I remember a scene in "Hackers" (it was on TV - I did *not* pay money to see it) where these supposed techno-Gods are drooling over a new laptop, and one of them remarks, "ooooh - I see it has a 28.8 bps modem!". 28.8 bps is rather slow - maybe they meant 28.8 kbps. And of course who could forget the end of ID4 (which I *did* pay to see I'm ashamed to say). Why couldn't they just sneak a nuke up to the mothership or something? No, they had to *INSTALL A VIRUS* on the *ALIEN* computer system. If this alien race runs Windoze then how can they be smart enough to travel half-way across the frickin' Universe?
It's true that there's a lot of bad code, but the cause isn't that better hardware makes programmers lazy. The cause is bad programmers, or bad managers/customers imposing stupid designs/requirements.
Better hardware has enabled the creation of larger, more complex, and more featureful applications. It takes more skill to manage this complexity, and there are very few programmers who actually have this skill. Of course, the explanation for bad software is more complicated than that, but bad programmers and bad project managers are high on my list of causes. Like practically any other problem in the world, it can be traced back to human stupidity.
I've heard lots of people talk about the "good old days" of computing when a word processor could run in 4K or whatever. Better hardware is a *good* thing, and it *should* be exploited to make life simpler/easier for application developers wherever possible. Whatever makes the developer's life better, will ultimately make the end user's life better too.
I think the benefit of a formal design methodology is a function of two things:
1) team size / size of project
On a large team, the diagrams & documents provide a roadmap for the team to follow, and they are essential for the purpose of keeping everybody on the team gainfully occupied.
On a small team, the full "process" may be serious overkill, and it should only be followed to the extent that the team considers it helpful and not a waste of time. For example, if some UML will help hash out the key design issues then by all means do it.
2) project complexity and team's amount of experience with the problems/tools/technologies involved
If there are a lot of difficult design issues on the project and/or the team lacks experience in some key areas then you'll need to be more rigid in following the process. This will take some extra time but it will reduce the risk.
On the other hand, if the design problems are very well understood or you're able to re-use a lot of code then you can save considerable time by avoiding a lot of the process.
***
Unfortunately, the process often becomes an end in itself, and it's followed on every project regardless of whether it's helpful. It's important to remember that good code is the #1 goal, and everything else you spend time on is in support of that goal.
Re:Huray! Now, more people use C++!!
on
GCC 2.95 Released
·
· Score: 1
You're quite right that it's easier to write inefficient code in C++. There can be methods invoked where the coder doesn't expect, yielding correct behavior and yet crippling performance. Ironically, for the same reason it's easier to write more efficient code as well, since complex data structures can be used with a minimum of effort. So it comes down the the coder's skill -- you'll tend to see greater extremes of *great* and *horrible* code in C++.
The biggest gains are from using better *algorithms*. E.g. going from O(n^2) to O(n) is going to matter a lot more than a constant 5-10% gain.
Most of the time it's only about 20% of the code in a project that needs to be fast. Profiling can help you identify that 20% and get it up to speed.
I think the aftermath of this accident reflects on the values of our culture: good looks and money. Would there be such widespread interest in this accident if JFK Jr. and his wife weren't such a glamorous couple? Same thing when Diana Spencer died -- Mother Theresa died around the same time and apparently Diana's death was far more "newsworthy".
The evidence right now suggests JFK Jr.'s inexperience and poor judgement caused that accident. Getting killed by your own poor judgement is bad enough -- taking others with you is far worse.
Of course it's sad, but I'm not going through a "grieving process" either because I didn't know these people. It's sad that the deaths of many truly great people go largely unnoticed, but people can't seem to grieve enough over this.
The ability of an AI to play a game well depends on the complexity of the game. The complexity of a game depends on how many possible moves there are at each turn, and how many possible game states there can be. For example:
Tic-tac-toe: very easy -- the machine can examine the whole game-tree on each move, and *always* make the best possible move (which will result in a tie if the human also makes the best possible move).
Checkers: more complex, but a deep search can be conducted, and a move database can be used to help matters also. There are some *excellent* (practically unbeatable) checkers programs in existence. And there are incredibly good human players also.
Chess: quite a bit more complex than checkers. The number of possible states for a Chess game is hopelessly huge. To create a grandmaster-comparable Chess engine, you employ tactics like:
o hardware acceleration of time-critical search code o move database for opening and end-games (tricky part is the middle game) o heuristics developed with the assistance of Chess grandmasters o a big-ass computer (lots-o-CPUs and memory bandwidth) o a very nice search engine of course;-)
It's important to note that adding more computing power doesn't help matters as much as you may think. For example, suppose you increase the computing power by a factor of 10. In a game where the number of possible moves is 10, this would enable you to see *one* (1) move further into the future. If you wanted to see two moves further into the future you'd need *100* times the computing power. This is over-simplifying things a bit, but you see my point.
Now consider a computer game like a flight simulator or a real-time sim like StarCraft. The complexity of games like this is so massivley f'ing huge that you can't cope with the problem by using a simple min/max search -- you *must* rely *heavily* on heuristics (e.g. if...then...) to make an AI that will perform better than a monkey. A lot of AIs are given artificial assistance (e.g. they "cheat") so that they won't be easily defeated by a competent human player.
Linux is a very nice system to develop on in general, but it has a ways to go before it can attract *lots* of game developers. Specifically, Linux needs to offer a nice set of application programming interfaces (APIs) for functionality such as:
o input devices -- USB joysticks, steering wheels o graphics -- OpenGL is the right direction here o *sound* We need interfaces that can really take advantage of features offered by kick-ass new sound cards like the Creative SBLive! and Diamond MX300 (environmental effects, positional audio, etc.)
As Linux users continue to grow in number, more game developers will start to see us as a viable market. Some really cool companies (such is id software) are already porting their games to Linux. But there *are* some technical barriers as well -- basically, Linux should offer APIs that cover the same *functionality* as Microsoft DirectX. I know there are some talented people working on this stuff, and I'm excited to see the results in the next year or two.
Linux is such a nice system technically, that with a large userbase willing to *pay* for games, and some really nice APIs to attract game developers, we'd get lots of cool games running natively under Linux. And you know what that means: one less reason to have Windows installed.
You can't control a process you don't understand
on
How to Manage Geeks?
·
· Score: 3
A large problem is that management has an interest in controlling/monitoring the development process, yet they don't truly understand this process. For example, developing good software requires a lot of time spent initially, coming up with the right abstractions, building a solid nucleus for for further development, etc. A manager who doesn't understand the art/craft of software won't be able to tell the difference between a person who is actively engaged in this up-front effort, and a person who spends all day web-surfing.
This brings up the issue of staffing software projects. Ideally, I think you want a *very* small group of highly skilled people to work on the project initially, to nail down the requirements, create a sane design, and code the essential/basic/difficult parts of the system. Then, near the end of the project, you build up the team with possibly less-skilled people to build the rest of the system on this solid foundation. Thus, the software almost magically comes to life in the last ~25% of the schedule, when there *appeared* to be hardly any progress before-hand.
The cost and quality of software is *hugely* affected by decisions that happen early on. These decisions must be made correctly, and the initial design must be coherent and sane. Once this solid foundation is layed, it's OK to make the team larger, and add less-skilled people.
In software, there are *important* jobs that it's hard to get volunteers for, such as writing documentation, ensuring the software has a *user*-friendly interface and not just a *geek*-friendly interface, etc...
This is why I think we need to welcome a certain amount of commercial interest in Linux, if we really care about "world domination". A certain amount of commercial interest in Linux will ensure that these important (but unexciting) jobs get done.
His specific argument about inadequate testing is dumb though. This is an area where Linux really excels -- millions of real users pounding on the software will find bugs you never would have found in a testing lab. ESR has eloquently described free software's advantages here in "The Cathedral and the Bazaar."
I know I shouldn't waste my time with this kind of flame-bait, but it's Sunday and I'm a bit bored.
Here's the e-mail I sent to Mr. Coates:
I'm sure you're getting lots of nasty e-mail about now. I wonder if your article was sincere -- it reads a lot like flamebait.
Linux is not "dinky" -- it is an excellent system that is starting to get the attention it deserves. I find it amusing that you judge yourself fit to make such a judgement when your technical knowledge would probably fit on the head of a pin.
You're correct that Linux is not for the average user's desktop just yet. Considerable effort is currently being spent in this area, but it will take another 2-4 years until I'll be able to recommend Linux to my Mom. And maybe Linux will *never* overcome MS's dominance on the desktop -- it doesn't mean we shouldn't *try*.
So Linux isn't for you. But instead of simply ignoring it, you feel the need to heap uninformed criticism on the efforts of the highly skilled people who develop free software. To what end? -- attracting attention to yourself and your article, which you unfortunately could not accomplish with your mastery of the facts, and brilliant synthesis of them.
When A and B often occur together, A and B are said to "correlate". A and B can correlate without A causing B or B causing A. Perhaps the is a third agent C that causes both A and B, for example. Consider:
FACT: "people who commit murder tend to play violent video games."
CONCLUSION ??? "playing violent video games tends to cause the commission of murder."
I *love* violent video games -- the more violence and gore the better, but I haven't killed anyone (lately).
** class dismissed **
Many people are incapable of critical thought and/or too lazy to bother with anything more than superficial inquiry. They are eager to accept simple answers to very complex questions ; there's a great need to have a *convenient* answer (e.g. a scape-goat), and not much interest in knowing the truth.
In the wake of a tragedy like in Colorado, people are even more unlikely to think rationally -- they will grasp even more desperately at ill-conceived explanations like:
o playing violent video games causes violent behavior in people who play them o the boys were "evil" o society is to blame -- by devaluing their lives, it taught them to devalue the lives of others
Some of the answers have some merit, some don't. The real answer is far too complicated to fit into a 30-second sound-bite, and in fact we may *never* have a satisfactory answer.
Life would be better in general if people could:
a) *realize* when they don't know the answer (be less stupid) b) *admit* that the don't know the answer (be more honest)
"I don't know" is sometimes the best answer. Unfortunately it's an answer our politicians aren't allowed to give...
Slashdot Mirror
Are there reasons why one would expect slightly better 3D performance under Windows than Linux, given drivers that are about equally optimized on each system? I'm interested to know if we should expect to match or even beat Windows 3D performance, or if 95% is about the best that can be done. If 95% is the best we can do, that's quite alright so long as we have good reasons (e.g. solid design, stability). I've always believed it's good to sacrifice a bit of performance to keep things manageable for software people, and stable for end-users.
It's hard to even imagine what a perfect world would be like. However, it seems to me that there'll always be a disconnect between the legal and the moral. The problem is that when you create legislation, you must be willing to enforce it. If you are going to enforce the legislation, it means you will be willing and able to impose penalties on those who violate it. If you are going to impose such penalties, you must have a clear standard that allows you to identify wrong-doers. The standard must not be subjective - you cannot expect people to abide by a law that is not clearly defined.
In a perfect world, perhaps there would be a lot more agreement about terms that are currently considered subjective (such as "offensive"). Thus, laws could be enacted that would otherwise be too subjective. I am not sure though: in a perfect world, does everyone agree on the definition of "offensive" (and other currently subjective terms)?
In our decidedly imperfect world, society's moral standards serve to keep people in line fairly well. There are positive and very negative aspects to this of course, since society's standards don't always make a lot of sense (e.g. people who are good-looking are favoured). However, if your peers judge that you are acting like an !%#-hole, or you are just plain too different from them, you will be isolated, and there are very real penalties for being isolated / marginalized in society.
"The nail that stands up gets pounded down." (Chinese proverb (I think))
I have witnessed the same thing myself - the process becomes an end in itself. People forget that what we're paid for is software, the process is only useful to the extent that it helps us to create better software.
First, I do think the process used for the FSW stuff is probably an excellent choice for that project. This is because of the following factors:
The author of this article seems to be saying that if all software was developed the same way, we'd be living in some sort of bug-free software utopia. The reality is that many software software projects proceed under very different circumstances:
Under these circumstances, you had better have some "hot shot" (!= cowboy) people on your project, or you will have a failed project. The real challenge on most software projects is to write good software in a fairly short period of time. Unfortunately, there are a lot of bad programmers and s/w project managers, and what we end with a lot of the time is shitty or mediocre software.
I thought the author's best point was that software development is unnecessarily crazy, and could benefit a lot from being done in a more relaxed atmosphere. Unfortunately, it seems beyond the ability of any one company to make this happen, given the need to compete in the marketplace. Basically, what would have to happen to make software better is for everyone to demand better software - to make quality a priority over speed. The markets currently are saying that speed is the bigger issue.
If they have a detailed record of my existence, I think I ought to have the right to see it. If I don't have that right, then I'll add this to the growing list of reasons to leave Canada. Other reasons include: o taxes are *crazy* here o I can't make as much money here o gov't is generally much more socialist, doesn't respect individual rights enough o people here continually look to gov't for answers -- to much "entitlement mentality". There are good things about being Canadian too, but right now I'm in a pissy mood :-) -VonKruel
When one of these new languages shows signs of becoming the "Next Big Thing", I'll consider having a look at it. And there's the rub : a language for development of large software systems needs a critical mass of users, which it has trouble getting when it has very few users. It's a serious problem even when the new language is much better designed than the status quo. I'd like just as much as anyone for a new language to come along and kick C++'s ass and become an industry standard, but I'm not holding my breath.
(Note: I didn't say C++ was industry standard.)
I also really liked the original MS natural keyboard. As you point out, the Elite was a flop. But the Pro is the best yet! The extra keys on top are pretty useless, but the keys have a better tactile response. I'm typing noticeably quicker with it. Try to find one in a store that you can try out.
-Adam
Templates have these advantages:
- compile-time type safety
- performance (no dynamic binding - function calls can often be expanded inline, avoiding a function call altogether)
OO has these advantages:- simpler programming - you can get some extremely long compiler errors when working with templates
- less code bloat
- it seems unfortunate for so much code to be in header files instead of
.cpp files (circular #include's can be fun)
The craziness over template-orientation seems counter-productive to me. Templates are a great feature of C++ and they are the only reasonable way to solve some problems in C++. However, many now seem to think they should be used to solve every problem. I agree that compile-time type safety is a Good Thing, but are we making an intelligent decision given that:- dynamic_cast allows safe downward casting in an inheritance hierarchy
- Moore's law is still going strong : most people writing application software really do not need to obsessively count CPU cycles any more - choosing the right algorithms is more important than an O(1) improvement. Was it Knuth who said "premature optimization is the root of all evil."?
CPU cycles are becoming more and more plentiful whereas talented designers and programmers are not. Template-orientation seems to make the wrong trade-off. I know that TO and OO can be used together in one program, but they are very different ways of achieving re-use. When should one be favoured over the other?A paper about the Slashdot effect being Slashdotted... Deliciously self-referential!
If you haven't read Hofstadter's books "Godel, Escher, Bach" and "Metamagical Themas" you should check them out.
This comment doesn't have an
First, I don't think it's fair to criticize any language on the basis that it's possible to write bad code in it. You can write bad code in any language, and this fact has been proven over and over again by programmers all over the world. There's far more bad code written in Perl and C++ than there is good...
I think Perl is often a great choice for whipping up small programs such as CGI. Perl has less of a learning curve than C++, and it provides a lot of good functionality (especially for text manipulation) that makes it possible to accomplish quite a bit in very few lines of code.
However, there's nothing about the C++ language that prevents you from getting a lot done in very few lines of code... you just need the right class libraries backing you up, and having a good mind for software design won't hurt either. In Perl, you get a lot of useful stuff "out of the box", whereas in C++ you need to go "shopping" for class libraries. ANSI C++ includes the STL (Standard Template Library) but it really only covers a portion of the re-usable functionality you'll likely need. For example, it doesn't have regular expressions or socket communication classes. No big deal, just figure out what you need and go get it... C++ is a very popular language for application development, so there's been a lot of effort spent developing class libraries for it.
I think the aspects in C++ that make it hard(er) to learn are largely those that make it a far better choice for large applications. Once you get over the learning curve, you can really appreciate C++ for all the power it gives you. C++ templates are very powerful (though I think they're overused). It's also a full-featured object-oriented language, and I'm very religious about object-orientation, especially for large applications. Yet it's not a pure OO language (which motivates some criticism), so you have the freedom to do things in a procedural style if you see fit.
Another issue that's relevant in large projects is debugging support. Is there such a thing as a Perl debugger that even approaches the power available in a modern C++ debugger? For example, debugging multiple execution threads, setting conditional breakpoints, etc.?
Anyway I'm really glad Perl exists because I think it does fill a void -- it enables the rapid development of small programs without requiring a huge up-front investment of learning time. But I cringe when I see people talking about how Perl is the ultimate language of all time, because I wonder how many ill-fated, large Perl projects are being started on the basis of this hype. Perl is worthy of praise, but remember it's not always the right answer.
I found your comments very heartening. I haven't made a priority of finding a mate, because I know I wouldn't make a good partner. Why not? I spend most of my time "geeking out" and I'm not in a hurry to change my behavior. Kids? No way! I'd be a horrible father and it would really cramp my geek lifestyle. If I told a woman I'd make her my first priority, it would be a lie and we'd both pay for that lie eventually.
:-)
There's a strong social pressure to find a mate. People tend to think that if you don't have a mate, then you must be horribly flawed in some way. Oh well - there's always a price for going against the grain. Later in life my interests may change, and I may try to find a woman who can tolerate me
People are often so keen to find a mate that they lie to themselves and/or their partner at the outset of a relationship. Neither person benefits from this in the long run. "Falling in love" is an irrational process anyway. At some early stage you decide "I am in *love* with this woman" and then you are willing to undertake any deception (and allow yourself to be deceived) in order to realize your romantic goal. Not being desperate for a relationship (and not rushing it) is probably the greatest key for finding a good, lasting one.
I agree that they movie makers are properly more concerned with *entertaining* people than necessarily portraying reality in every aspect of the movie. However, I think that if they would just hire a "computer technology consultant" (or whatever) on the movie, then they could pervert the truth in ways that serve the director's purpose without pissing off and/or alienating so many geeks. For example, I remember a scene in "Hackers" (it was on TV - I did *not* pay money to see it) where these supposed techno-Gods are drooling over a new laptop, and one of them remarks, "ooooh - I see it has a 28.8 bps modem!". 28.8 bps is rather slow - maybe they meant 28.8 kbps. And of course who could forget the end of ID4 (which I *did* pay to see I'm ashamed to say). Why couldn't they just sneak a nuke up to the mothership or something? No, they had to *INSTALL A VIRUS* on the *ALIEN* computer system. If this alien race runs Windoze then how can they be smart enough to travel half-way across the frickin' Universe?
Given your fame (among Linux geeks anyway), any areas you identify as needing improvement should be taken very seriously.
It's true that there's a lot of bad code, but the cause isn't that better hardware makes programmers lazy. The cause is bad programmers, or bad managers/customers imposing stupid designs/requirements.
Better hardware has enabled the creation of larger, more complex, and more featureful applications. It takes more skill to manage this complexity, and there are very few programmers who actually have this skill. Of course, the explanation for bad software is more complicated than that, but bad programmers and bad project managers are high on my list of causes. Like practically any other problem in the world, it can be traced back to human stupidity.
I've heard lots of people talk about the "good old days" of computing when a word processor could run in 4K or whatever. Better hardware is a *good* thing, and it *should* be exploited to make life simpler/easier for application developers wherever possible. Whatever makes the developer's life better, will ultimately make the end user's life better too.
I think the benefit of a formal design methodology is a function of two things:
1) team size / size of project
On a large team, the diagrams & documents provide a roadmap for the team to follow, and they are essential for the purpose of keeping everybody on the team gainfully occupied.
On a small team, the full "process" may be serious overkill, and it should only be followed to the extent that the team considers it helpful and not a waste of time. For example, if some UML will help hash out the key design issues then by all means do it.
2) project complexity and team's amount of experience with the problems/tools/technologies involved
If there are a lot of difficult design issues on the project and/or the team lacks experience in some key areas then you'll need to be more rigid in following the process. This will take some extra time but it will reduce the risk.
On the other hand, if the design problems are very well understood or you're able to re-use a lot of code then you can save considerable time by avoiding a lot of the process.
***
Unfortunately, the process often becomes an end in itself, and it's followed on every project regardless of whether it's helpful. It's important to remember that good code is the #1 goal, and everything else you spend time on is in support of that goal.
You're quite right that it's easier to write inefficient code in C++. There can be methods invoked where the coder doesn't expect, yielding correct behavior and yet crippling performance.
Ironically, for the same reason it's easier to write more efficient code as well, since complex data structures can be used with a minimum of effort. So it comes down the the coder's skill -- you'll tend to see greater extremes of *great* and *horrible* code in C++.
The biggest gains are from using better *algorithms*. E.g. going from O(n^2) to O(n) is going to matter a lot more than a constant 5-10% gain.
Most of the time it's only about 20% of the code in a project that needs to be fast. Profiling can help you identify that 20% and get it up to speed.
I think the aftermath of this accident reflects on the values of our culture: good looks and money. Would there be such widespread interest in this accident if JFK Jr. and his wife weren't such a glamorous couple? Same thing when Diana Spencer died -- Mother Theresa died around the same time and apparently Diana's death was far more "newsworthy".
The evidence right now suggests JFK Jr.'s inexperience and poor judgement caused that accident. Getting killed by your own poor judgement is bad enough -- taking others with you is far worse.
Of course it's sad, but I'm not going through a "grieving process" either because I didn't know these people. It's sad that the deaths of many truly great people go largely unnoticed, but people can't seem to grieve enough over this.
The ability of an AI to play a game well depends on the complexity of the game. The complexity of a game depends on how many possible moves there are at each turn, and how many possible game states there can be. For example:
;-)
Tic-tac-toe: very easy -- the machine can examine the whole game-tree on each move, and *always* make the best possible move (which will result in a tie if the human also makes the best possible move).
Checkers: more complex, but a deep search can be conducted, and a move database can be used to help matters also. There are some *excellent* (practically unbeatable) checkers programs in existence. And there are incredibly good human players also.
Chess: quite a bit more complex than checkers. The number of possible states for a Chess game is hopelessly huge. To create a grandmaster-comparable Chess engine, you employ tactics like:
o hardware acceleration of time-critical search code
o move database for opening and end-games (tricky part is the middle game)
o heuristics developed with the assistance of Chess grandmasters
o a big-ass computer (lots-o-CPUs and memory bandwidth)
o a very nice search engine of course
It's important to note that adding more computing power doesn't help matters as much as you may think. For example, suppose you increase the computing power by a factor of 10. In a game where the number of possible moves is 10, this would enable you to see *one* (1) move further into the future. If you wanted to see two moves further into the future you'd need *100* times the computing power. This is over-simplifying things a bit, but you see my point.
Now consider a computer game like a flight simulator or a real-time sim like StarCraft. The complexity of games like this is so massivley f'ing huge that you can't cope with the problem by using a simple min/max search -- you *must* rely *heavily* on heuristics (e.g. if...then...) to make an AI that will perform better than a monkey. A lot of AIs are given artificial assistance (e.g. they "cheat") so that they won't be easily defeated by a competent human player.
Linux is a very nice system to develop on in general, but it has a ways to go before it can attract *lots* of game developers. Specifically, Linux needs to offer a nice set of application programming interfaces (APIs) for functionality such as:
o input devices -- USB joysticks, steering wheels
o graphics -- OpenGL is the right direction here
o *sound* We need interfaces that can really take advantage of features offered by kick-ass new sound cards like the Creative SBLive! and Diamond MX300 (environmental effects, positional audio, etc.)
As Linux users continue to grow in number, more game developers will start to see us as a viable market. Some really cool companies (such is id software) are already porting their games to Linux. But there *are* some technical barriers as well -- basically, Linux should offer APIs that cover the same *functionality* as Microsoft DirectX. I know there are some talented people working on this stuff, and I'm excited to see the results in the next year or two.
Linux is such a nice system technically, that with a large userbase willing to *pay* for games, and some really nice APIs to attract game developers, we'd get lots of cool games running natively under Linux. And you know what that means: one less reason to have Windows installed.
A large problem is that management has an interest in controlling/monitoring the development process, yet they don't truly understand this process. For example, developing good software requires a lot of time spent initially, coming up with the right abstractions, building a solid nucleus for for further development, etc. A manager who doesn't understand the art/craft of software won't be able to tell the difference between a person who is actively engaged in this up-front effort, and a person who spends all day web-surfing.
This brings up the issue of staffing software projects. Ideally, I think you want a *very* small group of highly skilled people to work on the project initially, to nail down the requirements, create a sane design, and code the essential/basic/difficult parts of the system. Then, near the end of the project, you build up the team with possibly less-skilled people to build the rest of the system on this solid foundation. Thus, the software almost magically comes to life in the last ~25% of the schedule, when there *appeared* to be hardly any progress before-hand.
The cost and quality of software is *hugely* affected by decisions that happen early on. These decisions must be made correctly, and the initial design must be coherent and sane. Once this solid foundation is layed, it's OK to make the team larger, and add less-skilled people.
In software, there are *important* jobs that it's hard to get volunteers for, such as writing documentation, ensuring the software has a *user*-friendly interface and not just a *geek*-friendly interface, etc...
This is why I think we need to welcome a certain amount of commercial interest in Linux, if we really care about "world domination". A certain amount of commercial interest in Linux will ensure that these important (but unexciting) jobs get done.
His specific argument about inadequate testing is dumb though. This is an area where Linux really excels -- millions of real users pounding on the software will find bugs you never would have found in a testing lab. ESR has eloquently described free software's advantages here in "The Cathedral and the Bazaar."
I know I shouldn't waste my time with this kind of flame-bait, but it's Sunday and I'm a bit bored.
Here's the e-mail I sent to Mr. Coates:
I'm sure you're getting lots of nasty e-mail about now. I wonder if your article was sincere -- it reads a lot like flamebait.
Linux is not "dinky" -- it is an excellent system that is starting to get the attention it deserves. I find it amusing that you judge yourself fit to make such a judgement when your technical knowledge would probably fit on the head of a pin.
You're correct that Linux is not for the average user's desktop just yet. Considerable effort is currently being spent in this area, but it will take another 2-4 years until I'll be able to recommend Linux to my Mom. And maybe Linux will *never* overcome MS's dominance on the desktop -- it doesn't mean we shouldn't *try*.
So Linux isn't for you. But instead of simply ignoring it, you feel the need to heap uninformed criticism on the efforts of the highly skilled people who develop free software. To what end? -- attracting attention to yourself and your article, which you unfortunately could not accomplish with your mastery of the facts, and brilliant synthesis of them.
** Critical Thinking 101 ***
When A and B often occur together, A and B are said to "correlate". A and B can correlate without A causing B or B causing A. Perhaps the is a third agent C that causes both A and B, for example. Consider:
FACT:
"people who commit murder tend to play violent video games."
CONCLUSION ???
"playing violent video games tends to cause the commission of murder."
I *love* violent video games -- the more violence and gore the better, but I haven't killed anyone (lately).
** class dismissed **
Many people are incapable of critical thought and/or too lazy to bother with anything more than superficial inquiry. They are eager to accept simple answers to very complex questions ; there's a great need to have a *convenient* answer (e.g. a scape-goat), and not much interest in knowing the truth.
In the wake of a tragedy like in Colorado, people are even more unlikely to think rationally -- they will grasp even more desperately at ill-conceived explanations like:
o playing violent video games causes violent
behavior in people who play them
o the boys were "evil"
o society is to blame -- by devaluing their
lives, it taught them to devalue the lives
of others
Some of the answers have some merit, some don't. The real answer is far too complicated to fit into a 30-second sound-bite, and in fact we may *never* have a satisfactory answer.
Life would be better in general if people could:
a) *realize* when they don't know the answer
(be less stupid)
b) *admit* that the don't know the answer
(be more honest)
"I don't know" is sometimes the best answer. Unfortunately it's an answer our politicians aren't allowed to give...