[dahacouk]

Hands up who has never had a desktop application fatally crash, temporarily freeze or permanently hang on them? Apart from the abacus users over there we've all had it happen to us. But why?

Is it just sloppy programming or is there something fundamentally broken with the way applications and operating systems are coded?

After upgrading to OS X 10.4.3, Mail started consistently crashing a few seconds after launching. After digging around the forums I got a possible fix: remove all stored email messages and configuration/preference files. It worked, I'm happy to say. I got a virgin Mail application that was seemingly stable. Luckily, I use IMAP email - all my mail is stored on my server. So, after setting up the account details in Mail - yet again - I just synced Mail with the IMAP server and I had all my email local again - nice.

Now then, this debacle isn't new. I've had to do this all before. There's a pattern here perhaps. When the chips are down or when configuration files are corrupted or not understood by the new version of the software why does the application have to crash on me? Why is this such a fragile world?

What's the basis for my thinking that our software could be build to not crash, freeze or hang? I'll tell you...

Take the scenario where you're browsing the Web, hopping from one website to another - and then you click on a link to a website that doesn't exist. How do you know? Well, the browser says "can't find website" or some such thing. It doesn't crash, freeze or throw a wobbly - hopefully.

Now, what's special about the browser is that it is generally robust enough not to crash when it comes across websites that don't exist or don't adhere to 100% HTML standard specifications - hopefully. In fact there's a lot of expectation that websites wont exist or wont conform to web standards built into the browser.

Now, what would happen if Mail found that it's configuration files where corrupt or formatted wrong or of an old version? Could it just say "can't read configuration files - shall I try to repair or just set up a brand new one?" rather than just crashing all forlorn like? Flump! I know Mail is currently capable of setting up a new configuration file because that's what it did when I removed them.

What would happen if Mail was to pretty much expect configuration files not to conform to standard (like the web browser and its websites)? If rather than crashing Mail just asked politely "old preference files not readable - would you like to start afresh?" Wouldn't that be much nicer?

And another thing... What about that spinning coloured ball or watch (for pre OS X users) or sand timer (for Windows users), eh? That long pause. Why is my interface frozen when the application is waiting for data or running a calculation? That just seems archaic. A good (or bad) case in point is spotlight searches. Why does Finder freeze with that spinning ball when it does a spotlight search? And why can't I open any other Finder windows when it freezes?

So, something seems wrong at the core here. Spinning balls shouldn't exist. So, what we could be talking here is decoupling the desktop interface from the collection and management of the data. So that the interface never crashes or stalls but could report if it's not finding the data where or in the form it thinks it should find it. And the interface never momentarily freezes when accessing information or performing a calculation, it just displays a time line bar and lets you get on with other stuff.

Wouldn't this be much better - much more robust? Applications would be built to handle corrupt, malformed or missing data gracefully and also handle waiting for data to sync up by showing the user what's going on. And never crash or hang the user interface.

Developers could split the interface from the data processing part of their applications and enable these two components to message each other. Or an application could be split into many more components all messaging each other. The contents of each message would be checked before ingesting so that it couldn't hang or crash the recipient component.

I must admit that sometimes applications seem to cope well but there just seems to be far too many times when they don't.

Now, am I dreaming or is there fundamentally something amiss in the way applications and operating systems are built today? Couldn't all this be much better? What do you reckon, eh?

Cheers Daniel

[sunrain]

It's a nice dream, but I think there will always be bugs in software; especially as we keep asking more and more of our computers. We are imperfect beings and it shows up in our creations. Considering the fact that my *laptop* operates regularly as a audio production facility, video editing station and print graphics center, I'm amazed that it's able to do all of that as well as it does.

It doesn't make me any happier though when the bugs show up, but luckily Apple handles the problem better than most other platforms.

edit: oh, and welcome to AppleNova.

[MCQ]

Originally Posted by dahacouk Take the scenario where you're browsing the Web, hopping from one website to another - and then you click on a link to a website that doesn't exist. How do you know? Well, the browser says "can't find website" or some such thing. It doesn't crash, freeze or throw a wobbly - hopefully. Now, what's special about the browser is that it is generally robust enough not to crash when it comes across websites that don't exist or don't adhere to 100% HTML standard specifications - hopefully. In fact there's a lot of expectation that websites wont exist or wont conform to web standards built into the browser.

My guess would be that the task of a browser parsing and displaying a web page is largely independent of any other task. It's not being fed into another process, and other parts of the application aren't dependent on the data as input. Once your page is rendered via the parser, properly or improperly, that's it. Using your example of Mail, the configuration being read and used as input to other tasks within Mail - be it connecting to servers, conducting smart folder searches, applying rules, etc.

And another thing... What about that spinning coloured ball or watch (for pre OS X users) or sand timer (for Windows users), eh? That long pause. Why is my interface frozen when the application is waiting for data or running a calculation? That just seems archaic. A good (or bad) case in point is spotlight searches. Why does Finder freeze with that spinning ball when it does a spotlight search? And why can't I open any other Finder windows when it freezes?

Haven't seen Spotlight beachball yet.

[Brad]

As sunrain said, it's a nice dream you have, but it's based on some misunderstandings about how software fundamentally works.

Originally Posted by dahacouk Is it just sloppy programming or is there something fundamentally broken with the way applications and operating systems are coded?

Simple. It's the way the application is coded, but it's not "fundamentally broken" at all. An application can be coded to never crash or hang and that is the goal of most programmers, but most applications are so complex that no one can reliably monitor all possible conditions. Programmers are not "sloppy" as you propose. Programmers have to be responsible for understanding and tracking thousands of variables and millions of execution statements and for testing how they all work (in an exponential number of ways) under different conditions. It truly boggles the mind sometimes.

Originally Posted by dahacouk Take the scenario where you're browsing the Web, hopping from one website to another - and then you click on a link to a website that doesn't exist. How do you know? Well, the browser says "can't find website" or some such thing. It doesn't crash, freeze or throw a wobbly - hopefully.

That's actually a very simple case. All the programmer has to do is put a timer on the page request and when it hits a predetermined amount, give up and throw that message.

Originally Posted by dahacouk Now, what's special about the browser is that it is generally robust enough not to crash when it comes across websites that don't exist or don't adhere to 100% HTML standard specifications - hopefully. In fact there's a lot of expectation that websites wont exist or wont conform to web standards built into the browser.

Here's where that "some misunderstandings about how software fundamentally works" I mentioned comes into play. Web browsers are not mission-critical software. Web browsers differ from most other software in that they don't need to produce correct output. That's hugely important here and bears repeating. Web browsers differ from most other software in that they don't need to produce correct output. That's how they can get by with horribly malformed content with mismatched tags and still keep running.

Ever notice how Firefox, Internet Explorer, and Safari almost never display a site pixel-perfect the same as each other? What makes web browsers special is that that's okay! "If the input is broken," the programmer says, "it's okay to ignore part of it." This is a perfectly accepted practice with web browsers when not in strict mode. This is relatively easy for a web browser to do because it's just parsing text files with tags that describe content layout. The programmer just has to write the parser so that it requires certain conditions for a tag (like a matching closing tag) for that tag to affect the layout at all. If the tag doesn't fit that condition, it treats it as plain text for output and moves on to the next.

This is different from other productivity software on many different levels. Most important is the aforementioned factor that web pages don't have to produce perfect output. Compare this to any other application; most other applications (and especially the operating system itself) cannot simply "throw away" input or malformed commands as easily as this. Think of a bookkeeping application like Quicken. Which would be better, for it to die on a damaged file or to display the file with incorrect output? When you consider that thousands of dollars and my employees' welfare could be at stake, I'd rather it die and report a "bad file" error than try to "fudge it" and incorrectly calculate my business ledger, thereby allowing me to make some terrible decisions based on that incorrect output.

And that's just the simple case!

It gets much more complicated when you consider tasks that do more than just parsing a file. Illegal memory access is a huge source of crashes and hangs and are 100% the developer's fault. When an application is running, the operating system tells it that it has access to specific regions of memory. If the application tries to access memory outside of it's space, it is far worse than some missing text in an HTML file. Whole functions will fail, invalid commands will be queued up, and the application could literally start to behave completely randomly. So, again, it would be better for the application to crash than to continue in this unrecoverable state of disrepair.

Originally Posted by dahacouk And another thing... What about that spinning coloured ball or watch (for pre OS X users) or sand timer (for Windows users), eh? That long pause. Why is my interface frozen when the application is waiting for data or running a calculation? That just seems archaic. A good (or bad) case in point is spotlight searches. Why does Finder freeze with that spinning ball when it does a spotlight search? And why can't I open any other Finder windows when it freezes? So, something seems wrong at the core here. Spinning balls shouldn't exist.

Heh. Here's where threading comes into place.

An application is simply a long step-by-step list on instructions that run in what's called a thread. A thread must perform operations in order; that's simply how computers work. They don't arbitrarily skip around things. Programs generally go like this:

1. Set up some initial values and run any setup methods.
2. Listen for user to press a key or click a button.
3. Check through a list of actions and execute the method that matches the input.
4. Go to 2.

The wait cursor that you experience is when an application's main thread is stuck at 3. Remember, these steps must be followed to the letter. You cannot arbitrarily throw input to an application when it's not listening for it (at step 3). The operating system knows when an application can accept input; so, when it sees that the application cannot, it gives you that wait cursor.

There are two solutions for this:

• Make the methods so short that the time between inputs in too small for the user to notice.
• Run multiple concurrent threads and build a queue of inputs and commands.

The first simply isn't practical for any moderately sized application. The second is very common.

However, when creating multiple threads, you introduce all sorts of new problems that you need to watch as a developer. Threads run whenever the operating system gives them time to run; you cannot guarantee that a thread will complete by a certain time or even before another thread that is started after it. One very serious problem occurs when two threads access a shared piece of memory.

Say you have two a method that looks like this:
1. Set shared variable X equal to 0.
2. Print "hello world!"
3. Increment X.
4. If X is less than to 2, go to step 2. Else, go to step 5.
5. Set X equal to 0 and exit this method.

Can you guess how this becomes problematic if multiple copies of this are running? Lets call the threads A and B. You would expect them to output "hello world!" four times, right? No? Lets look at a few test runs:

A1: Set shared variable X equal to 0.
B1: Set shared variable X equal to 0.
A2. Print "hello world!"
B2. Print "hello world!"
A3. Increment X. (X now equals 1)
B3. Increment X. (X now equals 2)
A4. X is not less than 2; so, go to step 5.
A5. Set X equal to 0 and exit this method.
B4. X is less than 2; so, go to step 2.
B2. Print "hello world!"
B3. Increment X. (X now equals 1)
B4. X is less than 2; so, go to step 2.
B2. Print "hello world!"
B3. Increment X. (X now equals 2)
B4. X is not less than 2; so, go to step 5.
B5. Set X equal to 0 and exit this method.

Okay, that was four "hello world" prints. Try a different order because (remember!) we we cannot guarantee that threaded commands will execute in a specific order relative to each other:

A1: Set shared variable X equal to 0.
B1: Set shared variable X equal to 0.
A2. Print "hello world!"
A3. Increment X. (X now equals 1)
B2. Print "hello world!"
B3. Increment X. (X now equals 2)
A4. X is not less than 2; so, go to step 5.
B4. X is not less than 2; so, go to step 5.
A5. Set X equal to 0 and exit this method.
B5. Set X equal to 0 and exit this method.

Ruh roh! Now we only get two "hello world" prints. Now, that is an EXTREMELY simplified example and is only the tip of a very, very large iceberg. Can you imagine the havoc that can be wrought with more complicated matters? An even worse problem than that is when two threads get stuck in a loop just resetting a value over and over. Also, what if a later thread needs to use a previous thread's output? The latter has to wait for the former to complete, just as in a single-threaded application.

Fortunately, there are programming conventions that developers can use to try to avoid such conditions. However, developers are only human! Threading is very complex and takes a lot of work to safeguard and get to work correctly.

Originally Posted by dahacouk So, what we could be talking here is decoupling the desktop interface from the collection and management of the data. So that the interface never crashes or stalls but could report if it's not finding the data where or in the form it thinks it should find it. And the interface never momentarily freezes when accessing information or performing a calculation, it just displays a time line bar and lets you get on with other stuff. Wouldn't this be much better - much more robust?

Well, duh. It would be much better if we all drove hydrogen cars and lived in solar powered homes, but that's not happening because it would need a mammoth undertaking and countless hours of work.

These things are all great in theory, but in practice it takes a lot of work to implement. Sure, it's possible, but is it worth it? Is it worth spending another hundred thousand dollars and thousands of hours for MyGreatProgram.app to achieve this when the benefits are so relatively small? Industry-wide, this would easily take trillions of dollars and decades of programming and testing.

Originally Posted by dahacouk Developers could split the interface from the data processing part of their applications and enable these two components to message each other. Or an application could be split into many more components all messaging each other. The contents of each message would be checked before ingesting so that it couldn't hang or crash the recipient component.

Again, a fundamental misunderstanding. A lot of software already works this way!

[Brad]

Oh, and welcome to AppleNova!

The previous post was hastily typed while waiting in the noisy service area of the local Saturn dealership. So, I hope I did a sufficient job responding and that it makes some sense...

[DMBand0026]

Only Brad could type something like that in a Saturn dealership. Geez.




It's nice to have him around, isn't it?

[dahacouk]

Originally Posted by Brad An application can be coded to never crash or hang and that is the goal of most programmers, but most applications are so complex that no one can reliably monitor all possible conditions.

That is why I suggest breaking an application into many components - to make the maintenance and monitoring simpler. Each component can be tested independently. Each component can place limits on what data it will ingest.

Originally Posted by Brad Programmers are not "sloppy" as you propose. Programmers have to be responsible for understanding and tracking thousands of variables and millions of execution statements and for testing how they all work (in an exponential number of ways) under different conditions. It truly boggles the mind sometimes.

Right! That's why I think it could be time for a different paradigm (I can't tell how long I've wanted to say that 'p' word! ;-) It's not a programmer's fault if they miss a test here or there. How can they be expected to check everything faultlessly. But you can't sculpt a miniature figurine with an axe. Sometimes the tools need to change to suit the job.

Originally Posted by Brad Think of a bookkeeping application like Quicken. Which would be better, for it to die on a damaged file or to display the file with incorrect output?

Neither! To be clear I don't want my applications crashing or freezing or hanging. Not ever. No matter what. That's my priority here. So, to answer your scenario, I'd want Quicken to talk about the fact it's discovered an incorrect file, tell me where it is, give me the state of the file before it got damaged and help me correct the damaged file. But I do not want it to crash giving me some technical report, full of low level mumbo jumbo that doesn't mean bo-diddly to me.

Originally Posted by Brad When you consider that thousands of dollars and my employees' welfare could be at stake, I'd rather it die and report a "bad file" error than try to "fudge it" and incorrectly calculate my business ledger, thereby allowing me to make some terrible decisions based on that incorrect output.

I wouldn't want it to "fudge it" either. But I would want it to stay alive and help me out. But I guess that's where we fundamentally differ. You don't mind crashing applications and I do. I want my applications to be more robust.

Originally Posted by Brad Well, duh. It would be much better if we all drove hydrogen cars and lived in solar powered homes, but that's not happening because it would need a mammoth undertaking and countless hours of work.

I don't agree. We are not driving "hydrogen cars" nor living "in solar powered homes" because there is no financial incentive for anyone to do so. There are "a mammoth undertaking" and "countless hours of work" happening all the time. Close your eyes and picture over 6 billion people going about the world doing their business. That's a lot of undertakings and work hours. "Hydrogen cars" and "solar powered homes" already exist. No invention needed. The R&D's already been done. The investment spent. We're not using these products because they are not cheaper than the products we are already using. They are not cheaper because governments are not incentivising manufacturers to lower the prices - via taxation and the like. Governments are not incentivised to act because the voters don't care about the issue.

Originally Posted by Brad These things are all great in theory, but in practice it takes a lot of work to implement. Sure, it's possible, but is it worth it? Is it worth spending another hundred thousand dollars and thousands of hours for MyGreatProgram.app to achieve this when the benefits are so relatively small? Industry-wide, this would easily take trillions of dollars and decades of programming and testing.

Well, I guess it all comes down to priorities and what you want the big sofware companies to spend their huge R&D budgets on. My priority is to have applications that don't crash or hang. Those "trillions of dollars and decades of programming and testing" are happening anyway. I'd prefer that they concentrated on making my OS and apps stable as concrete! ;-)

Crashing and hanging applications is one of the biggest turn offs to people that work with computers. Having apps crash and loosing all one's data is just not on. It costs trillions to people and companies. There's your financial incentive! That's why I want to see some work done to eradicate the problem. And I reckon the idea of splitting the functionality into discrete independent modules is the way to go.

Originally Posted by Brad Again, a fundamental misunderstanding. A lot of software already works this way!

Does it? When Mail doesn't like its preference file it crashes in total - interface and all. And that suggests that any components are bound together tightly as if they were one thereby forfeiting the advantage of robustness. We need a new paradigm (I love that word! ;-)

Cheers Daniel

[Brad]

Originally Posted by dahacouk That is why I suggest breaking an application into many components - to make the maintenance and monitoring simpler. Each component can be tested independently. Each component can place limits on what data it will ingest.

As I said, that's already how it's done!

Just look at Safari as an example. The actual binary weighs in at 1 MB. One megabyte! Surely an application as fully-featured as Safari can't fit into 1 MB. So, where does everything go? It's broken up into components. The interface, for example, is stored in various NIB bundles. There are at least 22 NIBs in just the English localization for different parts of the interface. Then there's the WebKit framework, the "rendering engine" that is completely separate from the application. Of course, there are lots of other frameworks that Safari uses, including Cocoa, Carbon, AddressBook, ApplicationServices, Security, SystemConfiguration, SecurityFoundation, SecurityInterface, and SyndicationUI. Each of those may reference others too. Carbon alone is also composed of the ImageCapture, CommonPanels, OpenScripting, HTMLRendering, SpeechRecognition, SecurityHI, CarbonSound, Ink, HIToolbox, NavigationServices, Print, and Help frameworks.

How about something different like a chat client? Adium is an open-sourced multi-protocol chat program written in Objective-C. Internally, it has at least four custom frameworks, five plugins, sixty NIBs, and four scripts, not to mention any of the system-level frameworks that are linked. It's been a while since I looked through the SVN, but as I last recall there was a whole page-full list of separate classes.

A developer can work on one class (framework, library, etc) and have absolutely no idea how other classes work or even how his class is being used, as long as he produces the right interface and expected output. Separating and referencing components of an application like this is nothing new in the world of computer science.

Originally Posted by dahacouk I'd want Quicken to talk about the fact it's discovered an incorrect file, tell me where it is, give me the state of the file before it got damaged and help me correct the damaged file. [...] I would want it to stay alive and help me out. [...] I want my applications to be more robust.

You're probably tired of seeing me say this, but that too is already possible today. The tradeoff simply isn't worth it to the developers, though, to implement such exhaustive checking.

Originally Posted by dahacouk I don't agree. We are not driving "hydrogen cars" nor living "in solar powered homes" because there is no financial incentive for anyone to do so.

Analogies (especially car analogies) like this are destined to fail and are never intended to be stretched like this, but I'll humor you.

There absolutely is an incentive to what I mentioned about alternative fuels, both financial and environmental. Do you seriously think people don't want to save money on their gas and electricity bills? And that there would be no benefits (to the environment and personal health) to reducing the burning of fossil fuels and nuclear fission? There may be a greater upfront cost, but the long term savings would quickly compensate.

As you later said yourself, though, there's not enough incentive to the consumer. Consumers as a whole don't see the long term, only the short-term. If the consumer is satisfied enough with the status quo, he'll keep buying gas-guzzling SUVs and topping off his tank with $50 of fuel every week.

The same goes for this type of software. Until a threshold is reached where the consequences of bugs outweigh the current benefit and usability of the software, there's not going to be a serious incentive for anyone to change. I don't like that either, but it's just how the market works.

Originally Posted by dahacouk "Hydrogen cars" and "solar powered homes" already exist. No invention needed. The R&D's already been done. The investment spent. We're not using these products because they are not cheaper than the products we are already using.

Just the same, it is possible today for me to write a program that will not crash (outside of low-level attacks on the hardware or memory) and will present you will all sorts of messages when anything is wrong. Products like that are not available for sale, though, because it would be prohibitively expensive to produce even one of a moderate size.

Software costs could easily double, triple, or quadruple and upgrade cycles could be delayed for months (with innovation stifled in the mean time) as more time and energy are spent encapsulating and checking values and QAing.

Heck, just look at the classic Mac OS for a prime example. It had virtually no memory protection and used to crash at the drop of a hat. It grew for ten years before someone decided it needed an serious overhaul to introduce fail-safes and improve stability. That overhaul was called Copland and it was a spectacular failure that cost two years of development and untold millions of dollars. In the end, it was easier for Apple to spend half a billion dollars to buy a whole separate company and its operating system and another five years in modification than to fix its own. That should give you some idea of the scale of "cost" involved with fixing problems like this.

I have a personal question for you: Have you ever written any software? Had to debug and fix someone else's code? Studied data structures, abstraction, inheritance, polymorphism, and object oriented design? Software economics?

If so, I hate guys like you. (kidding ) I've had more than a few philosophical "how technology should be" discussions among colleagues and they always get drawn out for-ev-er.

If not, I hope I've served to help clarify things a bit.

[Brad]

Also, since this is more of a general software topic rather than a call for a specific tech support issue, I'm moving this thread to General Discussion.

[scratt]

Brad... You're posts are so long they are crashing Safari.. Jesus who coded this forum.. I mean come on guys can't you keep track of a few variables and stuff....

Only kidding.. They didn't really crash Safari.. Pleeeze don't go pulling stuff apart!

[Brad]

Hey, if you want me to crash Safari, I'll just go stroll through the OpenDarwin Bugzilla reports for WebKit...

[scratt]

Here's an interesting article from Wired...

buggy linky

[Brad]

Okay, try this in the "official" Safari 2.0.2, not the nightly builds:
http://www.project-think.com/crash/

Click the link on that page. Sometimes it works on the first try; sometimes it takes ten or twenty tries. Just be glad I'm in a good mood and am not integrating that into AppleNova's templates just to spite you, scratt.

[scratt]

I cannot believe I am sitting here trying to crash Safari, and what's more not being able to!

I have clicked on that 100 times now and it won't crash.. Just pops the window up and it dissapears again.. over and over..

Is this a wind-up? Or should it really crash.

(Yes I am using the "official' Safari 2.0.2" )

[Brad]

Well, it worked on both my Macs.

[scratt]

Originally Posted by Brad Well, it worked on both my Macs.

My Macs are better than yours..

EDIT: I tell you what though (and everyone please take note of this) if I suddenly dissapear from applenova someone get Brad for me, because it just occurred to me this could be selectively attached to applenova based on the user....... It would be quite a good way to passively ban someone! Just make their browser crash (if it worked - Brad!) each time they log in!

[Brad]

Rather, my Macs are more reliable and predicable than yours.

[scratt]

Originally Posted by Brad Rather, my Macs are more reliable and predicable than yours.

This has to be a first... Two people arguing over which computer is best based on reliably being able to re-produce a crash! I'm going to get some therapy this is tooo geeky!

[torifile]

This thread wins the award for Most Words Ever Written. My head hurts (and I didn't even read all of it).

[Kickaha]

Y'know, I'm not even going to get into this one.

dahacouk, I think you have an excellent future in software project management. "Sloppy programmers!"

[dahacouk]

Originally Posted by Dr. Kickaha dahacouk, I think you have an excellent future in software project management. "Sloppy programmers!"

You've got quote marks around a quote that I didn't make. So, who you are quoting?

And, by the way, I do "have excellent future in software project management", thanks! ;-)

Cheers Daniel

[ast3r3x]

Brad...has it ever occurred to you that your gf f——ks you for your mind?

Also dahacouk, like Brad said, programs are already broken into components (classes) most of the time. There are even ways to test these classes (UnitTesting is one method I believe...but I could be wrong, I'm not exactly a hard core programmer—I don't even use memory management) but it seems that even to peoples best efforts, the more complex something gets, inherently it will have more variables that you can't account for.

[Koodari]

Originally Posted by Brad There absolutely is an incentive to what I mentioned about alternative fuels, both financial and environmental. Do you seriously think people don't want to save money on their gas and electricity bills? And that there would be no benefits (to the environment and personal health) to reducing the burning of fossil fuels and nuclear fission? There may be a greater upfront cost, but the long term savings would quickly compensate. As you later said yourself, though, there's not enough incentive to the consumer. Consumers as a whole don't see the long term, only the short-term. If the consumer is satisfied enough with the status quo, he'll keep buying gas-guzzling SUVs and topping off his tank with $50 of fuel every week.

A needlessly gas guzzling car is not a good investment, but usually neither are the new, cool technologies. The capital costs with interest and depreciation factored in are just too high. I'd be surprised if a hybrid even came close to regular small diesels yet.

[arnoct]

Occasionally crashing software is not neccessarily a result of bad programming--I'll randomly have my laptop violently crash on me; it's not as a result of bad programming but instead bad ram :P

[Brad]

Originally Posted by ast3r3x Brad...has it ever occurred to you that your gf f——ks you for your mind?

Yeah. She's a fellow brainiac too. Oh, I never made a big announcement about it, but it's fianceé now.

Originally Posted by ast3r3x There are even ways to test these classes (UnitTesting is one method I believe...

Yup! In Java's Eplipse IDE, for example, I use both JUnit and FIT to automate code testing. Basically, you write a suite of special getters and setters and generate some test cases and it'll run them for you. It'll even give you a percentage of your code coverage that is tested! This helps to ensure that you're writing good test cases that cover all those nasty nested if and switch statements.

Originally Posted by arnoct Occasionally crashing software is not neccessarily a result of bad programming--I'll randomly have my laptop violently crash on me; it's not as a result of bad programming but instead bad ram :P

Excellent point! No amount of programming can escape faulty hardware. In fact, one of the more common causes of crashes for Mac OS X software stems from precisely that: bad RAM modules.

[seashellz2]

So anyone know what made BEOS so specail?

[dahacouk]

Originally Posted by seashellz2 So anyone know what made BEOS so specail?

Do tell. Do tell!

[Kickaha]

Originally Posted by dahacouk You've got quote marks around a quote that I didn't make. So, who you are quoting?

Paraphrasing you.

And, by the way, I do "have excellent future in software project management", thanks! ;-)

Good thing you're investigating the causes then. Kudos to you for that - there are *hordes* of project managers out there that understand about, oh, zero when it comes to technology, and just blame 'sloppy/lazy programmers' for all the ills... while the engineers are pleading to be allowed to fix the system, but since it won't show a benefit for the *next* quarterly results, they're denied. Of course, the managers ask very direct and simple sounding questions of the engineers, and don't get direct and simple answers: "How much will it cost?" "How much will it save us?" I'd send you the chapters on this from my dissertation, but I'm not that sadistic.

(And yes, I have a solution, it looks like.)

[dahacouk]

Originally Posted by Dr. Kickaha (And yes, I have a solution, it looks like.)

It looks like what?...

[Kickaha]

BeOS was a from-scratch rethink of how an OS should work, and it was a beautiful product. It was pervasively multi-threaded, the filesystem was metadata aware and *rich* from Day 1, and it was basically the geek's wet dream when it came to the underlying technologies.

The frameworks were even pretty good, which for the day was surprising.

But then, at some level, they dropped the ball and didn't offer much compelling for end-users. Rather like if Linux had been coded by design instead of grown. Too bad, really, it was a great system.

NeXT was a much better choice for Apple though.