How is Perl fitting for software that is developed by one team and maintained by other teams? What characteristics make it suited for long-term maintainability?
The requirements-for-the-language section is meant to make that tie. It seems I need to be a little less obscure. Also, see below for why some of that was left out.
I think this is a great start, but it's still a little too one-sided to be convincing to those not already convinced.
I agree, this piece isn't advocacy per se, it's sort of a prelude to advocacy. The intended audience was Perl Monks. It's also just a meditation, not really an essay (yet) -- it's meant to sort of foist my thought process into a place where I can get some meaningful discussion on the idea. I had to ramble on a bit about the background so that the couple of paragraphs that represent my point had some context.
I'd love to see a revision based on feedback received here and after you've written the opposite piece. Then it might well be the kind of stuff TPF can use for advocacy more broadly.
If I get some meaningful feedback, I will probably do a few more meditations to flesh out the remaining arguments. Based on the feedback from those, I will consider writing an actual essay, which I suppose I will post here as well.
Thanks for the criticism and encouragement, too!
In reply to Re^2: The Enterprise Language Trinity
by radiantmatrix
in thread The Enterprise Language Trinity
by radiantmatrix
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |