I've worked in three large IT shops now, and the CIO of each company would typically know *very* little about a given application besides its name (if even that), much less info about specific features or flaws therein.
When one works in an environment with several hundred in-house applications, it's easy for something to get lost in the shuffle, paricularly if the application in question isn't normally a source of issues or is using a techology which isn't "mainstream" for the company...
They've also historically had fairly large IT shops. That has given them a lot of time and manpower over the past four decades to write custom software for themselves, and that has resulted in many unique airline-specific systems, sometimes running on interesting combinations of hardware.
One of the main problems with a "central IT shop" for the airlines is the fact that, operationally, each airline is somewhat unique in terms of the internal operational procedures they use, and many of the software applications at each airline are very tightly tied to that airline's own local set of procedures and business rules.
I worked for ten years at Northwest Airlines on a flight operations system that was originally written at United Airlines in the mid-1960's, and we had to make a lot of fundamental changes to displays and other things so our pilots and flight dispatchers could use their own in-house terminology, and so that the software would match the largely paper-driven procedures that it was replacing.
Even were the airline industry not in its current financial bind, the prospect of replacing some of those systems isn't one to be taken lightly -- not only are the systems at a major airline closely intertwined with unique procedures, but they also tend to be tightly tied together in terms of data with lots of real-time message passing going on not only between the airline's internal systems but also between the airline and various third parties (ACARS messages, weather info, flight plan information, reservations info, etc.).
It's a very interesting industry from an IT perspective, at least when it isn't in a death spiral...
I've been a heavy user of command lines for over 20 years on a variety of OSes, most of them not UNIX or a UNIX derivative, and I admit that I generally prefer scads of aliases and shell scripts to a menu.
However, I still use mc under Linux (and FileJet under OS/2 and DOS, and @VSH under OS2200) to peruse the filesystem and to perform certain types of commands (mainly directory tree deletions and selective operations where point-and-shoot is more convenient for me than a series of filespecs).
Like text editing, the specific methods and tools that different people use for file management can vary tremendously.
That way, the newbie can perform various filesystem commands or navigate the filesystem without having to know the actual commands at first, and they can slowly wean themselves off the filemanager if they want to later on (it does provide a command line).
Heck, I still use mc a lot after over 10 years using Linux. It's a very useful tool.
There's an Obelisk of Light in the Stormbots mod for Tribes 1. I corrected it in my own hacked version so it would take a heavy in full health down to one red pixel in a single shot at around 800 meters or so.
"Here I go, Heavy O! I wonder what's over this ridgZZZZZZZTTTTT!!!"
Not on a bigger map like Real Earth or Australia, although you could use the fire-at-my-feet bug to fling the shots a lot further than normal and that would hit MOST points of the Australia map in a scattering fashion.
Not that I've ever used that technique, mind you...
You *could* boot a real DOS kernel in a VDM (or many other real-mode OSes like CP/M) from a diskette image using a method called a "virtual Machine Boot), but the default VDM setting was to use a virtualized DOS kernel interface (no real DOS present, just DOS-like hooks into OS/2 services).
...for that OS/2 folder attibute is "work area". It can be very useful for things like development environments and such where you might want to open and close multiple files or programs as a set.
We are able to manage multi-million-line systems quite effectively without using tools like CVS.
All it takes is some sort of intelligent change management system, not necessarily source code management, and perhaps also some additional tools so people can quickly see the status of a given source module.
FWIW -- we often leave small blocks of commented code in the production source. Why? Because our internal customers have been known to change their minds in the past. Believe it, or not.:-)
Ah. Would you care to port it to OS2200 then? The Unisys 2200 environment has no CVS port as far as I know, and it must be an easy task to do so given the flippant attitude in your response.
Right?
Or perhaps it didn't occur to you that there are a number of production *mainframe* systems out there that have been around for a very long time and that don't run on Intel hardware or use POSIX-compatible operating systems.
The whole world isn't UNIX and Intel, just the majority. But that doesn't mean that other platforms don't exist.
There wasn't one in use (or available that I know of) on the Unisys A-series (MCP) system I did some contract work on two years ago, and the Unisys 2200 (OS2200) systems I've been using professionally for the past 15+ years have no such thing.
That isn't to say there isn't some element of control over changes, though -- we apply correction images against the base source, for example, and usually don't just do whole-hog source replacement.
When I'm writing in assembler and doing a lot of register juggling, for example, I'll usually put in-line commentary in the code describing the nature of the values I'm working with and the operations I'm performing (since that isn't obvious at all from the code statements themselves).
I also sometimes do that in older Fortran dialects since most of them are limited to six-character variable names, and since it's not always obvious what is being done.
The three items you seem to object to all have fairly legitimate uses in some computing contexts.
1. Comment each function - Function name
Why do you need to repeat the name of the function? It's right there in the code.
Yes, and in some contexts that is precisely the problem. Depending on the language and editor(s) you are using, embedding the function names in comments can be very useful.
For example, if I use an "FC" command in a Unisys 2200 mainframe editor (say ED or UEDIT) to show all lines starting with "C" (comment lines) in a Fortran program, the results will be confusing if the function names themselves are not specified in a comment line. All I will see is comments with no context.
By adding the subroutine or function names in the related comments themselves, that missing context is restored.
5. Put in a '?' comment for code that you do not understand (good for function headers)
Code with personal annotations should never be released.
While I agree with this part,
If you don't understand it, you shouldn't be working with it; go find someone who does understand it instead, or stop and work it out.
this part of your comment seems limited to "perfect world" scenarios only.
I've spent most of my career working on mainframe code that was either originally written by people at other organizations or companies, or that was written so long ago that the original designers and coders were either retired or deceased.
When making a first pass at understanding such code, I've found it to be quite useful to leave various comments in the code so I have a good idea about my level of understanding the next time I have to come into that area of code.
I've also found such comments useful when left in the code by others, since it reflects their level of understanding as well. Some of the stuff I'm looking at now was originally coded in the early 80's and rewritten by my predecessor, and the comments he's placed in the code have proven to be invaluable to me, even though some of them were speculative in nature. Something like "What does this code do?" in his comments often alerts me to a tricky part in the logic that I'll want to pay special attention to.
FWIW, question marks and other comments/speculations are commonly used when working on someone else's previously-written code, at least in my experience, especially when that code is only intended for use in-house (the source is not released to customers).
8. Tag your bug fixes, code enhancements with a comment followed by a dash, date, and your initials. This is essential for large projects or for anything you will be working on for more than 6 months.
Once again, nothing with personal annotations should ever be released into source control. Not only should I not need to know who wrote or changed a particular snippet of code to fix a bug, I shouldn't even be able to tell by looking at the code.
When working on code that was written in-house, and which is intended to stay in-house, I *want* to know who made a certain change and why it was done. That type of notation can save me (or another support programmer) a lot of time.
While those types of details might be handled by the source control system(s) that you work with, keep in mind that some of us work on platforms where analogs to the UNIX-like source control systems many people are used to simply do not exist (and often such a thing isn't really needed).
When I did Unisys A-series mainframe contract work at a small company in southern Minnesota, they used the unparsed end of each COBOL line as a comment area, and one always placed their initials and a date there so people knew who did which changes and when those changes were created. The editor they used (CANDE) even had a special setting to automagically place a change mark on the end of each line that was modified.
Slashdot Mirror
The Fortran V and F77 stuff we have running here (as well as the stuff running in those languages at my former employer) doesn't have that problem.
:-)
Sometimes using an old 36-bit mainframe architecture (where an INT is 36-bits) is an advantage.
I've worked in three large IT shops now, and the CIO of each company would typically know *very* little about a given application besides its name (if even that), much less info about specific features or flaws therein.
When one works in an environment with several hundred in-house applications, it's easy for something to get lost in the shuffle, paricularly if the application in question isn't normally a source of issues or is using a techology which isn't "mainstream" for the company...
The trick is to determine whether or not the cost to converst a given system is actually worth it.
If a rewrite effort requires 50,000 or 100,000 man years to complete, you're talking serious money...
They've also historically had fairly large IT shops. That has given them a lot of time and manpower over the past four decades to write custom software for themselves, and that has resulted in many unique airline-specific systems, sometimes running on interesting combinations of hardware.
One of the main problems with a "central IT shop" for the airlines is the fact that, operationally, each airline is somewhat unique in terms of the internal operational procedures they use, and many of the software applications at each airline are very tightly tied to that airline's own local set of procedures and business rules.
I worked for ten years at Northwest Airlines on a flight operations system that was originally written at United Airlines in the mid-1960's, and we had to make a lot of fundamental changes to displays and other things so our pilots and flight dispatchers could use their own in-house terminology, and so that the software would match the largely paper-driven procedures that it was replacing.
Even were the airline industry not in its current financial bind, the prospect of replacing some of those systems isn't one to be taken lightly -- not only are the systems at a major airline closely intertwined with unique procedures, but they also tend to be tightly tied together in terms of data with lots of real-time message passing going on not only between the airline's internal systems but also between the airline and various third parties (ACARS messages, weather info, flight plan information, reservations info, etc.).
It's a very interesting industry from an IT perspective, at least when it isn't in a death spiral...
Probably not many job openings, though. :-(
I'm working mostly in F77 now. It's a good language for what it does.
Why else do you think the Slackware penguin smokes a pipe? :-)
Looks like the article was published yesterday.
Yahoo News is dispaying it as a current item.
I've been a heavy user of command lines for over 20 years on a variety of OSes, most of them not UNIX or a UNIX derivative, and I admit that I generally prefer scads of aliases and shell scripts to a menu.
However, I still use mc under Linux (and FileJet under OS/2 and DOS, and @VSH under OS2200) to peruse the filesystem and to perform certain types of commands (mainly directory tree deletions and selective operations where point-and-shoot is more convenient for me than a series of filespecs).
Like text editing, the specific methods and tools that different people use for file management can vary tremendously.
That way, the newbie can perform various filesystem commands or navigate the filesystem without having to know the actual commands at first, and they can slowly wean themselves off the filemanager if they want to later on (it does provide a command line).
Heck, I still use mc a lot after over 10 years using Linux. It's a very useful tool.
Oh wait! That was brown, brown, brown...
There's an Obelisk of Light in the Stormbots mod for Tribes 1. I corrected it in my own hacked version so it would take a heavy in full health down to one red pixel in a single shot at around 800 meters or so.
"Here I go, Heavy O! I wonder what's over this ridgZZZZZZZTTTTT!!!"
"Uh. Medic!!"
Oh yes. :-) TA is, anyway, up to ten (10) people in a given level. With all the units running around in that game, things can get messy rather quickly.
Now... I wanna see a Linux port!
Not on a bigger map like Real Earth or Australia, although you could use the fire-at-my-feet bug to fling the shots a lot further than normal and that would hit MOST points of the Australia map in a scattering fashion.
Not that I've ever used that technique, mind you...
You *could* boot a real DOS kernel in a VDM (or many other real-mode OSes like CP/M) from a diskette image using a method called a "virtual Machine Boot), but the default VDM setting was to use a virtualized DOS kernel interface (no real DOS present, just DOS-like hooks into OS/2 services).
...for that OS/2 folder attibute is "work area". It can be very useful for things like development environments and such where you might want to open and close multiple files or programs as a set.
The temperature is more stable all year around than it is in the outside world.
:-)
Also, it's harder for those nasty spyware authors to find you.
More information on EMX is here if anyone's interested...
We are able to manage multi-million-line systems quite effectively without using tools like CVS.
:-)
All it takes is some sort of intelligent change management system, not necessarily source code management, and perhaps also some additional tools so people can quickly see the status of a given source module.
FWIW -- we often leave small blocks of commented code in the production source. Why? Because our internal customers have been known to change their minds in the past. Believe it, or not.
Ah. Would you care to port it to OS2200 then? The Unisys 2200 environment has no CVS port as far as I know, and it must be an easy task to do so given the flippant attitude in your response.
Right?
Or perhaps it didn't occur to you that there are a number of production *mainframe* systems out there that have been around for a very long time and that don't run on Intel hardware or use POSIX-compatible operating systems.
The whole world isn't UNIX and Intel, just the majority. But that doesn't mean that other platforms don't exist.
There wasn't one in use (or available that I know of) on the Unisys A-series (MCP) system I did some contract work on two years ago, and the Unisys 2200 (OS2200) systems I've been using professionally for the past 15+ years have no such thing.
That isn't to say there isn't some element of control over changes, though -- we apply correction images against the base source, for example, and usually don't just do whole-hog source replacement.
When I'm writing in assembler and doing a lot of register juggling, for example, I'll usually put in-line commentary in the code describing the nature of the values I'm working with and the operations I'm performing (since that isn't obvious at all from the code statements themselves).
I also sometimes do that in older Fortran dialects since most of them are limited to six-character variable names, and since it's not always obvious what is being done.
Why is it that people seem to assume that all tools exist for all platforms?
Older techniques are sometimes still in use in various shops because that is all that is easily available.
I don't mind seeing criticisms or suggestions to use tools, but baseless insults are uncalled for.
Not all platforms have source control systems, and it isn't always convenient to use a system living on another platform.
Sometimes apparently "stupid" things are done for very good reasons.
The three items you seem to object to all have fairly legitimate uses in some computing contexts.
1. Comment each function
- Function name
Why do you need to repeat the name of the function? It's right there in the code.
Yes, and in some contexts that is precisely the problem. Depending on the language and editor(s) you are using, embedding the function names in comments can be very useful.
For example, if I use an "FC" command in a Unisys 2200 mainframe editor (say ED or UEDIT) to show all lines starting with "C" (comment lines) in a Fortran program, the results will be confusing if the function names themselves are not specified in a comment line. All I will see is comments with no context.
By adding the subroutine or function names in the related comments themselves, that missing context is restored.
5. Put in a '?' comment for code that you do not understand (good for function headers)
Code with personal annotations should never be released.
While I agree with this part,
If you don't understand it, you shouldn't be working with it; go find someone who does understand it instead, or stop and work it out.
this part of your comment seems limited to "perfect world" scenarios only.
I've spent most of my career working on mainframe code that was either originally written by people at other organizations or companies, or that was written so long ago that the original designers and coders were either retired or deceased.
When making a first pass at understanding such code, I've found it to be quite useful to leave various comments in the code so I have a good idea about my level of understanding the next time I have to come into that area of code.
I've also found such comments useful when left in the code by others, since it reflects their level of understanding as well. Some of the stuff I'm looking at now was originally coded in the early 80's and rewritten by my predecessor, and the comments he's placed in the code have proven to be invaluable to me, even though some of them were speculative in nature. Something like "What does this code do?" in his comments often alerts me to a tricky part in the logic that I'll want to pay special attention to.
FWIW, question marks and other comments/speculations are commonly used when working on someone else's previously-written code, at least in my experience, especially when that code is only intended for use in-house (the source is not released to customers).
8. Tag your bug fixes, code enhancements with a comment followed by a dash, date, and your initials. This is essential for large projects or for anything you will be working on for more than 6 months.
Once again, nothing with personal annotations should ever be released into source control. Not only should I not need to know who wrote or changed a particular snippet of code to fix a bug, I shouldn't even be able to tell by looking at the code.
When working on code that was written in-house, and which is intended to stay in-house, I *want* to know who made a certain change and why it was done. That type of notation can save me (or another support programmer) a lot of time.
While those types of details might be handled by the source control system(s) that you work with, keep in mind that some of us work on platforms where analogs to the UNIX-like source control systems many people are used to simply do not exist (and often such a thing isn't really needed).
When I did Unisys A-series mainframe contract work at a small company in southern Minnesota, they used the unparsed end of each COBOL line as a comment area, and one always placed their initials and a date there so people knew who did which changes and when those changes were created. The editor they used (CANDE) even had a special setting to automagically place a change mark on the end of each line that was modified.
A si