This is why Statistics will become more and more important over time--it allows you to make inferences about populations that you couldn't possibly count. If you already know Comp Sci or or learned how to program on your own, go for a couple of Stats degrees. Along with your programming skills Stats will do you very well as the information age unfolds.
Not a CS student. I learned software development on my own and in the industry and later returned to get a Stats degree. The reason I did that is Stats allows you to make inferences about populations from samples of the population. The utility of a Stats degree in software engineering should be self-evident: there are plenty of situations where you will be dealing with way too much information yet you have to make inferences about it. Therefore I would say if you are an able-enough programmer coming into college, keep software development as a part-time job and go for a stats degree or a math degree. In fact, better I think they teach basic programming like Java, C++, Perl, PHP, shell scripting, etc., at the level of high school and reserve CS (with emphasis on science) for college.
Years ago I used to use Coreldraw quite heavily for artwork for 4-color offset printing. But then I stumbled upon Inkscape and tried it out (both in Windows and Linux), but found it quite unsatisfactory. I never went back to it. Maybe things have changed since then.
Well, no surprise here. Governments want to get a piece of the Internet. This will drive up outsourcing prices, which drives up the market value of us programmers here in the U.S., at least a little bit.
"A couple of times in my career, I've inherited a fairly large (30-40 thousand lines) collection of code. The original authors knew it because they wrote it; I didn't, and I don't."
A couple of times in your career? You must be lucky. Most jobs you can get coding will always involve taking over someone else's code.
In my experience, design patterns are your best friend, bearing in mind that most of the code base will always remain a black box to you.
For example, when I was doing some health insurance work, I had inherited a code base that was substantially larger than 30 or 40 thousand lines of code. The objective was to make the code that used an older, fixed-length record format work with the newer X837 EDI format, which is basically XML but almost without any tags to help you figure out where the data begins and ends. Suffice it to say that the task was to figure out how to smoothly stick a square peg in a round hole.
The task itself determined the design patterns, of which an adapter pattern was the most used. The type of pattern in turn dictated what in the code to look for in order to implement it, and (of course) how the new code would be built. For example, since we were using an adapter pattern, the first order of business was to find out how the data was represented in the code base, and then trick the "black box" into using your own spiffy, new representation of the data.
For the most part I didn't have to care all that much how the application handled the data as long as I got the right data into a form the application would accept in my adapater.
I can think of several good reasons why a beginner should learn Perl:
* It is easy to learn. Don't listen to what the Python advocates tell you. There are lots of good tutorials out there on the web.
* It introduces you to syntax which is similar to other well-used languages such as C and Java. If you're going to do Perl, you're probably doing CGI, and then moving over to Java and J2EE isn't as hard as learning it from the start.
* If you learn Perl first, then classic shell languages such as bourne shell, korn shell, etc., won't be so cryptic when you need to modify or write one (and you will need to at some point). Many of Perl's built-in variables are the same as what you'll find in those shells.
* Regexes - nearly every language out there has them now, but Perl has for a long time been the leader in regexes. In my opinion, Perl's regex syntax along with the Perl culture itself encourages their broad use. When you learn regexes from Perl and you move to another langauge that has libraries for them (e.g. Java or C#), you'll find support for them but you will also find that long-time developers in those languages won't use them as much. If and when they need to use one, and they know you're into regexes, they will come to you to ask you how to construct them.
* Windows API Support - outside of Microsoft only products, Perl's library of Win32 modules is virtually unmatched by other scripting languages. Although they have them, languages like Python and Ruby don't even come close in this area. This is important because someone starting out with a programming language will often be starting out on Windows, not a *NIX platform. If you are a Windows sysadmin trying to break out of VBScript and move on to better things, then Perl is for you.
* Lots of legacy systems in production today use Perl. I was in a company once that hired some Python biggots, who wanted to convert all the programs written in Perl code to Python (and get paid for it -- har har), but the IT manager wisely kept them in check. Perl is ported to almost every flavor of *NIX out there, and then some, and on many platforms it is part of the default install package. (Sun OS is one that comes to mind.) If you know Perl, you're useful when you come across it.
* Quick and dirty scripts. Sometimes you need something that you can use quickly and throw away. Perl is perfect for one liners executed at the command prompt and for multi-line utilities. Plus, there is instant gratification that comes from creating useful one-liners, kind of like an endorphin rush.
. . . because a number of countries regularly dump hundreds of tons of grain each year to keep prices high. Just don't dump the grain and there will be no lack of food, unless some dictator withholds it to starve his own people.
Setting off a nuke on the moon. Just think of the kind of crater you can make with a nuke, the kind of dust plume you could create, and all the advertising you could get.
"This year's moon-nuke detonation has been brought to you by. .."
Since the start of the review is basically a flame against Perl, I can't resist making a plug for it--especially since it was the first serious programming language that I learned.
If a programming language is sufficiently powerful, you won't become proficient in it overnight. For myself, I went through three stages: tutorial, hobby, profession.
It started with me back in 1999 when I wanted to learn HTML, and so I set out to learn it. But in the mean time, a friend of mine in the business told me that with Perl you could pretty much do anything you want in making web applications. At the time, I didn't know the difference between server-side and client-side scripting, and I figured, why not give it a try?
So I searched on the internet and found Robert's Perl Tutorial. The introduction says, "It assumes that the reader knows nothing of programming whatsoever. .." On reading it, I knew this was for me. So, eventually I found out I had to download Perl, which I did, and then I started going through the tutorial. URL: http://www.sthomas.net/oldpages/roberts-perl-tutor ial.htm
Going through the tutorial took me two or three weeks. After finishing it, I decided to try to make my nascient website cooler than it was by adding some server-side scripting. Now that I wasn't just in the tutorial anymore, I had to learn something about CGI. That's when I found the site "CGI Programming 101", http://www.cgi101.com/class/ (I'm pleased it is still around, too.) From this I learned the rudiments of CGI programming with Perl.
From this, I wrote a program called Article Master, which, had I stuck with developing it, could have been *the* killer-app blogging software instead of MovableType. (I'm sure there are probably 50,000 other geeks out there who also started out with something like this, discontinued development on it, and are still kicking themselves in the butt for missing out on coming out with the killer app.) In any case, after building the software and getting it to work kind of OK, I developed a deployment package for it and submitted it to an online Perl script archive. After submitting it, the archive gave me a free email address and access to the exclusive programming forums. The site sent me an email telling me I got these exclusive benefits because I was a programmer.
I had never thought of myself as a programmer, but here was a site brimming with programmers telling me I was one of them. It was such a positive boost for me that it encouraged me further to develop my skills.
Soon enough, I bought the Perl CD Bookshelf from O'Reily. Now, I had all the information and reference material I needed to write almost anything I wanted. I did some other personal online projects, and then, somehow I got the idea to try out getting a job using Perl. (This was at the beginning of 2000, just before the dot-com bust, so the entrance bar was set pretty low.) I called up a head-hunting agency and asked them if they needed someone who knew Perl. The agent on the other side said, "Get down here ASAP!" I went, I took their computerized test, and the results made him do backflips. (Hey, I knew what JAPH meant, and that was a question on the test!) He said he would have no problem getting me into a job, which he did. (And the money was more than I had ever dreamed of making.)
When I started, I got an assignment (all CGI development) from one of the other lead programmers, and he asked me how long the job might take me. I hesitated, and just before I was about to say "a few days", he asked if I could do this in a few hours. I said, "Yeah, OK." I asked him if there was an HTML tool they used, and I just got this blank stare. I learned quickly that real Perl programmers don't use HTML editors--like our Perl code, we type everything else by hand. I somehow rose to the occaision and got the job done in time. From t
I once evaluated LJ, among TypePad and WordPress, and I decided that LJ was not what my group was looking for because it blocks client-side scripting. We needed client-side scripting.
. . . and more anti science comes from the Post-Modern left. When Harvard University President, Larry Summers, suggested that innate differences between men and women might have something to do with the underrepresentation of women in the hard sciences, he was reprimanded for expressing a politically incorrect opinion--science be damned. Some scientific perspective on the kerfuffle can be had here.
It'll be interesting to see what happens if missiles suddenly become useless and people have to close to visual range and dogfight away.
If missles become useless because of a laser defense system, to use the laser defense system as an offensive weapon would require a small adjustment. From that point on what will happen are initiatives to armor an aircraft against a directed energy weapon, when someone figures out how to pack a laser on a MIG.
Well, I took the Central Hindi Directorate course, so that's why I recommend it. A couple of dictionaries would help too. Father Kamal Bulke's English to Hindi dictionary is good for contemporary Hindi. "A Practical Hindi English Dictionary" (Hindi to English) by Mahendra Chaturvedi is also very good.
Alternatively, you might want to try snooping around Bharatiya Vidya Bhavan for elementary school books on Hindi. (Again, I don't have a link but I suspect they have a huge website.)
Right now I'm working on learning Sanskrit, a not quite as dead language as some others mentioned here. (In India you can still get the evening news in Sansrkit over the radio.)
No, you just have to watch them along with studying. If you just spend 1/2 an hour a day 5 - 7 days per week, open-ended, working with the books, and watching Hindi movies after you build up some vocabulary, then you will start to enjoy them.
I don't have the link for it, but the Indian Government's Central Hindi Directorate has a very good Hindi correspondence course. And a real human grades you, too!
The Indian government has a comprehensive program to practically make Hindi its national language. Officially, Hindi is its national language, but not all non-Hindi states (like Tamil Nadu) like that.
Along with your elementary Hindi readers and text books, watch Hindi movies! In Bollywood movies they speak excellent Hindi, and it generally isn't corrupted as it is spoken by people who natively speak Gujarati, Marathi or one of the other non-Hindi Indian languages.
And you also get entertained.
I currently work for the government, and we *try* use the SEI's Capability Maturity Model. The problem is that we try to use it in a maintenance and support environment.
First problem is that critical tools are sadly lacking. Unless you are adding a new feature, it is very time consuming and tedious to keep track of all your changes so that you can, as in the Personal Software Process, keep accurate statistics of what changes you made, how many lines of code were modified, how many were deleted, and how many lines of code you added. PSP, for example, is taught only for one language, but many projects and even many modules themselves use multiple languages. Yes, we have been using Process Dashboard (an open source PSP tool which tabulates your time and lines of code), but the real need is for a tool that can automatically keep track of all the changes you make while you make them. (An Eclipse plugin along these lines would be very cool.)
Another problem with CMM or other like methodologies is that some requirements are often enough not well known until the system makes it into production. Also, if future needs change, your software has to change with it. Unless you are making software for pace makers or weapons (things for which the specifications cannot be changed because they perform critical functions and sometimes even have to be proved by theorem), your users and management *will* come to you with requests for further enhancements, what to speak of all the bug fixes that will be there. Nothing much you can do to prevent it. Because most people who maintain the system once it goes into production are not the people who built the system, what happens then is that an awful (and I really mean awful) amount of time is spent by programmers just trying to figure out the system itself, tracking down what components need to be modified and why and where. And then once they have gone through all that, THEN they can make an estimate that is somewhat compatible to what PSP requires. Basically, the lions' share of programming time goes into the planning stage without touching a line of code, something that doesn't feel very good if, like most programmers, you like to build things. Sure, adequate documentation helps, but there is always a tradeoff between process and getting the job done expediently.
Advocates for agile development processes have typically said that processes like XP are the solution. But I've also developed using XP and have found that compared to something like PSP it lacks in its ability to make accurate predictions about how long it will really take to complete a task. This is because XP more or less uses rule-of-thumb engineering judgement to make time estimates whereas PSP tries to base estimates on historical data. (Of course, up until you get your historical data, even PSP uses engineering judgement). However, XP deals with an aspect of reality the more formal processes like PSP don't address so much, which is that most software specifications are going to change througout the project and change in post production in unexpected ways.
In summary, processes like PSP (CMM) lack critical tools needed to unburden developers from excessive process overhead. These methodologies are meant specifically for building new software, not dealing with the realities of built software, which is usually maintained and enhanced by someone other than the person who built it. IMHO what is needed are people to build automated tracking tools for changes made by coders and for more research and development in the area of operations and maintenance, which according to Sun Microsystems occupies as much as 80% of the development time on any code base.
Ever been to a public library in America? There are plenty of book-cases full of trashy romance novels, teen novels, popular interest magazines, and books that never made it to the Harvard Great Classics collection.
The blogosphere is no different. There are tons of blogs that are trashy, not very interesting, examples of poor writing, but in their midst there are gems of blogs that are paragons of excellent thinking, writing and exemplify the best in journalistic practice and ethics.
The criticism meted out was unfair, as that was judging the work of all bloggers by the worst among them. Would it be appropriate to judge the literary taste of librarians by all the Harlequin romance novels most of them keep on library shelves?
While we can practice (as this version of the story at Yahoo! suggests) a possible Mars mission by going to the moon, we have already done that! We did it in the 60s... that was almost 35 years ago!! What's on the moon?
Nothing is on the Moon--absolutely nothing. That's what is so great about it. Cost effective space exploration depends on developing propulsion systems which developing on Earth is very risky to the environment.
or at least their 56Kbaud modems scream compared to whatever modems they had 10 years ago. So they can download Perl, download an online tutorial, and start to learn how to program. What can be simpler than
This book has been a long time in waiting. I've used PerlXS to preserve legacy code written in C with more than satisfactory results. I had to do this on a win32 platform, where the man pages (usually written for *NIX environments) don't always 100% translate to a win32 environment.
Nope. Not any harder. Also a web server configuration - you can do something "special" with errors on any web server I've ever encountered both in Unix and Microsoft world.
Sure it is harder.
You have to make two platforms work together rather than work on one platform that does it all. From an archival standpoint, its easier to CVS your one WebApp rather than your httpd.conf + your CGI scripts. Of course, you could always #Include the code for the httpd.conf and bundle it with your CGI scripts, but that's not done much.
From a coding point of view, because you write your code in one place, there is more incentive to use features that you would otherwise have to modify your server config for. Most CGI programmers (and it doesn't have to be with Perl) don't often code both the httpd.conf and their collection of scripts at the same time. And those who need to code both Perl and Apache are probably working in mod_perl.
You seem to have a beef with Perl because you don't like Apache.
Wrong. I love apache. In fact, I interface Apache and Tomcat most of the time. It just that a framework that combines many traditional server features and scripting features makes much more sense to program in.
Perl is a just a language, not a platform. You can write.Net web apps in perl if you like and then you have all the goodies that you like so much about Tomcat but in perl (using IIS).
I'll wait for Perl6 to come out, which will be opensource answer to Java. I'm not a Microsoft fan, and I'm not about to pay $$$ for IIS when Apache and Tomcat are better and free.
Slashdot Mirror
This is why Statistics will become more and more important over time--it allows you to make inferences about populations that you couldn't possibly count. If you already know Comp Sci or or learned how to program on your own, go for a couple of Stats degrees. Along with your programming skills Stats will do you very well as the information age unfolds.
Not a CS student. I learned software development on my own and in the industry and later returned to get a Stats degree. The reason I did that is Stats allows you to make inferences about populations from samples of the population. The utility of a Stats degree in software engineering should be self-evident: there are plenty of situations where you will be dealing with way too much information yet you have to make inferences about it. Therefore I would say if you are an able-enough programmer coming into college, keep software development as a part-time job and go for a stats degree or a math degree. In fact, better I think they teach basic programming like Java, C++, Perl, PHP, shell scripting, etc., at the level of high school and reserve CS (with emphasis on science) for college.
Years ago I used to use Coreldraw quite heavily for artwork for 4-color offset printing. But then I stumbled upon Inkscape and tried it out (both in Windows and Linux), but found it quite unsatisfactory. I never went back to it. Maybe things have changed since then.
Well, no surprise here. Governments want to get a piece of the Internet. This will drive up outsourcing prices, which drives up the market value of us programmers here in the U.S., at least a little bit.
"A couple of times in my career, I've inherited a fairly large (30-40 thousand lines) collection of code. The original authors knew it because they wrote it; I didn't, and I don't."
A couple of times in your career? You must be lucky. Most jobs you can get coding will always involve taking over someone else's code.
In my experience, design patterns are your best friend, bearing in mind that most of the code base will always remain a black box to you.
For example, when I was doing some health insurance work, I had inherited a code base that was substantially larger than 30 or 40 thousand lines of code. The objective was to make the code that used an older, fixed-length record format work with the newer X837 EDI format, which is basically XML but almost without any tags to help you figure out where the data begins and ends. Suffice it to say that the task was to figure out how to smoothly stick a square peg in a round hole.
The task itself determined the design patterns, of which an adapter pattern was the most used. The type of pattern in turn dictated what in the code to look for in order to implement it, and (of course) how the new code would be built. For example, since we were using an adapter pattern, the first order of business was to find out how the data was represented in the code base, and then trick the "black box" into using your own spiffy, new representation of the data.
For the most part I didn't have to care all that much how the application handled the data as long as I got the right data into a form the application would accept in my adapater.
I can think of several good reasons why a beginner should learn Perl:
* It is easy to learn. Don't listen to what the Python advocates tell you. There are lots of good tutorials out there on the web.
* It introduces you to syntax which is similar to other well-used languages such as C and Java. If you're going to do Perl, you're probably doing CGI, and then moving over to Java and J2EE isn't as hard as learning it from the start.
* If you learn Perl first, then classic shell languages such as bourne shell, korn shell, etc., won't be so cryptic when you need to modify or write one (and you will need to at some point). Many of Perl's built-in variables are the same as what you'll find in those shells.
* Regexes - nearly every language out there has them now, but Perl has for a long time been the leader in regexes. In my opinion, Perl's regex syntax along with the Perl culture itself encourages their broad use. When you learn regexes from Perl and you move to another langauge that has libraries for them (e.g. Java or C#), you'll find support for them but you will also find that long-time developers in those languages won't use them as much. If and when they need to use one, and they know you're into regexes, they will come to you to ask you how to construct them.
* Windows API Support - outside of Microsoft only products, Perl's library of Win32 modules is virtually unmatched by other scripting languages. Although they have them, languages like Python and Ruby don't even come close in this area. This is important because someone starting out with a programming language will often be starting out on Windows, not a *NIX platform. If you are a Windows sysadmin trying to break out of VBScript and move on to better things, then Perl is for you.
* Lots of legacy systems in production today use Perl. I was in a company once that hired some Python biggots, who wanted to convert all the programs written in Perl code to Python (and get paid for it -- har har), but the IT manager wisely kept them in check. Perl is ported to almost every flavor of *NIX out there, and then some, and on many platforms it is part of the default install package. (Sun OS is one that comes to mind.) If you know Perl, you're useful when you come across it.
* Quick and dirty scripts. Sometimes you need something that you can use quickly and throw away. Perl is perfect for one liners executed at the command prompt and for multi-line utilities. Plus, there is instant gratification that comes from creating useful one-liners, kind of like an endorphin rush.
"Hi jackass, RTFM and stop wasting our time trying to help you children learn."
For a long time this defined the culture on the newsgroup comp.lang.perl.misc I'll bet this had something to do with the creation of Python.
. . . because a number of countries regularly dump hundreds of tons of grain each year to keep prices high. Just don't dump the grain and there will be no lack of food, unless some dictator withholds it to starve his own people.
Setting off a nuke on the moon. Just think of the kind of crater you can make with a nuke, the kind of dust plume you could create, and all the advertising you could get.
."
"This year's moon-nuke detonation has been brought to you by. .
Since the start of the review is basically a flame against Perl, I can't resist making a plug for it--especially since it was the first serious programming language that I learned.
." On reading it, I knew this was for me. So, eventually I found out I had to download Perl, which I did, and then I started going through the tutorial. URL: http://www.sthomas.net/oldpages/roberts-perl-tutor ial.htm
If a programming language is sufficiently powerful, you won't become proficient in it overnight. For myself, I went through three stages: tutorial, hobby, profession.
It started with me back in 1999 when I wanted to learn HTML, and so I set out to learn it. But in the mean time, a friend of mine in the business told me that with Perl you could pretty much do anything you want in making web applications. At the time, I didn't know the difference between server-side and client-side scripting, and I figured, why not give it a try?
So I searched on the internet and found Robert's Perl Tutorial. The introduction says, "It assumes that the reader knows nothing of programming whatsoever. .
Going through the tutorial took me two or three weeks. After finishing it, I decided to try to make my nascient website cooler than it was by adding some server-side scripting. Now that I wasn't just in the tutorial anymore, I had to learn something about CGI. That's when I found the site "CGI Programming 101", http://www.cgi101.com/class/ (I'm pleased it is still around, too.) From this I learned the rudiments of CGI programming with Perl.
From this, I wrote a program called Article Master, which, had I stuck with developing it, could have been *the* killer-app blogging software instead of MovableType. (I'm sure there are probably 50,000 other geeks out there who also started out with something like this, discontinued development on it, and are still kicking themselves in the butt for missing out on coming out with the killer app.) In any case, after building the software and getting it to work kind of OK, I developed a deployment package for it and submitted it to an online Perl script archive. After submitting it, the archive gave me a free email address and access to the exclusive programming forums. The site sent me an email telling me I got these exclusive benefits because I was a programmer.
I had never thought of myself as a programmer, but here was a site brimming with programmers telling me I was one of them. It was such a positive boost for me that it encouraged me further to develop my skills.
Soon enough, I bought the Perl CD Bookshelf from O'Reily. Now, I had all the information and reference material I needed to write almost anything I wanted. I did some other personal online projects, and then, somehow I got the idea to try out getting a job using Perl. (This was at the beginning of 2000, just before the dot-com bust, so the entrance bar was set pretty low.) I called up a head-hunting agency and asked them if they needed someone who knew Perl. The agent on the other side said, "Get down here ASAP!" I went, I took their computerized test, and the results made him do backflips. (Hey, I knew what JAPH meant, and that was a question on the test!) He said he would have no problem getting me into a job, which he did. (And the money was more than I had ever dreamed of making.)
When I started, I got an assignment (all CGI development) from one of the other lead programmers, and he asked me how long the job might take me. I hesitated, and just before I was about to say "a few days", he asked if I could do this in a few hours. I said, "Yeah, OK." I asked him if there was an HTML tool they used, and I just got this blank stare. I learned quickly that real Perl programmers don't use HTML editors--like our Perl code, we type everything else by hand. I somehow rose to the occaision and got the job done in time. From t
I once evaluated LJ, among TypePad and WordPress, and I decided that LJ was not what my group was looking for because it blocks client-side scripting. We needed client-side scripting.
. . . and more anti science comes from the Post-Modern left. When Harvard University President, Larry Summers, suggested that innate differences between men and women might have something to do with the underrepresentation of women in the hard sciences, he was reprimanded for expressing a politically incorrect opinion--science be damned. Some scientific perspective on the kerfuffle can be had here.
If missles become useless because of a laser defense system, to use the laser defense system as an offensive weapon would require a small adjustment. From that point on what will happen are initiatives to armor an aircraft against a directed energy weapon, when someone figures out how to pack a laser on a MIG.
Well, I took the Central Hindi Directorate course, so that's why I recommend it. A couple of dictionaries would help too. Father Kamal Bulke's English to Hindi dictionary is good for contemporary Hindi. "A Practical Hindi English Dictionary" (Hindi to English) by Mahendra Chaturvedi is also very good.
Alternatively, you might want to try snooping around Bharatiya Vidya Bhavan for elementary school books on Hindi. (Again, I don't have a link but I suspect they have a huge website.)
Right now I'm working on learning Sanskrit, a not quite as dead language as some others mentioned here. (In India you can still get the evening news in Sansrkit over the radio.)
No, you just have to watch them along with studying. If you just spend 1/2 an hour a day 5 - 7 days per week, open-ended, working with the books, and watching Hindi movies after you build up some vocabulary, then you will start to enjoy them.
I don't have the link for it, but the Indian Government's Central Hindi Directorate has a very good Hindi correspondence course. And a real human grades you, too!
The Indian government has a comprehensive program to practically make Hindi its national language. Officially, Hindi is its national language, but not all non-Hindi states (like Tamil Nadu) like that.
Along with your elementary Hindi readers and text books, watch Hindi movies! In Bollywood movies they speak excellent Hindi, and it generally isn't corrupted as it is spoken by people who natively speak Gujarati, Marathi or one of the other non-Hindi Indian languages. And you also get entertained.
I currently work for the government, and we *try* use the SEI's Capability Maturity Model. The problem is that we try to use it in a maintenance and support environment.
First problem is that critical tools are sadly lacking. Unless you are adding a new feature, it is very time consuming and tedious to keep track of all your changes so that you can, as in the Personal Software Process, keep accurate statistics of what changes you made, how many lines of code were modified, how many were deleted, and how many lines of code you added. PSP, for example, is taught only for one language, but many projects and even many modules themselves use multiple languages. Yes, we have been using Process Dashboard (an open source PSP tool which tabulates your time and lines of code), but the real need is for a tool that can automatically keep track of all the changes you make while you make them. (An Eclipse plugin along these lines would be very cool.)
Another problem with CMM or other like methodologies is that some requirements are often enough not well known until the system makes it into production. Also, if future needs change, your software has to change with it. Unless you are making software for pace makers or weapons (things for which the specifications cannot be changed because they perform critical functions and sometimes even have to be proved by theorem), your users and management *will* come to you with requests for further enhancements, what to speak of all the bug fixes that will be there. Nothing much you can do to prevent it. Because most people who maintain the system once it goes into production are not the people who built the system, what happens then is that an awful (and I really mean awful) amount of time is spent by programmers just trying to figure out the system itself, tracking down what components need to be modified and why and where. And then once they have gone through all that, THEN they can make an estimate that is somewhat compatible to what PSP requires. Basically, the lions' share of programming time goes into the planning stage without touching a line of code, something that doesn't feel very good if, like most programmers, you like to build things. Sure, adequate documentation helps, but there is always a tradeoff between process and getting the job done expediently.
Advocates for agile development processes have typically said that processes like XP are the solution. But I've also developed using XP and have found that compared to something like PSP it lacks in its ability to make accurate predictions about how long it will really take to complete a task. This is because XP more or less uses rule-of-thumb engineering judgement to make time estimates whereas PSP tries to base estimates on historical data. (Of course, up until you get your historical data, even PSP uses engineering judgement). However, XP deals with an aspect of reality the more formal processes like PSP don't address so much, which is that most software specifications are going to change througout the project and change in post production in unexpected ways.
In summary, processes like PSP (CMM) lack critical tools needed to unburden developers from excessive process overhead. These methodologies are meant specifically for building new software, not dealing with the realities of built software, which is usually maintained and enhanced by someone other than the person who built it. IMHO what is needed are people to build automated tracking tools for changes made by coders and for more research and development in the area of operations and maintenance, which according to Sun Microsystems occupies as much as 80% of the development time on any code base.
Ever been to a public library in America? There are plenty of book-cases full of trashy romance novels, teen novels, popular interest magazines, and books that never made it to the Harvard Great Classics collection. The blogosphere is no different. There are tons of blogs that are trashy, not very interesting, examples of poor writing, but in their midst there are gems of blogs that are paragons of excellent thinking, writing and exemplify the best in journalistic practice and ethics. The criticism meted out was unfair, as that was judging the work of all bloggers by the worst among them. Would it be appropriate to judge the literary taste of librarians by all the Harlequin romance novels most of them keep on library shelves?
Nothing is on the Moon--absolutely nothing. That's what is so great about it. Cost effective space exploration depends on developing propulsion systems which developing on Earth is very risky to the environment.
I'm sick of hearing of RIAA, the link to the Wired story of creating artificial diamonds was far more interesting.
here
or at least their 56Kbaud modems scream compared to whatever modems they had 10 years ago. So they can download Perl, download an online tutorial, and start to learn how to program. What can be simpler than
At the bottom of the page is found:
This book has been a long time in waiting. I've used PerlXS to preserve legacy code written in C with more than satisfactory results. I had to do this on a win32 platform, where the man pages (usually written for *NIX environments) don't always 100% translate to a win32 environment.
I'll probably get the book.
Sure it is harder.
You have to make two platforms work together rather than work on one platform that does it all. From an archival standpoint, its easier to CVS your one WebApp rather than your httpd.conf + your CGI scripts. Of course, you could always #Include the code for the httpd.conf and bundle it with your CGI scripts, but that's not done much.
From a coding point of view, because you write your code in one place, there is more incentive to use features that you would otherwise have to modify your server config for. Most CGI programmers (and it doesn't have to be with Perl) don't often code both the httpd.conf and their collection of scripts at the same time. And those who need to code both Perl and Apache are probably working in mod_perl.
Wrong. I love apache. In fact, I interface Apache and Tomcat most of the time. It just that a framework that combines many traditional server features and scripting features makes much more sense to program in.
I'll wait for Perl6 to come out, which will be opensource answer to Java. I'm not a Microsoft fan, and I'm not about to pay $$$ for IIS when Apache and Tomcat are better and free.