Aside from fixing the browsers, that is. We could create a WYSIWIG front end for generating xhtml and css. Put the intelligence in there to generate the hellacious hacks in the code. Have it generate different stylesheets to be used by different browsers. When new bugs come out just update the app. There are plenty of WYSIWIG apps out there for making web pages that could be upgraded this way. Nvu is the first to come to mind.
If you're using a server-side framework like ASP, PHP, ROR or mod_perl, the front end could easily generate the browser detection code to choose which stylesheet to be used on a per browser basis. There are only a small number of these frameworks in use, less than 10 cover over 95% of the web pages, I'm sure.
We don't hand-generate machine-code anymore, why should we hand-generate CSS, or HTML?
A better book on CSS differs little from a great manual on how to hand-crank a Model T Ford. WYSIWYG was invented in the 1970's. Layout using Wysiwyg tools has its problems, but CSS seems to solve none of them. (Maybe one, but I don't know which one).
The tragedy is that I really need a better book on CSS.
Hand-coded CSS seems to be hanging on mainly because people still need to hand-code HTML, even though that should be WYSIWYG too. And hand-coded HTML seems to be hanging on mainly because of mixin-languages like PHP which enable database integration. Word processors usually don't need database integration. Note that Microsoft went to great lengths to allow people to embed live spreadsheets into Word docs, a feature that has been widely ignored. Still, it's past time for web design to leave explicit hand-coding behind. Or else what's all this Computer Science for?
It isn't a scandal for the government to try to use logic and persuasion to stop the NYT from publishing secrets. These are, in effect, military secrets in time of war.
The NYT article itself says that the program was not being abused and that safeguards were in place. It's the US governments job to go after al-Queda and others making war against the US. Publishing the article made al-Queda safer but did not safeguard the rights of the citizens of the US or anywhere else.
The individuals in government who leaked the information to the NYT have violated US law. This is a bigger scandal.
It is interesting that the program is legal and the NYT story goes to great lengths to emphasize this. And also emphasizes that the program has already helped find some terrorists. The NYT also emphasized that both Democrats and Republicans have lobbied the newspaper intensively arguing that revealing the system will help terrorism and quite possibly result in additional deaths due to terrorism.
Yet the NYT insisted on publishing anyway. Since the story is no real scandal; Why?
"One should never, EVER attempt to optimize code on the first pass."
Sorry, that's too strong. Or misleading. It's no longer the first pass. We're well onto to our 10th or 100th pass, with kernels and operating systems. We're not trying to build the first one. We're trying to build a better one. That means analyze the old to build the new.
That would be like saying the folks coding weather prediction or climate models should code it first in javascript or ruby and then "Optimize" it into FORTRAN "Once the bugs are out". You can't really build a monolithic OS and then optimize it into microkernel. That's a pretty big refactoring!
Clearly this technological competition from overseas is a threat to our national security and that of the entire free world. Got the winners list? Ever heard of "Extraordinary Rendition"?
The tranquility of the New World Order cannot be threatened by a pack of under-age nerds and foreigners!
Re:Emacs and Vim are both old-school
on
Vim 7 Released
·
· Score: 1
I don't think they have latex/tex and source insight only runs on windows. Slickedit has a binary they sell apparently for x86 linux, though. It's $300 plus $60/year thereafter. Not free.
Emacs and Vim are both old-school
on
Vim 7 Released
·
· Score: 1
And they are quite ugly and hard to use. The tags systems are antediluvian. See Source Insight or Visual Slickedit for a much better approach (although they are both proprietary). They both illustrate a lot of the weaknesses of FOSS (not that there aren't strengths too).
But you can use either vim or emacs on a linux server you're getting to via SSH and you can do fix ups. The only alternative is 'ed'.
I was recently astonished to discover that vim is ahead of emacs in editing right-to-left text. That is, Arabic and Hebrew (and probably Farsi). I had switched from the old vi to emacs in the 1980's and hadn't been following vim development. The idea that vim was ahead of emacs in anything was a shock. But it is.
When I took freshman composition in the 1960's they made us read old books that the literature teacher liked (Canterbury Tales, maybe?) and I think I also had to read something by St. Augustine, which I found offensive on religious grounds.
Any topic that is too PC, is religious or dogmatic or insults the value systems of the students is going to generate resentment. If they can write to the resentment and use the anger, fine. But usually students understand the teachers ideology as the Party Line, stifling energy.
At one point in college they made us engineers write "how to" manuals for putting on a coat or turning on a computer (harder back then) thinking that was more copacetic than old farty poems. It was boring, too.
Nowadays we have email and web content. Get them to write long involved stories or explanations that will be sent out or published on the web. The vision of real people reading your stuff can be energizing. This is the 21st century, composition has become textual content.
An assignment based on fantasy and/or science fiction has the possibility of inspiring in a more flexible way. The romantically inclined can write about interplanetary romance, the techno-geeks can write about solar sails and nuclear fusion, and the frat boys can write about beer in space, if they are so inclined.
A writing assignment is like the premise of a sitcom or weekly cop show. Each week some new characters come into the airport, hospital, police station or the office and have their little drama and leave. A flexible premise allows different screenwriters to shovel in their own themes and plots.
I knew of a student who tried to write an essay about how to smoke pot (this was the sixties) and came within a nanometer of being kicked out of school. Tell them the rules early. Like maybe it has to be in English, written, with text and not comic book drawings, and no profanity. Or whatever your rules are.
People who post on forums are motivated to write a lot and get practice. There's a little crackpot in everybody and if you can get to it (punch the right buttons) maybe you can turn on the spigot of text and get them practicing.
Software engineers are, for some reason, the most logorrheac of all techies. They write endlessly about the internal and inter-personal process of writing software. I think it all comes from having too much keyboard time. Make sure all your students know how to touch type -- it widens the gates.
People learn by seeing good examples and bad examples of the same paragraph. They also learn by modifying their own text over and over. If you know how to teach patience and how to teach them to accept criticism gratefully then, uh, you don't need any help from me.
This article is based on a Coverity press release. These are the same people who put out a somewhat misleading press release on the bugginess of Linux vs Windows.
They counted bugs per line instead of bugs per function. So for 2 modules that did the same function and and had the same number of bugs, the one with more bloat was counted as less buggy.
Not that there is necessarily anything wrong with Coverity tools -- I haven't used them. But their press releases have logic errors.
Today's press release says programmers are being managed to work better because they bought Coverity tools. Maybe, maybe not.
I wrote a lot of multi-threaded code on a uniprocessor for embedded systems development. It turns out that a few things really simplify multi-thread code:
The only reason to multi-thread is performance
Almost all useful multi-thread apps that need a performance boost are accepting a stream of data and/or emitting a stream of data
Producer-Consumer relationships therefore solve most of what you need.
You can use a thread like a mutex. That is, you can have the thread accept events that order it to modify the data store and send back events that the data store has been modified. This is little different from what a monitor has to do internally anyway but is more powerful and often much easier.
Data streams are physical, usually coming to or from actual devices, not necessarily from logical sources like users. An OS will use a heavyweight process to separate users as a security tool, but a thread is a different creature.
It is still true that the structure of the software is often a simple reflection of the social structure of the team that built it. Beware of a situation where each programmer has to create his or her own thread to feel "Real". And go ballistic if you find programmers who need to raise their thread's priority to feel important.
Sun was putting out lots of internet-enabled and ethernet-enabled machines when Wintel was putting out zillions of un-networked or at least non-internetted machines. At first many of the first company and university nodes with internet addresses were vax machines. After that, the large number of Sun workstations and servers on the net enabled it to grow to the size where the next big push in net size came from wintel boxes on AOL and modems.
If it weren't for Sun, the argument is, some other internetworking and lan technology besides TCP/IP might have been the path, which might have grown much more slowly. The phone companies were pushing for the 7-layer stack et cetera...
Okay, you can pronounce "fork" okay. But what about "creat", "sqrt" or "chmod"? Then if you create a variable "szUser" you're going to have to spell it out and create a verb to permit camel-casing and all that.
I've actually had RSI and used previous voice systems. It's good for email to your family but tough when you have to make up "a += zlch(bz)" as you go. That stuff isn't in it's dictionary.
And vocal cord soreness actually is a known problem of these systems.
My advice: Stay out of the disability system as long as you can. They can spend money and not help you. They can send you to plenty of doctors who are useless. They will buy you an ergonomic chair that has little relevance. They will not protect you against employer discrimination. They will motivate employers to never hire you again until you move to another state. They will bill the last employer you worked for so that they blacklist you, even if most of the damage occurred under a different employer.
In the US, if you're out of work for a year or two the employers cannot be sure you weren't in jail. Jail records go behind a curtain after a certain number of years to protect against discrimination against ex-cons. So if you're not an ex-con the employer has to assume you may be one.
1. Pretentiousness
Brundage didn't get across the results of the "Influence" factor. Employees know everybody is watching and the software has a huge audience. They understand that they are truly important people in the world. Sometimes this gets quite pretentious. Sometimes things that would be pretentious anywhere else are actually appropriate for Microsoft employees. In many other companies I've worked at the employees only view the company as a way to earn money to get along -- not so at Microsoft.
The other result of the huge audience is that many (not all) developers have become exceedingly careful about creating anything that is a bug, looks like a bug, will be mistaken for a bug, or will generate support questions. A million emails or phone calls to complain about something that's "Actually correct" is very expensive to handle. It has to look right too.
2. Intelligence
Two or three of the people I've worked with at Microsoft are so intelligent it was actually frightening to watch them think. They could do things that I didn't know could be done. Look at a whole new program and gather it's purpose at a glance -- and see the bugs!
3. Popularity breeds cynicism.
By now all the important developers at MS are aware that solving the security problems are an ideal way to install additional controls on user and developer behavior; Such as changing protocols so that only MS products can interface with each other. Not that this is universally done. But it's an available tool. Likewise,the withdrawal of the Macro Assembler is for security but adds to MS control. MS has better software development tools (compilers and linkers, for example) than it sells to its customers use. This is perfectly legal and sensible but not an "Open" philosophy. It is easy for the OS to tell the difference between applications developed in-house, with retail compilers, and with competitive compilers. Occasionally there is a good reason to do this, so there is plenty of cover.
C++ frameworks for Windows development were, in my subjective opinion, deliberately sabotaged. Any really "Good" C++ class library for programming Windows could be ported to Apple or Linux, but MFC could not. Observe the history of ATL/WTL. They "Solved" this problem with.NET, which allows development with good tools that don't threaten MS with portability of applications.
4. Middle Management and "Reorgs"
A bane of existance at Microsoft. This actually may be one of the reasons that the company is so successful (I'm not sure) but the constant shake-ups are disruptive and expensive. The matrix of Product Managers, Program Managers and Project Managers is confusing even to the people with the titles.
5. More features than they can market.
There is no way the image of the company or of any of it's products can be allowed to be as complex as the actual products. Important inventions, features and innovations get buried. Abortions like OLE and even COM get over-emphasized. Bad designs like "IO completion ports" get promulgated to the world and can not be withdrawn.
6. The Caste System
There are several distinct layers of MS technical employees. At the top are the "Software Design Engineers". Next in line are the "Software Design Engineers in Test" ("S/DET's" who write internal test code). Within each of these, the caste is split between full-time blue-badges and lowly temp workers. The third caste is "Testers", sometimes referred to as "Monkeys", likewise split between full-time and temps. By the way, I learned at MS that there is such a thing as a talented tester. People who can break things more quickly and don't seem to mind keying and mousing the same thing over and over for each release. A good developer is not necessarily a good tester.
Social mobility between the castes is rare but it does happen. I've also seen people jump a level and then get fired when they don't work out.
Most of the people applying for college do not intend to go on for post-graduate degrees. CS is only really good if you've got a post-graduate degree (some exceptions apply).
Sure, if you've got and MBA and an undergrad degree in CS it's a good combination. But that's just it. CS is mostly good in combination, not by itself. The career doesn't last long enough. It is also confused with "Software Engineering" enough that it has the same problems -- neither 4 year degree will provide the basis for a career that will raise a family and provide a retirement.
I'm talking about the USA here.
Computers and software is a very dynamic field. That makes it sound interesting until you realize it also means unstable and unreliable. Okay, you might be bored to death doing the same thing for 40 years but "Dynamic Careers" can be hell, too.
Since the US government probably hasn't had time to do a thorough search, there probably are some interesting things buried in there. It might take a few years to sort it all out, but there could be evidence spread out over a series of documents that would surprise the left and the right.
As always, the politically committed will see what they want to see, rather than what's really there. It's hard to have an open mind.
By 1960 we were all supposed to have flying cars. Or at least roads that were ribbons up in the air. And world peace.
In 1960 the AI crowd announced they'd have machine translation of natural language licked by 1970. It isn't exactly licked yet.
So some things will change and some won't. The bathrooms of 1950 are a lot like the bathrooms of 2006. So are the livingrooms and even the garages. The TV's are different but the cars are quite recognizable. The bicycles are different but not radically so. Diapers are different but the babies are the same. The economy was an issue then and is still an issue now. But it's a different issue. In 1950 everybody was terrified by mass unemployment. Now people are scared of less-massive unemployment.
If you get a serious illness, you may cause the company's insurance premiums to go up. The additional costs add up so companies try to keep "Unhealthy" people off the roles.
Further, some companies are "Self-insured" and probably have under-the-table access to your medical records, anyway.
Is business in the business of firing sick workers? See this article on lobbying efforts to change the law in the US.
That's okay. British Columbia is neither British nor Columbia. They don't even export cocaine! Although they do make money from their abundant white powder...
Rails is still suffering growing pains. After that is over, it will have the problems of maturity. Rails has a lot of good ideas, and leveraging Ruby is one of them. But Rails is not well documented. It's almost as if the Rails devlopers have never seen really professional documentation and are happy to just look at the Rails source for information. For example, the API docs don't have a search box.
I think Ruby and Rails are about the right ideas for our current and near future environment -- cheap cpu's, tight schedules, evolving web standards, clueless users, heterogeneous client hardware (browsers and pda's) and ever faster networks.
And, by the way, the current Ruby implementation is not quite as mature as the current Perl or even Java implementations. This will change. The sweet spot for using Rails isn't today, it's the next 5 years or so. So now would be a good time to get the experience.
Not to knock PHP, it lets just anybody put together a dynamic web site without having to know too much. It's a straightforward system ideal for power users who don't want to be computer scientists but who need to build out their ideas. I have a neighbor who's expertise is in marketing and home products who is building his own product line with PHP. Ruby would be beyond him. Who knows, he might just strike it rich with PHP.
Let's two different attempts to, say, parse XML are coded up. Let's further say one module is 1,000 lines of code and the other is 2,000 lines of code. Let's further suppose they have the exact same bugs, possibly resulting from a typo in the spec. The method used by Coverity would rate one version as being twice as buggy as the other. Indeed, the superior effort, the one that used only 1,000 lines of code, would be penalized for it's efficiency!
We need to know exactly what they are doing. At least tell us what you mean by "information censorship" as this term is new to me. Do they censor technical information or is the database filtered for dirty words?
Slashdot Mirror
Also see InfoWorld.
And see Tech Republic.
Then go read everything written by Norman Matloff.
Aside from fixing the browsers, that is. We could create a WYSIWIG front end for generating xhtml and css. Put the intelligence in there to generate the hellacious hacks in the code. Have it generate different stylesheets to be used by different browsers. When new bugs come out just update the app. There are plenty of WYSIWIG apps out there for making web pages that could be upgraded this way. Nvu is the first to come to mind.
If you're using a server-side framework like ASP, PHP, ROR or mod_perl, the front end could easily generate the browser detection code to choose which stylesheet to be used on a per browser basis. There are only a small number of these frameworks in use, less than 10 cover over 95% of the web pages, I'm sure.
We don't hand-generate machine-code anymore, why should we hand-generate CSS, or HTML?
A better book on CSS differs little from a great manual on how to hand-crank a Model T Ford. WYSIWYG was invented in the 1970's. Layout using Wysiwyg tools has its problems, but CSS seems to solve none of them. (Maybe one, but I don't know which one).
The tragedy is that I really need a better book on CSS.
Hand-coded CSS seems to be hanging on mainly because people still need to hand-code HTML, even though that should be WYSIWYG too. And hand-coded HTML seems to be hanging on mainly because of mixin-languages like PHP which enable database integration. Word processors usually don't need database integration. Note that Microsoft went to great lengths to allow people to embed live spreadsheets into Word docs, a feature that has been widely ignored. Still, it's past time for web design to leave explicit hand-coding behind. Or else what's all this Computer Science for?
It isn't a scandal for the government to try to use logic and persuasion to stop the NYT from publishing secrets. These are, in effect, military secrets in time of war.
The NYT article itself says that the program was not being abused and that safeguards were in place. It's the US governments job to go after al-Queda and others making war against the US. Publishing the article made al-Queda safer but did not safeguard the rights of the citizens of the US or anywhere else.
The individuals in government who leaked the information to the NYT have violated US law. This is a bigger scandal.
Yet the NYT insisted on publishing anyway. Since the story is no real scandal; Why?
Know everything, that is. Nobody wears bellbottoms anymore.
Sorry, that's too strong. Or misleading. It's no longer the first pass. We're well onto to our 10th or 100th pass, with kernels and operating systems. We're not trying to build the first one. We're trying to build a better one. That means analyze the old to build the new.
That would be like saying the folks coding weather prediction or climate models should code it first in javascript or ruby and then "Optimize" it into FORTRAN "Once the bugs are out". You can't really build a monolithic OS and then optimize it into microkernel. That's a pretty big refactoring!
The tranquility of the New World Order cannot be threatened by a pack of under-age nerds and foreigners!
I don't think they have latex/tex and source insight only runs on windows. Slickedit has a binary they sell apparently for x86 linux, though. It's $300 plus $60/year thereafter. Not free.
But you can use either vim or emacs on a linux server you're getting to via SSH and you can do fix ups. The only alternative is 'ed'.
I was recently astonished to discover that vim is ahead of emacs in editing right-to-left text. That is, Arabic and Hebrew (and probably Farsi). I had switched from the old vi to emacs in the 1980's and hadn't been following vim development. The idea that vim was ahead of emacs in anything was a shock. But it is.
Any topic that is too PC, is religious or dogmatic or insults the value systems of the students is going to generate resentment. If they can write to the resentment and use the anger, fine. But usually students understand the teachers ideology as the Party Line, stifling energy.
At one point in college they made us engineers write "how to" manuals for putting on a coat or turning on a computer (harder back then) thinking that was more copacetic than old farty poems. It was boring, too.
Nowadays we have email and web content. Get them to write long involved stories or explanations that will be sent out or published on the web. The vision of real people reading your stuff can be energizing. This is the 21st century, composition has become textual content.
An assignment based on fantasy and/or science fiction has the possibility of inspiring in a more flexible way. The romantically inclined can write about interplanetary romance, the techno-geeks can write about solar sails and nuclear fusion, and the frat boys can write about beer in space, if they are so inclined.
A writing assignment is like the premise of a sitcom or weekly cop show. Each week some new characters come into the airport, hospital, police station or the office and have their little drama and leave. A flexible premise allows different screenwriters to shovel in their own themes and plots.
I knew of a student who tried to write an essay about how to smoke pot (this was the sixties) and came within a nanometer of being kicked out of school. Tell them the rules early. Like maybe it has to be in English, written, with text and not comic book drawings, and no profanity. Or whatever your rules are.
People who post on forums are motivated to write a lot and get practice. There's a little crackpot in everybody and if you can get to it (punch the right buttons) maybe you can turn on the spigot of text and get them practicing.
Software engineers are, for some reason, the most logorrheac of all techies. They write endlessly about the internal and inter-personal process of writing software. I think it all comes from having too much keyboard time. Make sure all your students know how to touch type -- it widens the gates.
People learn by seeing good examples and bad examples of the same paragraph. They also learn by modifying their own text over and over. If you know how to teach patience and how to teach them to accept criticism gratefully then, uh, you don't need any help from me.
They counted bugs per line instead of bugs per function. So for 2 modules that did the same function and and had the same number of bugs, the one with more bloat was counted as less buggy.
Not that there is necessarily anything wrong with Coverity tools -- I haven't used them. But their press releases have logic errors.
Today's press release says programmers are being managed to work better because they bought Coverity tools. Maybe, maybe not.
If it weren't for Sun, the argument is, some other internetworking and lan technology besides TCP/IP might have been the path, which might have grown much more slowly. The phone companies were pushing for the 7-layer stack et cetera...
I've actually had RSI and used previous voice systems. It's good for email to your family but tough when you have to make up "a += zlch(bz)" as you go. That stuff isn't in it's dictionary.
And vocal cord soreness actually is a known problem of these systems.
My advice: Stay out of the disability system as long as you can. They can spend money and not help you. They can send you to plenty of doctors who are useless. They will buy you an ergonomic chair that has little relevance. They will not protect you against employer discrimination. They will motivate employers to never hire you again until you move to another state. They will bill the last employer you worked for so that they blacklist you, even if most of the damage occurred under a different employer.
In the US, if you're out of work for a year or two the employers cannot be sure you weren't in jail. Jail records go behind a curtain after a certain number of years to protect against discrimination against ex-cons. So if you're not an ex-con the employer has to assume you may be one.
Oh great! Now the poeple who are pushing the theory of abiotic petroleum will push it one step further — abiotic fossils!
1. Pretentiousness
Brundage didn't get across the results of the "Influence" factor. Employees know everybody is watching and the software has a huge audience. They understand that they are truly important people in the world. Sometimes this gets quite pretentious. Sometimes things that would be pretentious anywhere else are actually appropriate for Microsoft employees. In many other companies I've worked at the employees only view the company as a way to earn money to get along -- not so at Microsoft.
The other result of the huge audience is that many (not all) developers have become exceedingly careful about creating anything that is a bug, looks like a bug, will be mistaken for a bug, or will generate support questions. A million emails or phone calls to complain about something that's "Actually correct" is very expensive to handle. It has to look right too.
2. Intelligence
Two or three of the people I've worked with at Microsoft are so intelligent it was actually frightening to watch them think. They could do things that I didn't know could be done. Look at a whole new program and gather it's purpose at a glance -- and see the bugs!
3. Popularity breeds cynicism.
By now all the important developers at MS are aware that solving the security problems are an ideal way to install additional controls on user and developer behavior; Such as changing protocols so that only MS products can interface with each other. Not that this is universally done. But it's an available tool. Likewise,the withdrawal of the Macro Assembler is for security but adds to MS control. MS has better software development tools (compilers and linkers, for example) than it sells to its customers use. This is perfectly legal and sensible but not an "Open" philosophy. It is easy for the OS to tell the difference between applications developed in-house, with retail compilers, and with competitive compilers. Occasionally there is a good reason to do this, so there is plenty of cover.
C++ frameworks for Windows development were, in my subjective opinion, deliberately sabotaged. Any really "Good" C++ class library for programming Windows could be ported to Apple or Linux, but MFC could not. Observe the history of ATL/WTL. They "Solved" this problem with .NET, which allows development with good tools that don't threaten MS with portability of applications.
4. Middle Management and "Reorgs"
A bane of existance at Microsoft. This actually may be one of the reasons that the company is so successful (I'm not sure) but the constant shake-ups are disruptive and expensive. The matrix of Product Managers, Program Managers and Project Managers is confusing even to the people with the titles.
5. More features than they can market.
There is no way the image of the company or of any of it's products can be allowed to be as complex as the actual products. Important inventions, features and innovations get buried. Abortions like OLE and even COM get over-emphasized. Bad designs like "IO completion ports" get promulgated to the world and can not be withdrawn.
6. The Caste System
There are several distinct layers of MS technical employees. At the top are the "Software Design Engineers". Next in line are the "Software Design Engineers in Test" ("S/DET's" who write internal test code). Within each of these, the caste is split between full-time blue-badges and lowly temp workers. The third caste is "Testers", sometimes referred to as "Monkeys", likewise split between full-time and temps. By the way, I learned at MS that there is such a thing as a talented tester. People who can break things more quickly and don't seem to mind keying and mousing the same thing over and over for each release. A good developer is not necessarily a good tester.
Social mobility between the castes is rare but it does happen. I've also seen people jump a level and then get fired when they don't work out.
Sure, if you've got and MBA and an undergrad degree in CS it's a good combination. But that's just it. CS is mostly good in combination, not by itself. The career doesn't last long enough. It is also confused with "Software Engineering" enough that it has the same problems -- neither 4 year degree will provide the basis for a career that will raise a family and provide a retirement.
I'm talking about the USA here.
Computers and software is a very dynamic field. That makes it sound interesting until you realize it also means unstable and unreliable. Okay, you might be bored to death doing the same thing for 40 years but "Dynamic Careers" can be hell, too.
As always, the politically committed will see what they want to see, rather than what's really there. It's hard to have an open mind.
By 1960 we were all supposed to have flying cars. Or at least roads that were ribbons up in the air. And world peace.
In 1960 the AI crowd announced they'd have machine translation of natural language licked by 1970. It isn't exactly licked yet.
So some things will change and some won't. The bathrooms of 1950 are a lot like the bathrooms of 2006. So are the livingrooms and even the garages. The TV's are different but the cars are quite recognizable. The bicycles are different but not radically so. Diapers are different but the babies are the same. The economy was an issue then and is still an issue now. But it's a different issue. In 1950 everybody was terrified by mass unemployment. Now people are scared of less-massive unemployment.
If you get a serious illness, you may cause the company's insurance premiums to go up. The additional costs add up so companies try to keep "Unhealthy" people off the roles. Further, some companies are "Self-insured" and probably have under-the-table access to your medical records, anyway. Is business in the business of firing sick workers? See this article on lobbying efforts to change the law in the US.
That's okay. British Columbia is neither British nor Columbia. They don't even export cocaine! Although they do make money from their abundant white powder...
I think Ruby and Rails are about the right ideas for our current and near future environment -- cheap cpu's, tight schedules, evolving web standards, clueless users, heterogeneous client hardware (browsers and pda's) and ever faster networks.
And, by the way, the current Ruby implementation is not quite as mature as the current Perl or even Java implementations. This will change. The sweet spot for using Rails isn't today, it's the next 5 years or so. So now would be a good time to get the experience.
Not to knock PHP, it lets just anybody put together a dynamic web site without having to know too much. It's a straightforward system ideal for power users who don't want to be computer scientists but who need to build out their ideas. I have a neighbor who's expertise is in marketing and home products who is building his own product line with PHP. Ruby would be beyond him. Who knows, he might just strike it rich with PHP.
They keep on making the same mistake.
We need to know exactly what they are doing. At least tell us what you mean by "information censorship" as this term is new to me. Do they censor technical information or is the database filtered for dirty words?