5 ms·

Perl: No Applications for Normal Users

21 points by fogus 17y ago

bumbledraven 17y ago
What does a cookbook do for people who don't cook? Perl is a programming language. CPAN is a bunch of Perl libraries. Perl and CPAN don't do anything for non-developers. [Edit: I see now that the author is saying that there are no significant applications for end-users written in Perl, which is certainly true. I attribute that in part to the difficulty of distributing a reasonably small installer package for a GUI application written in Perl.]
- jibiki 17y ago
  As far as I can tell, he's saying that there's not a lot of casual software (like games and such) developed in Perl(?) Anyways, Perl is a fantastic programming language for non-developers (e.g., people writing small programs for personal use.)
- gaius 17y ago
  Vast amounts of code is written by people who don't primarily self-identify as a programmer/developer/whatever. Python is huge within the science/engineering community who want to use NumPy for example, Perl has virtually no presence there.
  - frossie 17y ago
    Erm, it does depend on which part of the scientific community you are talking about - we're not all a monolithic Borgian block you know. There are a bunch of non-programmers using the Perl Data Language for example (pdl.perl.org). The real problem in my opinion is that perl has no buzz so is not picking as many new users - we can speculate about the reasons, I personally blame how perl6 has gone for a lot of it though.
  - smanek 17y ago
    Much more bioinformatics work is done in Perl than Python. I can't speak for other fields, though
- chromatic 17y ago
  > I see now that the author is saying that there are no significant applications for end-users written in Perl, which is certainly true. Not really; I meant that I haven't heard of very many. The HN title is excessively misleading. > I attribute that in part to the difficulty of distributing a reasonably small installer package for a GUI application written in Perl. I agree with that.
idlewords 17y ago
I think there are two reasons for the paucity of Perl applications for non-technical users: 1. It is horribly painful to try to write non-Web GUIs in Perl 2. It is horribly painful to maintain large codebases in Perl (speaking as a longtime Perl developer and big fan of the language)
- berntb 17y ago
  Why is it harder to maintain codebases in Perl if you follow the "Best Practices" book?
  - idlewords 17y ago
    Several reasons: - sigils make it difficult to scan code - there is poor IDE support for perl - it can be very hard to figure out what arguments are being passed, or what arguments a subroutine or method expects. - it's common to pass around a hashref (a.k.a. magic blob of data) as an argument. Finding out what the proper internal structure of this is can involve jumping around a lot of code - there can be spooky 'action at a distance' effects. For example, the URI module calls 'require' deep within a private internal class. This can crash your program if, for example, you've forgotten to properly implement the STORE method for a tied hash in a completely unrelated part of your program. For another example, using unicode in a regex somewhere can cause files to be pulled from disk, suddenly slowing your app by three orders of magnitude. - not everyone has read the best practices book, including the authors of very widely used CPAN modules - Chasing up and down inheritance chains can be very unpleasant. See MovableType. Again, nothing wrong with Perl, it just has certain features that make it a bear to work with when the project size exceeds a certain threshold, or when there are multiple programmers.
    - berntb 17y ago
      >- there can be spooky 'action at a distance' effects. Yeah, those are unique to Perl... :-) >- not everyone has read the best practices book True, it is unique that Perl has programmers which doesn't follow the coding standards of the group... :-) >- Chasing up and down inheritance chains can be very unpleasant. True, it is only Perl which have over complex OO libs. :-) >> For another example, using unicode in a regex somewhere can cause files to be pulled from disk, suddenly slowing your app by three orders of magnitude. I don't know much about Unicode. You mean that using Unicode characters would require loading a library? Can you give a reference to that "three orders of magnitude"?! If you count the startup time of the lib as run time, I am disappointed. >- there is poor IDE support for perl Huh? Afaik that IDE from Activestate gets good reviews, but Perl programmers use Emacs (or Vim) anyway. Than we have Padre on the way. >- sigils make it difficult to scan code >- it can be very hard to figure out what arguments are being passed, or what arguments a subroutine or method expects. (More or less the same point.) At least partly correct, I guess. I generally check the synopsis, first. Their existence probably comes from this. >- it's common to pass around a hashref (a.k.a. magic blob of data) ... Create an object, if it is complex. Edit: Moved answers to strange claims to top.

21 points by fogus 17y ago

What does a cookbook do for people who don't cook? Perl is a programming language. CPAN is a bunch of Perl libraries. Perl and CPAN don't do anything for non-developers. [Edit: I see now that the author is saying that there are no significant applications for end-users written in Perl, which is certainly true. I attribute that in part to the difficulty of distributing a reasonably small installer package for a GUI application written in Perl.]

jibiki 17y ago
As far as I can tell, he's saying that there's not a lot of casual software (like games and such) developed in Perl(?) Anyways, Perl is a fantastic programming language for non-developers (e.g., people writing small programs for personal use.)
gaius 17y ago
Vast amounts of code is written by people who don't primarily self-identify as a programmer/developer/whatever. Python is huge within the science/engineering community who want to use NumPy for example, Perl has virtually no presence there.
- frossie 17y ago
  Erm, it does depend on which part of the scientific community you are talking about - we're not all a monolithic Borgian block you know. There are a bunch of non-programmers using the Perl Data Language for example (pdl.perl.org). The real problem in my opinion is that perl has no buzz so is not picking as many new users - we can speculate about the reasons, I personally blame how perl6 has gone for a lot of it though.
- smanek 17y ago
  Much more bioinformatics work is done in Perl than Python. I can't speak for other fields, though
chromatic 17y ago
> I see now that the author is saying that there are no significant applications for end-users written in Perl, which is certainly true. Not really; I meant that I haven't heard of very many. The HN title is excessively misleading. > I attribute that in part to the difficulty of distributing a reasonably small installer package for a GUI application written in Perl. I agree with that.

idlewords 17y ago

I think there are two reasons for the paucity of Perl applications for non-technical users: 1. It is horribly painful to try to write non-Web GUIs in Perl 2. It is horribly painful to maintain large codebases in Perl (speaking as a longtime Perl developer and big fan of the language)

berntb 17y ago
Why is it harder to maintain codebases in Perl if you follow the "Best Practices" book?
- idlewords 17y ago
  Several reasons: - sigils make it difficult to scan code - there is poor IDE support for perl - it can be very hard to figure out what arguments are being passed, or what arguments a subroutine or method expects. - it's common to pass around a hashref (a.k.a. magic blob of data) as an argument. Finding out what the proper internal structure of this is can involve jumping around a lot of code - there can be spooky 'action at a distance' effects. For example, the URI module calls 'require' deep within a private internal class. This can crash your program if, for example, you've forgotten to properly implement the STORE method for a tied hash in a completely unrelated part of your program. For another example, using unicode in a regex somewhere can cause files to be pulled from disk, suddenly slowing your app by three orders of magnitude. - not everyone has read the best practices book, including the authors of very widely used CPAN modules - Chasing up and down inheritance chains can be very unpleasant. See MovableType. Again, nothing wrong with Perl, it just has certain features that make it a bear to work with when the project size exceeds a certain threshold, or when there are multiple programmers.
  - berntb 17y ago
    >- there can be spooky 'action at a distance' effects. Yeah, those are unique to Perl... :-) >- not everyone has read the best practices book True, it is unique that Perl has programmers which doesn't follow the coding standards of the group... :-) >- Chasing up and down inheritance chains can be very unpleasant. True, it is only Perl which have over complex OO libs. :-) >> For another example, using unicode in a regex somewhere can cause files to be pulled from disk, suddenly slowing your app by three orders of magnitude. I don't know much about Unicode. You mean that using Unicode characters would require loading a library? Can you give a reference to that "three orders of magnitude"?! If you count the startup time of the lib as run time, I am disappointed. >- there is poor IDE support for perl Huh? Afaik that IDE from Activestate gets good reviews, but Perl programmers use Emacs (or Vim) anyway. Than we have Padre on the way. >- sigils make it difficult to scan code >- it can be very hard to figure out what arguments are being passed, or what arguments a subroutine or method expects. (More or less the same point.) At least partly correct, I guess. I generally check the synopsis, first. Their existence probably comes from this. >- it's common to pass around a hashref (a.k.a. magic blob of data) ... Create an object, if it is complex. Edit: Moved answers to strange claims to top.