I don't even know where to start. "Developers take as long as they like to make their product and then add up the number of hours and expected sale units and price each unit accordingly. There is no incentive to conceive and code whole new classes of development tools that will give order-of-magnitude in productivity."
Developers typically have a scheduled finish date, and they try to cram as many features, technology, and improvements into that time to be competitive with other games, and have a chance of success. The development of every game involves many risks; from the engineering challenges of inventing new technology to just making things fun (often ideas that sound good on paper don't end up working out). Publishers typically lose money on most of their games and make it back on the few "stars". Prices are set by what they think will generate the most revenue. Development contracts are awarded based on expected sales. However, nobody can predict which games will sell well, so they must gamble in this fashion in much the same way as music and movie publishers, although the trend is towards "safer" bets such as sequels and licensed titles.
"But, hell, most of them are still using C or C++: the most backward, cryptic, and unproductive languages imagineable."
Games are typically coded in C/C++ because that is currently the best compromise between ease of use and efficiency of generated code. Skilled programmers spend their time solving language-independent software development problems, not battling syntax errors. The previous generation of console games were mostly coded in assembly; on modern consoles assembly is used fairly sparingly. Even C++ is considered too inefficient by many console developers. On a given hardware platform, the more efficient the code, the more graphical detail and behavioral complexity (e.g., physics and ai) can be achieved. Game developers typically write many custom tools to increase productivity, optimize scene data, etc.
"This is because software developers refuse to press for new types of software writing tools that will make it possible to develop a commercial game in 1/10 of the time that it takes today."
If we knew of some magical language that would let us develop in 1/10th the time with the same quality we would all use it! The main potential for lowering development time (and thus cost) is the increased use of middleware such as Renderware and pre-made physics engines. However, besides the expense of most of these products, there is also the decreased efficiency and utility of a general "one-size fits all" toolchain instead of a custom, product-specific engine. We make the best guesses we can about how to best achieve our development goals--while we might screw up sometimes, it is inconceivable that we would deliberately avoid any solution that would increase our productivity. Game development is very competetive, and we will do just about anything to get an edge. Use of middleware will probably increase dramatically with the next-generation consoles, especially the PS3, but any savings in development time will be overshadowed by the ever increasing demand for more game complexity, more textures, more complex scene data, more special effects, more animation, more online support, etc, etc.
Piracy won't "force" any improvements in the game development paradigm--the main effect of piracy is to lower the sales of games (when people who would have purchased the game pirate it instead), and to cause developers to spend more time devising anti-piracy schemes. Many pirates claim they use piracy like shareware (if it's actually good then I'll buy it), but in practice this happens rarely enough that there is no positive "reward the good games" effect. When total sales are lowered, basically the market shrinks and developers and publishers go under, fewer and less-ambitious games are developed. However, since many people who pirate games wouldn't have bought them anyways, the true effects of piracy on sales are impossible to accurately measure.
It looks like the vehicle is designed to have the frame rails under the driver contact the ground under hard braking. If the wheel completely seized up, it would just transfer more weight to the rails, which would transfer weight off of the wheel, making it easier for it to skid. Since the tire isn't a racing slick, its coefficient of friction would be far less than 1.0, so the forces involved would probably be something like 800 pounds or so, although if it happened suddenly it could have quite a jolt. It's not exactly a huge engine, so I'm not sure how much braking torque it could exert if seized.
So as long as the frame was strong enough not to break or fold up under this kind of stress, it might have a good chance of being able to skid to a stop as long as it could keep moving in a straight line. Even if it did break or tip over, I can't see how that would be any worse than being dumped off of a big motorcycle, not that that's a good thing either.
People keep talking in these threads about how OSS needs better documentation...
I "switched" for home use to OS X a couple years ago, and I have been surprised at how crappy Apple's documentation tends to be--there's usually only the briefest printed document, and clicking on "help" usually brings up the global help center with no context-sensitive information, and often doesn't cover fairly major parts of their software. Their developer documentation is also very patchy and disorganized.
The funny thing is that I think this is both a weakness and a strength--Apple tends to have very good UI design, and they probably have the (correct, IMHO) attitude that "if the user needs to look in the manual, it means we screwed up the design".
Another thing that I think is important to understanding why Apple's software is nice to use is that they mostly eschew having a "beginner" and "advanced" mode to their software, which forces the designers to keep things well organized and also means that the developers have to interact with their application much the same way that novice users will (a form of eating your own dog food). It also means that they have to keep the feature set fairly trim, especially the iApps; usually they get about 80% coverage of the features that any one user wants and do it really well--to get that last 20% would require much, much more complexity because everyone has their own "last 20%" of needs/wants. The fact that unlike Microsoft they tend to target home users instead of corporate which allows them to make small but very slick products with what is surely a much, much smaller developer staff.
In some ways, Microsoft is actually more similar in some ways to many open source projects than it is to Apple--they tend to be driven by technological features (dlls are cool, now we can unify all our scripting and embed a spreadsheet inside an address book entry, etc, etc), whereas it feels like at Apple the designers wear the pants, and you can imagine that they went through 300 iterations of the product as just a dummy prototype in InterfaceBuilder to get the buttons just right before even starting to code. Interestingly, apparently when pipes were added to UNIX, one guy spent weeks at the blackboard trying to come up with the right syntax, and once he did Ritchie or whoever it was implemented it in an evening. We still use the syntax while the implementation has surely changed, so you guess which was the hard part!
My last ramble: anyone who's been involved in commercial software developments knows that the "last 10%" of polishing a product from "promising" to "professional" takes at least as long as the other 90%, and even this is only possible if the product has been fairly well designed from the beginning. So assuming that the supply of people working for free (and not for free) on open source projects is constant, achieving the level of polish that these posters desire would require people to work on fewer projects or stick with existing projects longer, both of which tend to run contrary to the desire of programmers to make their "own thing" and to get bored once they've got cool core technology implemented and "mostly" working. People who can see things through that last bit are exceedingly rare and prized in the commercial software world, which is why most software is crap.
If you're still reading this, you're driving too close or at least have too much spare time...
I've also had a similar experience of trying to run as a restricted user in W2K, always having to log in and out as different users to get anything done, some things don't work properly, etc, etc. I much prefer the way OS X handles it, in that you never "log in" as administrator, instead you just temporarily give privilege to one process when installing software or changing system settings. In most UNIX systems, you never log into the GUI as root. Because of this design in OS X, it pretty much forces apps to behave properly, and even casual users will usually understand that having to type in their password meens "something important is happening".
In Windows, it feels like the WINNT user/administrator model has been poorly integrated with the Win95 "wide open" model. I suppose it probably works better in big corporate environments where users are not allowed to install software at all to control tech support costs, and so having them be restricted all the time is fine. However, it works poorly in a home environment where the user and administrator are usually the same person. There doesn't seem to be any obvious reason why MS couldn't add this feature to XP since they already have the "multiple users" feature.
The Xbox can handle games loaded from a DVD-R in UDF format, or even it's special Xbox DVD FAT format (burned as a "normal" disc image) - once it's modded. Why? Because it makes things easier for development. Developmnet Xboxes can be thought of as "half-modded" - developers can sign aps with a developer's key FOR THEIR XDK CONSOLES ONLY. Thus, they can test their releases with burned media (saving the expense of mastering a secure DVD and generating a signature).
Perhaps more accurately, the XDK devkits could "sometimes" boot burned disks (they had to be CD-RW's for some reason), if the blank was perfect, if the phase of the moon was correct, the correct chicken was sacrificed. Sometimes we had to flip the consoles on their backs to get them to boot. To be fair, Microsoft is not the only villain in this regards, as the $10,000 (originally $20K) PS2 devkits still use a $3 1st-gen PS2 DVD drive that tends to be pretty touchy, not to mention the incredibly loud high-pitched whine those things make. Luckily most of console development can be done using data loaded over the network from a PC, so error-prone burns can be postponed until the of the big milestone, and then it gets really exciting. I think GameCube gets the prize for "least coasters"...
The original Dreamcast used a liquid cooling system that was obviously maintenance-free since it was built into a console that children would use and also fairly inexpensive to mass-produce. I think the liquid-cooling was abandoned for the US release due to cost/reliability issues, so maybe it wasn't quite ready for prime time, but clearly it must have been pretty close.
I think it's part of the NIMBY thing--each area doesn't want any through traffic, so they put all those stop signs and the islands that force you to always turn. At least within the city proper you usually can get through on surface roads, but once you get to the suburbs, the street system becomes a bunch of isolated grids that often have *no* connecting roads, so you have to go to the nearest highway, which removes all redundancy from the road system, so each time there is construction everything is totally screwed. Don't even get me started about trying to get around on a bicycle, where often the highways totally cut up the area and it might be a mile or more to the nearest overpass.
It is a tough problem, of course, because everybody wants their street to have only local traffic for children's safety and to cut down on noise. Perhaps if there were more public green spaces at the neighborhood scale this would be less of a problem. However, in its defense, there are some usable surface streets in Minneapolis such as Lyndale in south minneapolis, which lets you bypass most of the crosstown commons cluster-fsck. (Which is also caused by NIMBY, because nobody will give them right of way to put in additional ramps to fix the situation).
Safety of sample return missions?
on
Methane on Mars?
·
· Score: 3, Interesting
If we did find some sort of microbial life on Mars, how confident can we be in our ability to keep it from spreading to Earth until we understand how it works, especially given how even some terrestrial phenomena such as prions have only been identified recently? Any time two ecosystems that have disjoint for a long time come into contact, often one side will "win", such as the mass extinction of South American marsupials or the uncontrolled growth of rabbits in Australia. (I'm also concerned that we may have already contaminated Mars with earthborn bacteria).
The lack of obvious artifacts on Mars makes me doubt that there is or probably has been any kind of sophisticated life, but there's still the chance that their microbes could kick our microbes' collective asses...
I'd feel a little better if the first experiments were done remotely...
What about the 1969 Dodge Charger Superbird with the "nose cone" and huge wing? Admittedly, these things were rare, and I don't think they came with "Type-R" stickers, though...
Spanish is written using a phonetic alphabet, but I don't know how spoken Spanish (and I think we're talking about vocal/subvocal, not written here) is a "proper phonetic" language compared to Chinese... both languages of course have phonemes, although Chinese (which is actually not really a language but a group of related but mutually unintelligible dialects) also has tones. While there are studies that show that people who are literate in phonetic alphabets are more easily able to break words up into their component sounds than non-literates in the same language, I think there is a analogous finding for literates/non-literates in syllable-based writing systems with respect to rhyming ability.
I don't think that illiterate people think differently than literate people, they just probably have less exposure to various written works and are probably better at guessing meanings to fit in to a literate world. People who have no language at all (this happens to deaf people in many parts of the world as well as the much more uncommon feral children) are probably even more stunted in intellectual development due to not being able to really receive ideas from other people, but people who learn language later in life will describe thoughts they had prior to language acquisition...
The worst part about making mistakes is that you have to watch other people repeat them for the rest of your life.
Re:simply translate the binary string
on
The Memory Masters
·
· Score: 1
well, i'm assuming the long binary string would be random or pseudorandom, so unless they choose a poor pseudorandom number generator, compression won't work (you can only achieve lossless compression on a signal that contains patterns of some sort). it would be a weird party trick if someone could learn to do LZW or something in their head, though..
I only know what I just read on the sealand website (I've never even heard of this thing before!), but if they have enough rich clients, I'm guessing an attack on the island would not go unanswered. It sounds like they have defended the island militarily back when it was just some dude hanging out on an island with his wife and kid; now that there might be millions of dollars or more tied up in the island (they don't accept investments of less than US$100,000), the will and resources for military defense seem even more likely. Their investors would be fools if there was no defense budget.
Obviously a top-tier military such as the US could easily blow up the island, but it's close proximity to England and the fact that England currently recognizes the sovereignty of the island might mean that England itself might react to some other nation attacking the island as a threat in their "backyard", much as the US considered the Soviet involvement with Cuba to be a threat.
So I think the main potential threats to Sealand are England and, as long as England remains our bitch, the US. If enough rich people in England and the US come to depend on Sealand in the same way they depend on Switzerland, it would make a military attack there unpopular. It would be very interesting to see what would happen if the US claimed (rightly or wrongly) that "terrorists" were using Sealand...
Also, the value of Sealand is not in it's physical incarnation (how much to a bunch of servers really cost?) but its legal status. Even if it were blown up, they could just build it up again (especially if they had distributed, encrypted backups, with a set of at least three people holding the keys with the usual provisions about never having all members present at the same time, etc...)
Although from this photo
the whole thing looks a little low-rent...
Wow, that's a cool site! I'm no biologist (although I hung out with a bunch in college), but I got sucked into reading some article about the effects of sleep cycles on memory consolidation--obviously I had to skim some of the details due to my background, but I was amazed at how readable the paper was compared to stuff I've seen in more popular sources... although it'd be nice to have real superscript-style footnotes instead of the inline style for readability.
Actually, in any form of auto racing, it is vitally important that the driver have a very good idea of how the car works. Most auto racing events have a practice session before the race--the driver's feedback is vitally important to the crew chief or race engineer to help make the car go fast and handle well at that track at the temperature/humidity/conditions of that day.
During the race, it is very common in many types of racing that various adjustments can be made to the car, either during a pit stop or via in-cockpit adjustments such as anti-roll bars, turbo settings, and brake-bias. While some types of racing allow telemetry, the feedback of the driver is still crucially important.
Another thing a driver must do in a race car is be aware of the condition of the vehicle, and be able to react swiftly and correctly to any change or problem--is the engine running hot, is the car running on fumes, is shock absorber malfunctioning, did that bump in the last turn tear up the air dam too much reducing front downforce, etc.
An analogy that I would draw is that a good programmer must have a pretty good idea of what's going on under the hood even while coding in a high-level language. Even if you code in C++ or Java, you should have a pretty good idea of what the generated machine code (or byte code) will look like, instead of thinking that it's all "magic", the same way a race driver should be able to imagine how the suspension compresses and the tire contact patches load up as he or she rotates the steering wheel and smoothly adds throttle...
Okay, this is a little tough because it's not clear if we're talking latency or throughput... here goes...
One station wagon traveling at 100 mph can reach mars in 350,000 hours (about 40 years, or about 10^9 seconds). During this time, the spirit would have transmitted about 10^13 bytes at 128 kbps, or 10000 Terabytes. Let's say we could cram about 1000 terabytes into a Custom Cruiser, utilizing the "wayback", so that would mean the spirit is the equivalent of 10 station wagons, give or take 1 order of magnitude... probably a more meaningful comparison would say that the spirit can broadcast at the equivalent of 0.25 stationwagons/year
Not too bad, really!
Warning: author is not responsible for silly arithmetic errors or totally invalid assumptions...
for a long time, i watched movies on a 1902, which was the monitor that came with my C-128, a fairly unsuccessful sequel to the C-64, which could run C-64 apps, native 128K apps (in 80 columns!) which were rarer than hen's teeth, and CP/M (a Z80 was also onboard).
I ran the sound through my stereo system, so when watching movies I had pretty good sound and a very tiny (14") but very sharp picture. The main problem was the high-pitched whine those things made.
When I first got it hooked up (I had unearthed it from my parents basement while in college), I had purchased a VCR from K-mart, and I rented some tapes where the top of the picture was all screwed up. I returned and exchanged the VCR, and still had the problem. Right as I was tearing my hair out, I found this little button on the back of the monitor that said "VCR". I pressed the button, and the picture fixed itself! I presume it was some sort of copy protection scheme that was screwing up the picture.
Amazingly, I later found out that _two_ other high school friends had also taken there commodore monitors to college and had the same exact experience with the "VCR" button!
Eventually I sold out my principles and got a real TV after the picture crapped out, and now I've got an InFocus X1 projector, thus losing my membership in the exclusive "computer's screen bigger than TV's screen" club...
I would guess that only a relatively tiny portion of OS X would benefit from things like autovectorization--probably most of the code is passing messages around, blocking on semaphores, writing out display lists to the video card, managing queues, etc, etc. The code that tends to benefit from vector optimizations are the really tight inner loops of 2D graphics routines and audio/video codecs; these are small enough that it may be easier to just vectorize them by hand or with GCC's intrinsics and probably beat the IBM compiler vectorizing "naive" code; and most G4s and above will do most of the pixel-pushing in graphics hardware, anyways. I haven't done much with altivec, but my experience with vector units on a certain other platform has been that if the code wasn't written with vector operations in mind, you can be *slower* overall by vectorizing it, because of the extra overhead of packing things onto 16-byte boundaries, moving between FPU and VU regs and so forth.
It's rare for most other code to be limited by floating-point performance; usually the CPU will spend most of its time blocking on pipeline stalls and cache misses, not ALU. Throw in the risk of having to manage and support separate G3/G4/G5 versions operating system components plus finding and fixing all the problems encountered when switching compilers, and it doesn't look like a very good plan...
I think this discussion is being clouded because people have experience with different-sized projects. If you are working on some fairly small tool which has a well-defined usage, it may be reasonable to rewrite the whole thing from scratch, partly because it is possible to test it fairly thoroughly yourself to verify your new version, and because it is possible to understand the whole thing in your head at one time, and thus make the decision to rewrite rationally.
However, if you're talking about a larger project such as a commercial software application with 50 man-years of development, a complete rewrite will usually be undertaken with a large degree of ignorance of the true problem domain. Also, you can rewrite your codebase to fit more nicely with the *current* state of your specs and requirements, but the new "elegent" design may be even less suitable to tomorrow's new feature request. Even rewriting a major subsystem from scratch can be a costly mistake.
The real trick is how to maintain the code in such a way that it continuously improves instead of just getting more and more riddled with spaghetti, dead code paths, and other clutter. It's especially hard, because it's easy to forget to treat a mature code base with respect, and just hack in "one more" thing because you are hoping to rewrite it at some point.
There is the "broken window" idea--one broken window will lead to an increasing spiral of vandalism, and one line of crud in a source file will give future programmers the feeling that they can add ten more lines of crud because the code is already "dirty". While the usual adage is to clean up the window immediately, the reality is that most source files have one hundred broken windows already and fixing them all right now is not an option. What takes discipline is to make sure to leave each file in a better condition than you left it--remove some dead code, do a little refactoring to clean it up, rename identifiers or reformat code to conform with project-wide standards (NOT your personal pet style!!! This is very annoying when people check out a file, reformat it to their own preference, add one small feature, break some other part of the code, and check it back in to source control...). Another common problem is when people come up with some "new religion", convert about half the code over to the new way, but leaving it in a "worst of both worlds" state because it turns out the "new way" was just "different" and added as many problems as it solved. It is easy to add code that goes against the grain of the existing code because you didn't bother to really understand the system and structure of the code, or because you don't "like" a certain design decision.
In many ways, the real achievement is that higher mental state where you stare at the huge, messy codebase that you've been working with for ages, have the "aha" moment, come up with a simple refactoring, make changes to fifty files, replace hundreds of lines of code with tens of lines, and it just works the first time and only takes a few hours, because for one fleeting instant, you had the whole thing in your head at once. I wish I could have more of those moments.
I'm as guilty as any for violating these ideas--I often keep my nice clean "new" subsystems tidy because they are already tidy and conform to my current design philosophies/religion, but let my big, mature--and often more imporant--subsystems grow increasingly crudified because I have the continuing fantasy that I will be rewriting them from scratch "next project"...
I remember my dad complaining about "too many special pieces" when I was a kid in the 80's. We had some older legos (they're legos, not Lego(R) bricks, dammit!) that were just the simple colored bricks, but the newer "town" and "space" legos had radar dishes, antennae, car bottoms, etc. Also, the small scale of the little lego people means that you really can't make things at the same scale with plain bricks, because the "resolution" is too coarse.
It's clear that having lots of special pieces encourages "collecting" lego sets, whereas once you have a big bag of the older simple bricks you don't crave more of them.
I think the early eighties were the first era of cheap, heavily marketed, "collectible" toys. I've heard that manufacturers actually designed the toys to be not that much fun to play with, so that once you get the toy, you just want more, because the fun is in the acquisition of the latest toy when watching the spinoff cartoon with embedded comercials, not the use.
Also, did anyone else feel really old when the original poster referred to Mindstorm as the toy that was such a mainstay of my childhood? Is he 14 years old or something?
IMHO, the current situation where you check your work mail from home by connecting to pop.work.com, but send mail that's from "user@work.com" through smtp.home.net is not very good--in an ideal world, you would use some sort of secure smtp to send your work mail through your work domain's smtp server, not your home isp's.
While they did have a certain psychological intimidation factor, AT-ATs were eventually abandoned by the Empire in favor of more conventional vehicles. After numerous cost overruns, mechanical failures, poor fuel economy, and a well-publicized "entanglement" fiasco, the controversial giant legged machines were deemed unworkable after sinking hundreds of billions into research and development, and they returned to more conventional wheeled vehicles.
At present time, working AT-ATs are extremely rare, although I did see one of the civilian variants for sale recently on eBay. (these "Atters" were equipped with DVD players and leather seats instead of lasers and armor plating, and were briefly popular with wealthy suburbanites). A gas-electric hybrid version of the smaller AT-ST, co-developed with Honda and aimed at urban drivers, was briefly offered, but sales were disappointing.
The whole point of vacuum tube guitar amps is that the whole signal path is tube--e.g., both preamp and power stage. Most of the nice crunch of a say a Fender Bassman is in the power stages. Furthermore, the interaction between the power amp and the speaker is also important, which is why you typically record a guitar amp with a microphone, not a direct box.
A low-voltage 12AX7 stuffed into a digital stomp box (with a window and an LED that makes it "glow") does not give you "real vintage tube-amp sound", no matter what the "pros" at Guitar Center might tell you!
Next up, the Babbage Analytical Engine on a single chip. No need to carry those bulky logarithm tables around anymore, just a really teeny oil can...
My experience with many companies is that e-mails to support or even sometimes sales accounts just go unanswered for days if at all, whereas a phone call gets a quicker response. I wouldn't mind if they just didn't offer e-mail service, but to post an address on their website that appears to go to/dev/null is very irritating not to mention unprofessional. My guess is that is that they might not have any oversight of the e-mail channel so they just get behind or deluged in spam...
I think one other issue is that for most home computers, there is no clear-cut delineation between user tasks and administrative tasks. One could imagine a computer that arrives with applications pre-installed and the administrative password hidden, but most people expect to be able to install software and change system settings (such as ISP) themselves--I think it is the installing and uninstalling of software and hardware that tends to make computers get screwed up over time, even without intentionally malicious software such as spyware, worms, and viruses. While most users would think twice before installing a PCI card, they wouldn't view plugging in a digital camera or scanner into an external port to be a "dangerous" activity, even though the potential to screw up your system is nearly equal.
Just to beat the car analogy to death, modern cars tend to have a clearly defined separation between "user" tasks and "mechanic" tasks, even to the point of engine covers that only expose the oil, coolant, and washer fluid dipsticks.
However, it's not really clear if things like installing software is part of "operating" a computer--while appliance-style computers (with pre-configured and/or stripped-down FreeBSD or whatever that's totally hidden) are certainly stable and efficient, they are obviously unable to serve everyone's needs at least in their present incarnations.
I think Mac OS X has a pretty good model where the ideal is that applications are self-contained bundles that you can drag wherever and just run without any sort of administrative password, so even without write access to the applications folder you could drag it into the home directory--unfortunately many apps have windows-style installers that require a password and can install who knows what all over your machine. Also, the way in OS X (like in most unices) that you can authorize processes to have administrative access on a case by case basis works better than Windows, where unless you want to be constantly logging out as user and logging in as administrator, most people give their primary account administrative privileges.
I think perhaps a three-tiered privilege system might be useful for systems--e.g., have a password box popup for configuration tasks such as installing software, which would give just enough access to say add and remove folders in the applications folder, or making fairly harmless changes such as TCP/IP settings, without giving the installer root access to the machine, and then a secondary "true root" password that should only be needed for more complex tasks. Also in my fantasy world, drivers for USB (or firewire) devices should be able to run at user privilege through a secure USB API--unlike PCI devices, people are constantly plugging things into USB ports and having to load in new drivers.
Another tack would be a more rigorous OS that gives software components the same type of protection from each other as users get from other users on a modern OS. Ideally "installers" as such wouldn't exist--instead installation would be handled by the OS, which would recognize the package as say a driver or application, and it would create a folder where it could place its stuff, plus of course some sort of versioning system so that if it was installing a different version of a package, it could know how to resolve it. Instead of giving the installer program root access like in OS X, you would instead merely authorize the OS to install one thing to a certain place, so ideally you could install an untrusted application without the possibility of it messing up your system.
I would also like to see any shared modules or libraries that the installed app is dependent on be installed *explicitly*, or at least visibly, as separate steps, so that if the app needs to install a newer version of a component that other apps already depend on, the user could make a choice about whether to install the component globally or just locally to that application--I know at least in Windows you can often just copy a DLL into an
Slashdot Mirror
"But, hell, most of them are still using C or C++: the most backward, cryptic, and unproductive languages imagineable." Games are typically coded in C/C++ because that is currently the best compromise between ease of use and efficiency of generated code. Skilled programmers spend their time solving language-independent software development problems, not battling syntax errors. The previous generation of console games were mostly coded in assembly; on modern consoles assembly is used fairly sparingly. Even C++ is considered too inefficient by many console developers. On a given hardware platform, the more efficient the code, the more graphical detail and behavioral complexity (e.g., physics and ai) can be achieved. Game developers typically write many custom tools to increase productivity, optimize scene data, etc.
"This is because software developers refuse to press for new types of software writing tools that will make it possible to develop a commercial game in 1/10 of the time that it takes today." If we knew of some magical language that would let us develop in 1/10th the time with the same quality we would all use it! The main potential for lowering development time (and thus cost) is the increased use of middleware such as Renderware and pre-made physics engines. However, besides the expense of most of these products, there is also the decreased efficiency and utility of a general "one-size fits all" toolchain instead of a custom, product-specific engine. We make the best guesses we can about how to best achieve our development goals--while we might screw up sometimes, it is inconceivable that we would deliberately avoid any solution that would increase our productivity. Game development is very competetive, and we will do just about anything to get an edge. Use of middleware will probably increase dramatically with the next-generation consoles, especially the PS3, but any savings in development time will be overshadowed by the ever increasing demand for more game complexity, more textures, more complex scene data, more special effects, more animation, more online support, etc, etc.
Piracy won't "force" any improvements in the game development paradigm--the main effect of piracy is to lower the sales of games (when people who would have purchased the game pirate it instead), and to cause developers to spend more time devising anti-piracy schemes. Many pirates claim they use piracy like shareware (if it's actually good then I'll buy it), but in practice this happens rarely enough that there is no positive "reward the good games" effect. When total sales are lowered, basically the market shrinks and developers and publishers go under, fewer and less-ambitious games are developed. However, since many people who pirate games wouldn't have bought them anyways, the true effects of piracy on sales are impossible to accurately measure.
So as long as the frame was strong enough not to break or fold up under this kind of stress, it might have a good chance of being able to skid to a stop as long as it could keep moving in a straight line. Even if it did break or tip over, I can't see how that would be any worse than being dumped off of a big motorcycle, not that that's a good thing either.
The funny thing is that I think this is both a weakness and a strength--Apple tends to have very good UI design, and they probably have the (correct, IMHO) attitude that "if the user needs to look in the manual, it means we screwed up the design".
Another thing that I think is important to understanding why Apple's software is nice to use is that they mostly eschew having a "beginner" and "advanced" mode to their software, which forces the designers to keep things well organized and also means that the developers have to interact with their application much the same way that novice users will (a form of eating your own dog food). It also means that they have to keep the feature set fairly trim, especially the iApps; usually they get about 80% coverage of the features that any one user wants and do it really well--to get that last 20% would require much, much more complexity because everyone has their own "last 20%" of needs/wants. The fact that unlike Microsoft they tend to target home users instead of corporate which allows them to make small but very slick products with what is surely a much, much smaller developer staff.
In some ways, Microsoft is actually more similar in some ways to many open source projects than it is to Apple--they tend to be driven by technological features (dlls are cool, now we can unify all our scripting and embed a spreadsheet inside an address book entry, etc, etc), whereas it feels like at Apple the designers wear the pants, and you can imagine that they went through 300 iterations of the product as just a dummy prototype in InterfaceBuilder to get the buttons just right before even starting to code. Interestingly, apparently when pipes were added to UNIX, one guy spent weeks at the blackboard trying to come up with the right syntax, and once he did Ritchie or whoever it was implemented it in an evening. We still use the syntax while the implementation has surely changed, so you guess which was the hard part!
My last ramble: anyone who's been involved in commercial software developments knows that the "last 10%" of polishing a product from "promising" to "professional" takes at least as long as the other 90%, and even this is only possible if the product has been fairly well designed from the beginning. So assuming that the supply of people working for free (and not for free) on open source projects is constant, achieving the level of polish that these posters desire would require people to work on fewer projects or stick with existing projects longer, both of which tend to run contrary to the desire of programmers to make their "own thing" and to get bored once they've got cool core technology implemented and "mostly" working. People who can see things through that last bit are exceedingly rare and prized in the commercial software world, which is why most software is crap.
If you're still reading this, you're driving too close or at least have too much spare time...
In Windows, it feels like the WINNT user/administrator model has been poorly integrated with the Win95 "wide open" model. I suppose it probably works better in big corporate environments where users are not allowed to install software at all to control tech support costs, and so having them be restricted all the time is fine. However, it works poorly in a home environment where the user and administrator are usually the same person. There doesn't seem to be any obvious reason why MS couldn't add this feature to XP since they already have the "multiple users" feature.
Here is one source.
It is a tough problem, of course, because everybody wants their street to have only local traffic for children's safety and to cut down on noise. Perhaps if there were more public green spaces at the neighborhood scale this would be less of a problem. However, in its defense, there are some usable surface streets in Minneapolis such as Lyndale in south minneapolis, which lets you bypass most of the crosstown commons cluster-fsck. (Which is also caused by NIMBY, because nobody will give them right of way to put in additional ramps to fix the situation).
The lack of obvious artifacts on Mars makes me doubt that there is or probably has been any kind of sophisticated life, but there's still the chance that their microbes could kick our microbes' collective asses...
I'd feel a little better if the first experiments were done remotely...
What about the 1969 Dodge Charger Superbird with the "nose cone" and huge wing? Admittedly, these things were rare, and I don't think they came with "Type-R" stickers, though...
I don't think that illiterate people think differently than literate people, they just probably have less exposure to various written works and are probably better at guessing meanings to fit in to a literate world. People who have no language at all (this happens to deaf people in many parts of the world as well as the much more uncommon feral children) are probably even more stunted in intellectual development due to not being able to really receive ideas from other people, but people who learn language later in life will describe thoughts they had prior to language acquisition...
The worst part about making mistakes is that you have to watch other people repeat them for the rest of your life.
well, i'm assuming the long binary string would be random or pseudorandom, so unless they choose a poor pseudorandom number generator, compression won't work (you can only achieve lossless compression on a signal that contains patterns of some sort). it would be a weird party trick if someone could learn to do LZW or something in their head, though..
Obviously a top-tier military such as the US could easily blow up the island, but it's close proximity to England and the fact that England currently recognizes the sovereignty of the island might mean that England itself might react to some other nation attacking the island as a threat in their "backyard", much as the US considered the Soviet involvement with Cuba to be a threat.
So I think the main potential threats to Sealand are England and, as long as England remains our bitch, the US. If enough rich people in England and the US come to depend on Sealand in the same way they depend on Switzerland, it would make a military attack there unpopular. It would be very interesting to see what would happen if the US claimed (rightly or wrongly) that "terrorists" were using Sealand...
Also, the value of Sealand is not in it's physical incarnation (how much to a bunch of servers really cost?) but its legal status. Even if it were blown up, they could just build it up again (especially if they had distributed, encrypted backups, with a set of at least three people holding the keys with the usual provisions about never having all members present at the same time, etc...)
Although from this photo the whole thing looks a little low-rent...
Definitely going into my bookmarks!
During the race, it is very common in many types of racing that various adjustments can be made to the car, either during a pit stop or via in-cockpit adjustments such as anti-roll bars, turbo settings, and brake-bias. While some types of racing allow telemetry, the feedback of the driver is still crucially important.
Another thing a driver must do in a race car is be aware of the condition of the vehicle, and be able to react swiftly and correctly to any change or problem--is the engine running hot, is the car running on fumes, is shock absorber malfunctioning, did that bump in the last turn tear up the air dam too much reducing front downforce, etc.
An analogy that I would draw is that a good programmer must have a pretty good idea of what's going on under the hood even while coding in a high-level language. Even if you code in C++ or Java, you should have a pretty good idea of what the generated machine code (or byte code) will look like, instead of thinking that it's all "magic", the same way a race driver should be able to imagine how the suspension compresses and the tire contact patches load up as he or she rotates the steering wheel and smoothly adds throttle...
One station wagon traveling at 100 mph can reach mars in 350,000 hours (about 40 years, or about 10^9 seconds). During this time, the spirit would have transmitted about 10^13 bytes at 128 kbps, or 10000 Terabytes. Let's say we could cram about 1000 terabytes into a Custom Cruiser, utilizing the "wayback", so that would mean the spirit is the equivalent of 10 station wagons, give or take 1 order of magnitude... probably a more meaningful comparison would say that the spirit can broadcast at the equivalent of 0.25 stationwagons/year
Not too bad, really!
Warning: author is not responsible for silly arithmetic errors or totally invalid assumptions...
I ran the sound through my stereo system, so when watching movies I had pretty good sound and a very tiny (14") but very sharp picture. The main problem was the high-pitched whine those things made.
When I first got it hooked up (I had unearthed it from my parents basement while in college), I had purchased a VCR from K-mart, and I rented some tapes where the top of the picture was all screwed up. I returned and exchanged the VCR, and still had the problem. Right as I was tearing my hair out, I found this little button on the back of the monitor that said "VCR". I pressed the button, and the picture fixed itself! I presume it was some sort of copy protection scheme that was screwing up the picture.
Amazingly, I later found out that _two_ other high school friends had also taken there commodore monitors to college and had the same exact experience with the "VCR" button!
Eventually I sold out my principles and got a real TV after the picture crapped out, and now I've got an InFocus X1 projector, thus losing my membership in the exclusive "computer's screen bigger than TV's screen" club...
It's rare for most other code to be limited by floating-point performance; usually the CPU will spend most of its time blocking on pipeline stalls and cache misses, not ALU. Throw in the risk of having to manage and support separate G3/G4/G5 versions operating system components plus finding and fixing all the problems encountered when switching compilers, and it doesn't look like a very good plan...
However, if you're talking about a larger project such as a commercial software application with 50 man-years of development, a complete rewrite will usually be undertaken with a large degree of ignorance of the true problem domain. Also, you can rewrite your codebase to fit more nicely with the *current* state of your specs and requirements, but the new "elegent" design may be even less suitable to tomorrow's new feature request. Even rewriting a major subsystem from scratch can be a costly mistake.
The real trick is how to maintain the code in such a way that it continuously improves instead of just getting more and more riddled with spaghetti, dead code paths, and other clutter. It's especially hard, because it's easy to forget to treat a mature code base with respect, and just hack in "one more" thing because you are hoping to rewrite it at some point.
There is the "broken window" idea--one broken window will lead to an increasing spiral of vandalism, and one line of crud in a source file will give future programmers the feeling that they can add ten more lines of crud because the code is already "dirty". While the usual adage is to clean up the window immediately, the reality is that most source files have one hundred broken windows already and fixing them all right now is not an option. What takes discipline is to make sure to leave each file in a better condition than you left it--remove some dead code, do a little refactoring to clean it up, rename identifiers or reformat code to conform with project-wide standards (NOT your personal pet style!!! This is very annoying when people check out a file, reformat it to their own preference, add one small feature, break some other part of the code, and check it back in to source control...). Another common problem is when people come up with some "new religion", convert about half the code over to the new way, but leaving it in a "worst of both worlds" state because it turns out the "new way" was just "different" and added as many problems as it solved. It is easy to add code that goes against the grain of the existing code because you didn't bother to really understand the system and structure of the code, or because you don't "like" a certain design decision.
In many ways, the real achievement is that higher mental state where you stare at the huge, messy codebase that you've been working with for ages, have the "aha" moment, come up with a simple refactoring, make changes to fifty files, replace hundreds of lines of code with tens of lines, and it just works the first time and only takes a few hours, because for one fleeting instant, you had the whole thing in your head at once. I wish I could have more of those moments.
I'm as guilty as any for violating these ideas--I often keep my nice clean "new" subsystems tidy because they are already tidy and conform to my current design philosophies/religion, but let my big, mature--and often more imporant--subsystems grow increasingly crudified because I have the continuing fantasy that I will be rewriting them from scratch "next project"...
It's clear that having lots of special pieces encourages "collecting" lego sets, whereas once you have a big bag of the older simple bricks you don't crave more of them.
I think the early eighties were the first era of cheap, heavily marketed, "collectible" toys. I've heard that manufacturers actually designed the toys to be not that much fun to play with, so that once you get the toy, you just want more, because the fun is in the acquisition of the latest toy when watching the spinoff cartoon with embedded comercials, not the use.
Also, did anyone else feel really old when the original poster referred to Mindstorm as the toy that was such a mainstay of my childhood? Is he 14 years old or something?
IMHO, the current situation where you check your work mail from home by connecting to pop.work.com, but send mail that's from "user@work.com" through smtp.home.net is not very good--in an ideal world, you would use some sort of secure smtp to send your work mail through your work domain's smtp server, not your home isp's.
At present time, working AT-ATs are extremely rare, although I did see one of the civilian variants for sale recently on eBay. (these "Atters" were equipped with DVD players and leather seats instead of lasers and armor plating, and were briefly popular with wealthy suburbanites). A gas-electric hybrid version of the smaller AT-ST, co-developed with Honda and aimed at urban drivers, was briefly offered, but sales were disappointing.
A low-voltage 12AX7 stuffed into a digital stomp box (with a window and an LED that makes it "glow") does not give you "real vintage tube-amp sound", no matter what the "pros" at Guitar Center might tell you!
Next up, the Babbage Analytical Engine on a single chip. No need to carry those bulky logarithm tables around anymore, just a really teeny oil can...
My experience with many companies is that e-mails to support or even sometimes sales accounts just go unanswered for days if at all, whereas a phone call gets a quicker response. I wouldn't mind if they just didn't offer e-mail service, but to post an address on their website that appears to go to /dev/null is very irritating not to mention unprofessional. My guess is that is that they might not have any oversight of the e-mail channel so they just get behind or deluged in spam...
Just to beat the car analogy to death, modern cars tend to have a clearly defined separation between "user" tasks and "mechanic" tasks, even to the point of engine covers that only expose the oil, coolant, and washer fluid dipsticks. However, it's not really clear if things like installing software is part of "operating" a computer--while appliance-style computers (with pre-configured and/or stripped-down FreeBSD or whatever that's totally hidden) are certainly stable and efficient, they are obviously unable to serve everyone's needs at least in their present incarnations.
I think Mac OS X has a pretty good model where the ideal is that applications are self-contained bundles that you can drag wherever and just run without any sort of administrative password, so even without write access to the applications folder you could drag it into the home directory--unfortunately many apps have windows-style installers that require a password and can install who knows what all over your machine. Also, the way in OS X (like in most unices) that you can authorize processes to have administrative access on a case by case basis works better than Windows, where unless you want to be constantly logging out as user and logging in as administrator, most people give their primary account administrative privileges.
I think perhaps a three-tiered privilege system might be useful for systems--e.g., have a password box popup for configuration tasks such as installing software, which would give just enough access to say add and remove folders in the applications folder, or making fairly harmless changes such as TCP/IP settings, without giving the installer root access to the machine, and then a secondary "true root" password that should only be needed for more complex tasks. Also in my fantasy world, drivers for USB (or firewire) devices should be able to run at user privilege through a secure USB API--unlike PCI devices, people are constantly plugging things into USB ports and having to load in new drivers.
Another tack would be a more rigorous OS that gives software components the same type of protection from each other as users get from other users on a modern OS. Ideally "installers" as such wouldn't exist--instead installation would be handled by the OS, which would recognize the package as say a driver or application, and it would create a folder where it could place its stuff, plus of course some sort of versioning system so that if it was installing a different version of a package, it could know how to resolve it. Instead of giving the installer program root access like in OS X, you would instead merely authorize the OS to install one thing to a certain place, so ideally you could install an untrusted application without the possibility of it messing up your system.
I would also like to see any shared modules or libraries that the installed app is dependent on be installed *explicitly*, or at least visibly, as separate steps, so that if the app needs to install a newer version of a component that other apps already depend on, the user could make a choice about whether to install the component globally or just locally to that application--I know at least in Windows you can often just copy a DLL into an