Well, faster drawing means programmers don’t have to spend as much time worrying about optimizing those portions of code.
Access to more APIs (apple mentioned that Inkwell APIs for example will be open to anyone) means it is easy to add very advanced capabilities to simple apps with very little additional effort.
A few unix goodies, including gcc3, help out. Did they announce better pthread support? I don’t remember, but that has been one of the big sticking points for porting POSIX compliant code (read unix apps) to OS X.
You still have to write your own code though just less of if
[quote author=“EDGar”]Well, faster drawing means programmers don’t have to spend as much time worrying about optimizing those portions of code.
I don’t mean to single you out here, EDGar, as this is a widespread problem. But comments like this indicate that programmers have gotten inherently lazy over the past 10 years, and this shows that the “public” has accepted this fact.
Case in point: Typing and printing a letter on my Apple //c wasn’t any slower than it is to do the same thing on my Pismo PowerBook. The //c crashed less frequently, and took a lot less time to boot up. My PowerBook has a 400MHz processor and 640MB of RAM (when I got OS X, I had to upgrade from 320MB because I was paging all the time). My Apple //c had a 1MHz processor and 128k of RAM, and most apps only needed 64k of that.
But times were different, then. Programmers prided themselves on “bumming” instructions out of a piece of code, getting it down to as few lines as possible—making it as efficient as possible. Nowadays we don’t bother making code more efficient, we just throw enough processing horsepower and RAM at it until it runs the way we wanted it to run. This, of course, creates bloated software that has tons of useless instructions buried in it, causing loss of performance and, in many cases, regular freeze-ups.
I agree with you… somewhat. By those rubrics shouldn’t we all be using xTerms, or even typewriters? (old typewriters respond more or less instantly to key presses). Or maybe we should all continue to program in assembly because compilers really aren’t as good at optimizing code as humans are. Or at the very least nobody should use object oriented languages like Objective-C, Java, or C++, they tend to be quite a bit slower than plain vanilla C. If we did that you would not see anything that resembled a modern user interface.
Obviously these are strawmen, but I think they illustrate the point. Yes it is important to carefully plan code, and not to be lazy. But wouldn’t you rather the (non-lazy) programmer spent his/her time fixing bugs and adding an essential or amazing feature rather than spending a month trying to determine how to squeeze that last drop of speed out of their app?
Yes lazy/sloppy programming == bad.
But, optimizations that can be performed once by someone else and inherited by everyone != bad.
very good point though.
[edit I knew there was something else I wanted to mention. This is also the type of thinking that lead to the y2k bug. Smaller, faster, smaller, faster at the expense of all else, including rather obvious (in hind sight) bugs]
[quote author=“EDGar”]Wouldn’t you rather the (non-lazy) programmer spent his/her time fixing bugs and adding an essential or amazing feature rather than spending a month trying to determine how to squeeze that last drop of speed out of their app?
If it were only the “last drop” of speed, then I could live with it. But as we all know, the “last drop” was the first thing to go. I think we’re up to a few buckets of speed right now with apps like IE, Word, Eudora, etc. Adium is a prime example of stellar coding using today’s frameworks. But it was written from the ground up over the last 6 months or so. IE, Word, Eudora, Filemaker, etc., all have years of sludge in their codebases that no one has bothered to clean up and optimize. Not only does it slow these apps down quite a bit, but it also makes them more buggy.
But, optimizations that can be performed once by someone else and inherited by everyone != bad.
Yes, but remember the deadlines now are set by managers, not programmers. Well, they always were, but management says “You will ship on this date!” and you have to get it done NOW. So there isn’t time to make things work that good any more.
[quote author=“tbone1”]Yes, but remember the deadlines now are set by managers, not programmers. Well, they always were, but management says “You will ship on this date!” and you have to get it done NOW. So there isn’t time to make things work that good any more.
Sadly, you’re right. This is what happens, and product cycles get shorter and shorter while quality diminishes because the poor programmers don’t have time to do their jobs properly.
But that’s exactly what the point of this thread has become! It’s not the programmers who need to speak out, it’s the customers! We (as a whole) have become complacent and all but expect software to crash and have errant bugs, etc. It doesn’t need to be this way, but in order for it to change people need to speak with their wallets (or, at the very least, with their customer service mail-in forms!).
I couldn’t agree with you more. vote with your wallet! It gets rather annoying to hear friends of mine complain endlessly about windows and MS office, then rush out to buy the latest version.
We noticed you may be running AdBlock on your computer. It takes real money to run this site and to deliver the news, tips, and opinions you love to read.
If you wish to block the ads that pay for the creation of our content, we ask that you instead support TMO Directly, either with a $5 monthly recurring contribution, or a one-time donation of any amount of your choice. Thanks!