the language is so fantastically huge, no two programmers even appear to be writing in the same language

He's absolutely right that divergence in programming dialect between programmers is one of the biggest problems in maintaining large bodies of code. However, I don't agree that the size of the language has anything to do with the problem. C code written by two different people can be just as radically different as Perl code, and C is small language.

The only way to guarantee that Perl code on a large project is "read-write" and not "write-only" is the same as with any other language - coding standards and code reviews to make sure they're being applied. Nothing else will ensure that a group of programmers is coding in the same dialect.

-sam

The only way to guarantee that Perl code on a large project is "read-write" and not "write-only" is the same as with any other language - coding standards and code reviews to make sure they're being applied.

Utterly right.
And we can also add that Perl today even offers the tools to automate the enforcement of such discipline, such as Perl::Critic.

Ciao,
Emanuele.

Really it are people like Tom Horsley...

I think he's wrong too, and followed up on that thread (saying "don't hire monkeys"), but Tom has contributed to p5p and Perl 5 for years. I think you may be mischaracterizing the person when you ought to focus on the argument instead.

Well, I only know him from this one message and I find it very unprofessional and damaging to Perl's reputation for no good reason.

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

Tom has contributed to p5p and Perl 5 for years. I think you may be mischaracterizing the person when you ought to focus on the argument instead.

You say he has contributed to p5p and Perl 5 for years, but the quote,

Perl really is a write-only language, and you just can't do production work write-only -

is just a dumb statement. If he is willing to paint Perl as just a write-only language you cannot really be suprised that someone is painting him as a j***a** whatever his contributions...

Perl is a language that a:

(a) philosophically, categorically refuses standardization ("There's more than one way to do it")
(b) has multiple meanings for each function call("context")
(c) is chock full of single character "special" variables that don't behave like normal variables (and the meaning of something as simple as "evaluate this variable" can change via tie() anyway)
(d) has an interpreter that "guesses" the meaning of a construct rather than a clear language standard... the motto is "try it in Deparse and then you can find out what it does"
(e) provides multiple features to allow programmers to alter the meaning of the code being run based upon run-time computations (autoload, eval, symbol table manipulations, coderefs, code filters, ties). Code can't be read in isolation, because what it means depends on what's been executed previously.
(f) can only be probabilistically parsed by anything other than the perl interpreter, because of point (d) above, leaving code management tools to guess and pray.

If that doesn't qualify as "write only", what language does? The only languages that I

The only way to make perl less "write-only" is to write coding standards to prevent abuses, and scale it back into a manageable language again.

However, part of the point of a higher level language is to enforce good coding conventions automatically: for example, no access to pointers in Perl means no pointer errors, even though programmer discipline, and "don't hire monkeys" should prevent pointer errors in C and assembly language. But traditionally, it hasn't.

Replacing human error with machine precision is exactly why we moved from assemblers to compilers in the first place. Then again, I'm sure a ton of people will now protest that "Assembly Language is not write only", and only a "j***a**" would think so...

*sigh*

the language is so fantastically huge, no two programmers even appear to be writing in the same language

I think that there is no production-ready language where that statement can't be made.

Besides, writing maintainable code takes effort, regardless of what language is used for programming. People can quite easily write unmaintainable code in any known programming language.

Do you mean "big projects" or "production code". To me "production code" makes my workplace productive - I have a pile of Perl script sitting there doing that job: Perl is hugely productive.

On the other hand I would be unlikly to use Perl for a really large application - Perl provides far too much rope and no tensioners to manage the slack. The bottom line is that there is no one language that is best for everything. Perl is damn fine for a lot of stuff and can be written to be maintanable for sure. I've even had to maintain some of my own code so I know it's possible. :)

... I would be unlikly to use Perl for a really large application ...

Actually, it is getting to the point now that rather few applications written in Perl need to be "really large", in terms of what the application developer needs to write from scratch.

I've created a number apps that are actually fairly small in terms of what I personally have written, but they do "really large" things that I couldn't dream of being able to do without the core and CPAN modules. I'm sure that if I joined all the modules for an app into a single set of source code, it would be a pretty large amount of code.

Indeed. And that thought crossed my mind as I was writing my reply. However much the same is true of most other languages, and certinally is true of the popular languages. It is still the case however that if you need to write large amounts of code there is a win by using languages that cut down your freedom of expression through strict type checking and other such constrains as a price for better management of large projects.

Unless you have been involved with a really large project that is large because it has to be (not because it is poorly written or poorly designed), it is hard to imagine the sorts of problems that arise and even harder to know how to manage them.

---

DWIM is Perl's answer to Gödel

Do you mean "big projects" or "production code".

I wouldn't know and most probably Tom Horsley wouldn't know either. As you say, writing maintainable code isn't more difficult to do in Perl than in any other language. The few C-programs I've written are after so many years well nigh impossible for me to understand what I tried to achieve then.

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

I've even had to maintain some of my own code...

If your employers are that mean, you should probably report them ;-)

I'm growing a company with a long-time friend, and Perl is the most important (if not the only) language we use. I'm curious where we are on the scale of project sizes.

You've asked what constitutes a "big" project in Perl and I can only say that this is terribly subjective. One project I worked on was a quarter million lines of code (pretty good code, too) and that was definitely a big project. Were it written in Java or C, it could easily have topped a million lines. There are those who will swagger in and say "yeah, I maintained a five million line project" and there are those who maintain 50K lines and think those are huge, but there's really no arbitrary cut-off. Thus, to say that Perl's bad for "large" projects does beg the question.

That aside, we had no problem maintaining our quarter million lines of code because we pair-programmed, had decent test suites, respected encapsulation, didn't have (many) unrealistic deadlines and so on. In short, with competent programmers and a decent work environment and code base, Perl scales well and we could get things done fast, fast, fast.

That being said, finding competent Perl programmers turns out to be more difficult than one might think. This is a constant complaint I hear from employers.

Cheers,
Ovid

New address of my CGI Course.

Thank you, Ovid. That helps me position myself, and it clarifies my feelings about the issue the OP raised.

Our code base for this particular project runs in the 90K lines. If I'm generous, I can take 30K off to account for dead code and unrefactored duplication. My feeling was that it's not exactly huge, but not trivial either. Your examples seem to corroborate that.

So, if two fairly competent, mildly disciplined coders can comfortably maintain a code base of that size, it seems entirely reasonable to me to suggest that Perl is quite suitable for big projects. Perl doesn't make it particularly hard to write modularised, well contained code. I don't see why it wouldn't be possible to create huge projects in it that way.

Hi Ovid

    Thats great u have made me feel that

"Yes evrything is possible & nothing is impossible and it need u to be a competent programmer."

    Its not the matter that you have to write a 50K line code or a million line code it all depends how efficiently and how effectively you can write ur Code with the optimum utilization of resources.

    And also said it right u need to have decent testing cases and suites and control over the code and maintainence of the code can be done easily and effectively. People can quite easily write unmaintainable code in any known programming language.

As one of our monk said

A good programmer can overcome a poor language or a clumsy operating system, but even a great programming environment will not rescue a bad programmer. — Kernighan and Pike

Sushil

I'd consider a programming project "big" if:

• There's at least 2 programmers assigned to the project full time for at least a month, i.e., it's labor budget is over about 400 hours.
• Or it requires a users' manual that's takes up more than 1 page (12 point type, reasonable margins, A4 or letter sized paper)
• Or if the program requires extraordinary testing and verification (say, the control software for a nuclear reactor)

emc

e^(π√−1) = −1

By Mr. Horsley's logic, English (or any other natural language) is a "write-only language" because there are so many ways of saying things. That's only true if you only learn one way of saying things, or a small sub-set of the vocabulary. Then you can't understand what someone else is saying, if s/he chooses to use a different phrase. It seems this is more an admission of an inadequate understanding of Perl, than a defect in the language. Perhaps it's better that Mr. Horsley *not* promote Perl, if this is true.

/(English|German|.+?) language/... Terry Pratchet wrote in one of his books something like (translated back from german) "it's rather impossible to express yourself properly in a language that has its roots in insulting the monkey at the next tree". So I think Perl is a rather big advance into the right direction ;-)

BTW: I don't want to insult the /.+? language/ or anybody who's using it (maybe except myself); it just sometimes seems very difficult to understand what somebody wants to say (especially if this person is a SAP consultant...)

Best regards,
perl -e "s>>*F>e=>y)\*martinF)stronat)=>print,print v8.8.8.32.11.32"

SAP consultant that can be understood is clearly an undertrained newbie. :-P

Jenda


Support Denmark! Defend the free world!

By Mr. Horsley's logic, English (or any other natural language) is a "write-only language" because there are so many ways of saying things.

He's right.

If you don't believe me, construct a parser to correctly decipher the meaning of an English sentence, or to reject it if the sentence is not valid.

It's hard. Very, very hard. English is a mess. It's one of the hardest languages to learn for a reason: it's huge, and it's inconsistent, even compared to other natural languages.

We have a whole host of ways to write negation: "not hopeful", "atypical", "unrelated", "disproportional", "counterintutive", "antiestablishment". That's not an exhaustive list. "Up" opposes "down", but "to burn up" is not the opposite of "to burn down".

The language is ambiguous, even at it's most basic levels: In the sentence: "He finished his bow, and walked off briskly", the actor could be a bowyer or an actor, but we can't know without more contextual information. Languages that resolve ambiguity due to context are harder to understand: English does it a *lot*. And despite training, we can't really manage to learn it all.

Everyone in every English-speaking nation that I can think of is legally required to attend a *minimum* 11 years of schooling, where they learn spoken and written English, and formal rules of grammar and composition. Despite this, few native speakers understand even the most common English language idioms.

For example, I don't know how many times I've read people who should know better write: "to tow the line" (to tug on a rope!) rather than "to toe the line" (to step carefully along a pre-set path) as an idiom for obedience to authority. They should know better after 11 years: but they don't.

That's only true if you only learn one way of saying things, or a small sub-set of the vocabulary. Then you can't understand what someone else is saying, if s/he chooses to use a different phrase.

Name ten people who know every single word in the Oxford English Dictionary, every meaning in every context. I don't know any; and I know a lot of teacher and English majors. I doubt you know anyone who does, either. Everyone speaks a subset of English; and that's a problem. Try talking to someone straight from Jamaica: you won't understand him. You won't understand someone straight from old-world Scotland: as one of my friends was quite rudely told, "Yae dinnae ken hae tae tawk raeght!"

English is a mess. Worse, yet, literary English is confounded by a whole host of metaphor, much of which only makes sense only if you have a grounding in classical mythology. If you disagree, well, perchance we might stridently take discourse in the temple of Mars, good sir! Engarde! :-P

You raised some excellent points, and you're right about many of them. English is a mess, even by comparison to other natural languages. However, a couple of observations may be in order. First, I don't actually need to write a parser. I came equipped with one, and it does a reasonable enough job - and so do most peoples'. Overall, people do understand one another, more or less. There are always spectacular exceptions, the stuff of many comedies and tragedies. Second, while everyone knows a subset of English, we tend to limit our spoken vocabularies to an even smaller subset, possibly for this very reason. In ordinary conversation I use fewer different words, and much simpler ones than I would for a term paper, for example. Because of this, most people understand me when I talk to them. I think what I'm trying to say here is that within my particular group of English-speakers, we tend to use a subsets that have more members in common.

Unfortunately, another problem with English is that we often use expressions without having any good idea about what they mean (your "tow the line" was a perfect example). I've seen things like putting the "petal to the metal", "he's not all their", and so on. Makes me want to pound my head with a brick. Still, overall, people do seem to convey their meanings well enough most of the time. When they don't - well, that's what laywers are for. ;-)

Between the regional differences ("fossicking for wolfram" could be called "prospecting for tungsten"), variations in spelling, pronunciation, grammar, etc., the changes that occur over time, and slang, it's really confusing. If you have access to OED, check out the definitions for "pure". # 12 is "dog poop" (they use different words, but that's what they're talking about). Hey, that guy is real pure... Nice used to mean nasty, wantons once referred to innocents, and so on. Bad is good... war is peace...

*NO* one knows all the words in the OED, not even the guy who assembled it (he's dead, anyway). Somewhere I read that at best a highly literate person knows in the neighborhood of 50K words. The OED defines about ten times that number. I don't even know anyone who could reliably recognize whether a group of characters was even a word in the OED, much less always say what it means. So, no - no one knows all the words in English.

As for taking discourse in the temple of Mars - ah, well, I am a devotee of Venus... or Dionysus... I'll pass.

Spiritway hit most of my points, so I'll try not step on his toes (although it's "toe the line" and "pedal to the metal").

I've no idea what your native language is nor do I have a good grasp of your fluency in English. However, most of your criticisms of English apply to other natural languages. Spelling? French spelling, while more regular than English, has very little to do with the phonetics, and is also irregular. It's also chock full of idioms. Modern Italian has quite regular spelling: it should, it was made up in the 19th century from the dialect used in Florence. In reality, Italian has numerous dialects, many of which are mutually incomprehensible (my grandparents were Piemontese; my mother in law is Neapolitan; they couldn't have spoken to each other in "Italian;" Piemontese and Neapolitan are mutually incomprehensible. These native Italian speakers would have to talk to each other in English.).

Once upon a time, English spelling was phonetic. English changed. Yes, cough, hiccough, and through once rhymed. The "k" in knee was pronounced, "thou" was the 2d person familar (like "tu" in French), and all was right in the world (and "right" and "rite" were pronounced differently). French has also changed with time; so has Spanish. Norwegian has two official forms and several unofficial forms.(see Norwegian_language).

Yes, English may be a mess, but as a natural language it's in good company: even the worst specified computer language is orders of magnitude less messy than the least messy of the natural languages.

emc

e^(π√−1) = −1

You’re uttering lots of anglocentric criticisms as if they were true only of English. Try to parse Japanese someday.

The fact is that all natural languages disambiguate extremely heavily on context. When I say “Albert was not happy about the Bomb,” you know exactly which Albert and which bomb I mean. This sentence would be nearly the same in every single language; there is almost no language in which this sentence would be inexpressible without the inclusion of more context, and yet it will be equally comprehensible in all of them.

Every single claim you make applies in one form or other to every single natural language. Some throw up hurdles you possibly haven’t even imagined because they work completely differently from English.

I don’t know if that’s a problem. Despite the fact that I might not understand someone from Jamaica, I can certainly talk to roughly a few hundred million people without any significant difficulty in communication. If that counts as failure for a language, I want to know what success is.

The contrast is a language like Esperanto, which is constructed, is extremely regular, has very few rules, can be picked up in about 2 hours other than memorising vocabulary – and has no speakers.

Makeshifts last the longest.

I suppose that adopting that perspective might diminish or eliminate the desire to argue the matter of Perl's applications and/or utility.

My stock response to the "write only" myth: Chinese is a write-only language to those who don't know it.

It seems like you are defining "write only" as a synonym for "don't understand". Which I think avoids the question. If you don't understand a language, you can't write it or read it. "Write only" means a person understands perfectly well what each individual statement means, but piecing together the big picture of what's going on can take an inordinate amount of time. As an example of a "write only" process, consider the act of writing a program for a Turing machine.

By your definition, every non-trivial application in every programming language is write-only. No matter how proficient one is in the language used, the first encounter with a non-trivial application will find the reader in that state of understanding the details but not (yet) grasping the whole.

It seems like you are defining "write only" as a synonym for "don't understand".

Probably it is closer to say that "write only" implies that the person making the claim only understands part of the language, not that it's entirely unknown to him/her. Case in point - I can fluently order food in Spanish, but I do not actually speak Spanish. Take me out of a restaurant setting, and I have serious problems understanding what people are saying (unless they happen to be talking about enchiladas).

In Perl (or any other rich programming language), there are many ways of getting a task done. It is entirely possible to be able to write a decent Perl program, but not to be able to clearly grasp what someone else has written - even if it happens to do the same task.

Your comment about a Turing machine program was excellent, and seems to offer a rebuttal to the complaint about Perl being "write-only". The original post discussed the criticism that Perl is too *rich*, that programmers had too many ways of saying things, making it difficult for other programmers to understand what they wrote. While there might be some truth to that idea, your idea is clearly another answer. A language that is feature *poor* is also hard to understand - perhaps even more difficult than one that is rich.

I think this probably says that we don't really have a good definition for what "write-only" means, in the context of a programming language. Whatever it means, though, I don't consider the fact that Perl is rich, to be a defect. I like being able to do things in a variety of ways, even if it does make it more difficult for me to follow what someone else has done. That difficulty is a reflection of my own shortcomings, not of the language. I simply haven't learned what X means, yet. One great benefit of Perl Monks is seeing so many different, often (but not always) brilliant ways of getting something done. It forces me to stop, puzzle out why the Monk chose that idiom, and to decide whether this way is better than whatever I came up with.

"Write only" means a person understands perfectly well what each individual statement means, but piecing together the big picture of what's going on can take an inordinate amount of time.

Precisely.

Given a passage of text in a language whose grammar is unlike any with which you are familiar (like, say, Chinese) and a dictionary translating the words of that language into one in which you are familiar, it doesn't take that long to reach the point of knowing what each individual word means, while still having no idea of the overall meaning. For me, at least, Chinese fits your definition of "write only" quite well, provided I have a Chinese-English dictionary available.

Chinese is a write-only language to those who don't know it.

Yes, because as we all know, the Chinese language is lauded for its obfuscated nature.

As we all know, every serious Perl hacker will immediately tell you that you should obfuscate all your production code.

Makeshifts last the longest.

A good programmer can overcome a poor language or a clumsy operating system, but even a great programming environment will not rescue a bad programmer. — Kernighan and Pike

(The C programming language) is a razor-sharp tool, with which one can create an elegant and efficient program or a bloody mess. — Kernighan and Pike

At least this Anonymous Monk has taken the effort to look up my website. Shall we ++ him for that?

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law