I'm assuming that by "commodity PC" you mean a standard x86 machine onto which you can install a non-MS x86 OS.
If the chips/BIOS are set up in such a way as to literally prevent the installation of a non-MS OS onto the bare machine, then there will be enough market demand for machines without this restriction that the market will fork. I'm not claiming that it will fork half-and-half, just that there will be enough demand in the world to create a market. The market may be too small or politically sensitive for the likes of Dell or HPAQ, but some Asian manufacturer(s) could make a good living off that market.
More likely, the existence of the extra crypto hardware can be accommodated by new designs in Linux/*BSD/etc. and might actually become quite useful to a user with complete personal control over its capabilities.
At some point, it would make sense for a service bureau to offer the service of reclaiming data off old media and copying as much as possible onto new media. We already have SBs that will recover data from crashed hard drives and others that will copy old super8 movies onto VHS and others that will move VHS to DVD.
It seems that there is a generic business here: moving data from old, even damaged, media to new media. A lot of local SBs already do parts of this. Maybe over time, we'll see a franchise appear offering a wide range of such services, that uses old designs and virtual machines to manufacture the necessary equipment for its franchisees....
As I've gotten older, I've noticed a definite change in my orientation from a close up on my own personal here and now to a wide angle view of family history. I remember my parents when they were younger than I am now. I can remember my grandfather when he wasn't much older than I am now, and I'm surprised at how I'm beginning to relate to them as peers.
They're gone now, but I want to know them more now than I ever did. The photos aren't even close to being enough, but I'm sure I glad I have them.
Maybe the original poster is just too young to have had experiences such as you describe, but I'm with you 100%. Like most Slashdotters, I imagine, I'm more oriented toward the future than the past. Even so, sometimes I imagine what it might be like to have a "holodeck" recreation of my surroundings as a child. Sitting in the back seat of our old car, with a young Mom and Dad in the front seat, surrounded by my favorite candies, some of my old toys....
I don't know how realistic VR is going to become, but even if I have to just do it in my head, having pictures of the old people, places, and things helps me to recreate a world that was good to me and fill in a lot of the details. Seeing even older pictures helps me to recreate worlds that had a big impact on my life, even though they disappeared before I came along.
These things matter to me, and they matter more as I get older and can begin to really feel my place in the sweep of human history.
Using better languages could reduce software bugginess dramatically, but only if programmers admit they have a problem.
Most developers overestimate the value of custom solutions to every problem. A language like C, with no built-in string type, no collections other than the most primitive array, no memory mgt above the finest-grained primitives, and so on, seduce programmers into working at too low a level of abstraction for most problems.
The nature of C is such that it is a good choice for the software equivalent of "innermost loop" code: small bits of code in constant use with crystal clear functional requirements that never change. The 1% of code that accounts for 95% of all CPU cycles should probably be written in C, massively code reviewed, tested exhaustively, and then left alone to do its well-defined and unchanging job.
Code of this sort should mostly be in the OS itself, or in libraries, although it's also appropriate in the "engine" portion at the heart of Big Apps, like database engines, spreadsheet recalc engines, text rendering engines, etc.
But programmers flatter themselves that everything they write is this type of code and use C for the other 99% for which it is ill-suited. Instead of working at a higher level, using built-in Unicode Strings, well-designed collections classes (where you simply can't write "outside the box"), automatic memory mgt., etc., they foolishly trade safety for speed, reliability for customizability, and so on.
It's so easy to trade safety for speed when you tell yourself that you're such a hotshot programmer that you don't overlook anything (hence no actual loss in safety) and your code is so important that an increase in performance is a Big Deal (probably undetectable to the end user.)
C is the perfect tool for programmers who think this way and a major reason for the general bugginess of software. It's an excellent choice for a small percentage of code and the biggest cause of bugs in the rest.
Maybe we could dispense with this sort of nonsense everytime the NY Times is referred to. If people know what the "mumble...mutter" refers to, they don't need the note. If they don't, then the note doesn't help.
Being hand-crafted and written in C are related. Most developers overestimate the value of custom solutions to every problem. A language like C, with no built-in string type, no collections other than the most primitive array, no memory mgt above the finest-grained primitives, and so on, seduce programmers into working at too low a level of abstraction for most problems.
The nature of C is such that it is a good choice for the software equivalent of "innermost loop" code: small bits of code in constant use with crystal clear functional requirements that never change. The 1% of code that accounts for 95% of all CPU cycles should probably be written in C, massively code reviewed, tested exhaustively, and rarely upgraded.
Code of this sort should mostly be in the OS itself, although it's also in the "engine" portion at the heart of Big Apps, like database engines, spreadsheet recalc engines, text rendering engines, etc.
But programmers flatter themselves that everything they write is this type of code and use C for the other 99% for which it is ill-suited. Instead of working at a higher level, using built-in Unicode Strings, well-designed collections classes (where you simply can't write "outside the box"), automatic memory mgt., etc., they foolishly trade safety for speed, reliability for customizability, and so on.
It's so easy to trade safety for speed when you tell yourself that you're such a hotshot programmer that you don't overlook anything (hence no actual loss in safety) and your code is so important that an increase in performance is a Big Deal (probably undetectable to the end user.)
C is the perfect tool for programmers who think this way and a major reason for the general bugginess of software. It's an excellent choice for a small percentage of code and a poor choice for the rest.
...And if you couldn't see it, maybe you need to educate yourself.
I'm well aware of the butterfly effect, including its implications. The combination of massive amplification with extreme nonlinearity makes it impossible to connect cause and effect with any reliability when you lack perfect knowledge (i.e. outside pure math), given sufficient separation.
If someone is going to quote the butterfly effect as evidence for his assertion of a cause and effect separated by 47 years in the real world, I'd have to say that he doesn't understand the implications of the butterfly effect. If you couldn't see that, maybe you don't either.
Then there'd be no discussion, and the ideas are often worth discussing. If you don't think so, propose a Cringely category (if there isn't one already) and unsubscribe instead of trying to unsubscribe all of us.
It's politically incorrect to say anything good about Flash on Slashdot, so you have to say goofy things like "Flash based, but still very good". Unless of course you don't care about/. political orthodoxy, in which case you are free to call it a very good Flash-based presentation.
the political instability in the region hasn't ceased since then
It hasn't ceased for millenia. This was a mere five years after the bloody Israeli war of independence, yet you pick an incident in 1954 and blame it for the region's instability.
Just as a butterfly flapping its wings in the Canary Islands may create a hurricane that wipes out Miami, a single act of nation wrecking can lead to the collapse of two skyscrapers 47 years later.
If you are claiming that something as insignificant and unnoticed as a butterfly flapping its wings can create such an enormous impact on something far away and apparently unrelated, then what makes you think you have any credibility in claiming your 47 year chain of causality? What goofy reasoning. Bin Ladin ISN'T killing to encourage democracy in the Muslim world, Iran or elsewhere.
Think about it: no Iran-Contra, no Gulf War, no 9/11 attacks, no coming world economic collapse when/if the oil supply suddenly runs out.
Let's join hands and sing John Lennon songs.
No, we would have wars about other things, like Communism or religion. Oil has only mattered for a century. Did war exist before that? Oh, wait, I forgot. War started with the creation of the CIA.
And as for the oil supply "suddenly" running out, where do I even begin? Does the name Jeremy Rifkin ring a bell? The more technology improves, the more years-worth of oil we can prove we have. The economics of oil will slowly change, and so will the technologies. We'll be able to manufacture it before the end of this century, if we still need it (we won't). Long before we ever run out, the amount of oil in proven reserves will have gradually become irrelevant.
Yes, and it's a lot harder for you to write the characters needed for programming in C++ or Perl. I'd rather have my English keyboard.
HOWEVER, what I'd like best of all would be to replace the dumb keyboard (hit a key, get the character printed on the key cap) with smart input methods at the OS level (maybe keyboard driver level if you don't have a GUI).
For example, I should be able to type user-defined abbreviations and have the OS replace them with what they represent. I should be able to type "deja vu" and have the OS input dictionary automatically replace it with "déjà vu" and so on. We should be able to use the tab key for autocompletion and substitution, so if I type e/ then tap the tab key, it might replace e/ with é, and so on.
Yes, I know we have some of this functionality in unix shells like bash, some in emacs, some in word processors like MS-Word, etc. I'd like it at the OS level so that no matter what I was typing into, I would have a virtual keyboard much more powerful than my simple physical keyboard and one that I could optimize for the characters/words/phrases I needed most often.
The problem is the diversity of characters used by people around the world, regardless of how they are encoded. Encoding them in anything other than Unicode would make the problem dramatically worse because no group will sit back for long and allow their language to be excluded from global naming protocols on this shared "worldwide" platform.
Having everyone share an ASCII-only system is no longer a viable option, so either everyone shares a single system that covers all languages (Unicode is the only viable option), or the system breaks up into a composite of conflicting encodings. (.com could be registered as half a dozen different byte sequences by different registrars.)
The Unicode solution is the only one that makes sense, then you have to look at rules for the use of characters. You would have to look at the rules for the use of characters even without Unicode. It's just that Unicode makes it so much simpler than the composite alternative that a solution is probably possible.
This IDNC3 proposal is a good start, but there are even more issues. People who wave their arms about the "problems of Unicode" aren't helping, though. Almost all of them are really just advocating "let's keep it simple by limiting it to the characters I need and disallowing yours", and that won't fly any longer.
Nobody who understands text data would use anything other than Unicode except for legacy handling. Using different encodings for different languages is as ridiculous today as using different encodings for English on different platforms used to be before everyone agreed to exchange data in ASCII.
Computer "enthusiasts" love to tinker with their toys. The rest of the business world hates the demands computers and software make on their valuable time and attention. We often label them "lusers" for the unpardonable crime of being more interested in running the economy than in endlessly tinkering with our favorite toys.
Right or wrong, that's how they feel and it's worth a few hundred extra dollars per person in software purchase price to avoid adding more "computer stuff" to the things most professionals have to pay attention to.
Most companies will gladly pay the MS tax if the alternative is today's Linux. Why would they subject their employees to a steep learning curve leading to significantly reduced functionality (as a business client machine) for the sake of a few hundred dollars per person?
They're almost all hoping, though, that someone else will go first and make Linux such a great business platform for non-computer types that it will be well worth the learning curve for the average business desktop/laptop user. Increased functionality would almost have to mean more savvy at figuring out what you want to accomplish with less required input from you. (Hardly the state of today's Linux, which prides itself on being amazingly customizable if you have the time, interest, and expertise to spend working on it.)
At that point, saying goodbye to MS will just be frosting on the cake, but until then most businesses will say, "you go first".
It sucks that all these great technologies are being relegated to obscurity because of...
I was trying to figure out how to end that sentence, and all I could come up with was Microsoft and FUD. I've been reading too much Slashdot!
Yes, you have. While it's true that MS can often save a language from obscurity (BASIC), it's hardly the only way, and making languages popular isn't MS's responsibility.
Languages like Java, JavaScript, and Perl are extremely popular, yet they owe little to MS. MS pushed for J++, JScript, and ignored Perl almost entirely until very recently, but that didn't matter much.
What it takes for a language to become popular is some huge advantage -- being the best way to do something that suddenly booms in importance (Perl for CGI) or having billions of dollars of development put behind it (Java, which was also in the right place at the right time), or being an incremental successor that keeps adding goodies to the most popular language (C++ absorbing C developers) so other (better) languages can't easily lure them away.
A language having some nice features is... nice, but that's not enough.
I agree with your frustration, though. I really wish that it could be possible for each of us to create his dream language and just use it wherever we go. Create a way for that to happen, and you'll have real popularity.
Make sure you work for a company that has its programmers in the same building with you.
Try to find a company using technologies of long-term interest to you.
Get to know some of the programmers. Have lunch with them.
Sharpen your skills with the technologies they use. If they do Java servlets, then you start building Java servlets. If they do VC++ Windows client apps, you do the same. Do it at home until you're pretty good, then start doing it to help out at your job (in your own department).
Then, when there is a dev crunch for the programmers, volunteer to help. Go to the engineering mgr, tell him that you've been doing this kind of work for the company in your dept. and ask if he'd like to borrow you for some side projects to help ease the resource crunch a bit.
He'll probably be interested, and he'll become your advocate. The guys you have lunch with might vouch for you. If you do a good job (don't prove you're better than they are, prove that their lives are easier with you on the team), you'll soon be pulled in full time.
After working there a while, you can go work somewhere else, using your demonstrated pro experience as your resume.
I agree about the environment. I'm recovering from surgery, and nobody knows I'm not in my cubicle. I'm hardly able to move, but I'm back to working full time from a bed. Of course that would be a bad thing if I didn't love my job, but I do. I love having a job where I can leave my sick bed and rejoin the world of the living -- without ever leaving my sick bed.
Even so, what you're saying about atmosphere reflects attitudes that tend to change (don't always, but tend to) as you get older and have a family. You get less interested in yourself (ideally) and more interested in the hopes and dreams of your family members. Your wife gets discouraged about where you're living, for example, and suddenly your jeans and T-shirts don't mean that much to you.
PHP programmers around you may have enough work to keep them employed, but skilled C programmers in their 40s or skilled COBOL programmers in their 60s may find such jobs pretty uninspiring.
If your career is expected to top out before you get your first gray hair, that's a dead end career, whether you can stay employed forever or not.
On the other hand, that pretty much describes the situation for star professional athletes, too, so perhaps "dead end career" is a bit too harsh. It's more like a "time-limited career", that implies the need for more than one career over the course of a lifetime. And that's not so bad....
I was a fulltime programmer. Now I'm in marketing, but I have a specialty programming skill that means that I still write code some days.
Doing both jobs, I can clearly see a difference. The biggest difference I see is that coding is a solitary "disappear into an artificial world inside my own head" type of activity, while marketing involves realtime interaction with the external world.
Coding requires an environment designed to shield me from the outside world so I don't notice it and come out of my "trance". Marketing requires paying close attention to the subtleties of the outside world and interacting with it cleverly in real time. The more I pay attention to the external world, especially to other people, the better I do.
I find that my biggest challenge in marketing is paying close attention to the external world for long stretches of time. While the "real" marketers can listen closely and catch the subtleties in almost everyone's comments during a long meeting, I find that the first time anyone says something interesting, I tend to take it offline inside my head, pondering it, missing not only the subtleties of subsequent comments, but often not hearing a word they said.
Both activities are difficult to do well, but they're definitely not the same. I think most jobs, like your daycare center example, are like my marketing job. You have to keep your eye on a whole bunch of kids simultaneously and respond correctly in real time.
Programming isn't unique, but it is very different from most jobs in its requirement that you stop paying attention to the outside world, turn inward and just think for long stretches. Programmers who can only do it for short stretches can still implement others' designs by chipping away at the task list, but they run into trouble when they have to blaze the trail themselves.
Nice guess, but not correct. Yahoo doesn't use techies as Web designers. They gave that up in early Tim Koogle days.
You may like the design, but that doesn't mean they let programmers design their pages.
The look comes from their early adoption of a pay-per-view advertising business model, which happened when the business people took over control from the founding techies. The more ad views per second, the greater the revenue, so get the pages up FAST, and move them thru to other sub-services with more targeted ads ASAP. No dawdling on the home page, because the higher rates come from the more targeted internal ads.
The techies at Yahoo don't do page content or design. That's the job of the "producers", who get their orders from the business people.
Slashdot Mirror
I'm assuming that by "commodity PC" you mean a standard x86 machine onto which you can install a non-MS x86 OS.
If the chips/BIOS are set up in such a way as to literally prevent the installation of a non-MS OS onto the bare machine, then there will be enough market demand for machines without this restriction that the market will fork. I'm not claiming that it will fork half-and-half, just that there will be enough demand in the world to create a market. The market may be too small or politically sensitive for the likes of Dell or HPAQ, but some Asian manufacturer(s) could make a good living off that market.
More likely, the existence of the extra crypto hardware can be accommodated by new designs in Linux/*BSD/etc. and might actually become quite useful to a user with complete personal control over its capabilities.
At some point, it would make sense for a service bureau to offer the service of reclaiming data off old media and copying as much as possible onto new media. We already have SBs that will recover data from crashed hard drives and others that will copy old super8 movies onto VHS and others that will move VHS to DVD.
It seems that there is a generic business here: moving data from old, even damaged, media to new media. A lot of local SBs already do parts of this. Maybe over time, we'll see a franchise appear offering a wide range of such services, that uses old designs and virtual machines to manufacture the necessary equipment for its franchisees....
As I've gotten older, I've noticed a definite change in my orientation from a close up on my own personal here and now to a wide angle view of family history. I remember my parents when they were younger than I am now. I can remember my grandfather when he wasn't much older than I am now, and I'm surprised at how I'm beginning to relate to them as peers.
They're gone now, but I want to know them more now than I ever did. The photos aren't even close to being enough, but I'm sure I glad I have them.
Maybe the original poster is just too young to have had experiences such as you describe, but I'm with you 100%. Like most Slashdotters, I imagine, I'm more oriented toward the future than the past. Even so, sometimes I imagine what it might be like to have a "holodeck" recreation of my surroundings as a child. Sitting in the back seat of our old car, with a young Mom and Dad in the front seat, surrounded by my favorite candies, some of my old toys....
I don't know how realistic VR is going to become, but even if I have to just do it in my head, having pictures of the old people, places, and things helps me to recreate a world that was good to me and fill in a lot of the details. Seeing even older pictures helps me to recreate worlds that had a big impact on my life, even though they disappeared before I came along.
These things matter to me, and they matter more as I get older and can begin to really feel my place in the sweep of human history.
You say the universe is conspiring to keep you unemployed, yet what you want to do with your time is fill in gaps in your Babylon 5 collection?
What's wrong with this picture? Could it be that YOU are part of the conspiracy? Perhaps, say, the leader?
Using better languages could reduce software bugginess dramatically, but only if programmers admit they have a problem.
Most developers overestimate the value of custom solutions to every problem. A language like C, with no built-in string type, no collections other than the most primitive array, no memory mgt above the finest-grained primitives, and so on, seduce programmers into working at too low a level of abstraction for most problems.
The nature of C is such that it is a good choice for the software equivalent of "innermost loop" code: small bits of code in constant use with crystal clear functional requirements that never change. The 1% of code that accounts for 95% of all CPU cycles should probably be written in C, massively code reviewed, tested exhaustively, and then left alone to do its well-defined and unchanging job.
Code of this sort should mostly be in the OS itself, or in libraries, although it's also appropriate in the "engine" portion at the heart of Big Apps, like database engines, spreadsheet recalc engines, text rendering engines, etc.
But programmers flatter themselves that everything they write is this type of code and use C for the other 99% for which it is ill-suited. Instead of working at a higher level, using built-in Unicode Strings, well-designed collections classes (where you simply can't write "outside the box"), automatic memory mgt., etc., they foolishly trade safety for speed, reliability for customizability, and so on.
It's so easy to trade safety for speed when you tell yourself that you're such a hotshot programmer that you don't overlook anything (hence no actual loss in safety) and your code is so important that an increase in performance is a Big Deal (probably undetectable to the end user.)
C is the perfect tool for programmers who think this way and a major reason for the general bugginess of software. It's an excellent choice for a small percentage of code and the biggest cause of bugs in the rest.
That way, they'll get more rain without the bother of having to pack them up and move them.
Maybe we could dispense with this sort of nonsense everytime the NY Times is referred to. If people know what the "mumble...mutter" refers to, they don't need the note. If they don't, then the note doesn't help.
Being hand-crafted and written in C are related. Most developers overestimate the value of custom solutions to every problem. A language like C, with no built-in string type, no collections other than the most primitive array, no memory mgt above the finest-grained primitives, and so on, seduce programmers into working at too low a level of abstraction for most problems.
The nature of C is such that it is a good choice for the software equivalent of "innermost loop" code: small bits of code in constant use with crystal clear functional requirements that never change. The 1% of code that accounts for 95% of all CPU cycles should probably be written in C, massively code reviewed, tested exhaustively, and rarely upgraded.
Code of this sort should mostly be in the OS itself, although it's also in the "engine" portion at the heart of Big Apps, like database engines, spreadsheet recalc engines, text rendering engines, etc.
But programmers flatter themselves that everything they write is this type of code and use C for the other 99% for which it is ill-suited. Instead of working at a higher level, using built-in Unicode Strings, well-designed collections classes (where you simply can't write "outside the box"), automatic memory mgt., etc., they foolishly trade safety for speed, reliability for customizability, and so on.
It's so easy to trade safety for speed when you tell yourself that you're such a hotshot programmer that you don't overlook anything (hence no actual loss in safety) and your code is so important that an increase in performance is a Big Deal (probably undetectable to the end user.)
C is the perfect tool for programmers who think this way and a major reason for the general bugginess of software. It's an excellent choice for a small percentage of code and a poor choice for the rest.
...And if you couldn't see it, maybe you need to educate yourself.
I'm well aware of the butterfly effect, including its implications. The combination of massive amplification with extreme nonlinearity makes it impossible to connect cause and effect with any reliability when you lack perfect knowledge (i.e. outside pure math), given sufficient separation.
If someone is going to quote the butterfly effect as evidence for his assertion of a cause and effect separated by 47 years in the real world, I'd have to say that he doesn't understand the implications of the butterfly effect. If you couldn't see that, maybe you don't either.
Then there'd be no discussion, and the ideas are often worth discussing. If you don't think so, propose a Cringely category (if there isn't one already) and unsubscribe instead of trying to unsubscribe all of us.
It's politically incorrect to say anything good about Flash on Slashdot, so you have to say goofy things like "Flash based, but still very good". Unless of course you don't care about /. political orthodoxy, in which case you are free to call it a very good Flash-based presentation.
An orthodox Jew won the popular vote for the vice presidency in the last election.
the political instability in the region hasn't ceased since then
It hasn't ceased for millenia. This was a mere five years after the bloody Israeli war of independence, yet you pick an incident in 1954 and blame it for the region's instability.
Just as a butterfly flapping its wings in the Canary Islands may create a hurricane that wipes out Miami, a single act of nation wrecking can lead to the collapse of two skyscrapers 47 years later.
If you are claiming that something as insignificant and unnoticed as a butterfly flapping its wings can create such an enormous impact on something far away and apparently unrelated, then what makes you think you have any credibility in claiming your 47 year chain of causality? What goofy reasoning. Bin Ladin ISN'T killing to encourage democracy in the Muslim world, Iran or elsewhere.
Think about it: no Iran-Contra, no Gulf War, no 9/11 attacks, no coming world economic collapse when/if the oil supply suddenly runs out.
Let's join hands and sing John Lennon songs.
No, we would have wars about other things, like Communism or religion. Oil has only mattered for a century. Did war exist before that? Oh, wait, I forgot. War started with the creation of the CIA.
And as for the oil supply "suddenly" running out, where do I even begin? Does the name Jeremy Rifkin ring a bell? The more technology improves, the more years-worth of oil we can prove we have. The economics of oil will slowly change, and so will the technologies. We'll be able to manufacture it before the end of this century, if we still need it (we won't). Long before we ever run out, the amount of oil in proven reserves will have gradually become irrelevant.
Yes, and it's a lot harder for you to write the characters needed for programming in C++ or Perl. I'd rather have my English keyboard.
HOWEVER, what I'd like best of all would be to replace the dumb keyboard (hit a key, get the character printed on the key cap) with smart input methods at the OS level (maybe keyboard driver level if you don't have a GUI).
For example, I should be able to type user-defined abbreviations and have the OS replace them with what they represent. I should be able to type "deja vu" and have the OS input dictionary automatically replace it with "déjà vu" and so on. We should be able to use the tab key for autocompletion and substitution, so if I type e/ then tap the tab key, it might replace e/ with é, and so on.
Yes, I know we have some of this functionality in unix shells like bash, some in emacs, some in word processors like MS-Word, etc. I'd like it at the OS level so that no matter what I was typing into, I would have a virtual keyboard much more powerful than my simple physical keyboard and one that I could optimize for the characters/words/phrases I needed most often.
...but it will have to be part of the solution.
The problem is the diversity of characters used by people around the world, regardless of how they are encoded. Encoding them in anything other than Unicode would make the problem dramatically worse because no group will sit back for long and allow their language to be excluded from global naming protocols on this shared "worldwide" platform.
Having everyone share an ASCII-only system is no longer a viable option, so either everyone shares a single system that covers all languages (Unicode is the only viable option), or the system breaks up into a composite of conflicting encodings. (.com could be registered as half a dozen different byte sequences by different registrars.)
The Unicode solution is the only one that makes sense, then you have to look at rules for the use of characters. You would have to look at the rules for the use of characters even without Unicode. It's just that Unicode makes it so much simpler than the composite alternative that a solution is probably possible.
This IDNC3 proposal is a good start, but there are even more issues. People who wave their arms about the "problems of Unicode" aren't helping, though. Almost all of them are really just advocating "let's keep it simple by limiting it to the characters I need and disallowing yours", and that won't fly any longer.
Nobody who understands text data would use anything other than Unicode except for legacy handling. Using different encodings for different languages is as ridiculous today as using different encodings for English on different platforms used to be before everyone agreed to exchange data in ASCII.
Very informative. Thanks.
Computer "enthusiasts" love to tinker with their toys. The rest of the business world hates the demands computers and software make on their valuable time and attention. We often label them "lusers" for the unpardonable crime of being more interested in running the economy than in endlessly tinkering with our favorite toys.
Right or wrong, that's how they feel and it's worth a few hundred extra dollars per person in software purchase price to avoid adding more "computer stuff" to the things most professionals have to pay attention to.
Most companies will gladly pay the MS tax if the alternative is today's Linux. Why would they subject their employees to a steep learning curve leading to significantly reduced functionality (as a business client machine) for the sake of a few hundred dollars per person?
They're almost all hoping, though, that someone else will go first and make Linux such a great business platform for non-computer types that it will be well worth the learning curve for the average business desktop/laptop user. Increased functionality would almost have to mean more savvy at figuring out what you want to accomplish with less required input from you. (Hardly the state of today's Linux, which prides itself on being amazingly customizable if you have the time, interest, and expertise to spend working on it.)
At that point, saying goodbye to MS will just be frosting on the cake, but until then most businesses will say, "you go first".
It sucks that all these great technologies are being relegated to obscurity because of ...
... nice, but that's not enough.
I was trying to figure out how to end that sentence, and all I could come up with was Microsoft and FUD. I've been reading too much Slashdot!
Yes, you have. While it's true that MS can often save a language from obscurity (BASIC), it's hardly the only way, and making languages popular isn't MS's responsibility.
Languages like Java, JavaScript, and Perl are extremely popular, yet they owe little to MS. MS pushed for J++, JScript, and ignored Perl almost entirely until very recently, but that didn't matter much.
What it takes for a language to become popular is some huge advantage -- being the best way to do something that suddenly booms in importance (Perl for CGI) or having billions of dollars of development put behind it (Java, which was also in the right place at the right time), or being an incremental successor that keeps adding goodies to the most popular language (C++ absorbing C developers) so other (better) languages can't easily lure them away.
A language having some nice features is
I agree with your frustration, though. I really wish that it could be possible for each of us to create his dream language and just use it wherever we go. Create a way for that to happen, and you'll have real popularity.
Make sure you work for a company that has its programmers in the same building with you.
Try to find a company using technologies of long-term interest to you.
Get to know some of the programmers. Have lunch with them.
Sharpen your skills with the technologies they use. If they do Java servlets, then you start building Java servlets. If they do VC++ Windows client apps, you do the same. Do it at home until you're pretty good, then start doing it to help out at your job (in your own department).
Then, when there is a dev crunch for the programmers, volunteer to help. Go to the engineering mgr, tell him that you've been doing this kind of work for the company in your dept. and ask if he'd like to borrow you for some side projects to help ease the resource crunch a bit.
He'll probably be interested, and he'll become your advocate. The guys you have lunch with might vouch for you. If you do a good job (don't prove you're better than they are, prove that their lives are easier with you on the team), you'll soon be pulled in full time.
After working there a while, you can go work somewhere else, using your demonstrated pro experience as your resume.
I agree about the environment. I'm recovering from surgery, and nobody knows I'm not in my cubicle. I'm hardly able to move, but I'm back to working full time from a bed. Of course that would be a bad thing if I didn't love my job, but I do. I love having a job where I can leave my sick bed and rejoin the world of the living -- without ever leaving my sick bed.
Even so, what you're saying about atmosphere reflects attitudes that tend to change (don't always, but tend to) as you get older and have a family. You get less interested in yourself (ideally) and more interested in the hopes and dreams of your family members. Your wife gets discouraged about where you're living, for example, and suddenly your jeans and T-shirts don't mean that much to you.
PHP programmers around you may have enough work to keep them employed, but skilled C programmers in their 40s or skilled COBOL programmers in their 60s may find such jobs pretty uninspiring.
If your career is expected to top out before you get your first gray hair, that's a dead end career, whether you can stay employed forever or not.
On the other hand, that pretty much describes the situation for star professional athletes, too, so perhaps "dead end career" is a bit too harsh. It's more like a "time-limited career", that implies the need for more than one career over the course of a lifetime. And that's not so bad....
I was a fulltime programmer. Now I'm in marketing, but I have a specialty programming skill that means that I still write code some days.
Doing both jobs, I can clearly see a difference. The biggest difference I see is that coding is a solitary "disappear into an artificial world inside my own head" type of activity, while marketing involves realtime interaction with the external world.
Coding requires an environment designed to shield me from the outside world so I don't notice it and come out of my "trance". Marketing requires paying close attention to the subtleties of the outside world and interacting with it cleverly in real time. The more I pay attention to the external world, especially to other people, the better I do.
I find that my biggest challenge in marketing is paying close attention to the external world for long stretches of time. While the "real" marketers can listen closely and catch the subtleties in almost everyone's comments during a long meeting, I find that the first time anyone says something interesting, I tend to take it offline inside my head, pondering it, missing not only the subtleties of subsequent comments, but often not hearing a word they said.
Both activities are difficult to do well, but they're definitely not the same. I think most jobs, like your daycare center example, are like my marketing job. You have to keep your eye on a whole bunch of kids simultaneously and respond correctly in real time.
Programming isn't unique, but it is very different from most jobs in its requirement that you stop paying attention to the outside world, turn inward and just think for long stretches. Programmers who can only do it for short stretches can still implement others' designs by chipping away at the task list, but they run into trouble when they have to blaze the trail themselves.
Nice guess, but not correct. Yahoo doesn't use techies as Web designers. They gave that up in early Tim Koogle days.
You may like the design, but that doesn't mean they let programmers design their pages.
The look comes from their early adoption of a pay-per-view advertising business model, which happened when the business people took over control from the founding techies. The more ad views per second, the greater the revenue, so get the pages up FAST, and move them thru to other sub-services with more targeted ads ASAP. No dawdling on the home page, because the higher rates come from the more targeted internal ads.
The techies at Yahoo don't do page content or design. That's the job of the "producers", who get their orders from the business people.