5 ms·

The largest reason why I would hesitate to use Perl in my startup would be the core philosophy of TIMTOWTDI (there is more than one way to do it). Being able t

The largest reason why I would hesitate to use Perl in my startup would be the core philosophy of TIMTOWTDI (there is more than one way to do it). Being able to write something multiple different ways leads to Perl being a lot easier to write than it is to read. As a result code maintenance can become a huge headache due to someone not understanding the idioms used by the person who originally wrote the code. I've seen this happen on a number of projects that I've worked with using Perl. Typically a person wouldn't be familiar with "silver ball" (Effective Perl Programming), would go off an write a large body of code which would be difficult to wade through. This gets exacerbated by new coders not understanding how perl expects you to understand some of its idioms (like $_, @_, etc.) implicitly. Because reading other people's code is a great way to learn a language, this makes Perl a lot less approachable. I think Ruby suffers from some of these problems to a certain degree as well. I haven't worked with Ruby professionally, but in the few times I've played around with it I've found myself spending a lot of time trying to figure out which looping construct I should use over another. Python does have a leg up in this department. The language tends to be fairly succinct and things like Pep8 and flake8 really help in making most code fairly digestible.

czbond 13y ago
You can get around readability with good comments. Perl can be a b*tch to deduce - but it is simple and powerful. I would also think hiring professional, experienced, Perl coders for a decent salary is easier than finding Rails, node,etc. (I've used Perl and Ruby for quite some time in the past. My last startup is still looking for more Rails engineers. I chose Rails because it was a good fit, but finding talent can be hard).
gabriel 13y ago
What language prevents TIMTOWTDI? And don't say Python. I'm not talking about the language motto. Because that's the nature of using these things called programming languages: http://www.paulgraham.com/langdes.html http://www.paulgraham.com/langdes.html Python has Pep8. Perl has Perl::Critic. C# has FxCop. Etc. I've not yet seen any language possess the qualities that prevent it from being unreadable. It's an amazing open question though, isn't it? I think you hit the point with "code maintenance can become a huge headache due to someone not understanding the idioms used by the person who originally wrote the code". But this isn't a language thing. This is a people thing.
- danbmil99 13y ago
  In my X, for whatever reasons (lang design, culture, etc) Python is most definitely the easiest language to read and understand what another programmer is trying to do. I don't think the most rabid PERL fanboy would ever make a similar claim.
chromatic 13y ago
As a result code maintenance can become a huge headache due to someone not understanding the idioms used by the person who originally wrote the code. I don't understand this. If this hurts you, wouldn't you have the same problem with domain knowledge, except an order of magnitude worse? Why are your developers not talking to each other?
- Patrick_Devine 13y ago
  Teams are dynamic, not static. You can have new hires, you can lose people and you can get code written by others that you have to maintain (especially the case with CPAN). I agree this is also a problem with domain knowledge. The second you commit something to your code base the clock starts ticking. The further away from your own code, the harder it is to have context and the more difficult it is to fix problems. If you feel like you can jump back in to your Perl code easily after a prolonged absence, by all means, do it. My point was only that in Perl, it's easy to use many different idioms which not all coders are familiar with. This can make debugging more difficult.
PySlice 13y ago
I think your comment is spot-on. A good Perl programmer can do wonders, but if you add just one average programmer to the team (without a very extensive training), he can write stupid things faster than the good programmer could fix, LOL. Then the codebase would be a mess, with things that kinda work but are conceptually wrong or weird for those who really know the language. And the good programmer could do anything in a less eccentric language anyway, so...

czbond 13y ago

You can get around readability with good comments. Perl can be a b*tch to deduce - but it is simple and powerful. I would also think hiring professional, experienced, Perl coders for a decent salary is easier than finding Rails, node,etc. (I've used Perl and Ruby for quite some time in the past. My last startup is still looking for more Rails engineers. I chose Rails because it was a good fit, but finding talent can be hard).

gabriel 13y ago

What language prevents TIMTOWTDI? And don't say Python. I'm not talking about the language motto. Because that's the nature of using these things called programming languages: http://www.paulgraham.com/langdes.html http://www.paulgraham.com/langdes.html Python has Pep8. Perl has Perl::Critic. C# has FxCop. Etc. I've not yet seen any language possess the qualities that prevent it from being unreadable. It's an amazing open question though, isn't it? I think you hit the point with "code maintenance can become a huge headache due to someone not understanding the idioms used by the person who originally wrote the code". But this isn't a language thing. This is a people thing.

danbmil99 13y ago
In my X, for whatever reasons (lang design, culture, etc) Python is most definitely the easiest language to read and understand what another programmer is trying to do. I don't think the most rabid PERL fanboy would ever make a similar claim.

chromatic 13y ago

As a result code maintenance can become a huge headache due to someone not understanding the idioms used by the person who originally wrote the code. I don't understand this. If this hurts you, wouldn't you have the same problem with domain knowledge, except an order of magnitude worse? Why are your developers not talking to each other?

Patrick_Devine 13y ago
Teams are dynamic, not static. You can have new hires, you can lose people and you can get code written by others that you have to maintain (especially the case with CPAN). I agree this is also a problem with domain knowledge. The second you commit something to your code base the clock starts ticking. The further away from your own code, the harder it is to have context and the more difficult it is to fix problems. If you feel like you can jump back in to your Perl code easily after a prolonged absence, by all means, do it. My point was only that in Perl, it's easy to use many different idioms which not all coders are familiar with. This can make debugging more difficult.

PySlice 13y ago

I think your comment is spot-on. A good Perl programmer can do wonders, but if you add just one average programmer to the team (without a very extensive training), he can write stupid things faster than the good programmer could fix, LOL. Then the codebase would be a mess, with things that kinda work but are conceptually wrong or weird for those who really know the language. And the good programmer could do anything in a less eccentric language anyway, so...