Exactly, it was pretty visible inside of the web app development community. They didn't even expect more than 150 responses, so the number of votes is a resounding success.
XML sucks for configuration files, to be honest. Trying to hand-edit XML in a 40x80 nano session in single-user mode... no thanks. Not to mention that XML is decidedly grep-unfriendly.
Well, it needs to be some standardized format./etc is a horrible way of working because every program has invented their own particular configuration file format, for no good reason. The amount of time it takes to learn the ins and outs of/etc is aggravating. To me, it is the least usable system, because of the learning curve.
The registry on the other hand is not a text-based format, so repairing / modifying it without booting from it is particularly trying. Which makes it a pretty lousy format as well.
The best mix between the two worlds for me is how OS X does it. All OS X configuration files are proplist files. Proplists are reasonably grep-able, but they are a standardized format, so there are GUI tools to edit any proplist, and it's straightforward to learn how to edit one manually.
Most web developers these days build for firefox first, and adapt for IE second. Running firefox means you get a first-class browsing experience.
Also, speaking as a web developer, please, if you're still using IE6, please, pretty please, stop using it. IE6 is the bane of our existance, and we wish people who use it would just die*.
(*) Or switch to a browser that doesn't date back to paleolithic times.
Back when I was about 13, I asked my dad to teach me programming. He pushed a visual basic beginner's book and the visual basic 3 floppies into my hands, and wished me good luck. In retrospect, I don't think this was such a bad approach.
What you'll need first and foremost is an environment with immediate visual feedback, that you can do one-liners in that gradually grow into larger programs. Visual basic fit the bill at the time, but these days I'd look more towards adobe flex (the gui tool, not the sdk), or if you get the heebie-jeebies from commercial products, just use html + javascript.
What's important is to recognize that there should be some measure of reward right at the start. The kid should be able to build stuff that does "something" his first day, and be able to grow that into building programs that he designs himself.
Don't try to push him in any way, let him discover things on his own pace. And don't try to enforce your "standards of work" on the kid, because it took you years, or even decades, to build up those standards, and it would be too off-putting to require him to "do it right" the first time around. Following from that sentiment, avoid pushing tools because they're "correct", but instead choose tools that have gradual learning curves, even if you wouldn't use them yourself necessarily.
If your requirements are specific, don't expect a huge pile of people (without jobs, mind you!) to be waiting in the wings for your spot to open up. You need someone who might take a year or two to get up to speed, but once there will be good.
You don't take a bricklayer, put him in between a bunch of architects and hope that in two years time he can design buildings.
Web development is a subdiscipline of software engineering, which in turn is like any other engineering field. What makes people good in the field is not knowing lots of tools, it's having a firm grasp on the basic knowledge of the field and knowing how to apply it.
The problem is that you really need formal education to get there. This stuff is nearly impossible to learn on the job, because the environment isn't suited to it.
The way we let people apply at my company is to ask them to build a really simple game in less than 4 hours, according to a featureset we describe. They can use any tool they want (we once hired someone who used pseudocode). We are NOT a game development house however, we make business apps. The goals is to see their basic problem solving and design skills.
Most of the job applicants have nothing after 4 hours. Nothing. Some come tell as after two hours that they give up and don't want the job anymore. This is not because the game is that hard to design (it's really easy, honestly), it's because it's too different from what they know (business apps, forms on top of a database). An engineer will go back to the basics, and come up with something, even if it doesn't work. From my experience however, most of the people in the software development field are tool and technology experts, not engineers. They learned to build a particular type of application in a particular technology, but they don't really understand the "why" of what they do.
So I think your father is right. There's a shortage of skilled engineers, because being a real engineer isn't valued. Knowing the tool du jour has a lot more sway on your resume than understanding how a compiler works. To me, that's just plain wrong.
A commonly mentioned benefit of web apps is portability, but this isn't really true either because of the variety (and inconsistency) of web browsers. What I think is a better approach is something like the solution we see with Qt, where you write your program once, then compile it for different platforms, and it looks native every time.
That still doesn't solve the deployment problem. You need rights on the local system to install that software. Why do you need those rights? Because native apps can interact in too many ways, and they can't be trusted, so rights are not automatically granted.
The clever thing about the web platform, and what sets it apart from other platforms, is that the security model by default lets you run any app, even one you don't trust, on any system, without it causing major catastrophes.
The web platform is building on a new concept: ubiquitous internet. The idea is that your applications and data live in the cloud, and are available to you on any device, anywhere, any time. Off-line support is only necessary as a short-term stopgap until the cloud is visible again (like the offline support of google docs).
This is why the web makes sense: it just works. No installs, no administration, no lost data when your local machine fails, no shuttling different versions around on usb sticks. It's true that it's less powerful, but it doesn't matter because the ease of use gained from having the apps and the data "out there" will vastly outweigh the lack of capability for the majority of users.
You're approaching this too much from a geek's perspective. Updating "the system" is too esoteric for the majority of users. If the user has to be bothered with such a concept as a package manager, it's bad UI.
Anyway, microsoft has a package manager, somewhat, and they have a consistent auto-update system that takes care of dependancies. And yet half of IE users use an old version.
Google uses map/reduce. It seems to work well for them. The system avoids thread synchronization during processing, and by doing that essentially turns it into a sequential programming model that can be debugged normally.
I think the advances are going to come from finding ways to avoid thread synchronization. Even if you need more threads overall, it's still a gain.
Architectures have changed and other stuff allow a current single core of a 3.2 to easily outperform the old 3.8's but then still why don't we see new 3.8's?
Clock rate is meaningless. They could build a 10 ghz cpu, but it wouldn't outperform the current 3 ghz cpu's.
A modern cpu uses pipelining. This means that each instruction is spread out across a series of phases (e.g. fetch data, perform calculation 1, perform calculation 2, store data). Each phase is basically a layer of transistors the logic has to go through. The clock rate simply is how often data is transferred to the next phase. The higher you push the clock, the faster instructions move through their phases towards completion. The problem is that the transistors in each phase take a while after every clock tick to stabilize. So, if you push the clock rate too high, the end result of your current phase won't have been reached yet, and you'll push garbage to the next phase. This is why a cpu that is overclocked too far will cause crashes. It simply doesn't do reliable calculation anymore.
Now, the reason you had higher clock rates on the P4 architecture is that intel "solved" the clock rate problem by having more phases and making each phase shorter. Overall the cpu was less efficient, but they could put a bigger ghz number on the package, so marketing was happy. They've come back from that because they couldn't compete on cost/performance with someone who didn't do that (amd), and their current architecture has appropriate-length phases again, with a lower clock rate to match.
Like you've observed however, overall the speed has gone up.
'm no software engineer, but it seems like a lot of the issue in designing for multiple cores is being able to turn large tasks into many independent discrete operations that can be processed in tandem. But it seems that some tasks lend themselves to that compartmentalization and some don't.
Think on this: google's applications run the gamut, containing lots of functionality which we think of as single-threaded. All of google's apps run on commodity hardwars, slower than the machine on your desk.
My point is this: if programmer's are forced to think about how they can deserialize an algorithm, they will invent solutions. In google's case, they've built a whole parallel empire on top of a map / reduce library.
CS != programming. In fact I would discourage any CS students from going into IT. IT is dead, its just the 21st century equivalent of paper pushing. Most IT shops are big bloated bureaucracies. They totally kill creativity. Go into the buisness side and actually have an impact and some influence.
Nonsense. There are plenty software development jobs out there where you get to work in an environment where creative solutions to interesting problems are appreciated. Where you do get a say in the end result, even if you're a junior programmer. I should know, I work at one.
That is not to say that those jobs necessarily are perfect (mine isn't, that's for sure), but if I ever felt that I worked just for my paycheck, and didn't enjoy what I was doing at all, I'd look for something else to do.
Really, Microsoft has no chance of pleasing you, do they? Just accept that it's good for everyone to have open standards, regardless of the possible ulterior motives involved.
The point is that MS's patent licenses (and therefore their specs), due to the non-commerce clause, are not GPL compatible. See, MS is not threatened by a BSD license, because if a BSD product takes off, they can just embrace, extend, extinguish. They're really worried about GPL though, because any GPL project that succeeds is a true competitive threat.
In short, I don't think they've opened the specs. Documented them, yes, published them, sure, but they have NOT opened them.
What about them? Local is local. Google gears has a security model whereby only the app that put the data locally can access that data again. There's no practical difference with local native apps security- or privacy-wise.
i was disappointed to find out that SproutCore projects are created with RUBY and that you touch javascript very little, if at all.
You don't need ruby when deploying, and the code you write is javascript. Sproutcore uses ruby to make life more convenient while developing, but it is a pure-javascript framework.
If you have the google gears plugin installed, google docs works offline. Offline support is not an inherent advantage of native apps. The only truly insurmountable advantage native apps have over web apps is performance, but with today's vastly overpowered multi-core machines, performance has faded into the background, and it's going to become less relevant as the browser upgrades get rolled out (javascript 2, faster layout engines, hardware-accelerated graphics api's,...).
Not saying that it is not needed, I am sure the "rest of the world" outside of the US and the EU would like some IP space all of their own, but market forces have already relegated that individuals have no need for unique IP space and NAT is good enough for the unwashed masses.
NAT is only good for networks. Every ISP subscriber still gets a unique IP, and with people leaving their PC's on 24/7, those might as well be unique IP's (my ISP does not charge that much extra to get a fixed IP).
I read a statistic that by 2010 half of the global population is going to have a cell phone (currently it's 4 out of 10), with most of the growth in asia and the middle east. Currently 1 in 6 cellphone users globally has an internet-enabled subscription (even if they don't use it), but this is going to grow considerably. We could be talking about up to a billion new internet users over the next decade, in asia and the middle east, the majority of them on cheap mobile devices. NAT is not going to be the answer, and IPv6 will become a necessity to reach those markets.
The NYT did an interesting article about cellphones and the third world. What's driving the adoption is economic necessity. The cost of doing business in a globalized world is that you have to be connected. http://www.nytimes.com/2008/04/13/magazine/13anthropology-t.html
Since you can't run 6 and 7 on the same machine, I stay on 6.
This is I think the biggest reason for the slow adoption of IE7. Microsoft did not provide a way to run IE6 and IE7 on the same machine, so corporations did not have the option of migrating to IE7 except for a few legacy sites, holding back demand for IE7 compatibility, and thereby holding back IE7 adoption. They're going to be better about this with IE8 by at least allowing you to go back to the IE7 engine even if you install IE8.
Please, not that old saw. There's nothing stopping microsoft or dell or some other company from getting a particular configuration marked as super-reliable and high-performance.
Also, OS X runs on PPC, Intel (with the same source code), and on ARM (iPhone). That's some pretty widespread hardware support if you ask me.
Hardware is besides the issue anyway. The real issue is internal structure of the software. I've yet to hear anyone argue that vista's internal design is clean, and that seems to translate into microsoft's inability to keep up the pace in delivering improvements.
Apple switched hardware architectures from 10.3 to 10.4. They rewrote their networking stack from 10.4 to 10.5 (admittedly, there were a few issues in the new stack related to wireless). They're going to change to a different filesystem from 10.5 to 10.6.
It's not the degree of change that's the issue, it's the degree of architecture. Windows is built by separate teams that build layers and components that somehow have to be fit together, resulting in a hodge-podge of programming API's that's a nightmare to keep supporting. OS X seems to have a more centralized vision, with a programming API that is mostly consistent, and probably way easier to maintain.
It also helps that mac developers are more willing to rewrite software (basically because the ones that aren't were weeded out a few transitions ago). When apple wants to make some radical change, like dropping support for an entire API, or moving to a different CPU architecture, the developers just go along with it. On windows they'd scream bloody murder.
I went to college for computers because I was good at them, and I liked the "magic".
Me too. Then I understood how they worked, they lost their magic, and I got seriously disappointed. I considered changing career paths (I was still studying), pretty much abandoned any own software projects, and resigned myself to a programming job I wouldn't like. Funny thing is, I found that I liked building the "magic" for other people just as much as I did trying to figure it out. What drives me now is building stuff that "just works".
Which was stupid because technology changes so fast that by time you've published a book on CS, it's outdated.
You're confusing software technologies with software techniques. The optimizations I use to make my web 2.0 apps faster are many of the same techniques that were used in the early 90's to make mac and windows apps faster. Avoiding server roundtrips, resource bundling to cut network overhead, compression, space/time complexity optimization. The techniques and theory hasn't changed much, and if you know the theory, picking up new technologies is easy as pie.
CS isn't like that--they are a layer removed from what's really going on as they attempt to come up with theories and see patterns. And that IS boring.
You do realize it's CS that builds all that "constantly changing" stuff you rave about right?
Although I do agree with you somewhat. The "science" part of CS has very little to do with the practical realities of the job. And most of the people who actually build stuff don't communicate enough, if at all, with end users and support personnel.
No, no, you only get geek cred for being on windows if you avoid tried-and-true microsoft solutions.
If you're porting KDE to XP, you get geek cred. If you're running a RoR install on top of a Firebird database, on Windows Server, you get geek cred. If you click around microsoft management console, and know how group policies work, sorry, you get no geek cred.
Now I know that there are a lot of exceptions to this rule, but generally speaking 90% of people who start out in a company as an entry level software engineer or IT guy dont move on to anything else. Thats why people get bored with it imho.
Keeping the same title does not have to mean that you do the same thing. I've been a professional software engineer for 4 years now, and every year I've worked on something completely different. I've build flash-based CAD systems, delphi-based translation software, a rich web grid component, and recently an outlook room reservation plugin. Now I'm designing a framework for a dual web 2.0 / xhtml mobile web portal. This is all at the same company with the same job title.
The vast majority of the time my work is not boring at all. The kind of "career growth" I experience is in knowledge and skill set (and in money too ofcourse), not in job title.
Then again, maybe I need to give it another decade and see how I feel about it then.
Slashdot Mirror
Exactly, it was pretty visible inside of the web app development community. They didn't even expect more than 150 responses, so the number of votes is a resounding success.
I'm running FF3 on a 1.2 ghz mac mini, and performance-wise it stacks up fine against safari 3.1.
XML sucks for configuration files, to be honest. Trying to hand-edit XML in a 40x80 nano session in single-user mode... no thanks. Not to mention that XML is decidedly grep-unfriendly.
Well, it needs to be some standardized format. /etc is a horrible way of working because every program has invented their own particular configuration file format, for no good reason. The amount of time it takes to learn the ins and outs of /etc is aggravating. To me, it is the least usable system, because of the learning curve.
The registry on the other hand is not a text-based format, so repairing / modifying it without booting from it is particularly trying. Which makes it a pretty lousy format as well.
The best mix between the two worlds for me is how OS X does it. All OS X configuration files are proplist files. Proplists are reasonably grep-able, but they are a standardized format, so there are GUI tools to edit any proplist, and it's straightforward to learn how to edit one manually.
Most web developers these days build for firefox first, and adapt for IE second. Running firefox means you get a first-class browsing experience.
Also, speaking as a web developer, please, if you're still using IE6, please, pretty please, stop using it. IE6 is the bane of our existance, and we wish people who use it would just die*.
(*) Or switch to a browser that doesn't date back to paleolithic times.
Back when I was about 13, I asked my dad to teach me programming. He pushed a visual basic beginner's book and the visual basic 3 floppies into my hands, and wished me good luck. In retrospect, I don't think this was such a bad approach.
What you'll need first and foremost is an environment with immediate visual feedback, that you can do one-liners in that gradually grow into larger programs. Visual basic fit the bill at the time, but these days I'd look more towards adobe flex (the gui tool, not the sdk), or if you get the heebie-jeebies from commercial products, just use html + javascript.
What's important is to recognize that there should be some measure of reward right at the start. The kid should be able to build stuff that does "something" his first day, and be able to grow that into building programs that he designs himself.
Don't try to push him in any way, let him discover things on his own pace. And don't try to enforce your "standards of work" on the kid, because it took you years, or even decades, to build up those standards, and it would be too off-putting to require him to "do it right" the first time around. Following from that sentiment, avoid pushing tools because they're "correct", but instead choose tools that have gradual learning curves, even if you wouldn't use them yourself necessarily.
If your requirements are specific, don't expect a huge pile of people (without jobs, mind you!) to be waiting in the wings for your spot to open up. You need someone who might take a year or two to get up to speed, but once there will be good.
You don't take a bricklayer, put him in between a bunch of architects and hope that in two years time he can design buildings.
Web development is a subdiscipline of software engineering, which in turn is like any other engineering field. What makes people good in the field is not knowing lots of tools, it's having a firm grasp on the basic knowledge of the field and knowing how to apply it.
The problem is that you really need formal education to get there. This stuff is nearly impossible to learn on the job, because the environment isn't suited to it.
The way we let people apply at my company is to ask them to build a really simple game in less than 4 hours, according to a featureset we describe. They can use any tool they want (we once hired someone who used pseudocode). We are NOT a game development house however, we make business apps. The goals is to see their basic problem solving and design skills.
Most of the job applicants have nothing after 4 hours. Nothing. Some come tell as after two hours that they give up and don't want the job anymore. This is not because the game is that hard to design (it's really easy, honestly), it's because it's too different from what they know (business apps, forms on top of a database). An engineer will go back to the basics, and come up with something, even if it doesn't work. From my experience however, most of the people in the software development field are tool and technology experts, not engineers. They learned to build a particular type of application in a particular technology, but they don't really understand the "why" of what they do.
So I think your father is right. There's a shortage of skilled engineers, because being a real engineer isn't valued. Knowing the tool du jour has a lot more sway on your resume than understanding how a compiler works. To me, that's just plain wrong.
A commonly mentioned benefit of web apps is portability, but this isn't really true either because of the variety (and inconsistency) of web browsers. What I think is a better approach is something like the solution we see with Qt, where you write your program once, then compile it for different platforms, and it looks native every time.
That still doesn't solve the deployment problem. You need rights on the local system to install that software. Why do you need those rights? Because native apps can interact in too many ways, and they can't be trusted, so rights are not automatically granted.
The clever thing about the web platform, and what sets it apart from other platforms, is that the security model by default lets you run any app, even one you don't trust, on any system, without it causing major catastrophes.
The web platform is building on a new concept: ubiquitous internet. The idea is that your applications and data live in the cloud, and are available to you on any device, anywhere, any time. Off-line support is only necessary as a short-term stopgap until the cloud is visible again (like the offline support of google docs).
This is why the web makes sense: it just works. No installs, no administration, no lost data when your local machine fails, no shuttling different versions around on usb sticks. It's true that it's less powerful, but it doesn't matter because the ease of use gained from having the apps and the data "out there" will vastly outweigh the lack of capability for the majority of users.
You're approaching this too much from a geek's perspective. Updating "the system" is too esoteric for the majority of users. If the user has to be bothered with such a concept as a package manager, it's bad UI.
Anyway, microsoft has a package manager, somewhat, and they have a consistent auto-update system that takes care of dependancies. And yet half of IE users use an old version.
Google uses map/reduce. It seems to work well for them. The system avoids thread synchronization during processing, and by doing that essentially turns it into a sequential programming model that can be debugged normally.
I think the advances are going to come from finding ways to avoid thread synchronization. Even if you need more threads overall, it's still a gain.
Architectures have changed and other stuff allow a current single core of a 3.2 to easily outperform the old 3.8's but then still why don't we see new 3.8's?
Clock rate is meaningless. They could build a 10 ghz cpu, but it wouldn't outperform the current 3 ghz cpu's.
A modern cpu uses pipelining. This means that each instruction is spread out across a series of phases (e.g. fetch data, perform calculation 1, perform calculation 2, store data). Each phase is basically a layer of transistors the logic has to go through. The clock rate simply is how often data is transferred to the next phase. The higher you push the clock, the faster instructions move through their phases towards completion. The problem is that the transistors in each phase take a while after every clock tick to stabilize. So, if you push the clock rate too high, the end result of your current phase won't have been reached yet, and you'll push garbage to the next phase. This is why a cpu that is overclocked too far will cause crashes. It simply doesn't do reliable calculation anymore.
Now, the reason you had higher clock rates on the P4 architecture is that intel "solved" the clock rate problem by having more phases and making each phase shorter. Overall the cpu was less efficient, but they could put a bigger ghz number on the package, so marketing was happy. They've come back from that because they couldn't compete on cost/performance with someone who didn't do that (amd), and their current architecture has appropriate-length phases again, with a lower clock rate to match.
Like you've observed however, overall the speed has gone up.
'm no software engineer, but it seems like a lot of the issue in designing for multiple cores is being able to turn large tasks into many independent discrete operations that can be processed in tandem. But it seems that some tasks lend themselves to that compartmentalization and some don't.
Think on this: google's applications run the gamut, containing lots of functionality which we think of as single-threaded. All of google's apps run on commodity hardwars, slower than the machine on your desk.
My point is this: if programmer's are forced to think about how they can deserialize an algorithm, they will invent solutions. In google's case, they've built a whole parallel empire on top of a map / reduce library.
My biggest grudge against these places is the "life suckage" they employ...
I mean.. I want to do something other than code 12 hours a day (ya know... sometimes?)
You underestimate the amount of overhead involved in a programming gig. If they can spend half their time coding, I'll be amazed.
CS != programming. In fact I would discourage any CS students from going into IT. IT is dead, its just the 21st century equivalent of paper pushing. Most IT shops are big bloated bureaucracies. They totally kill creativity. Go into the buisness side and actually have an impact and some influence.
Nonsense. There are plenty software development jobs out there where you get to work in an environment where creative solutions to interesting problems are appreciated. Where you do get a say in the end result, even if you're a junior programmer. I should know, I work at one.
That is not to say that those jobs necessarily are perfect (mine isn't, that's for sure), but if I ever felt that I worked just for my paycheck, and didn't enjoy what I was doing at all, I'd look for something else to do.
Really, Microsoft has no chance of pleasing you, do they? Just accept that it's good for everyone to have open standards, regardless of the possible ulterior motives involved.
The point is that MS's patent licenses (and therefore their specs), due to the non-commerce clause, are not GPL compatible. See, MS is not threatened by a BSD license, because if a BSD product takes off, they can just embrace, extend, extinguish. They're really worried about GPL though, because any GPL project that succeeds is a true competitive threat.
In short, I don't think they've opened the specs. Documented them, yes, published them, sure, but they have NOT opened them.
What about them? Local is local. Google gears has a security model whereby only the app that put the data locally can access that data again. There's no practical difference with local native apps security- or privacy-wise.
i was disappointed to find out that SproutCore projects are created with RUBY and that you touch javascript very little, if at all.
You don't need ruby when deploying, and the code you write is javascript. Sproutcore uses ruby to make life more convenient while developing, but it is a pure-javascript framework.
If you have the google gears plugin installed, google docs works offline. Offline support is not an inherent advantage of native apps. The only truly insurmountable advantage native apps have over web apps is performance, but with today's vastly overpowered multi-core machines, performance has faded into the background, and it's going to become less relevant as the browser upgrades get rolled out (javascript 2, faster layout engines, hardware-accelerated graphics api's, ...).
Not saying that it is not needed, I am sure the "rest of the world" outside of the US and the EU would like some IP space all of their own, but market forces have already relegated that individuals have no need for unique IP space and NAT is good enough for the unwashed masses.
NAT is only good for networks. Every ISP subscriber still gets a unique IP, and with people leaving their PC's on 24/7, those might as well be unique IP's (my ISP does not charge that much extra to get a fixed IP).
I read a statistic that by 2010 half of the global population is going to have a cell phone (currently it's 4 out of 10), with most of the growth in asia and the middle east. Currently 1 in 6 cellphone users globally has an internet-enabled subscription (even if they don't use it), but this is going to grow considerably. We could be talking about up to a billion new internet users over the next decade, in asia and the middle east, the majority of them on cheap mobile devices. NAT is not going to be the answer, and IPv6 will become a necessity to reach those markets.
The NYT did an interesting article about cellphones and the third world. What's driving the adoption is economic necessity. The cost of doing business in a globalized world is that you have to be connected. http://www.nytimes.com/2008/04/13/magazine/13anthropology-t.html
Since you can't run 6 and 7 on the same machine, I stay on 6.
This is I think the biggest reason for the slow adoption of IE7. Microsoft did not provide a way to run IE6 and IE7 on the same machine, so corporations did not have the option of migrating to IE7 except for a few legacy sites, holding back demand for IE7 compatibility, and thereby holding back IE7 adoption. They're going to be better about this with IE8 by at least allowing you to go back to the IE7 engine even if you install IE8.
Please, not that old saw. There's nothing stopping microsoft or dell or some other company from getting a particular configuration marked as super-reliable and high-performance.
Also, OS X runs on PPC, Intel (with the same source code), and on ARM (iPhone). That's some pretty widespread hardware support if you ask me.
Hardware is besides the issue anyway. The real issue is internal structure of the software. I've yet to hear anyone argue that vista's internal design is clean, and that seems to translate into microsoft's inability to keep up the pace in delivering improvements.
Apple switched hardware architectures from 10.3 to 10.4. They rewrote their networking stack from 10.4 to 10.5 (admittedly, there were a few issues in the new stack related to wireless). They're going to change to a different filesystem from 10.5 to 10.6.
It's not the degree of change that's the issue, it's the degree of architecture. Windows is built by separate teams that build layers and components that somehow have to be fit together, resulting in a hodge-podge of programming API's that's a nightmare to keep supporting. OS X seems to have a more centralized vision, with a programming API that is mostly consistent, and probably way easier to maintain.
It also helps that mac developers are more willing to rewrite software (basically because the ones that aren't were weeded out a few transitions ago). When apple wants to make some radical change, like dropping support for an entire API, or moving to a different CPU architecture, the developers just go along with it. On windows they'd scream bloody murder.
I went to college for computers because I was good at them, and I liked the "magic".
Me too. Then I understood how they worked, they lost their magic, and I got seriously disappointed. I considered changing career paths (I was still studying), pretty much abandoned any own software projects, and resigned myself to a programming job I wouldn't like. Funny thing is, I found that I liked building the "magic" for other people just as much as I did trying to figure it out. What drives me now is building stuff that "just works".
Which was stupid because technology changes so fast that by time you've published a book on CS, it's outdated.
You're confusing software technologies with software techniques. The optimizations I use to make my web 2.0 apps faster are many of the same techniques that were used in the early 90's to make mac and windows apps faster. Avoiding server roundtrips, resource bundling to cut network overhead, compression, space/time complexity optimization. The techniques and theory hasn't changed much, and if you know the theory, picking up new technologies is easy as pie.
CS isn't like that--they are a layer removed from what's really going on as they attempt to come up with theories and see patterns. And that IS boring.
You do realize it's CS that builds all that "constantly changing" stuff you rave about right?
Although I do agree with you somewhat. The "science" part of CS has very little to do with the practical realities of the job. And most of the people who actually build stuff don't communicate enough, if at all, with end users and support personnel.
No, no, you only get geek cred for being on windows if you avoid tried-and-true microsoft solutions.
If you're porting KDE to XP, you get geek cred. If you're running a RoR install on top of a Firebird database, on Windows Server, you get geek cred. If you click around microsoft management console, and know how group policies work, sorry, you get no geek cred.
Now I know that there are a lot of exceptions to this rule, but generally speaking 90% of people who start out in a company as an entry level software engineer or IT guy dont move on to anything else. Thats why people get bored with it imho.
Keeping the same title does not have to mean that you do the same thing. I've been a professional software engineer for 4 years now, and every year I've worked on something completely different. I've build flash-based CAD systems, delphi-based translation software, a rich web grid component, and recently an outlook room reservation plugin. Now I'm designing a framework for a dual web 2.0 / xhtml mobile web portal. This is all at the same company with the same job title.
The vast majority of the time my work is not boring at all. The kind of "career growth" I experience is in knowledge and skill set (and in money too ofcourse), not in job title.
Then again, maybe I need to give it another decade and see how I feel about it then.