If you want reliability, look at what NASA has produced. Those are some engineers. Ahh, but you said 'quickly', didn't you?:-) If you want something rock solid, you can't have it tomorrow, if you want it to do anything remotely complex.
I disagree. That might be true in many cases, but some of the truly great engineering feats were produced quickly by a small team of very, very good people. A classic example is the Lockheed Skunk Works under Kelly Johnson. The SR-71 was conceived in the late 1950s, yet has performance numbers that are unequalled even today. Even more amazing, it was designed and built by just a handful of people. Compare that with the thousands of people it takes to build a new military aircraft these days. Other examples of the Skunk Works' prowess include the P-80 (USA's first operational jet fighter), the U-2 (high-altitude spy plane), F-104 (first mach 2+ jet fighter), etc.
The moral of the story is you can perform very high quality engineering in a very short time (the P-80 took something like 140 days to design and prototype!!) if you have an incredible team with no red tape in the way. Unfortunately, this is rare.
you're kidding yourself if you think Java keeps you from having memory leaks, and I have enterprise code to prove it
Um. That was his whole point - bad engineers will always be bad engineers, no matter what the language. Java prevents an entire class of memory leaks by garbage-collecting unreferenced objects, but there's nothing in the language that stops you from doing something stupid like writing an unbounded cache.
I'd say one of the biggest advances of the past decade or two has been the proliferation of standard libraries, like the STL or Java's immense class library.
IMHO, one of the keys to writing good software is to not write very much software. Class libraries like the one in Java are almost invariably more feature-complete, more reliable, and better tested than roll-your-own libraries. Using existing libraries means you don't have to worry about off-by-one errors in your linked list implementation, or figuring out a good hash key for your string. While I think that all coders should know how to solve these problems, they shouldn't have to as part of their daily life. It's busywork, and giant class libraries do a wonderful job of making life easier. They let you concentrate on the important stuff - the algorithms, and marketing's feature of the week.
Yes, libraries have been around for more than a decade. The STL and Java both showed up in the mid 90's, though, and I'd argue they've made a huge difference since then. Yes, they have bugs. Yes, there have been other advances. Yes, there are special cases where standard libraries aren't appropriate. There's no silver bullet, but standard libraries are a huge advance.
Glide ratio comparisons
on
Fanwing Planes?
·
· Score: 5, Informative
For comparison, a Cessna 172 has a glide ratio of about 9:1, which means you can cover 9 miles of ground for every mile of altitude. Mooney - whose aircraft are legendary for not wanting to come out of the sky - builds planes with a glide ratio of 10:1 to about 15:1. Sailplanes can have about a 50:1 ratio. Believe it or not, the Boeing 747 has about a 15:1 ratio. The space shuttle has about a 1:1 ratio.
In sum, with a glide ratio of 2:1 or 3:1, you don't want to lose power in a fanwing. Let's hope they're successful in increasing it.
Re:Check your toy store for even later versions
on
Fanwing Planes?
·
· Score: 2
Are you sure? Testors, for example, released their "F-19 Stealth Fighter" with much fanfare in 1986, back before the F-117, B-2, Have Blue, etc were made public. The F-19 model looked nothing like the stealth aircraft that were later made public, and it turns out there's no such thing as an F-19.
Testors released models of the F-117 *after* it was made public, I'm fairly sure. Same goes for the other manufacturers.
(Of course, the "F-19" is still a bit of a mystery - maybe it's real after all. But I doubt it.)
HP/lift: fanwing vs. cessna
on
Fanwing Planes?
·
· Score: 5, Informative
For comparison, the current model of the Cessna 172 (single piston engine 4-place general aviation aircraft) has a 160HP engine with a max takeoff weight of 2450lbs. The max useful load (which includes fuel, I think) is 837lbs. Cruise speed is 122kts, which is about 230kph.
Does the 2 tons that the fanwing can lift include the weight of the craft, fuel, etc. or is that 2 tons of cargo? The site is down...
The original Divx was a Circuit City-backed DVD rental system that relied on proprietary hardware. More info here.
These days, Divx is an MPEG-4 encoding/format thingy pushed by DivxNetworks. It has no relation to the Circuit City version.
To make matters worse, there was a cracked Microsoft MP4(?) codec floating around a few years ago that was called DivX or DivX:) or something; it's not related to either of the other Divxes AFAIK.
26 letters in the alphabet = 456,976 different 4-letter combinations, and all of those clowns had to pick the same 4 letters in the same order. grrrr
As a mac user, I don't care. Movielink sounds awful, and Netflix is way cooler anyway.
I'm sure there are plenty of "big picture" reasons why this is bad - no mac support for other stuff like encrypted CDs, etc - but I'm going to ignore those for now and continue to be narrow-minded about this, since it's Monday and you can't stop me. To me, this article is like saying "Divx not supported on macs" - it will be met with a resounding chorus of "so what?"
(No, not that Divx. The original one. Who was the jackass that thought it would be a good idea to name a codec after the Circuit City fiasco, anyway?)
At the risk of sounding like a troll, do you have a better idea? Seriously, I don't know much about the space program, and the Saturn V seemed to get the job done for a lot less than the current shuttle costs (let alone the cost of a new one). SSTO is a nice dream, but it seems to me that tried-and-true is what we need right now.
And how could we forget the Naked Mole Rat's reports over at MacEdition? He's the grand-daddy of all rumormongers; he got his start as Mac the Knife way back when MacWeek was still around.
IOW, the generated code is not used by humans. If so, then why use Java as the info transfer mechanism? (This question is raised in a nearby reply.)
I'll answer the other reply here, too.
The generated code IS used by humans. Perhaps more importantly, the generated code is used by other systems that speak a certain format, like SQL.
For example, start with a simple chunk of data: a "user." It has a username and a password. Your data definition might look like this:
user { String username String password }
That's about as concise as I can get without losing human readability (which is a requirement for the data definition). Now, you probably want to manipulate that data at some point. Say you want to manipulate it in Java, because you're stuck with a shop full of Java engineers. You need a java class file:
public class user { private String username; public getUsername() {return username;} public setUsername(String u) {username=u;} [...] }
You also want to store that data in an RDBMS from Java. Assume you want to do it simplistically, no EJB or anything:
public class UserPersister { public storeUser(User u) { connection c = getDBConnection(); c.execute("insert into user username=" + u.getuserName() + ", password=" + u.getPassword()); } }
Of course, your object isn't much good unless you can display on a screen somewhere (say as part of a webapp). You need a servlet or a JSP or something (I don't care what) to display that object:
Writing all of that stuff by hand sucks. So I make the computer do it for me, based on my data definition. I never have to touch the generated code (in fact, it's not allowed). That doesn't mean it's useless, though - the generated stuff still does things, and it gives other programmers familiar and always-up-to-date tools to work with.
It sounds like your approach is to make tools that understand the data definition directly, which is a valid approach. They're just two different solutions to the same problem. I like code generators because they spit out stuff that other people can work with without any understanding of the data definition, or how to use/abuse it. As you said, the tools just aren't there for table-driven code right now. And what happens when you have to switch DBs/storage paradigms?
I prefer to store UI field info in tables (AKA "data dictionary" or "field dictionary".) These tables then generate the UI's as needed.
IMO, code generators are evil. You are going from a compact representation of attributes to a less compact representation (code). IOW, bad information factoring. It is like entering and management spreadsheet data via XML instead of a grid.
Um. So is it good or bad to generate stuff? You can't have it both ways. Your compiler is a code generator, like it or not. You go from a compact representation of information (C, Java, whatever) to a less-compact version (asm/0s and 1s) that the computer can understand.
Furthermore, the compact representation of the information that's provided as input to the generator is the goal! It sounds like we agree - compact good, big piles of code bad. The code generator lets you make one tidy little file - your data definition - that the generator then blows out into the various APIs that other components need. You still have the piles of code, but you don't have to think/worry about them, because they're always there and they always "just work.".
Sure, it would be nice if we didn't need to generate any code and we could just operate on the data itself, but there are real-world considerations that make that difficult. RDBMSes talk SQL, browsers talk HTML, and there's a bunch of stuff in between. You still have to get from the UI to the DB, and you can either write that code yourself, or have the computer do it for you. By defining the data and then transforming the data definition (via code generation or other method), you can have your cake and eat it.
(And yes, I hate getters/setters too, but they're only about 1% of the stuff you can actually generate)
The fact that 1.4 is 60% bigger than 1.3 is a reason *to* use individual imports, not a reason not to. That's what, 1000 new classes to keep track of? How do I know that the Document in your file is an XML document + not a swing text one? It's a lot easier to grep for "Document" and have it pop up in the import statement then have to play guessing games about which classes are in which packages. (Yes, I know that you'd have to be explicit if you have 2 classes with the same name in different packages. That's not my point).
Individual imports are a real pain in the butt to code. They're a huge help for the next guy, though. Maintenance programmers usually don't know the modules they're working on well. This means they're not sure whether your JPanel is really a javax.swing.JPanel, or the custom com.foo.JPanel that's buried in an inner class 3000 lines into your file. They're often not familiar with APIs, either (senior guys usually write new code, they don't maintain it).
I agree that for a book maybe individual imports aren't the best idea, but in the Real World they're incredibly useful. Remember, it's not for you - it's for the other guy.
Most J2EE apps are terribly flawed from a maintenance and flexibility standpoint.
Why? There's a fundamental issue at stake that Sun has partially solved, but not completely: What your application does should have nothing to do with how it does it.
For example, take the "bank account" app that I've seen used as a tutorial in many places. Customers can have one or more accounts, and they can perform operations on those accounts (deposit, withdraw, transfer). The code necessary for those operations is trivial. It's the support code that makes writing enterprise apps so difficult. At the minimum, you need:
A database schema
Code to read/write the DB in a transaction-safe manner
Presentation code (webapp, could be something else)
You'll probably want to expose a few other interfaces, like an API for your app to be used on a message bus so other apps can access it.
It sucks to have to write all of that extra code. It gets even worse if you have to modify your app (add/delete fields, features, etc). Sun is slowly chipping away pieces of the problem (EJB sort-of makes persistence easy, unless you need stored procs, etc), but they haven't solved one of the big the underlying issues:
The application has data that can exist in multiple representations. Each representation requires work to make sure it's always in sync with the rest of the representations.
There's an easy way out - define your data, and let the computer generate the different representations for you. While you're at it, have the computer write the code that can convert data in one format to another format. This is obvious for things like going from one XML format to another, but not so obvious when trying to convert a web form into a java object, or a java object into a database record.
By defining your data and using code generators or other automation techniques (reflection) to create those different representations, you can slash maintenance costs, time to add new features, etc. Want to add a new field to an object? Update the canonical representation of the object, and presto, your entire app supports it, from the web UI down to the DB schema. Want to add a new data format? Write a generator for it, and all of your objects automatically support that new format.
The overhead is higher at first, but it pays off incredibly quickly. On my last project we saved many many man-years by doing this. Check out thesandbossproject for an LGPL set of tools to help out with this, based on the SAND architecture.
(Yes, I've glossed over about a zillion issues. It's not that I havent thought of them, it's that the problems are solvable. The main point is that your data representations should always be in sync with each other, without your lifting a finger. And no, UML doesn't quite get you there yet).
It should be 3.0: here's why
on
Linux Kernel 3.0?
·
· Score: 5, Funny
There's no 2.6 in the list of What Software Version Numbers Really Mean, so obviously it can't be 2.6. Therefore it must be at least 3.0. In fact, I'm stil confused as to how a 2.4 release got out.
The "one mouse, multiple computers" trick has been around since at least 1992, when Jorg Brown and Eric Hayes whipped it up for MacHack (search for "NetMouse"). It was a fantastic hack - it really did make life easier when working with multiple computers. I don't think it let you drag + drop files between desktops (hey, it was 1992!), but it's certainly a logical evolution.
Sure there are other ways to move files around (hey, use Zmodem if you want!) but in general, easier is better.
Gimme a break....you're pulling the straw man routine. The 1/4" was an example; the car will still work just fine, and the weather stripping will keep out the water. The door won't look right, that's all. Trust me on this, my car has this exact defect but has managed to stay dry.
You make some good points about cost - American industry is saddled by an absurd health care system, etc. There are a zillion different factors that determine the cost of everything (like advertising! ha! you don't know much about industry if you didn't mention advertising!) that I deliberately overlooked because, well, this is slashdot, not a graduate thesis. I think we're both in agreement that software is comparatively cheap.
Ever buy a car, or even look at the price tag of a car? It's *at least* $10,000 USD, these days more like $25-30k for one with a few bells + whistles. Show me a piece of consumer software that costs anywhere near that much.
Now, some people will argue that a car is much more complex than a piece of software, and it certainly has a higher raw material cost. I'd agree with the latter, but not the former. Software is immensely complex, and software engineering usually doesn't have the benefit of tolerances. A door panel on a car can be 1/4" too small and the car will still work. You can't really do that in software; the software will break if everything isn't exactly right. That type of precision takes a hell of a lot of time/effort/etc. How much does GM spend to develop a new car? Billions. And they're still more expensive than an operating system, which is at least as complex. Given the amount of stuff that went into it, Windows XP is a bargain at only $99 or whatever (usability considerations aside). And then there's Linux....
One-off software is significantly more expensive than consumer software, but even there it's cheap when compared to the rest of the world. Want a custom car? What does that cost? (Hint: a lot, for any kind of quality). Or how about a custom dump truck for your mining operation? A custom or low-volume piece of software can run $10k-$1M or more, depending on what it is. Even those prices are on par for custom vehicles. While those numbers represent a lot of money to me, that's not a lot in the grand scheme of things. Software is damn cheap, especially when you consider the benefits it can provide (like the spreadsheet....VisiCalc + its followers literally changed the world).
I don't think software costs a lot. That said, I'm sure it can be made more cheaply + reliably given better tools. The same thing is true for every industry.
The really important part here is that Apple would be using a new bus with these machines. What the bus is doesn't matter so much as the fact that it's not the Maxbus, which is what the G4 and its ilk use. Maxbus is designed for routers + other embedded apps, not high-performance desktop computers. Currently Maxbus runs at 167Mhz, which is about as far as Motorola is willing to push it (167Mhz single-pumped, mind you). As a result, even a single G4 can more than saturate the bus, and the dualies spend a *lot* of time idling (they share one memory bus). Big caches help the problem, but there's still a fundamental issue.
Even if the new chips are clock-for-clock identical to the current G4, the mere fact that they're running on a newer bus will make the machines much more powerful.
For more info about this, head over to Ars and check out the posts in the Mac Achaia by BadAndy from earlier this summer ("Altivec, anyone?" I think it was titled). He knows a hell of a lot more about this stuff than I do; it makes for fascinating reading, and you can really understand why faster CPUs alone won't cut it for Apple.
Take a look at SAND, which is an approach to enterprise app development that solves most of these problems by making heavy use of code generation. Unlike most projects where the code is generated up front and then modified by hand, SAND puts code generation into the build cycle of the product so the code and model are always in sync (if you're going to complain that this makes the build take longer, don't. Trust me, it's better this way).
There's an open-source implementation of SAND called Sandboss that's getting off the ground; while it's still missing pieces, it's rapidly becoming functional (most of the generators are in place already, so take a look). The prepackaged version is out-of-date, so look at the CVS tree.
Right now there's no UML-to-SAND tool or any kind of visual editor, so you'll have to spec your objects as you go. It's a lot easier than it sounds.
Disclaimer: I'm working on sandboss because it kicks ass. I used a previous incarnation at my last job, and it saved literally man-years of development.
Also, it's my personal preference, but I don't want to have to wade through line after line of comments to find that the person who checked in the source file wrote:
if (n = 0)
instead of
if (n == 0)
That's a good example of why more + better comments are necessary. Perhaps the author meant to write "if (n = 0)". Without some indication of intent, nobody knows which is correct without some detective work. The comments are there to verify that the code wasn't mistyped. As a professional developer, I'd rather know for sure what the code is supposed to do than have to guess (and potentially introduce a regression if I guess wrong).
In a similar vein, take a look at the Sandboss project . It's an open-source implementation of something called "Structs and Nodes Development"; it makes heavy use of javadoc + code generators to drastically simplify programming large distributed systems.
While the implementation isn't complete (yet), the concept works amazingly well (I used a previous iteration at my last job) and saves literally man-years of development on large projects. Very cool stuff...
Slashdot Mirror
I disagree. That might be true in many cases, but some of the truly great engineering feats were produced quickly by a small team of very, very good people. A classic example is the Lockheed Skunk Works under Kelly Johnson. The SR-71 was conceived in the late 1950s, yet has performance numbers that are unequalled even today. Even more amazing, it was designed and built by just a handful of people. Compare that with the thousands of people it takes to build a new military aircraft these days. Other examples of the Skunk Works' prowess include the P-80 (USA's first operational jet fighter), the U-2 (high-altitude spy plane), F-104 (first mach 2+ jet fighter), etc.
The moral of the story is you can perform very high quality engineering in a very short time (the P-80 took something like 140 days to design and prototype!!) if you have an incredible team with no red tape in the way. Unfortunately, this is rare.
Um. That was his whole point - bad engineers will always be bad engineers, no matter what the language. Java prevents an entire class of memory leaks by garbage-collecting unreferenced objects, but there's nothing in the language that stops you from doing something stupid like writing an unbounded cache.
IMHO, one of the keys to writing good software is to not write very much software. Class libraries like the one in Java are almost invariably more feature-complete, more reliable, and better tested than roll-your-own libraries. Using existing libraries means you don't have to worry about off-by-one errors in your linked list implementation, or figuring out a good hash key for your string. While I think that all coders should know how to solve these problems, they shouldn't have to as part of their daily life. It's busywork, and giant class libraries do a wonderful job of making life easier. They let you concentrate on the important stuff - the algorithms, and marketing's feature of the week.
Yes, libraries have been around for more than a decade. The STL and Java both showed up in the mid 90's, though, and I'd argue they've made a huge difference since then. Yes, they have bugs. Yes, there have been other advances. Yes, there are special cases where standard libraries aren't appropriate. There's no silver bullet, but standard libraries are a huge advance.
In sum, with a glide ratio of 2:1 or 3:1, you don't want to lose power in a fanwing. Let's hope they're successful in increasing it.
Testors released models of the F-117 *after* it was made public, I'm fairly sure. Same goes for the other manufacturers.
(Of course, the "F-19" is still a bit of a mystery - maybe it's real after all. But I doubt it.)
Does the 2 tons that the fanwing can lift include the weight of the craft, fuel, etc. or is that 2 tons of cargo? The site is down...
These days, Divx is an MPEG-4 encoding/format thingy pushed by DivxNetworks. It has no relation to the Circuit City version.
To make matters worse, there was a cracked Microsoft MP4(?) codec floating around a few years ago that was called DivX or DivX :) or something; it's not related to either of the other Divxes AFAIK.
26 letters in the alphabet = 456,976 different 4-letter combinations, and all of those clowns had to pick the same 4 letters in the same order. grrrr
I'm sure there are plenty of "big picture" reasons why this is bad - no mac support for other stuff like encrypted CDs, etc - but I'm going to ignore those for now and continue to be narrow-minded about this, since it's Monday and you can't stop me. To me, this article is like saying "Divx not supported on macs" - it will be met with a resounding chorus of "so what?"
(No, not that Divx. The original one. Who was the jackass that thought it would be a good idea to name a codec after the Circuit City fiasco, anyway?)
At the risk of sounding like a troll, do you have a better idea? Seriously, I don't know much about the space program, and the Saturn V seemed to get the job done for a lot less than the current shuttle costs (let alone the cost of a new one). SSTO is a nice dream, but it seems to me that tried-and-true is what we need right now.
As The Apple Turns is another excellent site for commentary and rumors.
And how could we forget the Naked Mole Rat's reports over at MacEdition? He's the grand-daddy of all rumormongers; he got his start as Mac the Knife way back when MacWeek was still around.
1. Give away course material
2. ???
3. Profit!
What do you mean, "would have?" It sounds like they DID catch the bug, and they even caught it in the field. heh.
I'll answer the other reply here, too.
The generated code IS used by humans. Perhaps more importantly, the generated code is used by other systems that speak a certain format, like SQL.
For example, start with a simple chunk of data: a "user." It has a username and a password. Your data definition might look like this:
That's about as concise as I can get without losing human readability (which is a requirement for the data definition). Now, you probably want to manipulate that data at some point. Say you want to manipulate it in Java, because you're stuck with a shop full of Java engineers. You need a java class file:
You also want to store that data in an RDBMS from Java. Assume you want to do it simplistically, no EJB or anything:Of course, your object isn't much good unless you can display on a screen somewhere (say as part of a webapp). You need a servlet or a JSP or something (I don't care what) to display that object:Writing all of that stuff by hand sucks. So I make the computer do it for me, based on my data definition. I never have to touch the generated code (in fact, it's not allowed). That doesn't mean it's useless, though - the generated stuff still does things, and it gives other programmers familiar and always-up-to-date tools to work with.It sounds like your approach is to make tools that understand the data definition directly, which is a valid approach. They're just two different solutions to the same problem. I like code generators because they spit out stuff that other people can work with without any understanding of the data definition, or how to use/abuse it. As you said, the tools just aren't there for table-driven code right now. And what happens when you have to switch DBs/storage paradigms?
IMO, code generators are evil. You are going from a compact representation of attributes to a less compact representation (code). IOW, bad information factoring. It is like entering and management spreadsheet data via XML instead of a grid.
Um. So is it good or bad to generate stuff? You can't have it both ways. Your compiler is a code generator, like it or not. You go from a compact representation of information (C, Java, whatever) to a less-compact version (asm/0s and 1s) that the computer can understand.
Furthermore, the compact representation of the information that's provided as input to the generator is the goal! It sounds like we agree - compact good, big piles of code bad. The code generator lets you make one tidy little file - your data definition - that the generator then blows out into the various APIs that other components need. You still have the piles of code, but you don't have to think/worry about them, because they're always there and they always "just work.".
Sure, it would be nice if we didn't need to generate any code and we could just operate on the data itself, but there are real-world considerations that make that difficult. RDBMSes talk SQL, browsers talk HTML, and there's a bunch of stuff in between. You still have to get from the UI to the DB, and you can either write that code yourself, or have the computer do it for you. By defining the data and then transforming the data definition (via code generation or other method), you can have your cake and eat it.
(And yes, I hate getters/setters too, but they're only about 1% of the stuff you can actually generate)
Individual imports are a real pain in the butt to code. They're a huge help for the next guy, though. Maintenance programmers usually don't know the modules they're working on well. This means they're not sure whether your JPanel is really a javax.swing.JPanel, or the custom com.foo.JPanel that's buried in an inner class 3000 lines into your file. They're often not familiar with APIs, either (senior guys usually write new code, they don't maintain it).
I agree that for a book maybe individual imports aren't the best idea, but in the Real World they're incredibly useful. Remember, it's not for you - it's for the other guy.
Why? There's a fundamental issue at stake that Sun has partially solved, but not completely: What your application does should have nothing to do with how it does it.
For example, take the "bank account" app that I've seen used as a tutorial in many places. Customers can have one or more accounts, and they can perform operations on those accounts (deposit, withdraw, transfer). The code necessary for those operations is trivial. It's the support code that makes writing enterprise apps so difficult. At the minimum, you need:
You'll probably want to expose a few other interfaces, like an API for your app to be used on a message bus so other apps can access it.
It sucks to have to write all of that extra code. It gets even worse if you have to modify your app (add/delete fields, features, etc). Sun is slowly chipping away pieces of the problem (EJB sort-of makes persistence easy, unless you need stored procs, etc), but they haven't solved one of the big the underlying issues:
The application has data that can exist in multiple representations. Each representation requires work to make sure it's always in sync with the rest of the representations.
There's an easy way out - define your data, and let the computer generate the different representations for you. While you're at it, have the computer write the code that can convert data in one format to another format. This is obvious for things like going from one XML format to another, but not so obvious when trying to convert a web form into a java object, or a java object into a database record.
By defining your data and using code generators or other automation techniques (reflection) to create those different representations, you can slash maintenance costs, time to add new features, etc. Want to add a new field to an object? Update the canonical representation of the object, and presto, your entire app supports it, from the web UI down to the DB schema. Want to add a new data format? Write a generator for it, and all of your objects automatically support that new format.
The overhead is higher at first, but it pays off incredibly quickly. On my last project we saved many many man-years by doing this. Check out thesandbossproject for an LGPL set of tools to help out with this, based on the SAND architecture.
(Yes, I've glossed over about a zillion issues. It's not that I havent thought of them, it's that the problems are solvable. The main point is that your data representations should always be in sync with each other, without your lifting a finger. And no, UML doesn't quite get you there yet).
There's no 2.6 in the list of What Software Version Numbers Really Mean, so obviously it can't be 2.6. Therefore it must be at least 3.0. In fact, I'm stil confused as to how a 2.4 release got out.
Sure there are other ways to move files around (hey, use Zmodem if you want!) but in general, easier is better.
You make some good points about cost - American industry is saddled by an absurd health care system, etc. There are a zillion different factors that determine the cost of everything (like advertising! ha! you don't know much about industry if you didn't mention advertising!) that I deliberately overlooked because, well, this is slashdot, not a graduate thesis. I think we're both in agreement that software is comparatively cheap.
Now, some people will argue that a car is much more complex than a piece of software, and it certainly has a higher raw material cost. I'd agree with the latter, but not the former. Software is immensely complex, and software engineering usually doesn't have the benefit of tolerances. A door panel on a car can be 1/4" too small and the car will still work. You can't really do that in software; the software will break if everything isn't exactly right. That type of precision takes a hell of a lot of time/effort/etc. How much does GM spend to develop a new car? Billions. And they're still more expensive than an operating system, which is at least as complex. Given the amount of stuff that went into it, Windows XP is a bargain at only $99 or whatever (usability considerations aside). And then there's Linux....
One-off software is significantly more expensive than consumer software, but even there it's cheap when compared to the rest of the world. Want a custom car? What does that cost? (Hint: a lot, for any kind of quality). Or how about a custom dump truck for your mining operation? A custom or low-volume piece of software can run $10k-$1M or more, depending on what it is. Even those prices are on par for custom vehicles. While those numbers represent a lot of money to me, that's not a lot in the grand scheme of things. Software is damn cheap, especially when you consider the benefits it can provide (like the spreadsheet....VisiCalc + its followers literally changed the world).
I don't think software costs a lot. That said, I'm sure it can be made more cheaply + reliably given better tools. The same thing is true for every industry.
Even if the new chips are clock-for-clock identical to the current G4, the mere fact that they're running on a newer bus will make the machines much more powerful.
For more info about this, head over to Ars and check out the posts in the Mac Achaia by BadAndy from earlier this summer ("Altivec, anyone?" I think it was titled). He knows a hell of a lot more about this stuff than I do; it makes for fascinating reading, and you can really understand why faster CPUs alone won't cut it for Apple.
(scroll down to #29 in the list, it's worth it)
There's an open-source implementation of SAND called Sandboss that's getting off the ground; while it's still missing pieces, it's rapidly becoming functional (most of the generators are in place already, so take a look). The prepackaged version is out-of-date, so look at the CVS tree.
Right now there's no UML-to-SAND tool or any kind of visual editor, so you'll have to spec your objects as you go. It's a lot easier than it sounds.
Disclaimer: I'm working on sandboss because it kicks ass. I used a previous incarnation at my last job, and it saved literally man-years of development.
if (n = 0)
instead of
if (n == 0)
That's a good example of why more + better comments are necessary. Perhaps the author meant to write "if (n = 0)". Without some indication of intent, nobody knows which is correct without some detective work. The comments are there to verify that the code wasn't mistyped. As a professional developer, I'd rather know for sure what the code is supposed to do than have to guess (and potentially introduce a regression if I guess wrong).
While the implementation isn't complete (yet), the concept works amazingly well (I used a previous iteration at my last job) and saves literally man-years of development on large projects. Very cool stuff...