If we had an assignment operator nobody (?) would have confused = with == inside a C if-statement and we surely would have saved the cost many times over by now.
For crying out loud we coders have contributed a lot to computing (!) At least give us an assignment operator and a new equality operator on the keyboard. It's not as if we aren't sure we're going to need it in a few years!
I actually laughed out loud when I read your code. It's been a long time since C code actually made me laugh. I think some of the responders missed the joke.
And I think your code will actually run, too. I like the semantics (put the tail of the string into temp, put the head in the tail, and put the temp into the head -- more like English).
I tried the Ruby plugin for eclipse and it was too hard to get things to work. It all went together okay but when I started to use it, the thing kept on asking me for pathnames and which workspace to use. I had no idea which workspace to use, I just wanted to edit and run a ruby file.
Also, it kept on giving me lists of errors I could not understand.
I went back to scite and jEdit. I'm thinking of going back to emacs, actually.
You're assuming that you can tell the on position from the off position. I did not assume that.
If the on position can be either up or down, then there are 48 ways the switches can be connected to the bulbs. The on position for bulb 1 can be any of 6 points, then the on position for bulb 2 can be any of the 4 remaining points, and the on position of bulb 3 can be one of the two remaining points. 6 X 4 X 2 = 48.
Really, the way you worded it, you can't even assume that all three switches have on in the same (up or down) position.
The first programmers to use operating systems rather than program the bare machine felt the same way. You now use OS's, DBMS's, compilers, interpreters, chips...
In any situation, you take a bunch of tools and primitives and make an application.
The increased readability and lower likelihood of programming errors on the array option...
The array version is neither clearer nor less error-prone. And I dare you to prove differently!
The pointer version is more portable across the chasm of compiler quality. That is, it will run well even on poorer compilers.
The question of clearer is a question of cognitive psychology, not computer science, and requires experimentation to validate. The experiment would be confounded by the existing prejudice against pointers and the habit of CS profs of teaching subscripts over pointers.
N.B.: There are problems with C pointers, but that comes up when using pointers to data structures, not pointers to bytes. Dangling pointers, free/malloc problems, and all that. Using subscripts helps very little, however.
It is not true that the optimization is nearly pointless, it is that the difference in performance is so small as to make the decision nearly pointless. No pun intended. In some situations, the difference may be very important. The pointer version is no harder to code, read, or debug, and might possibly give you back benefits.
What I'm trying to say here is that the pointer version is not an optimization, it's an alternative. Optimizations require more work than the vanilla version. For string/character loops, there is no more work in coding the pointer version.
One of the reasons the machine bleeds off a million cycles every time it raises a window may be that the coders didn't pay attention to performance.
Some products need to be built for performance. If you're in that situation, you need to know beforehand what techniques will shoot yourself in the foot. The original article asks that question. You failed to anwer it.
Somebody has to write the XML parser, the Ruby interpreter, the Java VM. They're in C for a reason. And it makes sense to know beforehand what coding techniques will not come back to bite you. Once you've written 100,000 lines of C code you really don't want to discover the product is a pig because of a coding technique strewn all over the source code.
It certainly used to be true that the embedded C cross-compilers I used in the 1980's generated significantly tighter code with pointers than with arrays. So I got into the habit of coding that way.
Most Significant: In the given example (string reversal) the subscript code isn't safer than the pointer code. Neither technique is likely to create buffer overflows or problems like that.
To really compare speeds, the code should use post-increment on the subscripts/pointers. On simpler compilers that can speed things up. Since that's what you'd do if you were coding for speed you should test it.
With a perfect compiler it doesn't matter. The question posed was, how good are the various compilers? Fair question.
Usually you can find a tool that will dump out all the system calls with arguments. See what the program is doing, and maybe write some scripts to analyze the log files. It gives you a genuinely useful perspective that you'll never get from reading the code.
For programs that primarily do file processing, you can get a similar understanding by analyzing the input files and the output files.
For database programs you often can get the DBMS to log the transactions or the SQL.
For embedded systems you would need a hardware device called a logic analyzer to get the data to make the analysis.
For communications software you'd need to get something to dump the packets to log files. Lots of these for the popular protocols.
From the above analysis you might be able to write a spec (that is, a doc that would tell somebody what the program is supposed to do, so they could code it from scratch just by reading the spec).
The slowest interpreters can be the most useful languages, sometimes. Consider Javascript and the Unix shells. Absolute molasses, both of them. Absolutely essential.
On the other hand, we absolutely cannot do without C or something very much like it. What else would we use to write the JVM in? And Perl?
C is getting old, we need a replacement. C++ is too complex and error prone; At least -- we know we can do better than either C or C++ and keep the high performance. Look at the D programming language, as a proof of concept. Can we do better than D and keep the performance?
Clearly, interface specs are indispensible. Without section (3) of the man pages you wouldn't be able write apps to run on the kernel Linus wrote for us.
Design specs need to be taken with a grain of salt. They represent planning. Just like you need planning to deal with broken levees on Lake Ponch. you need planning to build significant systems. All plans die on contact with reality. But the planning process is essential. The hardest parts of building significant software is often in the parts that are unexpected and unplanned for. Imagine if the whole system were that way?
And the two forms merge. Just like they needed technical data on the pumps to estimate how long it would take to pump out NO, you need tech specs on file formats and application behavior to build software over a certain size.
And if you still hate specs just get contact lenses;-)
Technically, you don't need to remove the bra to conceive a child. It helps, but it isn't an absolute "Requirement".
Later, at feeding time... But you'll get plenty of time to figure out the mechanism before then.
There was a rare and isolate group of people discovered some time ago where the women actually had their breasts growing on their backs, instead of their chests. Breastfeeding was very awkward but dancing was popular.
Hacking -- that is, casual and/or experimental coding, is a useful and necessary source of both innovation and learning.
Lots of important inventions started out as one-off ideas that were tried before they were analyzed; hash tables, binary search, circular buffers for device drivers. Even Duff's Device.
Many situations require experimental programming so the coder can figure out how to get stuff done: What do I do to get this chip to output data? How do I get the database to give me the data I want in the form I want? Which regular expression will filter the log as I need it?
Experimental programming often makes up for weak or fuzzy specs when you need to read the spec to understand the chip, the database, the gigabytes of log data...
Bram Cohen gave a nice talk at Stanford about the need for experimentation in developing the network code for BitTorrent. The video is on the web.
Are there any examples of insertion? What to do with null fields? I haven't had time to study all the stuff yet...
So, in wrap up, how far does this take us to the Brooks' "Magic Bullet" for programming? Does further tying data structure into code still provide the clean separation between code and data required by good design? Can I prevent my data definitions from proliferating all through my source base so when the DBA re-does the database I'm not stuck with obsolete and broken applications?
And can I do stored procedures and give up SQL entirely or will DBA's need to learn both SQL and a new.NET language in addition to all their existing admin tools?
Can I use Reflection to inquire of the structure of the data and generate code to manage the database? Or are the older solutions still the best for this?
In what other ways will SQL-server and.NET become more tightly integrated? And when will the both become part of the Operating System like IE, with all the attending benefits?
I see the polymorphism angle (XML/Databases/Arrays) but is there a way to inherit data definitions? To subclass them?
And when will the WMI, the Windows hierarchy in a GUI application, the programs own class hierarchy through Reflection, and the HTML-DOM be accessible through these new interfaces, or have I just run aground on the shoals of logic and imagination? A bridge too far? How about the files in a directory, or is that just WMI again?
What tools and hacks will be need to deal with volatile (externally modified) dynamic data? SQL-server has some of it's own but coders still need to specify read-with-lock from read-without-lock. All the other data except for arrays and some XML is volatile (subject to modification by other threads or CPU's). Different data sources have different volatility models (db's, WMI, processes running on the OS, nodes on the net).
Microsoft will only provide good Windows-programming tools if you agree to use lock-in programming tools. So if you want to do good work in Windows programming you will end up using lock-in Microsoft products.
Just look at the design quality of MFC vs the ATL package. Any really good application framework in C++ is going to be, almost by definition, a framework that can be ported to another OS, such as Linux or Apple. So MS came up with MFC that stamps it's Windows identity on every other line without remorse.
When ATL slipped out it was quickly dubbed "A mistake" and the next release was merged back into MFC so no portable programming could take place.
By using a proprietary programming system like.NET and C# or VB.NET, Microsoft is free to innovate and provide truly excellent tools without worrying abouut somebody trying to copycat and port their tools to another platform. Enabling platform portability for Windows programs would be just too expensive. This way, there's no threat.
For the same reasons, Borlands OWL and then Delphi had to be killed, and Java extinguished. Java, though, has not been killed, but MS can attack it through fundamental quality (.NET...) since they're not portable. Java is the last, best hope for software platform portability on the client and when it's gone, it's gone. Ruby and Python are just niche products, and any Ruby.NET or Python.NET is necessarily going to be just different enough so that the apps written in them aren't platform-portable.
Java and.NET share a weakness, however. If you want to distribute a demo for web download you have to redistribute a massive runtime to download and install with it. And.NET just isn't done yet: WinForms is an interim product and "Vista" will disrupt everything.
Web apps are the next threat to MS after Java. Should we look for MS to start breaking AJAX sometime soon? You'll notice that, as somebody pointed out, MS stopped all development on IE and DHTML when the web platform became too threatening.
COM and DCOM were the MS attempt to side-step all important client and Web systems and thrust a new unportable infrastructure on the user community. But the sword had a double edge and it's complexity and unreliability cut back at Microsoft as well.
If you want to write client code for Windows, live with the lock-in. Avoid COM programming as much as possible.
If you're not overweight then get a small fridge for your office, but if you are, then don't get a Bodybilt chair. My Bodybilt chair broke 3 times.
Put your office in a cottage about a hundred yards from your house so you'll walk to work every morning. It's good exercise and you'll appreciate the isolation.
While you're at it, put the cottage over the edge of a fresh water lake so you can stand up from your computer, walk out onto the deck and dive into the lake, go for a swim and then climb back up to the deck to dry off before you go back to work. Consider stocking the lake with trout or at least mermaids. I think trout fishing is a good way to organize a design session -- and modern languages have a "Reflection" feature to facilitate this. Avoid grizzly bears. Just keep some sort of notebook handy to jot down your design decisions. Any kind of notebook will do.
It would be best to own the whole lake to avoid the distraction of motorboaters and float planes. To avoid RSI and other hand pains it would be prudent to hire a secretary to type in the code. You'll just dictate the programs as you lean back in your recliner.
Oh, and avoid any projects with deadlines -- they cause anxiety and stress...
There is a surplus of programmers and software engineers these days. If you want to get a CS degree you'll need another degree (I'd recommend an MBA) to go along with it. That way you can be the idiot in charge instead of the other way around.
The science/engineering dichotomy makes some sense. The Physics and Chemistry undergrad 4-year degrees are preparation for graduate school (Masters and Ph.d), while the engineering degrees are preparation for work or for grad school.
After decades of trying, Software Engineering has finally split off from Computer Science as an undergraduate degree in a meaningful way. Unfortunately, the theoretical stuff is too theoretical and the practical stuff may not last very long. While lisp and RPG programming are still alive (and both were said to be obsolete in the 1960's), lots of technology dies. XML may be gone in a few decades, and hopefully Java, too.
No matter what you do, when you go for your first job do NOT put the word "Test" on the resume (CV) anywhere. If they ask you whether you tested your software, tell them no, it just worked. And that in team projects the other guys did the testing. Most CS grads do not get jobs writing software. A lot get shoved into testing, which is not what they want. If they offer you a job in testing, just say no. If you once get a job in testing on your CV, you can never leave it.
In order to answer your questions in further detail, we have to know more about you, what your plans are, and what your goals are. If you're after money, go into business. If you want to code, take as many coding AND CS courses as you can. Even SQL.
In any case, try to code in as many different languages as you can. And languages that are different, not just variations on the theme of OO.
Some topics are only prep for grad school, you won't get a job with only a 4-year degree: AI, robotics, graphics, computer vision, machine learning, and probably game programming.
The following are immensely practical: automata theory, compilers, set theory, predicate calculus, Boolean algebra, algorithms and data structures, searching and sorting, SQL, and specification systems, among others. And by all means learn what TLA stands for.
And do consider learning Hindi, as the guy said.
For the last several decades, employers want somebody with 2 or 3 years of experience. Any more or less and they won't hire you. Not everybody, of course.
They are for hardware repair (A+), DBA's sometimes, various species of computer operators. The only Cert for software developers these days is a CS degree or 15 years of software development experience. Or your name on a popular piece of software. Bram Cohen wrote BitTorrent and I'm sure he can get a job whenever he wants. Likewise with Larry Wall and Linus...
The certs don't test well enough. And the tests are too thorough in narrow areas. You really have to be a specialist in Cisco or Novell administration (or whatever).
We'll see how the glut of software engineers and off-shoring may be changing this.
Don't be afraid of Ruby
Well I tried to install with the ruby on rails one-click installer, just to see what all the dang hype is about, and the OnLamp instructions fail at the gem step.
If you must know, it claims:
ERROR: While executing gem... (Gem::RemoteSourceException)
Error fetching remote gem cache: getaddrinfo: no address associated with hostname.
I guess Ruby isn't quite done yet. Although to be fair, it took about a day and a half to install Microsoft Visual Studio.
Some embedded systems have a notion of DST and of local time. The right way to do this with networked embedded system (ATM's, phone switches) is to have each computer keep GMT(UCT) internally and know it's timezone and DST rules for local display.
Think about what happens when the network crosses timezones and when data records containing time stamps go over the network. Data records should contain time in GMT and some indication of node-id (which would give you time zone) or the time zone itself. Mobile systems make it even more complex and more necessary to use UCT(GMT) internally. But GPS can provide enough information to help resolve ambiguities.
I once coded for an embedded system that used a time chip that tried to perform DST changes on the time chip. It turned out that if the machine should reboot at 1:30 of the morning when the clocks get turned back -- there was no way to tell which 1:30 AM it was, the first one or the second one.
Governments insist on playing with DST rules so computer systems (including embedded systems) should keep all time internally as a simple binary counter of ticks (seconds or microseconds for example) together with a notion of the time of the start of the epoch (zero ticks) and a configurable local time zone and DST rules. Do not rely on DST changing on some Sunday morning. Some months have 5 Sundays, so specifying the "4th Sunday in April" may not do what you want, anyway.
For embedded system that do not have to display date and time locally, dispense with the whole concept of DST.
Test your time software in Japan as well as London (virtually) as some code will break in that half of the earth.
To save precious memory space, you can store the year in a 1-digit field for five more years:-)
Slashdot Mirror
That is, '←' (left arrow)
For crying out loud we coders have contributed a lot to computing (!) At least give us an assignment operator and a new equality operator on the keyboard. It's not as if we aren't sure we're going to need it in a few years!
And I think your code will actually run, too. I like the semantics (put the tail of the string into temp, put the head in the tail, and put the temp into the head -- more like English).
Also, it kept on giving me lists of errors I could not understand.
I went back to scite and jEdit. I'm thinking of going back to emacs, actually.
Yes. There are only 3 possibilities, and you've enumerated them all...
The king can only flip the cup K times. The Counter is waiting for (N - 1) * (K + 1) flips, which is bigger than K.
If the on position can be either up or down, then there are 48 ways the switches can be connected to the bulbs. The on position for bulb 1 can be any of 6 points, then the on position for bulb 2 can be any of the 4 remaining points, and the on position of bulb 3 can be one of the two remaining points. 6 X 4 X 2 = 48.
Really, the way you worded it, you can't even assume that all three switches have on in the same (up or down) position.
In any situation, you take a bunch of tools and primitives and make an application.
The array version is neither clearer nor less error-prone. And I dare you to prove differently!
The pointer version is more portable across the chasm of compiler quality. That is, it will run well even on poorer compilers.
The question of clearer is a question of cognitive psychology, not computer science, and requires experimentation to validate. The experiment would be confounded by the existing prejudice against pointers and the habit of CS profs of teaching subscripts over pointers.
N.B.: There are problems with C pointers, but that comes up when using pointers to data structures, not pointers to bytes. Dangling pointers, free/malloc problems, and all that. Using subscripts helps very little, however.
It is not true that the optimization is nearly pointless, it is that the difference in performance is so small as to make the decision nearly pointless. No pun intended. In some situations, the difference may be very important. The pointer version is no harder to code, read, or debug, and might possibly give you back benefits.
What I'm trying to say here is that the pointer version is not an optimization, it's an alternative. Optimizations require more work than the vanilla version. For string/character loops, there is no more work in coding the pointer version.
Some products need to be built for performance. If you're in that situation, you need to know beforehand what techniques will shoot yourself in the foot. The original article asks that question. You failed to anwer it.
It certainly used to be true that the embedded C cross-compilers I used in the 1980's generated significantly tighter code with pointers than with arrays. So I got into the habit of coding that way.
Most Significant: In the given example (string reversal) the subscript code isn't safer than the pointer code. Neither technique is likely to create buffer overflows or problems like that.
To really compare speeds, the code should use post-increment on the subscripts/pointers. On simpler compilers that can speed things up. Since that's what you'd do if you were coding for speed you should test it.
With a perfect compiler it doesn't matter. The question posed was, how good are the various compilers? Fair question.
For programs that primarily do file processing, you can get a similar understanding by analyzing the input files and the output files.
For database programs you often can get the DBMS to log the transactions or the SQL.
For embedded systems you would need a hardware device called a logic analyzer to get the data to make the analysis.
For communications software you'd need to get something to dump the packets to log files. Lots of these for the popular protocols.
From the above analysis you might be able to write a spec (that is, a doc that would tell somebody what the program is supposed to do, so they could code it from scratch just by reading the spec).
Later on, modify the code and see what happens.
On the other hand, we absolutely cannot do without C or something very much like it. What else would we use to write the JVM in? And Perl?
C is getting old, we need a replacement. C++ is too complex and error prone; At least -- we know we can do better than either C or C++ and keep the high performance. Look at the D programming language, as a proof of concept. Can we do better than D and keep the performance?
Design specs need to be taken with a grain of salt. They represent planning. Just like you need planning to deal with broken levees on Lake Ponch. you need planning to build significant systems. All plans die on contact with reality. But the planning process is essential. The hardest parts of building significant software is often in the parts that are unexpected and unplanned for. Imagine if the whole system were that way?
And the two forms merge. Just like they needed technical data on the pumps to estimate how long it would take to pump out NO, you need tech specs on file formats and application behavior to build software over a certain size.
And if you still hate specs just get contact lenses ;-)
Later, at feeding time... But you'll get plenty of time to figure out the mechanism before then.
There was a rare and isolate group of people discovered some time ago where the women actually had their breasts growing on their backs, instead of their chests. Breastfeeding was very awkward but dancing was popular.
Lots of important inventions started out as one-off ideas that were tried before they were analyzed; hash tables, binary search, circular buffers for device drivers. Even Duff's Device.
Many situations require experimental programming so the coder can figure out how to get stuff done: What do I do to get this chip to output data? How do I get the database to give me the data I want in the form I want? Which regular expression will filter the log as I need it?
Experimental programming often makes up for weak or fuzzy specs when you need to read the spec to understand the chip, the database, the gigabytes of log data...
Bram Cohen gave a nice talk at Stanford about the need for experimentation in developing the network code for BitTorrent. The video is on the web.
Ruby's a better descendant than Python!
So, in wrap up, how far does this take us to the Brooks' "Magic Bullet" for programming? Does further tying data structure into code still provide the clean separation between code and data required by good design? Can I prevent my data definitions from proliferating all through my source base so when the DBA re-does the database I'm not stuck with obsolete and broken applications?
And can I do stored procedures and give up SQL entirely or will DBA's need to learn both SQL and a new .NET language in addition to all their existing admin tools?
Can I use Reflection to inquire of the structure of the data and generate code to manage the database? Or are the older solutions still the best for this?
In what other ways will SQL-server and .NET become more tightly integrated? And when will the both become part of the Operating System like IE, with all the attending benefits?
I see the polymorphism angle (XML/Databases/Arrays) but is there a way to inherit data definitions? To subclass them?
And when will the WMI, the Windows hierarchy in a GUI application, the programs own class hierarchy through Reflection, and the HTML-DOM be accessible through these new interfaces, or have I just run aground on the shoals of logic and imagination? A bridge too far? How about the files in a directory, or is that just WMI again?
What tools and hacks will be need to deal with volatile (externally modified) dynamic data? SQL-server has some of it's own but coders still need to specify read-with-lock from read-without-lock. All the other data except for arrays and some XML is volatile (subject to modification by other threads or CPU's). Different data sources have different volatility models (db's, WMI, processes running on the OS, nodes on the net).
Just look at the design quality of MFC vs the ATL package. Any really good application framework in C++ is going to be, almost by definition, a framework that can be ported to another OS, such as Linux or Apple. So MS came up with MFC that stamps it's Windows identity on every other line without remorse.
When ATL slipped out it was quickly dubbed "A mistake" and the next release was merged back into MFC so no portable programming could take place.
By using a proprietary programming system like .NET and C# or VB.NET, Microsoft is free to innovate and provide truly excellent tools without worrying abouut somebody trying to copycat and port their tools to another platform. Enabling platform portability for Windows programs would be just too expensive. This way, there's no threat.
For the same reasons, Borlands OWL and then Delphi had to be killed, and Java extinguished. Java, though, has not been killed, but MS can attack it through fundamental quality (.NET ...) since they're not portable. Java is the last, best hope for software platform portability on the client and when it's gone, it's gone. Ruby and Python are just niche products, and any Ruby.NET or Python.NET is necessarily going to be just different enough so that the apps written in them aren't platform-portable.
Java and .NET share a weakness, however. If you want to distribute a demo for web download you have to redistribute a massive runtime to download and install with it. And .NET just isn't done yet: WinForms is an interim product and "Vista" will disrupt everything.
Web apps are the next threat to MS after Java. Should we look for MS to start breaking AJAX sometime soon? You'll notice that, as somebody pointed out, MS stopped all development on IE and DHTML when the web platform became too threatening.
COM and DCOM were the MS attempt to side-step all important client and Web systems and thrust a new unportable infrastructure on the user community. But the sword had a double edge and it's complexity and unreliability cut back at Microsoft as well.
If you want to write client code for Windows, live with the lock-in. Avoid COM programming as much as possible.
Put your office in a cottage about a hundred yards from your house so you'll walk to work every morning. It's good exercise and you'll appreciate the isolation.
While you're at it, put the cottage over the edge of a fresh water lake so you can stand up from your computer, walk out onto the deck and dive into the lake, go for a swim and then climb back up to the deck to dry off before you go back to work. Consider stocking the lake with trout or at least mermaids. I think trout fishing is a good way to organize a design session -- and modern languages have a "Reflection" feature to facilitate this. Avoid grizzly bears. Just keep some sort of notebook handy to jot down your design decisions. Any kind of notebook will do.
It would be best to own the whole lake to avoid the distraction of motorboaters and float planes. To avoid RSI and other hand pains it would be prudent to hire a secretary to type in the code. You'll just dictate the programs as you lean back in your recliner.
Oh, and avoid any projects with deadlines -- they cause anxiety and stress...
The science/engineering dichotomy makes some sense. The Physics and Chemistry undergrad 4-year degrees are preparation for graduate school (Masters and Ph.d), while the engineering degrees are preparation for work or for grad school.
After decades of trying, Software Engineering has finally split off from Computer Science as an undergraduate degree in a meaningful way. Unfortunately, the theoretical stuff is too theoretical and the practical stuff may not last very long. While lisp and RPG programming are still alive (and both were said to be obsolete in the 1960's), lots of technology dies. XML may be gone in a few decades, and hopefully Java, too.
No matter what you do, when you go for your first job do NOT put the word "Test" on the resume (CV) anywhere. If they ask you whether you tested your software, tell them no, it just worked. And that in team projects the other guys did the testing. Most CS grads do not get jobs writing software. A lot get shoved into testing, which is not what they want. If they offer you a job in testing, just say no. If you once get a job in testing on your CV, you can never leave it.
In order to answer your questions in further detail, we have to know more about you, what your plans are, and what your goals are. If you're after money, go into business. If you want to code, take as many coding AND CS courses as you can. Even SQL.
In any case, try to code in as many different languages as you can. And languages that are different, not just variations on the theme of OO.
Some topics are only prep for grad school, you won't get a job with only a 4-year degree: AI, robotics, graphics, computer vision, machine learning, and probably game programming.
The following are immensely practical: automata theory, compilers, set theory, predicate calculus, Boolean algebra, algorithms and data structures, searching and sorting, SQL, and specification systems, among others. And by all means learn what TLA stands for.
And do consider learning Hindi, as the guy said.
For the last several decades, employers want somebody with 2 or 3 years of experience. Any more or less and they won't hire you. Not everybody, of course.
Well, if they're high in kindness they'll at least die out soon...
The certs don't test well enough. And the tests are too thorough in narrow areas. You really have to be a specialist in Cisco or Novell administration (or whatever).
We'll see how the glut of software engineers and off-shoring may be changing this.
Well I tried to install with the ruby on rails one-click installer, just to see what all the dang hype is about, and the OnLamp instructions fail at the gem step.
If you must know, it claims: ... (Gem::RemoteSourceException)
Error fetching remote gem cache: getaddrinfo: no address associated with hostname.
ERROR: While executing gem
I guess Ruby isn't quite done yet. Although to be fair, it took about a day and a half to install Microsoft Visual Studio.
Think about what happens when the network crosses timezones and when data records containing time stamps go over the network. Data records should contain time in GMT and some indication of node-id (which would give you time zone) or the time zone itself. Mobile systems make it even more complex and more necessary to use UCT(GMT) internally. But GPS can provide enough information to help resolve ambiguities.
I once coded for an embedded system that used a time chip that tried to perform DST changes on the time chip. It turned out that if the machine should reboot at 1:30 of the morning when the clocks get turned back -- there was no way to tell which 1:30 AM it was, the first one or the second one.
Governments insist on playing with DST rules so computer systems (including embedded systems) should keep all time internally as a simple binary counter of ticks (seconds or microseconds for example) together with a notion of the time of the start of the epoch (zero ticks) and a configurable local time zone and DST rules. Do not rely on DST changing on some Sunday morning. Some months have 5 Sundays, so specifying the "4th Sunday in April" may not do what you want, anyway.
For embedded system that do not have to display date and time locally, dispense with the whole concept of DST.
Test your time software in Japan as well as London (virtually) as some code will break in that half of the earth.
To save precious memory space, you can store the year in a 1-digit field for five more years :-)