4 ms·
I used to sell software to very large corporations, and for enterprise-wide deployment. You won't sell them anything written in Perl, nor will you find them au
by smoyer 13y ago
I used to sell software to very large corporations, and for enterprise-wide deployment. You won't sell them anything written in Perl, nor will you find them automating systems with it (there are domain specific languages for performing OAM&P on large numbers of systems.
If you want "no questions asked" in this environment, you need to pick Java ... and as of JavaEE6/7, it's a much more efficient language. Granted that it's not as dense as Perl, but it's also type-safe and with good conventions, readable.
If you're developing SaaS, use what you're most productive with (assuming you're not productive simply because you're creating crap). I've see people who can write in beautiful Perl, and I have no problem reading it. I've also seen people who write whole programs on one line just because they can ... and a couple months later, they can't read it either. Note that I've also seen bad Java, Python, etc programming.
- einhverfr 13y ago> Granted that it's not as dense as Perl, but it's also type-safe and with good conventions, readable. The argument for Java is that there is a wide developer base, and lots of libraries. Perl, with appropriate frameworks, can be remarkably typesafe too (see Moose, etc). It's still loosely typed under the surface, but you have good error handling of invalid type syntaxes as long as you don't break encapsulation. The big things I am looking at though are: 1. Maintenance and testing. 2. Readability You can write unreadable crap in any language. What Perl excels at is allowing you to improve readability and maintenance/testing by building mini-dsl's in your framework which reduce testing footprints.
- narrator 13y agoIt's really hard to write unreadable crap in Java. Even if you do, there's automated refactoring to fix it. That's the thing about Java. It makes it really hard for clever bad programmers to do a lot of damage to a project. With Perl the sky's the limit.
- einhverfr 13y agoAs long as function and variable names are arbitrary, you can write code that appears to do one thing and does something else. Far more damage can be done that way than by straight obfuscation.
- kamaal 13y ago>>It's really hard to write unreadable crap in Java. I work on legacy Java code bases every day, where I see thousands of lines of code all to just simply set and read variables. I'm not sure how that's even remotely described as readable.
- rat87 13y agoIt's readable and easily followed spaghetti code it just obscures what the programs means with unnecessary details.
- collyw 13y agoPeople say the same about Python, but it is completely possible. Deeply nested hashes with no comments explaining the structure. Variable names such as 'Indexes' and 'indexes' in the same function. I have had to rewrite code like that.
- morganherlocker 13y agoIf the OS is Windows, as it often is in these environments, C# seems to strike the best balance between safety, ease of recruitment, and flexibility. I have not used it in several years, but I still look back and miss awesome elements of the language like linq, the selection of super polished UI frameworks, Visual Studio, the ability to use dynamics when you needed to, the lack of drama in the community, and the ease of finding answers to obscure questions on SO. Of course, I left the platform for a lot of the same reasons, but in the context of being increasingly involved with OSS. That said, the positives still hold true for the enterprise space you are describing.
- bashcoder 13y agoTrue on the sales point. And it's getting harder and harder to find coders who want to spend all their time writing perl, as great as it is. That makes it tough for enterprises to maintain perl codebases. Also, more CPAN libraries seem to be in a state of atrophy these days and I think the long-looming specter of perl 6 has had a depressing effect on that community. The post talks about Moose, which is a behemoth with huge and varied dependencies and must be be tougher to maintain these days. Every time I've tried to write a project in Moose, I've regretted it in the long run. However, I've written plenty of big, enterprise-class projects in perl instead of buying them from major vendors. Over the years, we were almost always able to beat the value proposition of Big Software precisely because we had a solid team of perl coders.
- mst 13y agoThe spectre of perl6 stopped bothering us about 2006; CPAN uploads have been up every year since. If you find Moose too many dependencies, try Moo.
- bashcoder 13y ago> The spectre of perl6 stopped bothering us about 2006 From a practical usage standpoint, sure. But wouldn't you agree that an effective major version freeze has had a chilling effect on the progression of the language? I'd argue it's had a deleterious effect to varying degrees, even since 2006. It's not enough for a community to be not bothered. They need to be energized, and it's tough to make the argument that the perl6 snafu has been helpful to the perl movement. > CPAN uploads have been up every year since. CPAN traffic was down over 10% last year, according to Alexa. In fact, many perl popularity metrics were down at least 10% in 2013. [0] My experience, admittedly anecdotal, is that CPAN packages in general are not maintained with the same vigor as in years past. But why would they be, if people are moving their focus to other languages? Regarding Moo, thanks - I'll definitely have a look. [0] http://szabgab.com/the-popularity-of-perl-in-2013.html http://szabgab.com/the-popularity-of-perl-in-2013.html
- mst 13y ago