CPAN: $677 Million of Perl

Adam K writes "It had to happen eventually. CPAN has finally gotten the sloccount treatment, and the results are interesting. At 15.4 million lines of code, CPAN is starting to approach the size of the entire Redhat 6.2 distribution mentioned in David Wheeler's original paper. Could this help explain perl's relatively low position in the SourceForge.net language numbers?"

Comments

Interesting... POPFile cost $500K

[JohnGrahamCumming]

Wow, using sloccount on the full POPFile source shows that developing it would have cost around $500K in a regular software company. That seems about right given the length of time we've been working on it and the number of people involved. Cool tool.

Now if only I could push the donations up above $5,000 :-)

John.

Re:Interesting... POPFile cost $500K

[DaHat]

I beg to differ.

Should your 'ruling class' not have the work being done for them by the working class', the 'working class' would starve long before it's masters. The 'working class' is far more likely to live paycheck to paycheck than the 'ruling class'

Coincidently, while this was being typed my boss came by with my paycheck... now I can pay down my student loan debt by a small fraction!

I don't know about you, but I know that my corporate masters have much bigger savings accounts and investments then I or most in my department.

Re:Interesting... POPFile cost $500K

[ajs318]

But if you weren't spending so much of your precious time in your factory or office working for your boss, then you would be free to pursue alternative survival techniques that do not depend on a regular supply of pound notes ..... such as growing your own food, sewing your own clothes, building your own shelter. The Working Class are better equipped to do this than the Ruling Class, because we already have at least some of the necessary skills from the work we already do for the Ruling Class; whereas the Ruling Class is absolutely dependent on the Working Class for everything. Can you imagine the owner of a chain of restaurants knowing how to peel a potato, or the owners of a chain of electronics stores knowing how to wire up a 13 amp plug? Do you think that the owners of Ford or GM know how to change a tyre?

Re:Interesting... POPFile cost $500K

[redtux1]

parent was not not too precise, but the point is true, just not on an individual basis.

to rephrase

The working as a whole would last longer than the employing class (capitalistists - I include sub-contarctors in the former).

The reason being that the capistalist list class, in simplified terms survives and prospers by earning money off invetsments, the value of which is ultimately determined by the labour put into them. The Working/middle class gets its money by doing the work.

Classic,very simplified marxist economics.

and yeah, I know unreconstructed marxist, blah, blah.

Still true tho'

Re:Interesting... POPFile cost $500K

[the chao goes mu]

Anyone lacking the capacity to peel a potato lacks the intelligence to do pretty much anything. I doubt your "ruling class" is so out of touch with reality that they lack some of the basic skills you describe.

Also, though you think it impossible, some do rise through the ranks to join your so-called ruling class. Do you think they then forget all that they previously knew?

In fact, that's one of the major shortcomings of your Marxist view, it assumes "classes" are somehow innate, assigned at birth, and immutable. The theory is at odds with reality.

Re:Interesting... POPFile cost $500K

[kryptkpr]

In fact, that's one of the major shortcomings of your Marxist view, it assumes "classes" are somehow innate, assigned at birth, and immutable. The theory is at odds with reality.

But classes are assigned at birth. You are born into a poor family, or a rich family. You were born to a Jewish family, or a Christian family. The truth of the matter remains that you will _most likely_ continue to lead the same lifestyle as your parents and family.

However, nobody said anything about classes being immutable .. lots of children rebel against their parent's ways, and decide to do something completely different.

Re:Interesting... POPFile cost $500K

[meme_police]

Not true, more people in the working class have the skills to support themselves with a trade in a barter society than the ruling class does. If the ruling class is deposed they usually end up surviving on savings or the good nature of their followers.

Re:Interesting... POPFile cost $500K

[Hognoxious]

The reason being that the capistalist list class, in simplified terms survives and prospers by earning money off invetsments, the value of which is ultimately determined by the labour put into them. The Working/middle class gets its money by doing the work.

Much as I hate marxists, you are right.

The reason is, in a society like any modern western one, the capitalists own the means of production, and are able to skim off the value of "the labour put into them", as you say. They can enforce that ownership by means of the courts & police.

However, in the post-apocalypse world much beleoved of novelists and movie-makers, nobody owns nothing, unless they've got a bigger, meaner, better armed gang than anybody else that wants it.

Lucifer's Hammer is a very good book, IMHO.

yeah, but try removing the punctuation

[WebMasterJoe]

If you take out the punctuation, though, it's down to twelve lines of code.

Re:yeah, but try removing the punctuation

[haystor]

You mean:

If you take out the punctuation, it's down to twelve lines of comments.

Huh?

[Billobob]

Low position? For a language that's not suppose to be a full-blown low-level language like C/C++, perl is pretty damn well represented - over 1/3 the number of projects compared to C isn't that bad. If you have just one file, something like sourceforge usually isn't needed.

Re:Huh?

[XemonerdX]

Did you even attempt to click the underlined word 'sloccount'? If not, do it now and read the first line of the first paragraph.

Subject rejected - looks too much like ASCII art!

[Greg Larkin]

Can the tool also figure out how much of the CPAN code looks like line noise in a terminal window?

[Ob. reference: I love Perl and use it all of the time, but a programmer I met years ago said it was the only language where the source code reminded him of line noise]

Bahhh!

[justanyone]

Bahhh, I know people richer than that!

Now compute the economic gain of using Perl vs. any other language:
Perl vs. Nothing : $677M
Perl vs. C : $1.25B
Perl vs. C# : $2.77B
Perl vs. Hand Optimized Assembly on Honeywell DPS-3E running GCOS operating system: Priceless

Re:Bahhh!

[trentblase]

Wait, so I'm sitting here using nothing. If I switch to Perl I'm going to make $677M? Sweet!

Mining CPan

[Numen]

Whatever ones favourite language might be, a project to mine CPan and port useful modules to Python, Java or C# would be interesting.... Perl syntax reads as a little terse to many non-Perl devs.

Re:Mining CPan

[Dr. Zowie]

>"C#"
You misspelled "INTERCAL".

Re:Mining CPan

[Daniel Dvorkin]

Well, what I'd like to see first would be a Python equivalent to CPAN existing in the first place. (Name suggestion, since CPAN is taken: CYAN, the Comprehensive pYthon Archive Network.) Languages such as PHP with PEAR, and R with CRAN, have done very well following the same model, even if these archives aren't nearly as big or comprehensive as CPAN. Give it time, give it time ...

And for those who say "do it yourself" -- I don't have the resources. However, I will say, that if CYAN existed, I would happily put some of my own time into porting CPAN (or, for that matter, PEAR and CRAN) modules I've found useful.

Re:Mining CPan

[Waffle Iron]

Well, what I'd like to see first would be a Python equivalent to CPAN existing in the first place.

While it's not nearly as big as CPAN, I often find Python code I need in the Vaults of Parnassus

Re:Mining CPan

[Daniel Dvorkin]

Oh yeah, that's a good site, and I've found some useful stuff there. It just seems kind of ... unstructured compared to CPAN. The bigger flaw is that I can't type "vex install PACKAGE" at the command line and have it happen automagically. CPAN takes a lot of flak, but it's damn easy to use.

Re:Mining CPan

[imroy]

I think the Python work would be interesting. I'm a long-time Perl coder and Python looks interesting. But IMHO, PHP would be a waste of time. Part of the reason CPAN is so huge is that perl5 is coming up to its 10th anniversary. The perl5 language has remained very stable over that time. But PHP5 has just been released and from what I've heard it's another major change to the language. But if it's got namespaces and/or sane package management like everyone's been begging for, then PEAR might start to really pick up. I guess we'll see in another 10 years. Either PEAR will be huge success, or programmers will reminisce "Remember PHP? I think someone's coded up a Parrot compiler for that old language " :)

Re:Mining CPan

[ajs]

I checked out that site.

I only looked at a handfull of the links. It's sort of a Yahoo! (the original indexer, not todays search engine-cum-kitchen sink) for Python code, which is ok, but check out how one uses CPAN in the real world:

# perl -MCPAN -e shell
cpan> i /SpamAssassin/
Distribution F/FE/FELICITY/Mail-SpamAssassin-2.63.tar.gz
Modul e Mail::SpamAssassin (F/FE/FELICITY/Mail-SpamAssassin-2.63.tar.gz)
cpa n> install Mail::SpamAssassin
---- Unsatisfied dependencies detected during [F/FE/FELICITY/Mail-SpamAssassin-2.63.tar.gz] -----
Filter::Simple
Shall I follow them and prepend them to the queue
of modules we are processing right now? [yes]

I'm sure you can see how this makes CPAN far more useful for building a large repository of useful Perl modules. How, in Python, can you build several layers of libraries that depend on each other without this kind of repository of dependency information? How does a user "come into the know" about these factors?

Of course, that ignores the fact that CPAN modules all come with regression testing and online documentation (installed in the sytem "man" tree) as well.

Re:Mining CPan

[Thing 1]

not todays search engine-cum-kitchen sink

Yuck, I wouldn't want to eat off dishes cleaned in that sink...

Re:Huh?

[_14k4]

Here, I'll repost the link from the article you never read:

sloccount

Golf?

[ellem]

Pfft 15.4 Million lines?

I could write CPAN in a one liner!

#! /usr/bin/perl
use warnings ;
use strict ;

print "CPAN: ;

Re:Golf?

[decepetion]

you mean perl -e 'print "Cpan\n"' THAT is a one-liner

Re:Golf?

[the_mad_poster]

Um... because if it put the string terminator right before EOF you'd, presumably, wind up with one giant print statement that just prints out your source code from the point of the original goof? And that would be stupid?

Perl isn't Linux

[gorim]

Perl is a cross-platform tool that existed long before Linux did. Why do such things get posted under Linux ? May as well post it under BSD it would be doing the same thing. This happened with the recent Bash 3.0 topic as well. Why do people associate things with Linux just because it is open source ? (Unless it is BSD open source).

Re:Perl isn't Linux

[maxwell demon]

Well, it's not Microsoft, it's not Apple, so it must be Linux. Easy, isn't it? :-)

Re:Perl isn't Linux

[Prowl]

looks like it's been changed to "Perl" now. Yesterday's bash 3 story still appears to be in "Linux" though.

Re:Perl isn't Linux

[slashdrone]

Right! That's why it should be called GNU/Perl/Linux.

Re:Perl isn't Linux

[GedConk]

Well, on the plus side, the Linux color scheme is one of the less painfull on the eye.

Just be thankfull it is not posted under IT
*shivers*

Re:Perl isn't Linux

[nicolas.e]

Why not BSD ?

Re:Perl isn't Linux

[maxwell demon]

Ok, here's the true story of Unix:

Someone has invented a time machine (at some time in the future, but as soon as a time machine is invented, the difference between future and past isn't really relevant anyway). On his first trip into the past, he left a printout of the Linux kernel source in the past. Someone found it, thought he could improve it and called the resulting system Multics. Now, that system turned out too complicated, and therefore the developers went back to the original Linux design, and called that system Unix. Therefore anything Unixoid is in truth Linuxoid, and therefore belongs into the Linux section.

Useless Measurement?

[webword]

What is more important, lines of code or lines of quality code? People are always so impressed with sheer numbers. Quality is important.

A similar issue is format and structure. You might do something almost right, but it could be better. For example, you might include dates on your web pages but is the format good for users? It can probably be better!

Numbers are only impressive when they are placed in context of their overall utility. Of course, regarding code, measuring "overall utitility" is no joke. Can you really tell that the code from Programmer A is better than Programmer B.

In any event, keep your eyes open. Don't let "15.4 million lines of code" amaze you just because the number is big. Let it amaze you because of what it means, and what those lines of code do for users.

Re:Useless Measurement?

[Zebbers]

Ummm that date article makes a few decent points but is mostly a single person's rant.

While true when dealing with CPAN, I think we know RH's utility and the main issue is that it is free.

Re:Useless Measurement?

[Geoff-with-a-G]

What is more important, lines of code or lines of quality code? People are always so impressed with sheer numbers. Quality is important.

Seriously.
And it's Perl.
I thought the whole point was that you could write a massive Perl program in a single line.
15.4 million just tells me that CPAN is getting sloppy. Let's knock that down to say, 17 HUGE lines, okay?

Re:Useless Measurement?

[ajs]

LOC isn't a great measure, but when talking about CPAN there are several things to keep in mind that modify the premise of measuring LOC:

• Perl modules on CPAN include their own, customized installation and testing harness. This renders them far more valuable than a simple dumping ground of LOC.
  
• CPAN presents a searchable, globally mirrored database of this code, which again increases its value.
  
• Perl itself has an extremely powerful syntax. Many of Perl's detractors, in fact, will claim that this is far too much power to have in a syntax (vs. grammar and/or semantics and/or external libraries), so comparing 1000 LOC in Perl to 1000 LOC in, say, Java or C# or other "mid-level languages" (my phrase) can be quite favorable to Perl. Even comparing to other high-level languages can be, depending on the application (of course, each high level language has its own strengths, and for example, Python's thread handling is much simpler than Perl's, and both Ruby and Python make OO much easier).
  

That said, I think that the idea that comparing LOC in, say, a Red Hat distribution to LOC in CPAN is valuable, regardless of the fact that structure and format are also concerns. They are equally concerns in both environments, and both environments have roughly equal pressures on improving both incrementally over time (e.g. bad code gets migrated away from the core and good code gets migrated in).

ALL OF THAT aside, Perl's CPAN is most valuable not because of its size or the quality of the code, but because it is a repository where thousands of people with highly specialized needs share code with each other. Perl is unique in having created such a space that is widely used outside of core advocates of the language. I don't know why that's the case, but as long as it is, it's a very good thing.

Getting code noticed by your niche's peers and making it available for everyone to use is key to Perl's success as a language.

Re:Useless Measurement?

[matthewsmalley]

The first date format is the one I see the most often. Ironically, it is the one used most often.

There's either a very subtle wit at work here, or just an uncaught tautology.

Odd thing to write a rant about, but I guess everyone's got their pet peeve.

On a more constructive note... padding with a 0 helps maintain fixed widths for columns of data of course.

Re:Useless Measurement?

[FLEB]

Dates: I've always been a fan of "2004-07JY-30". The other ones won't sort alphanumerically.

Re:Useless Measurement?

[vhold]

What exactly is your question that makes it a useless measure and quality of code a useful one?

My question "How many lines of code are there in this central repository?" is answered perfectly by the measure of "Lines of code in this central repository", making it the most useful measure possible in at least one situation.

Re:Useless Measurement?

[StrongAxe]

For example, you might include dates on your web pages but is the format good for users? It can probably be better!

I've gone to many web pages looking for dates, without success. (I suspect that many slashdotters have had similar experiences.)

Re:Useless Measurement?

[H09N0X10U5]

What are usenets? Do they come on AOL discs?

Oh, and are they good or are they whack?

Relatively low?

[stinkyfingers]

It's relatively low because that list is in alphabetical order!

Re:Relatively low?

[babbage]

Yeah, no kidding. Just think about how dejected the Zope guys must feel with their nice modern system when both Ada and APL are blasting from the past ahead of all other languages. Maybe they'll try to get ahead by renaming themselves to "Aaaaaaa Zope".

:-)

Re:Relatively low?

[nysus]

5th. You overlooked Java.

Nevermind, I goofed, hit "IT" right above "Linux"

[gorim]

Embarassing I know. Maybe I can blame on silly new topics and color schemes that are so close to each other :)

Gilb's Law

[YetAnotherName]

For anyone who says that lines of code isn't a useful measure, just remember "Gilb's Law":

Two years ago at a conference in London, I spent an afternoon with Tom Gilb, the author of Software Metrics ... I found that an easy way to get him heated up was to suggest that something you need to know is "unmeasurable." The man was offended by the very idea. He favored me that day with a description of what he considered a fundamental truth about measurability. The idea seemed at once so wise and so encouraging that I copied it verbatim into my journal under the heading of Gilb's Law:

Anything you need to quanitfy can be measured in some way that is superior to not measuring it at all.

Gilb's Law doesn't promise you that measurement will be free or even cheap, and it may not be perfect---just better than nothing.

--Tom DeMarco and Timothy Lister, Peopleware 2/E, Dorset House Publishing, New York, 1999.

Re:Gilb's Law

[Troed]

Invalid* measurements are worse than no measurements at all.

- from someone educated according to Gilb's principles, but "a few" years in the industry wiser now.

* Invalid in this context means (among other things) statistically uncertain. "It says X here!" is worse when managements says it than "We don't know" and they then ask your current opinion.

Re:Gilb's Law

[duckandcoveranduck]

No, sometimes it's better to know that you don't know something for sure than to have the false assurance of some (almost) made-up numbers.

Re:Gilb's Law

[Minwee]

I'm not seeing any connection there.

Glib's Law only states that there exists _some_ measure with a value greater than that of not measuring. It doesn't say that every measure, no matter how bizarre, is better than nothing. Glib's Law tells us nothing about the value of lines of code.

If measurement for measurement's sake was always a good thing then I could take an eight bit CRC of the source code or the ratio of "e"s to "i"s and use those as metrics for quality.

Re:Gilb's Law

[Profane MuthaFucka]

The case of "I don't know" is just a special case of any other measurement. The error bars go from -infinity to +infinity, rather than some smaller range.

The problems lie when people leave off the error bars.

Re:Gilb's Law

[ClosedSource]

Gilb's law doesn't appear to be based on logic. It suggests a relationship between your needs and useful measures (if you don't have a need to quantify something, does that mean it can't be measured?").

In addition, even if it was a fact that something "can be measured" that doesn't imply that any particular individual or institution is capable of performing that measurement.

I think Gilb's law is primarily based on denial. Humans want to believe they are in charge of the universe and many can't accept the fact that they aren't.

Re:Gilb's Law

[xdroop]

Anything you need to quanitfy can be measured in some way that is superior to not measuring it at all.

Gibb's Law does nothing to address the problem that just because you've found a way to measure something, that particular way is superior to not measuring it at all.

Re:Gilb's Law

[Profane MuthaFucka]

Actually it's not quite what you wrote. This is the logic chain that I was thinking of:

1) All measurements have errors (are uncertain) to some degree.
2) Uncertainty can be infinite.
3) Infinite uncertainty is the same as "I don't know"
4) No threshhold of uncertainty has been stated as the dividing line between a good measurement and a bad measurement.
5) Therefore, the statement that "uncertain measurements are bad" is not well enough defined.

The main question that I have, which you may have an answer for is what amount of uncertainty in a measurement provides the threshhold for good or bad measurements?

My position is that by viewing all measurements as a three-part quantity (value, units, error) and never separating them, is a good idea. The last part of your statement above seems to talk about a lack of communication in the team, not about the utility of measurements themselves, which is a different problem.

Re:Gilb's Law

[Coryoth]

found that an easy way to get him heated up was to suggest that something you need to know is "unmeasurable." The man was offended by the very idea.

Better not let him near any pure mathematics then. Mathematciains have determined that there are, in fact non-measurable sets - that is, sets that you can't actually measure. Sure, they're also non-computable and highly pathological, but their existence can be proved.

Jedidiah.

Re:Gilb's Law

[sdcharle]

Better not let him near any pure mathematics then. Mathematciains have determined that there are, in fact non-measurable sets - that is, sets that you can't actually measure. Sure, they're also non-computable and highly pathological, but their existence can be proved.

His rule sounds like he thinks like a pure mathematician, though, stating something exists but not providing any method for actually finding such a method.

Re:Gilb's Law

[T-Ranger]

You have a problem with different fields using "measurable" differently. In non-measurable sets, most non-set theorists would call that non-countable (which may or may not be a different theory. I remember "non-countable' from my discret math days, but never non-measurable. Beh). Many people would say that infinity is sufficent measurement (which is why I perfer countability to measurability).

So far as Gib is concerned, "very big" is a measurement. If you have 3 sets of infinite size, saying that they have sizes of infinity, infinity-1 and infinity-2 (if you get them in the right order) is better then nothing. Such a definition would outrage any math geek. But now you have some metric

Re:Gilb's Law

[Tony-A]

Anything you need to quanitfy can be measured in some way that is superior to not measuring it at all.

Correct, but the problem is in the assumption that the measurement means more than it does.
But this is also a problem with any measurement with any degree of imprecision.
I see these references to programming languages that assume that a language is somehow representative of the level of the stuff written in them.

You measure A. You measure B.
Is A bigger than B?
The numeric values give a precise answer but with a significance related to the error margins around the values.
Say it's about 1000 miles to the sea coast. You go aproximately 999.5 miles in that direction. It is now exactly half a mile to the coast?

Is A bigger than B?
Both have large errors, but if they have the same large errors, then something useful can be said about the difference.

The measurements are useful, just not as useful as one would like.

Re:Gilb's Law

[Tony-A]

measure is the generalization of the length of a set of points.
If A and B are disjoint, measure(A+B) = measure(A) + measure(B).
Unit interval has length (measure) of 1.
Remove any finite (or countable) set of points and you still have meansure 1.
There exists Cantor's Perfect Set which has an uncountable number of points but has measure 0.
He would be talking about sets so nasty that it is impossible to define a measure on them that doesn't lead to logical impossibilities. (For real hairy stuff check out algebraic topology;)

The utility of measure theory is that you can combine discrete statistics and continuous statistics into just statistics.

Re:Gilb's Law

[vhold]

It's only a good or bad measurement depending on what your question is.

If your question is "Just, in general, how big is this thing?", then it's a pretty useful measurement.

If your question is "How complex is this thing?", it's probably a pretty decent shot in the dark.

If your question is "Will it will win the ultimate war of the languages?", then your question is retarded.

Re:Gilb's Law

[T-Ranger]

That you replied with a formal math proof proves my point. We are not talking about formal math. We are talking about what normal people think of when you say "measurable".

Re:Gilb's Law

[Hognoxious]

Statement 1:

there exists _some_ measure with a value greater than that of not measuring.

Statement 2:

every measure, no matter how bizarre, is better than nothing. Glib's Law tells us nothing about the value of lines of code.

There exists a well known device for converting statement 1 into statement 2. It's called a PHB.

If measurement for measurement's sake was always a good thing then I could take an eight bit CRC of the source code or the ratio of "e"s to "i"s and use those as metrics for quality.

You are a PHB!

Re:Huh?

[servognome]

/. response efficiency warning!
To conserve server resources in the future please update your response "Did you even attempt to click the underlined word 'sloccount'? If not, do it now and read the first line of the first paragraph." with the more efficient "RTFA" or "RTFA you stupid noob" if you are not into the whole brevity thing.

Whoa, too much politics lately...

[Bingo Foo]

... I thought it said "C-SPAN."

Although their "Book TV" show is usually as dense as Perl, and often profiles books that are write-only.

Perl coders make $135k/year?

[scovetta]

$677 million, 5,000 person-years = ~$135,000/year/person.

I don't know any perl coders who make $135 a year, let alone $135,000!

(sorry, but it's true)

Re:Perl coders make $135k/year?

[Anonymous Coward]

since its donated time, could i detuct that on my taxs?

(not a perl programmer, but if i could, then i probably would start.)

Re:Perl coders make $135k/year?

[daperdan]

I don't know any perl coders who make $135 a year, let alone $135,000!

Just so you know:
Amazon.com hires Perl programmers at a pretty good rate. Perl continues to be one of the top languages on the net. You statement is pretty rediculous. Check jobs.perl.org if you think people can't make money writing perl. You statement is quite ignorant.

Re:Perl coders make $135k/year?

[NoMoreNicksLeft]

In any company employing that many perl programmers, there is at least 1 manager per 2 programmers. Therefor:

$135,000 per 2 programmers = $270,000 per year

$200,000 per year for manager
$35,000 x 2 per year for 2 programmers
+_______
$270,000

Now, it's also quite obvious from this math, that the manager must bring in far more value than a programmer. Which leads me to this conclusion, a software company that fires all its programmers and hires more managers could only become a stronger company.

Thank you, thank you. No, I do not have my MBA, but I did glean this all from managers at previous employers. Anyone know of job openings for a computer flunky in the Richmond, VA area?

Re:Perl coders make $135k/year?

[shotgunefx]

Not sure which Perl programmers you know... but I've been living off it since 98

Re:Perl coders make $135k/year?

[Waffle Iron]

It may cost the employer $135K, but that's not the programmer's take-home pay. One rule of thumb I've seen is to multiply salary by ~2 to get the employer's total costs including equipment, office costs, taxes, etc. That would imply a salary of around $67K.

Re:Perl coders make $135k/year?

[Minwee]

On average, salary is only half of what a company pays for an employee. If you count benefits, office space, training, administration and all of the other costs involved that $135k works out to more like a $67,000 salary.

A junior programmer working in Manhattan makes about $60,000 a year according to a recent salary survey, going up to $90,000 for a senior guru. Based on those numbers I don't see anything wrong with the $135k/year figure.

Coders may not _make_ $135,000, but they do _cost_ that much to employ.

Re:Perl coders make $135k/year?

[Christianfreak]

Search one of the big job sites for 'Perl' you'll find lots of jobs offering quite a bit of money for the skill. Not $135,000 true but there are several that make $80 - 90k (depending on the market) which would certainly cost the company paying them 120k+ when you factor in benefits, insurance, payroll taxes etc. etc.

Re:Perl coders make $135k/year?

[CPlusPlusOwnsYou]

I don't know any perl coders who make $135 a year, let alone $135,000!

I used to work at scotia bank for my high school co-op program and I was making $1k/month writing perl scripts to make graphs (using gnuplot) from webserver statistics. Was a sweet job for a 17 year old =)

Re:Perl coders make $135k/year?

[Anonymous Coward]

Yeah, but you have to have an income first.

Re:Perl coders make $135k/year?

[kwoff]

I don't know any perl coders who make $135 a year, let alone $135,000!

How many Perl programmers do you know? I'm a Perl coder, and I make significantly more than $135 / year.

Re:Perl coders make $135k/year?

[dwheeler]

Take a peek at the Gigabuck paper, especially section 2.3, which explains how the numbers are derived. It includes salary and all overhead (office space, management, benefits, etc.). Quote: "For programmer salary averages, I used a salary survey from the September 4, 2000 issue of ComputerWorld; their survey claimed that this annual programmer salary averaged $56,286 in the United States. I was unable to find a publicly-backed average value for overhead, also called the ``wrap rate.'' This value is necessary to estimate the costs of office space, equipment, overhead staff, and so on. I talked to two cost analysts, who suggested that 2.4 would be a reasonable overhead (wrap) rate. Some Defense Systems Management College (DSMC) training material gives examples of 2.3 (125.95%+100%) not including general and administrative (G&A) overhead, and 2.81 when including G&A (125% engineering overhead, plus 25% on top of that amount for G&A) [DSMC]. This at least suggests that 2.4 is a plausible estimate. Clearly, these values vary widely by company and region; the information provided in this paper is enough to use different numbers if desired. These are the same values as used in my last report.

Note that these are year 2000 U.S. dollars.

Re:Perl coders make $135k/year?

[SpecBear]

First off: $135K/person/year is cost, which is a lot more than just salary. To get closer to the actual cost, don't think in terms of the cash compensation for a salaried employee, think in terms of the rate charged by a contractor (who must pay for his own training, payroll taxes, health insurance, equipment, etc). Taking that into account, all of the professional Perl coders I've known have cost at least that much.

Granted, I don't know many who code Perl professionally, but those who do make as much as any of the other programmers I know.

Re:Perl coders make $135k/year?

[Prof.Phreak]

Coders may not _make_ $135,000, but they do _cost_ that much to employ.

Wouldn't that mean that coders _make_ more than $135k for the company? (otherwise why would a company employ them in the first place?)

So value wise, Perl coders could be making millions :-)

Re:Perl coders make $135k/year?

[Hognoxious]

Which leads me to this conclusion, a software company that fires all its programmers and hires more managers could only become a stronger company.

It's like when a company fires people, its stock price goes up.
Therefore my company that employs nobody (because it doesn't exist) has infinite market cap.

What is this post about?

[Blakey Rat]

What the hell is this post talking about? CPAN? SLOCOUNT? Red Hate 6.2? I honestly have no clue. Is lines of code measured in dollars or lines? If lines, why is there a dollar amount in the headline? If dollars, why is there a lines count in the article?

Re:What is this post about?

[0x0d0a]

CPAN?

A particular large, public archive of perl code that many people use as a resource.

SLOCOUNT?

It's not an acronym. It's a program to count lines of code and estimate cost to produce said lines.

Red Hate 6.2?

An older version of a full Linux distribution (OS, application software, etc) produced by Red Hat.

If lines, why is there a dollar amount in the headline?

Because sloccount estimates cost of development as well as giving lines, and half a billion dollars in development costs sounds particularly appealing.

Re:What is this post about?

[admdrew]

SLOCOUNT?

It's not an acronym. It's a program to count lines of code and estimate cost to produce said lines.

Check out the homepage for SLOCCount - a set of tools for counting physical Source Lines of Code (SLOC).

Re:What is this post about?

[0x0d0a]

The entire name is not an acronym -- I was pointing out that "SLOCCOUNT" is not the right capitalization to use.

Re:What is this post about?

[admdrew]

Actually, an acronym can be either the first letter of words or parts of words.

acronym @ dictionary.com. The example it gives is radar - radio detecting and ranging

Low position?

[fanatic]

Copying and pasting the linked Sourceforge page into a file, then sortting yelds the following highest project numbers:

Perl 5254 projects
PHP 9010 projects
Java 12210 projects
C 13069 projects
C++ 13255 projects

So perl is behind only 4 others. Given that much Perl project work probably ends up in CPAN instead of sourceforge, this is actually pretty high. Did the poster mean he'd expect higher without CPAN?

Re:Low position?

[AnotherBlackHat]

A lot of the C++ projects are also C projects.

-- less is better.

Re:Low position?

[lawpoop]

Yes, but close to 75% of all those PHP Projects are a DVD/CD cataloging system.

Re:Low position?

[btsdev]

You're completely correct. And beyond that, I think the fact that Perl has even THAT many projects is astounding: how many source-forge-sized applications do you think people would write in Perl? Pretty impressive since I'd venture to guess that 95% of perl programmers only use perl as their versatile glue/scripting/web language of choice (as opposed to their hardcore production language).

sub _{$b-$a;}print((split(//,",rekcah lreP rehtona tsuJ"))[sort _ 0..24])

Re:Low position?

[PMuse]

I suppose that Perl accounts for less than 1/2 as many projects as the leaders, but...

C++ 13255 (18.7%)
C 13069 (18.5%)
Java 12210 (17.2%)
PHP 9010 (12.7%)
Perl 5254 (7.4%)
Python 3249 (4.6%)
All 38 others (20.9%)

Re:Low position?

[scotch]

No, you got that bassackwards: virtually all of the C projects are also C++ projects.

Re:Low position?

[bcrowell]

If you look here, you'll see that desktop software numerically a very large percentage of projects on SourceForge. Perl just isn't a very popular language for writing GUI apps (although I've done it, and there are even some pretty good games written in Perl, such as Frozen Bubbles). To some extent, this is due to people's perception that Perl's main purpose in life is to do CGI. However, there are also some barriers that have kept Perl from being a popular language for programming GUIs. Specifically, the XS system for gluing C and Perl together is a pain in the butt for end users, because when they upgrade Perl, they have to recompile every single CPAN module that uses XS. No, I'm not the only person who thinks this is a problem; XS is scheduled to be terminated with extreme prejudice in Perl 6, and replaced with something that's easier for both programmers and end users.

The GUI toolkit that I used (Perl/Tk) also seems to have some problems with stability; I spend an awful lot of time tracking down problems reported by users because of some problem with the version of Perl/Tk they've got. Dunno if other Perl GUI toolkits are better in this department. Perl/Tk is nice in many ways (excellent documentation, code that uses it is extremely readable), but now that my project is mature, it's really a drag that 100% of the bug reports are things that I can't do anything about, because they're problems in Perl/Tk (or in the Perl/Tk that comes with a specific Linux distro, especially Gentoo).

Re:Low position?

[chromatic]

You only have to recompile XS modules if the new version of Perl has broken binary compatibility. That happens sometimes with major releases (between 5.6.x and 5.8.x), but rarely in minor releases. It's actually a goal that 5.8.x releases all have binary compatibility. If a release breaks that, Nick'll release a new version very quickly if at all possible.

You're right about Perl 6's successor to XS, though. It's NCI and it's fabulous, even now.

Re:Huh?

[XemonerdX]

To conserve server resources in the future... STFU?

All lines are not equal

[fanatic]

One line on perl typically does a lot more than one line of C code (even without absurd "golf" tricks). The same is true of other high level languages. So even leaving out issues of programmer quality, what does this really mean?

Also, from the linked article:

Reasons why these results are meaningless:

• Most importantly, I've told SLOCCount all of CPAN is one project, which is probably inflating the numbers significantly. When I get more time, I may run SLOCCount per-distribution, then sum the totals. However, SLOCCount appears to have bugs handling this many sub-projects, so I will need to run them separately and manually sum the results.
• mini-cpan.pl doesn't actually find only the latest versions of everything, some dists are duplicated and some may be ignored.
• There's probably plenty of generated code not being identified correctly.
• There's probably plenty of code downloadable from CPAN that wasn't written for CPAN, and so probably shouldn't be counted.
• All the usual reasons why code metrics based on numbers of lines of source code are meaningless.

And here's another: CPAN includes perl itself - which is probably a *lot* of lines of C code.

Re:All lines are not equal

[Kristoffer Lunden]

One line on perl typically does a lot more than one line of C code

There was an excellent, brief example of that in an otherwise also excellent comment to the Paul Graham thingy over at Perlmonks here. It was in java, but the point still remains.

Re:All lines are not equal

[ameoba]

One line on perl typically does a lot more than one line of C code (even without absurd "golf" tricks). The same is true of other high level languages. So even leaving out issues of programmer quality, what does this really mean?

Tha standard argument is that, regardless of which language you're using, for a sufficiently large project, the number of lines of code a programmer can produce is relatively constant. Some languages may require less lines to get the same ammount of work done, but the work to produce a KLOC is approximately constant.

I forget the source (Mythical Man Month, maybe?) but there was some study that showed that programmers writing ASM produced the same LOC as those using some early HLL (PL/1?). I've heard it said that this number remains relatively constant as more powerful languages get introduced.

Re:All lines are not equal

[TheEnigma]

Yes but perl cannot be used to write an operating system, last I checked.

The point is to measure *EFFORT*, not code functionality or power or quality or anything else. Read the relevant article(s).

If you want to create a measure of code capability, you are more than welcome to do so! Then we can all criticize your short-sightedness.

Re:All lines are not equal

[Tony-A]

some study that showed that programmers writing ASM produced the same LOC as those using some early HLL (PL/1?).

Makes sense, if you consider what the programmer sees at one time as one page.
You have to get to the right page.
Once on that page, you have to be able to see what is relevant.
Seems like this stuff is measured more consistently and accurately by lines of code than by tokens or by non-whitespace characters.

From going back over my own stuff, I've found that the easiest and most useful commenting device has been blank lines separating dense globs of code. If I don't have to mess with the innards, the fewer lines the better. One aspect of a dense glob of code is that to the programmer it functions as a long name for the glob which has the further advantage of not having to be stored elsewhere.

LOC is a lousy measure, but I suspect that all other measures are worse.
It's probably a better measure of complexity than it "should" be because there will be tendencies to optimize style and content per line to minimize the effort of dealing with it.

Re:All lines are not equal

[Tony-A]

That example is a bit more devious than it appears.

The problem is to print stuff from a file.

Perl (PHP would do the same) will print it or die trying.

Java code will print it (or an error message)
and keep on going regardless

Single entry, Single exit
Whether it works or not.
This is progress?

Re:All lines are not equal

[ameoba]

Exactly. In a sense, it's a very good measure of how much code a programmer can work on in a given period of time, a good indicator of the ammount of work that can be done.

OTOH, it's a poor measure of useful work, or work done right. Something that takes 100 lines of decent C might be doable in 10 lines of Python or 1000 lines of ASM or 500 lines of poorly written C or 50 lines of C that ignores important cases. ...and god forbid we try to use it for estimating projects before they've been started. Thinking of facing somebody that could say "Lets see... I think we can do this project with $BIGFOO KLOC" with a straight face scares me.

Re:All lines are not equal

[Kristoffer Lunden]

It would be easy to 'warn' instead of 'die', or to just silently ignore any errors instead if that is a better approach. Sometimes it is, sometimes it's not. :)

Re:All lines are not equal

[Tony-A]

Sometimes it is, sometimes it's not.

Yes, but it's always a good idea to be able to tell the difference.
UltraDev at least used to have a server behavior (chunk of code) that would check if the user's login was valid. If invalid, the code would send a redirect and then fall through and proceed merrily to produce the html that the user was supposed to be locked out of.

There's a psychological trap in the ON ERROR or try ... catch in the assumption that one can/should actually be able to do something about trapped errors. The problem space is about an order of magnitude more complicated and the required tools simply do not exist (probable exception of LISP) to do a fix-up and a retry or ignore with the proper scope. What annoys me is using medium effort to field a small error that becomes then a big error. With PHP or Perl, if you don't want to die, then don't say die.

Re:All lines are not equal

[Tony-A]

OTOH, it's a poor measure of useful work

Exactly, assuming you mean worth or value as opposed to effort or cost.

There is also the fact that it takes considerable time skill and effort to make something smaller.

I think we can do this project with $BIGFOO KLOC" with a straight face scares me.

What the program does -- asset.
The lines of code it takes to do it in -- liability.

As a measure of what it would cost to do it, maybe reasonable.
There is a trap if KLOC are considered a usable metric of progress. Following the rule of 90% of anything is garbage, it should be possible to spend 90% of the time on the first 10% that matters and get it right, then spend 10% of the time on the remaining 90% garbage. Any trust in a KLOC metric will do the 90% garbage first, making the "remaining" 10% non-garbage essentially undoable. Odds for which view will be takern?

Re:All lines are not equal

[Hognoxious]

From going back over my own stuff, I've found that the easiest and most useful commenting device has been blank lines separating dense globs of code.

If a group of lines has enough of an identity to need a delimiter, it has sufficient importance to merit a comment.

Depends on why you're doing the work for.

[oneiros27]

if you're doing the work for a recognized non-profit organization, then you might want to talk to an accountant, and see if it's worthwhile to do. There are probably implications where you work for non-profit, and it produces code that you can re-use in other for-profit applications.

But I'm not a tax lawyer or an accountant, so if you're really interested in writing off some of your work, it'd be worth looking into.

Nonsense.

[dpbsmith]

Patently, bad measurements are worse than no measurements.

"Measurement drives performance." If you are measuring the wrong thing or using misleading measurements, you will do the wrong thing.

Anyone who thinks they can devise a meaningful measurement the quality of Beethoven's Fifth Symphony versus Brahm's First... or which tastes better, vanilla ice cream or fresh pineapple... or who is a better ballplayer, Willie Mays or Sammy Sosa... needs to have their head measured, preferably with a standardized test.

In order to tell whether measurement in some way is superior to not measuring it at all, you need a way to measure the quality of the measurement. But to do that, you need...

Re:Nonsense.

[Merk]

Read the quote carefully: "Anything you need to quanitfy can be measured in some way that is superior to not measuring it at all."

He's not saying that *any* measurement is better than no measurement. He's saying that there exists a measurement that is better than no measurement.

Which tastes better, ice cream or fresh pineapple? I don't know, but rather than say "It's impossible to say! Any measurement will be flawed." You could do a survey and see what most people think tastes better. That may not be the measurement that is better than no measurement, but for certain purposes it may be.

In the end, it depends on what your reason for doing the measurement is. If you're going to be marketing a new bubble gum flavour, then this survey is better than no information at all.

Re:Nonsense.

[babbage]

You're taking only part of the original quote though:

Anything you need to quanitfy can be measured in some way that is superior to not measuring it at all.

You seem to be ignoring the first part of the statement -- "anything you need to quantify" -- by pointing out that it's meaningless to compare the quantitative difference between symphonies or flavors, but these things are essentially subjective, so there's little merit in "measuring" their differences. There is no need to quantify here.

I mean, obviously Beethoven's symphonies are much better than Brahms', and there can be no question that ice cream is better than pineapple, right? :-)

Obviously, that's a silly assertion, but that's the point: by using subjective examples, you're dealing with things that can't be measured in any way that would be meaningful to more than one person, so there is no need to do so.

+++++

On the other hand, you go from there to athletes, and this one breaks down for a different reason: people quantify the attributes of athletes all the time! The whole point of being an athlete is to engage in physical competition where there are winners and losers, and there's no way to determine that without some kind of clear metrics, from simple & obvious ones like who wins more often to more complex ones like, well, all the books of statistics that baseball fans accumulate.

Therefore, sure, you can get lost in debates about whether Mays or Sosa is the better player, but this is in most ways not a subjective matter, because you have all kinds of statistics available to justify an argument for one or the other being "better". You can argue that which statistics are more or less important is a subjective matter, and that could be the case, but even still this is a realm of carefully compiled numbers, which at least provides an essentially quantitative foundation for the matter.

Arguing that Michael Jordan was a better basketball player than Larry Bird -- on grounds that he won more championships, or he had a better free throw percentage, or whatever (I'm not a sports fan, I don't actually know that Jordan had a better free throw percentage than Bird, but nevermind that) -- is, I think it's very safe to say, better than not attempting to use any kind of measurements, and just saying that Jordan was "a stronger player" or was "more telegenic" or whatever.

+++++

So, while I've never heard of this Glib's Law, it does make sense. The important thing to keep in mind is the implied caveat that most things are worth quantifying, but not all, and if you try to quantify an essentially subjective thing than you're just falling down a rabbit hole. For everything else though, it can provide a useful basis for understanding things -- maybe not a perfect one, but at least some kind of common ground for discussing things.

What's so objectionable about that?

Re:Nonsense.

[starm_]

Okay, but as long as your measurment has some significant corelation with what you are trying to predict, it brings you information and it is usefull. Not to say that there can't be a better measurment but it could be too costly or you just havent discovered it yet.

The reason you can't measure the quality of Beethoven's Fifth is because it is so hard to define the concept of musical quality. You could always rate music according to a definition that you made. Consider something like:"I make a random group of people rate music on a scale of 1 to 10 and I define the quality of music by the score it gets." You could make a group of people rate some music and analyse what parameters, (Amount of harmony, complexity, randomness, tonal range, anything else you can think of..., etc, etc...) are correlated with the ratings. Then you could try to predict weather a piece of music is good by applying your model on it. Probabilisticly, if you have a large enough sample, your model would predict better than a random flip of a coin to rate music. Therefore, your model would be usefull. Your model wouldn't always get it right. That is unless you accounted for all the possible variables that make music good and all the interactions between the variables. But you would still have usefull information.

Re:Nonsense.

[ClosedSource]

"He's not saying that *any* measurement is better than no measurement. He's saying that there exists a measurement that is better than no measurement."

Then he's really making a philosophical statement that probably has little value in a practical sense. Even if it were true, a measurement that you can't identify, is exactly the same as no measurement at all.

So we just have to go back to basics and say that any proposed measurement should be supported by evidence and we should reject those that aren't.

Re:Nonsense.

[dze]

Well, Mays was clearly a lot better baseball player than Sosa. With baseball you can very accurately estimate a player's contribution to scoring runs and thus winning ballgames.

But for symphonies or ice cream, just about the only meaningful measurement of anything is an opinion poll about people's preference. And I do agree with your basic point.

Re:Nonsense.

[Minna Kirai]

With baseball you can very accurately estimate a player's contribution to scoring runs and thus winning ballgames.

Which still doesn't tell you who's a better player, unless they somehow had the same sets of opponents and teammates. (And equipment, and weather conditions, and everything else that matters)

For example, Freeda Foreman has a better winning record than Mike Tyson. Does that make her a better boxer? Imagine what would happen if they fought...

Re:Nonsense.

[Hognoxious]

Which tastes better, ice cream or fresh pineapple? I don't know, but rather than say "It's impossible to say! Any measurement will be flawed." You could do a survey and see what most people think tastes better.

And that would be a survey, not a measurement.

A general (but not infallible, I'm not as arrogant as Gilb or his disciples) rule is: What unit is it in? If it ain't got a unit, it ain't a measurement - it's an opinion.

Re:Nonsense.

[Hognoxious]

needs to have their head measured, preferably with a standardized test.

A Vickers hardness test?

IIRC, this involves whacking them with pyramidal wedges and seeing what size dents it makes.

Re:Nonsense.

[Merk]

The unit is "people". 500 people liked pineapple. 200 people liked ice cream.

Have you ever used a moveable pulley? For every Newton of force you apply (unit: newtons), you get two Newtons of force at the other end (unit: newtons). That gives you a mechanical advantage of 2. No units there... but is that an opinion? Nope, it's mechanical fact.

When measuring an inherently subjective question (which tastes better), an inherently subjective measurement is all you can hope for. Does that mean the measurement is invalid? No. Does it mean the thing being measured is unimportant? No.

Re:Nonsense.

[m1kesm1th]

For example, Freeda Foreman has a better winning record than Mike Tyson. Does that make her a better boxer? Imagine what would happen if they fought...

He might bite off more than her ear.

PERL programs are hard to distribute

[jzilla]

PERL is nice in that it has a lot of prepackaged modules that provide a lot of functionality. But when you distribute code that uses these modules, the end user must install them. This is a big pain in the rear for the average user, which is why I believe that PERL is a bad choice for programs intented for the end user.

Re:PERL programs are hard to distribute

[Dr. Zowie]

This is a pain, and it has certainly hit us in the PDL world. We're only now starting to get appropriate automated packages built.

On the other hand, if all you need is perl modules (no external libraries) then you can use the CPAN module itself to reach out to CPAN, get the perl code, and test it right there on your system. nearly all the time, it just plain works. That is amazing (to me, anyway).

Re:PERL programs are hard to distribute

[Christianfreak]

You know if you took a second to search CPAN, you'd find that your assertion is not at all true

Also its "Perl" as the name of language "perl" as the name of the interpreter. They aren't acronyms, PERL doesn't exist.

Re:PERL programs are hard to distribute

[dpb]

In which case you probably want to check out RPMPan project, which provides the entirity of CPAN packaged in RPMs and all 'apt-get'-able. See their Source Forge page

Re:PERL programs are hard to distribute

[admdrew]

They aren't acronyms, PERL doesn't exist.

If you asked Larry Wall, the father of Perl, that's not true. Perl is said to stand for "Practical Extraction and Reporting Language," something that's pretty descriptive.

Larry has also referred to Perl as "Pathologically Eclectic Rubbish Lister," a little poking fun at himself with regard to Perl's beautiful looking code.

Re:PERL programs are hard to distribute

[Eravnrekaree]

Not quite true. Compared to what? Most complex programs and libraries written in most languages do rely on other libraries to provide additional facilities. Most GUI programs ussually rely on a graphics library of some sort, because it would be a expensive allocation of time and effort to try to build these things directly when it saves time and resources to instread use another library that provides these things rather than reinvent the wheel. This is the whole idea of libraries and re-use, to avoid re-inventing the wheel. If you use your Linux distributions package installer it will ussually automatically install required libraries. This will happen for almost any GUI program, no matter what language. Many common Linux C/C++ programs use dozens of seperate libraries that need to be installed. If the Linux distro is properly designed it should also install Perl modules required for a Perl program to run. Perl programs are no different than programs written in other languages in their use of external libraries. If you are concerned about end-users bieng inconvenienced by downloading modules, then you can provide a distribution of your program that includes all of the modules that it requires. Of course you should consider allowing advanced users to install the modules themselves.

Furthermore, I have found that manually installing Perl modules is ussually always a very simple and easy process, just as easy or eisier as installing a C library. It is made especially eisier because we have CPAN where you can easily find Perl modules you need from one central location, and it saves you time, you spend less time looking for a library.

Re:PERL programs are hard to distribute

[ajs]

when you distribute code that uses these modules, the end user must install them

When you distribute code that requires Gnome, the user must install Gnome.

When you distribute code that requires glibc2.2 the user must install glibc2.2.

When you distribute code... is this getting through?

If your program is distributed to Linux systems, you can easily build an apt tree that includes the modules on which you depend as RPMs (or DPKGs for Debian) and then the user just adds you to their sources.list. Alternatively, you could submit your program to CPAN with apprpropriate dependency info, and the user will automatically install the dependencies.

None of this is hard, in fact this is WHY CPAN is so popular.

Re:PERL programs are hard to distribute

[metamatic]

In addition to the already posted reasons why you're wrong, there's nothing to stop you from including the necessary libraries with your Perl software in some lib directory, and making your software adjust the @INC variable to look there first.

Re:PERL programs are hard to distribute

[chromatic]

I know Larry. It's Perl. See perlfaq1.

Re:PERL programs are hard to distribute

[Chokma]

It depends.

For Linux users, installing Perl modules is no more difficult than installing other software from source.

But for Windows users, it can be a royal pain in the ass. The problem stems from the fact that you simply cannot use CPAN modules which require make or a C-compiler. Many interesting modules need either or both.
Of course, the user can install make, and he may even get to installing cygwin or visual C. But if you want to distribute a Perl program to the unwashed masses of Outlook Express users, who get strange pimples on their butt just from looking at source code, this is clearly not the way to go.

Well, I hear some say, "Does he not know about the glorious PPM distributed by Activestate which allows you to install the binary version of many modules?" Indeed, I have used PPM and it will work , but not always. Often, the modules you need are not in the repository or they are far too old or not available for the version of Perl the user has (example: WWW::Mechanize @ activestate.com was about 0.48 while the CPAN version was 0.72).

I am the author of three Perl programs on Sourceforge and the one package which gets the most downloads is the compiled exe for Windows. Sadly, it is also really hard to make those perlish .exe-versions. And yes, I know about PAR and perlbin - but the main problem is: you cannot distribute the perl58.dll by Activestate with your programs as they own the copyright to it. (Perl is free via the Artistic License, but this license also allows some not so nice things). Of course, I could buy the Activestate Perl compiler for $150 or something...

My solution to the distribution problem is: make sure that you have easy to understand instructions for downloading and installing Perl and package those modules you can with the main archive of your code. Mostly, those modules are GPL or PA-licensed and thus it is no problem to include them in free software.
Special cases like the modules needed for https/SSL and WWW::Mechanize are covered by an install script.
Sadly, some users are not even capable of clicking on "download" on the Activestate-Site...

Re:PERL programs are hard to distribute

[admdrew]

I know Larry. It's Perl. See perlfaq1.

First off, I never said it was 'PERL' ;) I think a grandparent did that.
Second, I took your advice and checked perlfaq1.

All from perldoc.com:

Regarding PERL (this link is perlfaq1, btw) - But never write "PERL", because perl is not an acronym, apocryphal folklore and post-facto expansions notwithstanding.

Regarding "Practical Extraction and Report Language" - The title given to perl in this page. Also, check the rest of the perldoc.com site

Regarding "Pathologically Eclectic Rubbish Lister" - Perl actually stands for Pathologically Eclectic Rubbish Lister, but don't tell anyone I said that.

Taking into account the man's humor and wit, it's safe to call it whatever you want, as long as you don't take anything too seriously :)

Re:PERL programs are hard to distribute

[Lil'wombat]

If you need to distribute Perl Applications, check out Perl PAR. It comes with a tool called PP (PAR Packager) that allows you to combine your script and all dependent modules into a standalone exectable for any platform.

Re:PERL programs are hard to distribute

[qa'lth]

Or, since Perl is OpenSource, you could do what I did, and set up the toolchain on Win32.

The full toolchain.

I now have my own, custom perl5.8 with full backend compiler, and my own perl58.dll file. Distribution is much nicer, now.

All it needed was a small patch to the Makefile for mingw32, a copy of dmake, and it builds wonderfully.

I didn't even need a cygwin environment. Mingw32, dmake, and the perl sources were enough to get it built and runnable.

This is, of course, on winXP.

No need to pay ActiveState extortion when you can just build it yourself.

Re:Huh?

[sdcharle]

A lot of projects on SourceForge are like bands conceived by teenagers that never get past the 'designing the first album cover' stage.

SourceForge is a great tool with meaningful projects there, but you kind of have to take the info you get from looking at overall numbers there with a grain of salt.

Relatively low position?

[shmigget]

Nearly twice as many projects as Python, almost three times as many as VB, and more than a third as many as C or C++ is low? For a scripting language? I think these numbers prove the versatility and popularity of Perl.

Re:Relatively low position?

[huckda]

twice as many projects as Python...and it's how much older?

and C/C++ really aren't scripting languages..VB outright sucks...

versatility maybe... popularity..not a chance...

not a good measurement

[mqx]

This type of measurement is simplistic and poor: it fails to take into account the functional density of the languages. For example, in one line of perl, you can do what takes ten lines of C/C++ -- especially considering that this is one of perl's raison d'tre.

The measurements really should be multi-dimensional:

- lines of code
- number of projects
- number of files
- number of modules (classes, namespaces, etc)
- statement density (e.g. per-language primitives: while, for, @, ->, ... etc);

Re:not a good measurement

[chanceH]

I also nominate:

size of output of gzip -9

Ohhhhhh CPAN

[aarku]

I read the whole thing including the comments as CSPAN and was like wtf?

Random perl comments

[14erCleaner]

a) I thought there was only one line of Perl that did everything.

b) Maybe the sloc counter didn't recognize Perl comments, so it overcounted lines. Wait, Perl programs never have comments.

c) Does this make it "a Perl of great price"?

Remember

[ajs318]

I think one of the reasons why many of the things people do in Perl don't end up becoming SourceForge projects is because they're specific to a particular environment -- my company does pretty much everything {that others might do on Windows desktops} using in-house-written Perl scripts accessed through a web browser; but they really aren't general-purpose enough to warrant releasing to the world at large. For instance, we need to store the Ordnance Survey grid references of our customers -- but not everyone will need that functionality. Perl itself provides a kind of "generality-of-purpose abstraction layer"; there's not much sense in writing a program that can handle fifty squillion different data formats if you're only ever going to use one, especially given that processor power and disk space are so cheap nowadays. I also use Perl for jobs that could be done using bash or awk or sed, but Perl is just so handy; and if I need to add one more fearure, I know I can. I'll also use perl -e 'print "something\n"' in an Xterm as a calculator {one day I'll even define a key map that puts the sequence on a function key}.

Alternatively, Perl -- thanks to all those wonderful library bindings -- might well be used for an initial "feasibility study", say to develop and test the most important function(s) that will end up forming the core of a project; and, once the proof-of-concept is there, the whole thing is then rewritten "from the ground up" in something like C or C++ {which has bindings for the dead same libraries anyway, but feels more "proper" because it's compiled rather than interpreted}.

Re:Remember

[sql*kitten]

the proof-of-concept is there, the whole thing is then rewritten "from the ground up" in something like C or C++

Ha ha, that never happens. Show someone a semi-working prototype and they'll think it's 90% done and want a ship date from you there and then, preferably some time in the next week, just long enough to tweak the interface. Never write a prototype you wouldn't be willing to support in production!

Re:Remember

[dozer]

That whole perl -e 'print "something\n"' is a drag to remember. Call this command 'pell' (for Perl Tell or Perl Shell) and put it in your path (no idea why Slashdot is destorying the indenting).

#!/usr/bin/perl

if(@ARGV) {
print eval join(' ', @ARGV), "\n";
} else {
for(;;) {
print "> ";
print eval <>, "\n";
}
}

It evaluates and prints its arguments (pell 1+2 is the same as perl -e 'print 1+2, "\n"'). Or, if you don't supply any arguments, it drops you into an interactive shell. Use "exit" to exit of course.

For fun, add Term::Readline capability. :)

Re:Remember

[ajs318]

That is cool ..... now I will have to tweak it so as to stop when I hit ctrl-D. Or maybe just open a special xterm just for pell.

Re:Remember

[ajs318]

I was thinking to write the prototype in Perl, but not show it to anybody else until / unless it's working well enough to use.

But you are right ..... last place I worked, some people actually wrote Windows programs by developing the UI before the algorithms! I've always preferred to start nearest the hardware and work towards the user ..... users are so much more flexible, and can be persuaded to put up with all kinds of things.

Re:Nevermind, I goofed, hit "IT" right above "Linu

[illuvata]

don't worry, you still get modded up

I did not understand:

[leuk_he]

I've told SLOCCount all of CPAN is one project,
isn't the sum equal to all parts? I know it is more difficult to do big projects. (all those middle-managers)
generated code
Is code, generated more efficiently.
code downloadable from CPAN that wasn't written for CPAN,
there is probably code in red had that was never written for red had. That is the trouble with open source.
numbers of lines of source code are meaningless.
No no, they give you serious bragging rights!

So things are not that bad. Just the duplicates....
So things aren't quite bad. Just the duplicates....

Re:Subject rejected - looks too much like ASCII ar

[AJWM]

a programmer I met years ago said it was the only language where the source code reminded him of line noise [emphasis added]

He'd obviously never seen APL -- one the few languages terser and more cryptic than Perl, and (AFAIK) the only one to require its own font.

ActionScript?

[Doc Ruby]

Sure, Slashdotters hate Flash, but why aren't there any ActionScript projects on SourceForge, while there are 1822 JavaScript projects?

Re:ActionScript?

[pepeperes]

maybe flash coders are more like 'artists' and they like to work alone???

Re:ActionScript?

[Doc Ruby]

Most Flash movies are produced by graphic artists, with minimal programming (scripting), just like "HTML programming" in the 1990s. But there are AS scripts and tutorials out there on the Web, some with sophistication. But I haven't found any online AS repository like SourceForge or CPAN. Yet SourceForge has Euclid and Simula sections, each with a single project. There's a chicken/egg paradox which keeps repositories and code bases mutually rudimentary. But all it would take would be adding a few dozen useful ActionScript projects to SourceForge to jumpstart the community. Unless there's another inhibiting factor.

Re:ActionScript?

[teflaime]

Maybe noone has offered the idea of creating an ActionScript repository? Or there is some sort of proprietary mind set amongs Flash coders?

Don't know, but I think an ActionScript repo would get mroe action than a Euclid repo...

Duplicate purpose modules and waste everywhere

[Offwhite98]

In my experience with CPAN I have found it follows the Larry Wall concept that there are many ways to do the same thing. For starters, there are several modules which can communicate with a POP3 server. There are many XML parsers and many means of talking to a MySQL database. Unfortunately I would not say each solution is feature complete or even good quality. It is great that it has built-in Pod Doc, but the fact remains is that it can be quite difficult to get some things done.

I was able to whip together a webmail client which fetches mail from a POP3 server and parse the MIME types to display content with several Perl modules which was a pretty amazing feat with the little amount of code which I wrote. But as I wrote it I had to come up with many workarounds for incomplete features in the CPAN modules. I also found that some modules were object oriented and some were not.

So in the end I am finding things like the Java Foundation Classes or the .NET 1.1 profile implemented by Mono to be much more appealing. While there may be fewer means of connecting to a POP3 server, there is a good chance the one that is there will work well enough.

But I am still curious how the Ruby folks are doing. They have been committed to object-oriented programming and may be able produce higher quality solitions. Anyone doing Ruby here?

Re:Duplicate purpose modules and waste everywhere

[swimmar132]

Yes, Ruby is good. Learn it. Everything is an object.

Re:Duplicate purpose modules and waste everywhere

[scotch]

Is ruby an object?

Re:Duplicate purpose modules and waste everywhere

[Eravnrekaree]

I have used CPAN extensively. I have found it to be a valuable and comprehensive resource. I see having a choice between modules as a benefit. Whats wrong with having a choice? I really dont understand why some seem so opposed to choice and seem intent on forcing everyone to do things one way, thier way, rather than allowing people to have a choice between several different methods and alternatives, even though I have found that when I have a choice between different methods or features, I actually spend less time implementing what I want to do since I am able to choose the feature that best fits my needs, rather than having to cope with features that are awkward and clumsy for what I need to use it for, and ussually it just takes a minute or two of reading the handy documentation to see if a module or feature does what I need it to do. You can ussually see in a few minutes whether or not a module will suite your needs by simply looking at the documentation that comes with the module. Ussually it is sufficient. I simply havent seen the problems that you have described, especially not to a greater extent than other languages.

Most of the Perl modules I have been carefully tested and a lot of work was put into them. There are some that could use more functionality. However, its important that people contribute their modules, even if they do not contain every last feature, since, believe me, it ussually much eisier to extend an existing module than trying to write one from scratch. I have extended and enhanced many modules myself, and I have found the Perl language to be just as readable and maintainable than other languages, despite what some have said. In fact, I have saved a lot of time by simply expanding on someone elses module rather than having to write one from the ground up. So i do think CPAN is doing the right thing by not restricting chioce and letting people decide what features best suite their needs rather than forcing people to use a restricted set of features or into a single methodology that some people prefer but not others.

Furthermore, the Perl OO system is more than adequate, and I have found that creating and using modules is as easy and simple, and straightforward on Perl as it is on other languages, yet it gives you an incredible amount of flexibility and power, which I have found only makes the maintainanence and production of perl code eisier, since I am not forced to use a highly restricted set of features for what I need to do, some of which may be awkward for a particular purpose. Perl doesnt force OO on you either, obviously in many short simple programs OO is likely to be overkill. Its main advantages come when you are using modules and you want to keep namespaces seperate. I have found that for instance, having to use OO for something as simple as a print to STDOUT to be highly unnatural and require more typing and verbosity than necessary. Perl allows you to reserve the OO features for when they do provide a benefit, ussually in a larger program or a more complex constructs. Perl doesnt force this on you, although you could have that way if you wanted I am sure.

Re:Duplicate purpose modules and waste everywhere

[Eravnrekaree]

I should further emphasize that I find Perl perfect for my own needs, tastes, and it is eisiest for me to understand and use. However, I think people should choose which language suits them best. Perl might be perfect for me but for others Ruby might be preferred. If I wanted a language that did things like Ruby, i'd use Ruby. Its a good things that every language isnt the same and that each one does things differently, this provides you choice in what kind of language to use. If every language were the same, you wouldnt have much choice. I emphasise, Perl should be Perl and Ruby should be Ruby, Perl shouldnt try to be Ruby or vice versa, and people should choose which one based on their needs and preference. This is why I dont think its very good to expect every language to work in the same way.

Feel free to use Ruby, I dont complain about or insult other languages because they are different, in fact I like the fact there are other languages that do things differently, its different from Perl and people have different needs, and in fact I am sure its a pretty good language. I just prefer Perl as it fits me best. I have found Perl to be highly functional for me.

Peace,

Eravnrekaree

Re:Duplicate purpose modules and waste everywhere

[xteddy]

Of course:

Ruby = Class.new
# => Ruby
ruby = Ruby.new
# => #
ruby.is_a? Object
# => true

One of those rare moments when Peopleware is wrong

[alispguru]

Anything you need to quanitfy can be measured in some way that is superior to not measuring it at all.

But, how do you know that the way you're measuring it is better than not measuring at all? There are lots of ways to measure things that are worse than no measurement at all, because they reward the wrong activity.

The canonical examples here are paying programmers per bug fixed, or paying testers per bug detected. Either one of these alone is bad - together they allow programmers and testers to print money for themselves.

In theory, nothing is unmeasurable. In practice, some things are so hard to measure that you might as well not even try.

Could this simply mean...

[djeaux]

... that a lot more folks write Perl?

Could it mean that folks who write Perl are more likely to submit their work to CPAN?

How does the "instant gratification" of using an interpreted language factor into all this? I know one of the attractions of Perl for me is that I don't have to compile it to see if it works. I just run it.

Re:Could this simply mean...

[belg4mit]

a) Not everyone submits to CPAN. I daresay a small portion of the user population does, it's rather intimidating. And often what you want is already available.

b) Perl is demi-compiled, not interepreted. Tcl
is interpreted. Perhaps you should familiarize yourself with perl -c

Re:Could this simply mean...

[djeaux]

b) Perl is demi-compiled, not interepreted. Tcl is interpreted. Perhaps you should familiarize yourself with perl -c Thanks for this clarification. My IT director always derides Perl as "interpreted" & I've always taken that as truth. I'm off to familiarize myself with -c.

(I'm not a programmer, I'm a guy who uses programming languages for specific jobs. Or does that make me a demi-programmer <GRIN>

Again, thanks for putting a new wrinkle in my cerebrum!

Win32 Too

[Prien715]

I don't understand either. I all my Perl programming for Windows.

If anyone's interested, I've developed a hardware/software audit script entirely in Perl for Win32 (binaries included) that stores data in a centralized MySQL server. Vist here.

Is that the cleanup cost ?

[Alan Cox]

After the first detailed analysis of the large perl leak onto the net experts reckon CPAN could cost $677M to clean up 8)

If its the cost of writing the code then it should be a good approximation of the cost of writing it when perl 6 comes out

Re:Perl still sucks? Really!?

[fprog]

Clean syntax...
You can write some pretty clean syntax in perl just:

#!/usr/local/bin/perl -Tw

use warning;
use strict;
use diagnostics;
use vars qw{ ... };

main();
exit;

# Your perl code.

1;

portable libraries?!
What the heck are you smoking dude? I want some!
It works on more platforms than any other language,
including C because it wraps libc platform weirdness into "you don't have to know or care" equivalent.
Think about EBCDIC, incomplete , endianess, file systems
that don't have all unixes attributes.

A decent GUI library?
There's a Perl/Tk. okay it sux.
There's a wrapper for GTK and Windows API.
okay it sux too.

There's an HTML API, where you can write
your entire program in HTML/JavaScript/Perl,
and just install some Apache, with mod_xmlrpc
and mod_perl thing that runs whatever you want locally on the machine. --> "good portable compromise".

You could also use something like C++ Builder
an embed your perl program within your C/C++ application.

perllinux.sourceforge.net

[GodWasAnAlien]

http://perllinux.sourceforge.net

Re:perllinux.sourceforge.net

[FuzzyBad-Mofo]

Now that is scary..

WTF?

[Dr. Zowie]

Ever looked at CPAN?

Re:Subject rejected - looks too much like ASCII ar

[paster]

Look at this: XHTML parser using K programming language
Perl is really clean language :)

If the "Ruling Class" is made up of morons...

[WebCowboy]

...then how'd they become the Ruling Class? You know, not every rich person is a slutty blonde bimbo heiress like Paris Hilton (someone who I'm sure would struggle to make up the bed in just one room of one of daddy's hotels). A good deal of the wealthy class is self made (particularly in North America)--perhaps your view is coloured by the more class-oriented system of the UK, where there is a fair bit more wealth through inheritance.

Jobs and Woznaik founded Apple and Jobs still runs it (hell of a lot bigger than a mere electronics store chain). I'm sure both of them would be more than capable of wiring up a 13A plug seeing as they were capable of designing, building and programming a computer (and devices allowing them to call Europe for free). And while Bill Gates came from a fairly affluent family, he was hardly a billionaire and managed to survive the early Micro-soft days in dumpy New Mexico digs and do low-level assembly programming.

And yes, I'm sure many of the owners of GM and Ford know how to change a tyre--seing as they are publicly held companies with a large number of shareholders. I'm willing to bet that the executives.management could do it (Lee Iacocca comes agross as a guy who is down-to-earth enough that he could.

My sister is the Canadian president of a multi-national corporation and not only can she peel a potato, she peeled many of them making dinner for her two kids every night as a stay-at-home mother when she was in her early twenties.

Fact is, it is no longer the 19th century, democracy is widespread and the "ruling class" is no longer so dominated by inheritance like it once was. This Marxist theory of the proletariat rising up en-masse against a ruling class dependent on workers output just doesn't wash. Today, those of the working class with the capacity and drive to step up are able to rise one-by-one. And once you are part of the "ruling class" it is human nature to defend it regardless of others actions--particularly when your wealth is earned.

Re:If the "Ruling Class" is made up of morons...

[trentblase]

Today, those of the working class with the capacity and drive to step up are able to rise one-by-one

I agree that moving through the class boundary is much easier now than ever before, but the offspring of the wealthy will always start much higher on the class ladder than the poor. Meanwhile, it's easier for them to kick faster climbers beneath them in the head.

Re:If the "Ruling Class" is made up of morons...

[Hognoxious]

perhaps your view is coloured by the more class-oriented system of the UK, where there is a fair bit more wealth through inheritance

You should learn something about the UK taxation system. On second thoughts, just learning something would be a start.

units

[pepeperes]

I'd daresay that Gilb's law's meaning is nearer to something more like "anything that can be quantified"... I mean, there are no units in which you can quantify the symphonies' quality or other subjective affairs. But if the thing you wanted to measure in the beginning, is measurable in certain units, then surely any approximation is better than no idea at all...

Re:units

[Minna Kirai]

I mean, there are no units in which you can quantify the symphonies' quality

Total ticket sales.
Ratio of first-time to repeat audience.
Days of theatrical run.
Public opinion surveys.
Number of "stars" from newspaper reviewers.

Re:units

[pepeperes]

All those variables are subjective, and as such susceptible to change from, say, one century to the next. So they are not fixed measuring units!

Yes, but...

[JohnA]

...how much of that is devoted to MP3 taggers and MVC frameworks... :-)

Tests ?

[data64]

I wonder what percentage of 15.4 million lines of code are tests. CPAN emphasizes on tests in every module submitted.
In some cases the size of the test scripts is larger than the core code of the module.

Re:OK

[Molt]

Umm.. Perl has a vast repository of reusable code to avoid reinventing the wheel. It's called CPAN.

Other studies: Red Hat LInux 7.1, Debian 2.2

[dwheeler]

If you find this interesting, you might also want to take a look at my updated paper More than a Gigabuck: Estimating GNU/Linux's Size, which examines Red Hat Linux 7.1. The "Gigabuck" paper shows that:

1. It would cost over $1 billion (a Gigabuck) to develop this Linux distribution by conventional proprietary means in the U.S. (in year 2000 U.S. dollars).
2. It includes over 30 million physical source lines of code (SLOC).
3. It would have required about 8,000 person-years of development time, as determined using the widely-used basic COCOMO model.
4. Red Hat Linux 7.1 represents over a 60% increase in size, effort, and traditional development costs over Red Hat Linux 6.2 (which was released about one year earlier).

Another related paper (that I didn't write) is Counting Potatoes: The size of Debian 2.2. They found that Debian 2.2 includes more than 55 million physical SLOC, and would have cost nearly $1.9 billion USD using over 14,000 person-years to develop using traditional proprietary techniques.

So what's the purpose of all these studies? Insight. There are all sorts of limitations in any measure, including any source lines of code (SLOC) measure. But, in spite of those limitations, there are things you can learn. Using tools (like SLOC counting tools) to measure software can help you understand things about the software, as long as you understand the limitations of the measure.

In particular, many studies have shown that SLOC is very strongly related to effort (so much so that you can even use equations to predict it). If you want to determine effort in CPAN, you can't just go ask people; few open source software / Free Software (OSS/FS) developers record exactly how much effort they invested. So, these kinds of measures are really helpful for estimating how much effort went into developing the software. Obviously, not all effort is equal (a genius can turn a hard problem into an easy one). And not all code is good, or even useful. But if you want to understand and measure effort, then these measures do have a value. In particular, these results have shown that OSS/FS can scale up to large projects requiring large amounts of effort.

Re:Other studies: Red Hat LInux 7.1, Debian 2.2

[dwheeler]

You did design the system, write the documentation, wrote and ran the tests, and debugged it, right? The estimates take the number of lines of code, and use it to estimate the entire estimation time. Actually writing the code is often a small fraction of the total development time.... but the SLOC is a handy way to estimate the rest of it.

Re:Perl still sucks

[Eravnrekaree]

I use Perl every day and it has been one of the eisiest to learn and use language that I have found. The syntax to me, seems pretty clear, concise and easy to read, for instance, for a GUI example:
use Tk;
$win=MainWindow->new;
$label=$win->Label(tex t=>'Hello World');
$label->pack;

. The syntax actually is very clean and rather simple and easy to use. In my extensive use of Perl I have found the syntax to be very clean, clear, and easy to understand. I think Perl does things a little differently than other languages, and immediately when people see something that is different to them, it seems many think that there is something wrong with it. If you look at another language for the first time it might seem unusual and strange to you. I have looked at PHP, Python, C++ and Java, those languages seem difficult and strange to me when I first look at them, but thats probably because I hadn't used them enough. It shouldn't be wrong to be different. Perl does things differently but that doesnt make it bad or worse than other languages.

As far as OO goes, Perls OOs is not "bolted on". It is elegantly, carefully designed and integrated with the language. The process of creating and using a Perl module is simple and straightforward, I have done it many times, and just as easy as other programming languages. For example: use Module; $module=Module->new; $module->method(); seems pretty simple and clear to me, in fact, more elegant than some other OO languages that I have seen, in my opinion. I have used C++ and Java, and actually do prefer the design of Perls OO over other languages, it actually takes me less time to use it and code for it than it does on other languages, but thats my personal preference. I have found that with Perl OO and Perl syntax in general it is easy to write clear, good, concise code in less space than many other languages. Perl, to me anyway, requires less language verbage than say C++ or Java does, but is clear and concise.

People have different needs and tastes, and if people should use the programming tools that best suites them. Perl best suites my needs and works in a way that is natural and easy to me. It took me less time to learn Perl than it has other languages.

As far as the GUI libraries, Perl has interfaces to a wide range of GUI libraries, from GTK, QT, OpenGL, Tk, FLTK, etc. Take your pick. Tk is most often distributed with Perl, including with ActiveState Perl on Windows. I have used TK on many occassions and found it to have a very elegant and well designed, yet powerful API.

Perl modules to me seem to be very portable, I have used ones on many different OSs and programs, with no problem. There is nothing inherit in the module system that makes it unportable.

I really havent seen any of the issues that you have mentioned in my extensive use of the Perl programming language.

For effort, it works well

[dwheeler]

Actually, your argument suggests it's a reasonable measure. Yes, one line of Perl can do more than a typical line in C. So, a program in Perl should take fewer lines, and thus less effort, than if you'd done it in C. By measuring the SLOC of the Perl code, you can then estimate effort to create that Perl code, which would have been less in Perl than if it were done in C.

If your argument is, "this measure doesn't measure how many lines of code it would have taken in C", or "how much effort would it have taken if it was written in C", well, that's true. So what? That wasn't what was being measured. If that's what you wanted, there are well-known conversion factors where you can estimate the SLOC in C, and convert it to effort. But those conversion factors are estimates with a LOT of slop, and the published conversion factors have almost no published data to justify them, nor do they identify the ranges and standard deviations and other caveats. But if that's what you wanted, I'm not sure if there's a better way to do it.

Comments

[dwheeler]

SLOCCount measures "physical SLOC", and thus ignores blank lines and comment-only lines (including Perl PODs). It's not the same as "wc -l". Go read its documentation if you want to understand exactly what it does; it has a lengthy description of exactly what it measures, and why, along with references to the (substantial) research literature behind such tools.

Re:Subject rejected - looks too much like ASCII ar

[Anonymous Coward]

TECO (what the original emacs was written in) is even worse. Consdier this TECO program Program to calculate pi. There are explaations of the program out there on the net.

In article < BZS.95Apr13040535@world.std.com> bzs@world.std.com (Barry Shein) writes:

>Then again at MIT a lot of the office people were using TECO, gimmee a
>break, it was indistinguishable from line noise (hey, I loved TECO, ...

+0UN QN"E 20UN ' BUH BUV HK
QN< J BUQ QN*10/3UI
QI< \+2*10+(QQ*QI)UA B L K QI*2-1UJ QA/QJUQ
QA-(QQ*QJ)-2\ 10@I// -1%I >
QQ/10UT QH+QT+48UW QW-58"E 48UW %V ' QV"N QV^T ' QWUV QQ-(QT*10)UH >
QV^T @^A/
/

The above program will calculate an arbitrary number of digits of PI. For TOPS-10 TEC124, the command was "39eiPI.TEC$$" to get 39 digits of PI.

Re:PHP

[nysus]

That's far too simplistic a statement. It depends on your task. If all you want to do is serve up web pages, what PHP was primarily created for, then yes, PHP is easier to work with. But if you want to sequence DNA, Perl is the tool for the job. With Perl, you can get a lot more done with far fewer lines of code to tackle hard-core programming problems.

Re:OK

[ajs]

industry standard languages

Ok, that was your problem, right there. The languages you refer to may be widely used in YOUR industry, and thus have libraries that you need in that industry, but I assure you that in MY industry, Perl (given CPAN) is far-and-away the best tool for most jobs BECAUSE of its ubiquity and support libraries for just about anything you would ever want to do.

That doesn't say your language is useless, but clearly you're only looking at a small slice of the world.

give us a real unit of measure

[_UnderTow_]

"At 15.4 million lines of code,"

But how many libraries of congress is CPAN?

Bowery's Razor

[Baldrson]

Code should not be multiplied beyond necessity.

-- Bowery's Razor; a corollary (applicable to programmers and other state crafters) of Okham's Razor.

Re:OK

[Kiryat Malachi]

See, I would argue that the industry standard languages are (in order) C, C++, VB, and LabWindows/LabView/MATlab/other very high level language, because of my slice.

Its likely that your slice (the Perl-using slice) is also a very small slice. Based on a fairly wide-ranging look, I'd guess that C and C++ are the most widely used.

Re:Subject rejected - looks too much like ASCII ar

[AJWM]

Well, kind of. Technically, TECO wasn't a programming language but a text editor (and corrector). Emacs wasn't so much a program written in it but a collection of editing macros for it.

I'll agree, though, that it looks like line noise.

Re:OK

[ajs]

Yes and no... it depends on what level of development you're talking about. C and C++ are used throughout (I'm guessing) both of our environments, but your avergage in-house coder for operations or end-user apps is probably not going to be writing in those languages. In high-tech firms that are bringing new solutions to the business world (e.g. software spin-offs from accademia, scientists writing code to support their work, Linux and/or Unix admins trying to get work done) you're going to see a lot of the sorts of high-level languages that are available in that world.

In the insurance companies and other non-technical companies that have a lot of technology dependencies, you're probably going to see much more of the proprietary systems (like VB) in use because they feel more comfortable with something that comes with a salesman (I'm not saying that in a negative way, it's just my experience).

You totally missed my point.

[WebCowboy]

I explicitly stated that as time goes on inheritance of wealth becomes less important to determining success.

My sister was borne to a father who worked shift work running the boilers in a meat processing facility at the time. He was not, isn't and probably won't ever be (as he is now retired) president or chairman of a multinational company. My sister worked her way up from selling door-to-door to suppliment a fairly modest household income to where she is now twenty years later. She is not related in any way to the founder of the company, and daddy had nothing to do with her current position except to raise his kids well.

While it's sure a hell of a lot easier to be born into a position of wealth, there is NOTHING in the free world today that prevents a "commoner" from improving his lot in life except his or her own sense of limitation.

Re:You totally missed my point.

[michael_cain]

While it's sure a hell of a lot easier to be born into a position of wealth, there is NOTHING in the free world today that prevents a "commoner" from improving his lot in life except his or her own sense of limitation.

Bless everyone who does better than their parents in life, but from a statistical perspective, it turns out that parents' status is a pretty good indicator of where the children will end up. Economists estimate that about 80% of the variation in personal wealth in the US can be explained by the parents' wealth. Note that it is not appropriate to apply the numbers to individuals -- while 80 out of 100 children born to poor parents may end up poor, there's little way of predicting WHICH 80 that will be.

There are many reasons why such class "persistence" might occur. Maybe there's various forms of institutionalized discrimination going on -- it's easier to get into Harvard if your dad went there, and at Harvard it's easier to meet people who can advance your career later in life, etc. Maybe it's all about ambition and drive that derive in some fashion from genetics -- if your parents and grandparents were ambitious (and hence successful), you're more likely to inherit the gene and be ambitious as well. But certainly some of it is situational -- an ambitious and talented black male born to inner city poverty is MUCH more likely to die by gunshot as a teenager than is a lazy dumb white guy born to rich parents, and being gunned down as a teenager really limits your long-term prospects.

Re:6.2?

[msh104]

And why not, the only thing the end user uses his desktop for is pressing the icons for the apps he wants to use, just openoffice, mozilla, a mail client and 99% of the users are happy

Re:OK

[Kiryat Malachi]

I do embedded. Most embedded code is C and C++. I've never seen Java or C# or Perl or any of those (Perl for pretty obvious reasons - you need a substantial base underneath it). In fact, embedded is pretty much a death knell for anything interpreted, and for very HLL.

We use VB and LabWindows to write interfaces to talk to our embedded boards, and MATLab to do data analysis.

Remember that there's a *lot* of programming that has nothing to do with PCs.

Re:Huh?

[RodRandom]

Yes. Anyway, the number of development projects using a language is not necessarily the measure of its usefulness or the extent to which it is used. JavaScript is everywhere in HTML but has few whole projects compared with other "languages."

The number of utility scripts and small applications in Perl must be astronomical (many of these of course are available on CPAN and don't need to be developed).

ISO 8601 == YYYY-MM-DD

[scragz]

While well written, the author of the linked page completely failed to mention the /real/ date standard, ISO 8601. It is the most logical (descending order) and least confusing.

Re:ISO 8601 == YYYY-MM-DD

[wkitchen]

It's good. But only for a while. They really nead to add at least one more "Y" to avoid the Y10K bug. If you think finding programmers to fix 40 year old code was a problem, just imagine trying to find someone to fix 8000 year old code.

FIRST POST!!!!

[Hognoxious]

gulping down caviar paid for by OS zealots hard work?

Firrt one with a missing apostrophe where there should have been on, surely?

small_talk

[H09N0X10U5]

There's a second 's' missing, somewhere...

Re:PHP

[H09N0X10U5]

If all you want to do is serve up web pages, what PHP was primarily created for, then yes, PHP is easier to work with. But if you want to sequence DNA, Perl is the tool for the job.

Ah right. That's what it was intended for. I did wonder.

Hognoxious' Law

[Hognoxious]

Anything you need to quanitfy can be measured in some way that is superior to not measuring it at all.

Anything you (think you) can quantify can be manipulated by people 'gaming the game' to the detriment of something that really matters.