[Arnt]

But the small perl codebases I have are great.

I have a crontab that runs every five minutes: 30 lines that use one CPAN module, no bugs in years. The code has the kind of hackiness that's okay when it fits on one screen, and it fits on one screen precisely because of that hackiness.

[lmm]

It's very hard to know which codebases will grow to be large - every codebase starts out small, and by the time you realise it's going to be big, rewriting into another language is expensive. Better to use a language that can scale to small codebases and large, that can accommodate hackiness and cleanness alike.

[Arnt]

Nicely put, but I notice that you avoid names and numbers.

How expensive can it be to rewrite a hundred or a thousand lines, if a perl script keeps growing? And what are these languages (you use plural so I do too) that are optimal for every case?

[lmm]

> How expensive can it be to rewrite a hundred or a thousand lines, if a perl script keeps growing?

A hundred lines, or a thousand lines, is not so bad. But where do you draw your line in the sand that you're going to stick to? If you don't insist right at the start on coding to your maintainability standards, why would you make that change when your script went from 30 lines to 100, or 100 to 500 (no doubt always driven by an urgent functional need)? It's always easier to add one more change to the existing codebase; the only point where you'd rewrite is when the codebase becomes literally unmaintainable because no-one understands it, and at that point migrating it is extremely expensive.

> And what are these languages (you use plural so I do too) that are optimal for every case?

I'm not saying optimal (I doubt that's possible), I'm saying pick a language that's adequate for every case. I'm partial to Scala, which was explicitly designed as a "scalable language" that would work for large and small codebases; other ML-family languages (e.g. OCaml) are similar. In my book any language with the ML featureset is more than adequate for large codebases, and any language that has a REPL/interpreter and doesn't require Java-like explicit types is adequate for scripting tasks. (Side note: I've always found it odd that Perl didn't have a first-class REPL, since IME that's one of the biggest natural advantages of scripting languages). If you want to start from the scripting end, Python, Ruby or even TCL offer a level of consistency and least-surprise that let them scale to larger codebases than Perl, though I wouldn't really want to use any of them on a truly large codebase.

[Arnt]

Next question: Code written in which of these languages tend to avoid needing major redesign when a thirty-line script grows unanticipatedly to much, much more?

[lmm]

I've seen plenty of Scala codebases grow without ever needing an overall redesign, and don't see why it would be different for any other language. Of course the end state is very different from the start state, and no doubt pieces end up getting rewritten many times over. But being able to incrementally evolve the codebase while keeping it all working is much easier and cheaper than having to rewrite in one go. In my experience you only need a "redesign" when you did too much design up front in the first place; if you always keep code changes driven by concrete use cases and avoid premature generalisation, you end up with a codebase that won't impede future changes any more than it has to.