3 ms·

This is a thoughtful post, thank you. > Meanwhile perl's incoherence makes it very hard to write large programs and solve hard problems ... I've been on teams

This is a thoughtful post, thank you. > Meanwhile perl's incoherence makes it very hard to write large programs and solve hard problems ... I've been on teams writing very large systems solving very hard problems in Perl 5 for more than 20 years. I know that some of that stuff that was written in the 90s is still under active development and maintenance today, even though it's several developer generations in the past. Perl 5 may or may not be 'incoherent'. It is certainly somewhat idiosyncratic. But so is JavaScript, perhaps to a lesser degree. Perl 5 in the large requires some somewhat different (but not too difficult) disciplines. But that's not so different than most other languages. > In many ways I'd say it was the go of its day. This made me smile! Thank you again.

lmm 12y ago
> Perl 5 may or may not be 'incoherent'. It is certainly somewhat idiosyncratic. But so is JavaScript, perhaps to a lesser degree. I think if "it's not a lot worse than Javascript" is the best you can say in its favour... > Perl 5 in the large requires some somewhat different (but not too difficult) disciplines. But that's not so different than most other languages. The problem I always saw was that libraries would follow their own styles, so once you had a project that depended closely on several different libraries you'd be forced to cut against the grain of several of them. It's a problem that's lessened in a language with a single standard way of doing OO, a single standard way to do event-driven I/O, or even trivial things like code formatting. Maybe the perl community has found more of a consensus in recent years. Nowadays I work almost completely in scala, which some people compare to perl, so I'm concerned about not repeating perl's decline in popularity.
- raiph 12y ago
  > The problem I always saw was that libraries would follow their own styles, so once you had a project that depended closely on several different libraries you'd be forced to cut against the grain of several of them. It's a problem that's lessened in a language with a single standard way of doing OO, a single standard way to do event-driven I/O, or even trivial things like code formatting. The Perl 6 language design directly addresses this problem. The intent is to avoid throwing out the baby (making both timtowtdi and long term language evolution practical) with the bath water (lack of composability of the various ways to do things and of new features that emerge). The Rakudo implementation is most of the way there.

lmm 12y ago

> Perl 5 may or may not be 'incoherent'. It is certainly somewhat idiosyncratic. But so is JavaScript, perhaps to a lesser degree. I think if "it's not a lot worse than Javascript" is the best you can say in its favour... > Perl 5 in the large requires some somewhat different (but not too difficult) disciplines. But that's not so different than most other languages. The problem I always saw was that libraries would follow their own styles, so once you had a project that depended closely on several different libraries you'd be forced to cut against the grain of several of them. It's a problem that's lessened in a language with a single standard way of doing OO, a single standard way to do event-driven I/O, or even trivial things like code formatting. Maybe the perl community has found more of a consensus in recent years. Nowadays I work almost completely in scala, which some people compare to perl, so I'm concerned about not repeating perl's decline in popularity.

raiph 12y ago
> The problem I always saw was that libraries would follow their own styles, so once you had a project that depended closely on several different libraries you'd be forced to cut against the grain of several of them. It's a problem that's lessened in a language with a single standard way of doing OO, a single standard way to do event-driven I/O, or even trivial things like code formatting. The Perl 6 language design directly addresses this problem. The intent is to avoid throwing out the baby (making both timtowtdi and long term language evolution practical) with the bath water (lack of composability of the various ways to do things and of new features that emerge). The Rakudo implementation is most of the way there.