in reply to disadvantages of perl

I "had" to learn Perl during my work, but I really like the language now.

However, there are several aspects, which I don't like that much:

1) Perl on Windows. I don't see any "real" applications being written in Perl for Windows, probably in part because you have to install Perl on Windows first. Linux usually comes with a Perl installation. On my local Windows machine I don't even have Perl installed (because I don't need it there, which - for me - also shows that it's not being used that much on Windows).

2) CPAN is great. What is not so great in my opinion is the documentation and usage of the cpan shell. I often saw questions on perlmonks on how to install / uninstall specific versions of a module. Sure, there are ways to do that, but it's not really trivial.

3) Threads in Perl. Even with Perl 5.10 I often see a ""*** glibc detected *** double free or corruption" when using threads. I suspect that this is related to some older versions of CPAN modules that I'm using, but it's just for my specific situation something I don't like about Perl. This is why I ported many of my perl scripts to use processes / fork instead of threads.

4) Some of the general language constructs. I don't know about all the special symbols and in general stick to a more "C-like" programming style in Perl. I also don't like Perl's built-in OOP mechanism, which is why I use Moose. So there are ways to use Perl the way I'd like to use it, but it also means that it sometimes hard for me to read and understand existing Perl code.

I now use Perl a lot and I think for certain problems it's the "best" language to use. However, the problems I mentioned above (and some more) don't make me feel like it's the "perfect" programming language.

Replies are listed 'Best First'.
Re^2: disadvantages of perl
by GrandFather (Saint) on Jul 02, 2009 at 21:07 UTC

    1) I'm not sure what you call a "real" application, but I've written a number of significant applications using Perl and Tk that are used daily by a number of people or are major parts of our corporate software deployment process. They look awful (Tk's like that), but were quick to write, are easy to maintain and are very appropriate to their purpose. Oh, and they are all running on Windows of course.

    There is no "perfect" language, although there are languages that are well suited to particular application domains. Perl is a very good text processing and prototyping language. It is not such a good general GUI application development language, although it performs really well in that role for small applications if you don't care much about the "look". Perl can be very portable across systems.

    True laziness is hard work

      I don't doubt that it can be a good approach to develop certain applications for Windows in Perl.

      It's more like a question I'm asking myself why I never got in contact with Perl when using Windows. All of the applications I use on Windows are either binaries (probably written in C, C++, C#, ...) or java-based.

      On the other hand on Linux I often see tools written in Perl. Most of them run on the shell and don't provide a GUI. So maybe that's the main reason here: GUI development isn't that easy / good / advanced in Perl.

      Don't get me wrong: I'm not stating that developing Perl on Windows is bad, I'd more like to state my own experience and maybe get some input from others to understand if I have some misconceptions there.

        Web apps are GUIs and with a huge amount of well defined cross-app behaviors which add value and guarantee some level of user acceptance/experience. Some of the best/biggest apps in the world are all/mostly Perl.

        I do GUI Perl programming for Windows, using Win32::GUI. It's not exactly easy, but it's not too bad either; most problems can be solved given sufficient STFW time. I do sometimes feel that the time spent solving GUI problems is chewing up the time saved by going to CPAN for the core logic, though, which would be my number one complaint about Perl.

        Number two complaint -- threading. I have to write sequentially, because forking uses so much memory and threading just doesn't.

        "Nothing was broken, and it's been fixed." -- Jon Carroll