Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Slow evolution of Perl = Perl is a closed Word

by Anonymous Monk
on Aug 31, 2007 at 09:28 UTC ( [id://636279]=perlmeditation: print w/replies, xml ) Need Help??

I had developed in Perl 5 for years, and for years Perl was my 1st programming language and I loved it. Also for years I hated Java and .Net. I still respect Perl and think that it has a lot of very interesting things, but I still don’t have the smart things that arrived to the programming world in the last years.

This is my feedback after some years away of Perl working with other languages:

2 years ago I stopped to develop in Perl 5 due business opportunities, and started to do Research and Development with Java, and after this R&D project started to create and sell commercial applications in Java with the results of the R&D project. I stopped to hate Java (version 1.5+), but I still hate .Net.

Today a look to Perl and still don’t see very important resources that came to the programming world of Java, and other languages. But without this important resources will be much more difficult to use Perl in new business projects.

I don’t want to say that Perl is dying. But also I don’t want to say that Perl is alive only because still exists real Perl applications to be maintained. Is the same to say that COBOL is alive because we still have Banks that use it

Other problem that I see is that Perl 6 doesn’t exist in practice yet, years after Perl 6 started to be really developed.

Perl 5 is still the best language to use to process text data, but the world today needs much more resources:

  • A good IDE, like Eclipse for Java.
  • Good multi-threading.
  • Standard and rich GUI.
  • Today Perl is very far to have real solutions in these areas due this problems:

  • To have a good IDE for Perl 5 is difficult, since Perl 5 has a very complex syntax, especially because Perl 5 depends of runtime states to be really parsed. Today a good IDE is capable to parse the code, navigate the code, show documentation texts over the code and point code errors and warnings without run the code. To do this on Perl 5 to me is near to impossible. I was waiting for Perl 6 to resolve these syntax problems, but Perl 6 today is just a dream.
  • We see that multi-core computers are the future, and the only way to really use the total power of the hardware is a good multi-threading language. Perl 5 multi-threading model is just a pain. Good and real multi-thread in these days for me is like good memory management, we can’t live without. Perl 5 multi-thread model doesn’t work for real applications, especially because we have to much work to can use multi-thread and we only can create a fill threads in Perl. Today Java is the best language when we talk on multi-thread, since have all the needed resources to control concurrence access to data, Thread control, and critical sections. Also we can create a lot of threads, much more than Perl, and also with a good performance.
  • The use of GUI for desktop applications is very important. Perl still don’t have standard solutions for Desktop GUI. We have wxPerl, that I have collaborated and is very good, portable, but is not standard and available in any Perl installation. Also is problematic to create Desktop Applications with the bad multi-thread model of Perl 5. GUI means multi-thread, and since on Perl 5 you have to design all the code to have it on multi-thread, this is a big problem, especially when you want to use 3rd part modules.
  • Perl still have very good things:

  • CPAN: The paradise to contribute or find already done work to help on our projects.
  • REGEXP: Perl is still the best language when we talk about REGEXP, and actually I still prefer to test REGEXP on Perl before use it on Java. Also is still the best REGEXP engine, especially when we talk about performance and features to create patterns.
  • Powerful syntax, that help to create fast solutions for complex problems. But the dependence of runtime states to parse the language is a big problem for me, since invalidate any real solution for a good IDE.
  • One of the strongest reasons to use Java today is to be able to have Eclipse, that really help the job and speedup it, and a good multi-threading. I just can’t use a language that doesn’t have these resources.

    I still hope that one day Perl6 will be there, and Perl world will have a good IDE and real multi-threading model. The problem is that programmers won’t wait for that, and when Perl 6 arrives for us the other languages will be much more developed.

    Replies are listed 'Best First'.
    Re: Slow evolution of Perl = Perl is a closed Word
    by perrin (Chancellor) on Aug 31, 2007 at 12:17 UTC
      Believe it or not, many Java programmers dislike Eclipse and never do GUI programming. Your personal preferences do not indicate the fate of the industry.

        Your personal preferences do not indicate the fate of the industry.

        Wow! A nice simple refutation of every "perl is dying" node here in the monastery. I wish I had more than one vote.

        -derby
          A nice simple refutation...

          Not really. Personal preferences do not necessarily reflect the fate. But they might. Just because it's a personal preference doesn't make it not true.

          It's really a contradiction, not a refutation. A refutation needs to prove the statement false. A contradiction is just asserting the opposite.

          -xdg

          Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

    Re: Slow evolution of Perl = Perl is a closed Word
    by GrandFather (Saint) on Aug 31, 2007 at 10:40 UTC

      It seems to me there are a number of misconceptions in your thesis and a couple of assertions that are just plain wrong. First off two items that are simply incorrect:

      1. Actually there are good IDEs for Perl - Eclipse for one, Komodo from ActiveState for another.
      2. GUI does not imply any requirement for multi-threading support.

      The overriding misconception however is that the fate of a programming language is tied to growing to encompass the complete gamut of programming application areas. That is simply not the case. Perl does not need to evolve into something that is strong in GUI and multi-threading application areas to remain a useful and successful language. It helps that Perl provides some support in those areas because very often mixing in a little GUI code or multi-threading avoids the need to reach for a different tool. However Perl's strong suite is as a text processing tool and it is still the case that text processing tools that involve very little GUI or multi-threading code are required and will continue to be required for a long time yet.

      Languages like COBOL fall by the wayside because new languages and techniques do what they did better. In the areas where Perl is strong there is very little to beat it. And in many of the areas where Perl is strong it continues to grow stronger. Consider the new facilities that are being added to the Perl 5.10 regex engine for example. Consider also that Perl has been, and continues to be, highly successful in building a library of code (CPAN) to augment the facilities provided by the language. Both Perl and its support continue to grow - rumors of Perl's demise are both premature and exaggerated.


      DWIM is Perl's answer to Gödel
    Re: Slow evolution of Perl = Perl is a closed Word
    by swampyankee (Parson) on Aug 31, 2007 at 13:20 UTC

      Some people like IDE's; some don't. I've found them a mixed blessing for a number of reasons, most of which are entirely subjective. Two problems I've seen fairly often are that IDE's tend to encourage many programmers – especially inexperienced ones – tend to jump into coding too soon and that IDE's seem to encourage developers to think in terms of widgets, not in terms of data and algorithms.

      COBOL, a language in which I've done essentially no work, is alive for a number of reasons, including the simple fact that is an excellent language for its problem domain. It also has a large, albeit shrinking, pool of programmers who are both very proficient in the language and very proficient in the problem domain.


      emc

      Information about American English usage here and here.

      Any New York City or Connecticut area jobs? I'm currently unemployed.

    Re: Slow evolution of Perl = Perl is a closed Word
    by xdg (Monsignor) on Aug 31, 2007 at 10:38 UTC
      A good IDE, like Eclipse for Java.

      How about EPIC? Not sure how good it is, but it's a start.

      Still, from various posts here, I still get the sense that people are using vi/vim/emacs as the development tool of choice. I'm curious why that is.

      -xdg

      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

        First of all, i have to say that everything about IDEs is IMO a question of personal preferences. There is no absolute answer.
        I use vim with auto indent and no syntax highlighting. This is, because first of all vim is immensely powerful. Also i like the fact, that my hands don't have to leave the keyboard for using the mouse ... ever. Also i think using a terminal window with 80x24 chars is motivating to write compact and elegant code. This also makes me think more about the code i write, which IMO results in better quality code.
        What most IDEs do i just do in multiple terminal windows. I.e. keeping track of log or error files using tail, starting a debugger and so on. Many functions build in IDEs are there to replace common CLI tools anyway.

        I'll admit that i have not spend that much time looking at and working with IDEs, so maybe I've just not seen the light yet...
          In the past, I've spent a lot of time working in IDEs, mostly because I was using proprietary languages where the IDE and the compiler were tightly coupled. Some were pretty good, others not so much. I've come away from it convinced that an IDE is a terrific tool for developing GUIs, since you can get all the draggy-droppy form creation and so forth.

          But I've never much liked making GUIs. I mostly write back-end server code by preference and web apps by necessity (i.e., that's where most of the paying work seems to be), so my preferred "IDE", like yours, consists of several xterms running some mix of vim, bash, tail, top, or maybe a couple other things and a nearby Firefox window, whether for testing web code in development, looking up reference materials, or occasionally dropping by the monastery to check out the latest rumors of Perl's demise.

        A reply falls below the community's threshold of quality. You may see it by logging in.
    Re: Slow evolution of Perl = Perl is a closed Word
    by xdg (Monsignor) on Aug 31, 2007 at 18:49 UTC

      From other comments, I get the impression of a lot of knee-jerk defense of Perl. I thought that the OP actually did a fairly nice job of identifying some particular strengths and weaknesses, and did so fairly constructively. We need more constructive reflection of that sort.

      (More to the point, we need people to actually go work on the weaknesses!)

      Personally, I found some of the ideas compelling, though for slightly different reasons.

      GUIs/IDEs: Two halves of the same coin. We're in a world where the vast majority of people learn to use a computer through a GUI -- that's the "natural" interface for them. Yes, some of us are old enough to have started their computing life on the command line. (Some of us are probably even older and will tell stories about punch cards, switches and vacuum tubes.) For those people, Perl may be quite natural. And, yes, some of those raised on GUIs eventually learn the power of command lines, speed keys, multiple terminal windows, etc., but I suspect that is not the natural orientation for most people.

      As a result, I would hypothesize that for those who "think GUI", an IDE will seem like a more natural way to approach the task of programming. And likewise, creating a GUI application is more likely to be a meaningful accomplishment early in the learning process. (e.g. "Hello world" in a window with menus and buttons instead of "Hello world" printed to the console.)

      If that hypothesis is true, then Perl is not well positioned today to be an entry level language relative to some other languages. I'm not saying that it can't be an entry-level language, just that other languages with strong IDE/GUI support are probably better at the entry-level for those raised with the GUI to begin with.

      Concurrency: Beyond just the issue of threads and multi-core architectures is the more general use of concurrency in applications. My sense is that concurrency is a growing paradigm -- or at least that concurrency is seen as a lower-cost way to improve performance for certain classes of "hard" problems than other alternatives.

      Again, if that hypothesis is true, it's worth examining what types of concurrency Perl might be well suited for (e.g. process-level parallelization with database-backed persistence and sharing) and what types it is less suitable for (e.g. thread-level parallelization) and seeing what improvements could be made.

      Both of those ideas are aimed at the following:

      • Grow the pool of Perl developers faster by lowering real or perceived barriers to adoption
      • Grow the domain of work for which Perl is an optimal solution

      To me, both of those seem like worthy goals. So, from that perspective, kudos to the Anonymous Monk for reminding us of them.

      -xdg

      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

        A thoughtful post, but I disagree. I don't see so much "knee-jerk defense of Perl" as (healthy) skepticism about the OP's assertion of the central importance of IDEs, threading, and GUI development. Sure, all three are considered sexy by large segments of the geek population, but, at least in the problem domains where I work, they're pretty thoroughly irrelevant.

        The last time I used an IDE or had to deal with threading per se was in 2001 and I eventually abandoned the IDE (MS Visual Studio) on that project because it was getting in my way more often than it was helping. In the broader sense of concurrency that you brought up, that project was the last time I encountered something that called for anything beyond the ability to run multiple independent instances of a process or maybe occasionally fork a child to handle a large chunk of processing, then die. I don't think I've done a GUI since 1998 or 99 unless you count web pages or a trivial Perl/Tk project that I did just for the sake of seeing what it's like.

        I suppose you could call this a reflexive defense of Perl, depending on how you look at it, but I don't think that would be accurate. It's much more a statement of "You think that stuff's so important, huh? Prove it." I don't deny that IDEs and GUI tools (both GUIs for development and tools for developing GUIs) would make it easier to attract new blood (albeit with swampyankee's caveat of IDEs tending to enable 'code now, think later' work styles) and being able to trivially create pervasively-threaded code would do wonders for buzzword-compliance, but I'm not convinced that these things would do anything to truly improve the language or the community.

    Re: Slow evolution of Perl = Perl is a closed Word
    by andreas1234567 (Vicar) on Aug 31, 2007 at 12:38 UTC
      The Art of UNIX programming by Eric Raymond quotes Brian Kerninghan:
      On the other hand, the 'user-friendly' GUIs of other operating systems have their own problems. Finding the right buttons to push is like playing Adventure: the interfaces are just as burdensome as any Unix command line interface, save that one in theory can find the treasure by sufficient exploration. In Unix, one needs the manual.
      --
      Andreas
    Re: Slow evolution of Perl = Perl is a closed Word
    by Joost (Canon) on Aug 31, 2007 at 19:46 UTC
      # A good IDE, like Eclipse for Java.
      An IDE like Eclipse, which relies on static analysis is never going to be good enough for a language as dynamically typed as perl. Perl is just not that kind of language. The syntax is a relatively minor issue (and that's probably saying something).

      The only reason it works on Java at all, is because Java seems to be designed from the ground up to have the programmer make extra-double-carefully clear what (s)he expects some object to be and do anywhere that object is used (or even just glanced at).

      # Good multi-threading.
      Perl's multi-threading is still under development. IMO it's mostly useful because it enables you to use native multi-threaded libraries. I agree it can be a pain to use, though. In any case, threads aren't needed to build GUIs. You can build a perfectly good GUI system using just callbacks/events for instance.
      # Standard and rich GUI.
      Show me one portable language that has a good modern looking, standard GUI. Tcl/Tk, maybe. Java definitely does not have one. Note that even Eclipse does not use the "Standard and rich" Java GUI, because it's too damn slow and ugly.

        "An IDE like Eclipse, which relies on static analysis is never going to be good enough for a language as dynamically typed as perl..."

        As I said, Perl 5 in my opinion is impossible to be really parsed without run the code. This is way I still wait Perl 6, that is not so dependent of runtime states to define code.

        "Perl's multi-threading is still under development..."

        I know that! Is also have collaborated to it. The point is that we can’t wait more for a fine multi-threading on Perl. 5 years to develop it is just too much!

          5 years? People have been trying to get decent threading into Perl at least twice that long. Bolting threading onto the side of a language that was developed in a way that is rather antithetical to threading is an extremely ugly task. I doubt you'll ever see reasonable threading in Perl 5 because

          1. I haven't seen over that decade the will to initiate the rather fundamental rewrite that would be required
          2. Perl 6 makes such a fundamental rewrite within Perl 5 even less likely

          A decent threading model was attempted for many years and eventually abandoned as impossible and replaced by a horrid threading model that had a better hope of one day becoming stable, if no hope of ever becoming a particularly good way of doing threading.

          So the hope for decent thread support in Perl is simply Perl 6.

          - tye        

          As I said, Perl 5 in my opinion is impossible to be really parsed without run the code. This is way I still wait Perl 6, that is not so dependent of runtime states to define code.

          Perl - like many other "dynamic languages" - is just too flexible to be statically analyzed with certainty. This is not a parsing problem. LISP (which famously has "no syntax" and is completely trivial to parse) has the same issues.

          Consider this:

          my $method = "method_name"; for my $class (qw(Class1 Class2 Class3)) { my $object = $class->$method(shift (@arguments)); }
          Now consider that all the string literals in this code are just strings, and can come from anywhere else, including files, databases, user input etc.

    Re: Slow evolution of Perl = Perl is a closed Word
    by samizdat (Vicar) on Sep 01, 2007 at 12:41 UTC
      Boy... AM, you sound a lot like one of the guys I had working for me. We switched from a PHP-based *working* web system to developing in Java, on his insistence that "Enterprise apps are all done in Java now." The Java prototype is *still* in a sandbox, two years later, and I've sold out my piece of the company in disgust.

      A long time ago, I did a lot of app programming in Digitalk Smalltalk/Win. There was a really nifty add-on available called WindowBuilder that made GUI-building amazingly simple. The basic IDE had all the traditional Smalltalk inspectors and class hierarchy browsers, and it was totally fun to work with. Smalltalk syntax was a witch, and that was the only downside. Whoever thought up using two kinds of brackets for nesting parentheticals should receive a topcoat of hot tar and feathers! OTT, I was a happy camper. Until, that is, I had to go beyond the GUI and talk to hardware. Therein lies the rub. My Smalltalk system, and also Java, really was not happy venturing outside of its sandbox. I had to code '86 asm at the DOS level and load it asa TSR via batch file. Anybody else here remember the Norton Editor? ;-]

      Specifically to your points, I'd have to agree that a good IDE can really help make a GUI app elegant and easy to use, but it can't make up for deficiencies in the language and its libraries. I agree that the arcane nature of Perl5's syntax and state-driven parsing does make some of the niftier IDE features difficult, but Perl5's deep integration with UNIX makes it so much better than most other languages for a huge class of applications in systems and embedded programming. Yes, GUIs are nice, and Windiots are helpless without them, but under the GUI hood lies the heart of the program, and that's raw code. In Perl, that raw code is very concise, unlike in Java or C source.

      FInally, I think the last word has not been written on multiprocessing scheduling and development paradigms, and won't be until easy-to-use multiprocessors are commonly available and people have a chance to cook with them. We're doing something about that at D***, and I don't mean multi-core in the usual x86 sense. :)))

      Don Wilde
      "There's more than one level to any answer."
        Just one comment: Do not use JSP!

        JSP for me is not Java, and is a very bad option for Web. For web PHP and Perl are better. Or you can use GWT (Google Web Toolkit) where you still can use Java without the JSP mess.

          Like I said, I walked away from the whole mess. I have lots better things to do with my time than discussing religion with programmers, and my ex-partner's the one who gave them the go-ahead over my objections, so he gets to feel the pain of the Java boondoggle.

          Don Wilde
          "There's more than one level to any answer."
    Re: Slow evolution of Perl = Perl is a closed Word
    by erroneousBollock (Curate) on Sep 01, 2007 at 04:45 UTC
      Today a good IDE is capable to parse the code, navigate the code, show documentation texts over the code and point code errors and warnings without run the code.
      That kind of thing is usually called "static analysis" and support for it is language-dependent. Java is an extremely simple language, semantically speaking, so static analysis of Java source code is quite easy.

      The perl module PPI can parse perl quite well, so there's no good reason for an IDE to miss out.

      Existing perl5 IDE's (such as Komodo) or tag systems can navigate perl code very well so that's a non-issue.

      In Visual Studio, the VB.Net team chose to employ more static analysis (before compile-time) than the C# team because that was an expectation of incoming VB programmers... in that case the decision was not related to the difficulty in statically analyzing the source code.

      IDE's that show errors as you type are simply compiling the source code all the time as you type. Some exceptions to this include type/arity errors which can be determined by simple lookup. Re-compiling all the time slows down the IDE (and is the reason that Visual Studio does not do the same for C#).

      perl5 does not have type or arity signatures for its methods so that kind of lookup or analysis is quite meaningless.

      As for documentation, there's no reason why an IDE for perl cannot parse structured POD for a method to have it provided (in a tool-tip) in other contexts.

      Some errors are not easily detectable until run-time due to a concept known (in non-perl circles) as "late binding". Languages like Java and C#(<3.0) have no inbuilt late binding so one doesn't notice that class of error in practice, however both provide introspection/reflection API's and the same sorts of errors apply there... the IDE is no help in those cases.

      Dynamic languages in general benefit more from unit testing than from static analysis, and so IDE's with good support for unit-testing suffice in practice.

      To have a good IDE for Perl 5 is difficult, since Perl 5 has a very complex syntax, especially because Perl 5 depends of runtime states to be really parsed.
      I do not believe the later statement to be true. Can you cite credible sources for this assertion?

      To do this on Perl 5 to me is near to impossible. I was waiting for Perl 6 to resolve these syntax problems, but Perl 6 today is just a dream.
      These "problems" are not about syntax. The perl language must be parsed by a sufficiently context-aware parser. (A discussion of classes of parser is out of scope here.)

      The language features which make perl different/difficult to parse relate to expressiveness and semantics.

      There's been a conscious effort in the perl6 design team (over the last year) to reduce parser ambiguity in the perl6 grammar, solely to make parsing perl6 faster (not easier... it was easy before ;).

      At the risk of being down-voted, I think your whole rant is simplistic and ill-informed.

      -David

        To have a good IDE for Perl 5 is difficult, since Perl 5 has a very complex syntax, especially because Perl 5 depends of runtime states to be really parsed.
        I do not believe the later statement to be true. Can you cite credible sources for this assertion?

        Of course it is true. The whole reason BEGIN blocks were created was so that useing a module could force the module's run time to happen before the remainder of the useing code's compile time so that the run-time states could impact how the remaining Perl code is parsed.

        In the general case, reliably parsing Perl code that uses a module requires one to run the Perl code (and perhaps even XS code) of the used module. This is also true for BEGIN blocks not implied by use statements.

        And the PPI documentation covers quite a bit of this. So if you use PPI for implementing your IDE, then your IDE will simply not be able to handle some Perl code. For many people, the Perl code that they deal with is rarely such that PPI actually fails on it (how fully and correctly PPI parses it is surely more variable, though I haven't seen good data on this). In fact, the author of PPI reports that almost everything on CPAN (excluding some things) can be parsed as well as PPI tries to.

        But trying to pretend that the parsing problem doesn't in fact exist is just silly, IMHO.

        - tye        

          Of course it is true. The whole reason BEGIN blocks were created was so that useing a module could force the module's run time to happen before the remainder of the useing code's compile time so that the run-time states could impact how the remaining Perl code is parsed.

          In the general case, reliably parsing Perl code that uses a module requires one to run the Perl code (and perhaps even XS code) of the used module. This is also true for BEGIN blocks not implied by use statements.

          Ok, that's a reasonable explanation. Do you know whether there are any examples of this that aren't Source-Filter related issues ?

          I believe that modules which change code semantics aren't really relevant to this issue, only those which change how code is parsed for the purposes of simple static analysis.

          And the PPI documentation covers quite a bit of this. So if you use PPI for implementing your IDE, then your IDE will simply not be able to handle some Perl code. For many people, the Perl code that they deal with is rarely such that PPI actually fails on it (how fully and correctly PPI parses it is surely more variable, though I haven't seen good data on this). In fact, the author of PPI reports that almost everything on CPAN (excluding some things) can be parsed as well as PPI tries to.
          Well that's good. With the size of CPAN, that's a pretty good indicator that a PPI-based approach would be very effective for use in an IDE.

          But trying to pretend that the parsing problem doesn't in fact exist is just silly, IMHO.
          You're right, of course.

          I wonder if anything can be done (perhaps in the area of machine-readable POD) to make it easier for IDE implementors to deal with such issues.

          -David

        To have a good IDE for Perl 5 is difficult, since Perl 5 has a very complex syntax, especially because Perl 5 depends of runtime states to be really parsed.

        I do not believe the later statement to be true. Can you cite credible sources for this assertion?

        Better yet, I can give an example.

        $x = foo / bar / - 1;

        Is bar a function call, or part of a regexp? It depends on foo's prototype. If foo is an imported symbol, then running code (the exporting module's import function) is required to determine foo's prototype and therefore whether bar is part of a literal or not.

        sub foo() { ... }$x = foo() / bar() / -1;
        sub foo { ... }$x = foo(m/ bar / - 1);
    Re: Slow evolution of Perl = Perl is a closed Word
    by syphilis (Archbishop) on Aug 31, 2007 at 12:53 UTC
      Thinking about IDE devotees ... they would be termed "IDEots", n'est-ce-pas ?

      Cheers,
      Rob
      Update: Whoo ... "Reputation: -3" ... I guess, by my reasoning, that means there's at least three "IDEots" perusing this thread.

        The downvotes are probably for misspelling "n'est-ce pas". ;-)

          The downvotes are probably for misspelling "n'est-ce pas"

          Doh !!! .... and rightly so :-)

          Cheers,
          Rob
          Absolument vrai.

        It's a known fact that not a single competent, experienced, skilled programmer in the world uses an IDE, nor has used one at any point in his or her career.

        ...

        ...

        ...

        <borat>NOT!</borat>

        I agree it's a personal preference. For me, if I'm working on a project with 30 different source files, I really like being able to move to the one I want to look at next with a single click and run a build with a single keypress. If that makes me an idiot, I guess I'm an idiot.

        Update: Apparently I am thick and can't recognize a joke. In my defense, though, I have seen the "IDEs are stupid as is anyone who uses them" theme pop up here from time to time.

          It's spelled "IDEot", you idiot.

          I disagree with ChemBoy. I'm sure there are at least two reasons one would downvote syphilis:

          1. One is an "IDEot" and is offended
          2. One is an idiot and didn't "get" the joke

          Though, the most likely reason is probably that one didn't appreciate the joke, as I'm sure some won't appreciate mine either.

          - tye        

        A reply falls below the community's threshold of quality. You may see it by logging in.

        I guess, by my reasoning, that means there's at least three "IDEots" perusing this thread.

        I agree—I'm sure that everybody who has downvoted this post has done so out of defensive personal pique. No other reason seems possible.



        If God had meant us to fly, he would *never* have given us the railroads.
            --Michael Flanders

    Re: Slow evolution of Perl = Perl is a closed Word
    by ysth (Canon) on Sep 02, 2007 at 20:52 UTC
      People continually cite this "is not standard and available in any Perl installation" as a showstopper (whether it's XML parsing, GUI development, object framework, or any of several other things). I just don't buy it. Pick the tools you want and develop using them. If you can't require the libraries you need on your target system, well, that's a problem with your distribution method, not with perl.

      Not anointing the favored solution of the week into the core has kept CPAN the paradise you describe it as.

    Re: Slow evolution of Perl = Perl is a closed Word
    by hardburn (Abbot) on Aug 31, 2007 at 22:24 UTC
      • A good IDE, like Eclipse for Java.
      • Good multi-threading.
      • Standard and rich GUI.

      These are very superficial reasons against a language. IDEs are a matter of personal choice. Multi-threading is being worked on, and is of limited use for web apps anyway (even on multi-core processors). GTK2 is pretty good for GUIs and works pretty well across platforms, with a few other choices beyond that.

      If I was going to bother moving to a new primary language, it'd better offer something clearly superior to Perl. The kind of stuff that's been kicking around CS departments for a long time, but has barely registered in mainstream languages. Stuff like type inferencing or operators in RPN notation. If the language isn't going to challenge me to learn new concepts, it's hardly worth learning.


      "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

        "Multi-threading is being worked"

        Is in working progress for years! How many years we will need to wait to have a good multi-threading model on Perl? I just have waited to much!

          Is in working progress for years! How many years we will need to wait to have a good multi-threading model on Perl? I just have waited to much!
          I won't pretend that support for robust threading is well implemented in perl5... it's just not.

          However, Java's concurrency is not exactly all that.

          I'd say that Java's concurrency primitives (and the design patterns programmers build on them) are the state-of-the-art circa 1997.

          There are wonderful new ways to think about (and express in code) concurrency that are only really supported well by languages like Erlang, Haskell and Scheme (please let's not have an argument about Scheme). Java's concurrency primitives are concise, robust and orthogonal for the Java language but do not necessarily map well to languages with (encouraged) abstraction techniques based around closures and/or first-class functions.

          I (and many others) agree that perl5's support for threading needs serious work (looks like progress in Parrot/Pugs is good in that area) and that increasingly, folks will focus on concurrency as a dealbreaker, what with 4, 8 and more cores becoming the norm any-time-now.

          If you're concerned about writing good, concurrent, perl5 code today, you might try designing your code around message-passing (look at Thread::Queue) as in Erlang, as this works well in practice.

          -David

          How many years we will need to wait...

          I suppose that depends on how many more years you're willing not to contribute somehow to getting a good multi-threading model in Perl. Things don't get done unless someone does them. Sometimes that means people that want them have to take some initiative in getting them done.

    Re: Slow evolution of Perl = Perl is a closed Word
    by talexb (Chancellor) on Sep 04, 2007 at 13:50 UTC

      I'm coming to this thread late, but I have a couple of observations.

        Perl 5 is still the best language to use to process text data, but the world today needs much more resources:
        • A good IDE, like Eclipse for Java.
        • Good multi-threading.
        • Standard and rich GUI.

      I'm not sure what your thesis is. I'm an engineer, and my motto is, The right tool for the right job!

      For me, Perl turns out to be the preferred tool for most of what I do on the job. Sometimes I *could* use Perl, but a shell script is just easier. The fact that it's lighter weight is a bonus.

      Wanting to use an IDE is a developer preference. I loved Borland's Turbo C when it came out, about 20 years ago, and I used it professionally on DOS in the late 80's and early 90's. I moved to OS/2 and Presentation Manager after that, and went to an editor called KEdit. It had some IDE features like reading the error file and placing the cursor on the source file line with the syntax error.

      These days gvim is enough of a development environment for me .. if I have a syntax error, I can find it as quickly as I need to, and if I need to look up a function, I'll just open an xterm window and look it up using perldoc -f split, or even open up my copy of the Camel.

      I'm still not sure that good multi-threading is absolutely necessary -- I suspect that the number of problem domains that need this feature is small, and that this argument is a red herring.

      The whole GUI thing is just a toy. I'm happiest on a command line, and I've been using a command line for 30 years. A GUI is fine when you want to do a limited number of things. It's very frustrating when you want to be creative. For example, recently I wanted to print a bunch of Java source files, two up. How the heck do you do that with a GUI? With the shell, I just did

      ls *.java | xargs -iyy 'mpage -2 yy | lpr'
      and I was done. Yes, I had to read the man page for xargs -- I don't use it often enough -- but I knew it existed, and that it would do the right thing.

      If you're talking about development of a GUI application, I'm not sure Perl is the best platform for that -- you probably want to think about using Java for the frontend, and Perl for the backend. That way you get the best of both worlds: A flexible GUI that's portable, and terrific power in the backend where you need it.

      Alex / talexb / Toronto

      "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

        if I need to look up a function, I'll just open an xterm window and look it up using perldoc -f split
        You mean you don't like :!perldoc -f split?

        Open source softwares? Share and enjoy. Make profit from them if you can. Yet, share and enjoy!

          That's a cute way to do it, but it doesn't allow my to look at the split documentation while I update my code.

          Anyway, I use Windowmaker on a two screen system, so I have all the screen real estate that I need -- an extra xterm just showing me documentation on split just makes sense.

          Alex / talexb / Toronto

          "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

    Re: Slow evolution of Perl = Perl is a closed Word
    by erroneousBollock (Curate) on Sep 01, 2007 at 05:06 UTC
      Perl still don’t have standard solutions for Desktop GUI. We have wxPerl, that I have collaborated and is very good, portable, but is not standard and available in any Perl installation.
      This is more an indictment of the standard installation footprint of the various perl distributions (and those created by OS distribution maintainers).

      perl programmers know (or should know) that if they need a module to do something, the first place to look is CPAN; there are many GUI libraries available therein.

      I won't comment as to whether wxWindows should/shouldn't be a good default for cross-platform GUI's as that is a matter of taste.

      Also is problematic to create Desktop Applications with the bad multi-thread model of Perl 5. GUI means multi-thread,
      Java has this just about right... the two predominant GUI libraries are well written w.r.t threading expectations. Badly written GUI components (w.r.t threading) abound for the .Net platform; a platform where lean, robust threading is available.

      FACT: It's easy to write threaded code for perl5 using the message-passing paradigm.

      As for your assertion that GUI ==> threads, I'd argue that the responsibility for GUI responsiveness is at the feet of GUI library designers and that GUI code is only embarrassingly aided by threaded user code.

      Computationally-intensive code benefits far more from concurrency than do GUI systems.

      and since on Perl 5 you have to design all the code to have it on multi-thread, this is a big problem, especially when you want to use 3rd part modules.
      This comes down to two issues. Firstly, some perl modules are not thread-safe. This can be mostly worked around with scoping hacks and there has been noise about notation of CPAN to reflect thread-safety of the modules available there.

      Secondly, some C/C++ libaries (used by perl modules) are not thread-safe - the blame there shouldn't really leveled at perl.

      These problems exist for many languages, not just perl.

      -David

    Re: Slow evolution of Perl = Perl is a closed Word
    by Your Mother (Archbishop) on Sep 01, 2007 at 06:00 UTC
      Standard and rich GUI.

      Just to mention (scanning the thread I think no one has) the world wide web--and the display protocols that drive it--is the most standard and standardized GUI. Not particularly rich as is, sure, but Perl long did, and still does at times, rule the school in that arena.

      And if Perl is, isn't it?, still the best text processing language, we can say it wins by default since all programs in any language are written in text.

      I'm rubber, you're glue. No tag backs!

    Re: Slow evolution of Perl = Perl is a closed Word (NQP, parrot concurrency == Oh dear.)
    by erroneousBollock (Curate) on Sep 10, 2007 at 10:21 UTC
      Please excuse me, but I'm going to quote from two different sub-threads here, just to get my response in once place... sorry if that's confusing. Re-depth was getting rediculous so....

      RE: NQP.

      BrowserUK wrote:

      I take that to mean, that despite the context and the second half of the sentence, the "prototype" mentioned is some kind of Perl 6 language prototype, and not any kind of Parrot threading prototype.
      NQP is "just another language on top of parrot".... like TCL or basic. It's an extremely small subset of perl6 with much a stricter grammar. If I'm reading the meeting minutes correctly it serves a few purposes:
      • something a little more high-level for HLL implementors to write compilers with
      • a testing ground to ensure perl6 features map nicely onto parrot's APIs
      • a bootstrapping stage of the "perl6 compiler written in perl6".

      RE: parrot concurrency

      That leaves just the existing PPD ... is based upon the Perl 5 iThreads model;
      Are we reading the same document?

      The PDD describes internal and external (HLL) constructs required for concurrency. They mention two distinct HLL APIs: "shared everything", and "shared nothing". (They're also supporting "completely independent" threads).

      The PDD says that the schedulers will manipulate Task PMCs (which describe priorities, constraints, and keep stats?) in order to co-ordinate interpreters and interpreter pools.

      User-level PMCs will be the standard PMCs in "shared nothing"; PMCs will have their vtable replaced in "shared everything" such that (internal, ordered) locking of parameters is enforced for PMC method calls.

      It looks like they're only sharing PMCs (not small enough for hardware-level atomicity but small enough to be done efficiently)... not externs or strings of bytes. That would imply that HLL compilers organise marshalling of user-level data-structures.

      If I read it correctly, a pool of "shared everything" threads will be implemented as a pool of "shared interpreters" implemented in a lightweight manner over plain POSIX threads. Different vtable methods on the (shared) PMCs will support access to either pool-wide or thread-local PMCs.

      In the "shared nothing" model they seem to be saying that they're going to implement it on top of the "events" APIs they've marked out in an earlier PDD.

      It says that there will be thread-specific and (interpreter) pool-specific event queues and that events will be guaranteed to post in the target thread (and in the "correct" order). At this level what they describe sounds a lot like the way Erlang implements its message-passing for lightweight processes.

      [the PDD?] was written by people who had never used that model; makes no concessions to the obvious failures of the only existing implementation of that model; seeks to perpectuate all the mal-features of that model
      Well I can't speak as to the "who", but I just don't see how you get to that conclusion. The features described in the PDD are very low-level and could be used in a great many ways by HLLs (such as perl6, tcl and Python). I can't find one place where they (at parrotcode... or the perl6 design team for that matter) say that they're going (overall) for anything like iThreads; rather I see plenty of examples to the contrary.

      In the parrot concurrency PDD it says they must "support" something like iThreads for HLLs, but in reading about the APIs they're providing it seems that an iThreads-like model is only one of many possible HLL concurrency models you can build on parrot's APIs.

      As an example iThreads could be implemented by an HLL compiler writer (say for per5-on-perl6) with the "shared nothing" parrot APIs. It (like perl5's threads.pm) would need to copy non-shared data to remain API-compatible.

      That doesn't stop any HLL designer from building a myriad of other concurrency models over either (or both) of the parrot -supported concurrency models. An HLL compiler could provide POSIX-like, Erlang-like, Java-like or invent-your-own models of concurrency. IIUC it looks like a very broad-minded design.

      [concurrency?] will have to be tack-on to the Parrot single tasking architecture after the fact just as the existing implementation was.
      I also don't get that impression at all. It seems to me like they're creating a very broad set of possibilities for a variety of HLL compilers (perl6 not being special). I just can't understand how you can say that given the discussion in the PDD.

      I'm going to have a closer look at the group archives and meeting minutes to gauge the progress for myself, and to see if anyone's talking about straying from what they've talk about in the PDDs... but on the face of it, I don't see any reason to be pessimistic about it.

      I don't see why the parrot team shouldn't continue to work on parrot in an order that seems appropriate (to the parrot developers) while keeping in mind the constraints and decisions implied in the concurrency PDD. It's something that I do all the time in projects, and something which (as you mentioned) can be greatly aided by regression testing.

      perl6 concurrency:

      Now here's where I start to share your concern (but probably coming from a different tack). The perl6 concurrency DRAFT spec is at an extremely early stage of progress. One could argue (as you have) that it's extremely important to get it correct from the beginning. I don't know what steps have been taken so far by the perl6 team (as distinct from the parrot team).

      I for one am concerned about the focus on STM (but that may turn out to be a non-issue... I'll wait to see what Elizabeth et al come up with). I'd wager that there'll be many, many Perlmonks meditations and questions on perl6 concurrency as the implementation starts to fill out... I believe we'll have ample opportunity to discuss that progress at a later date.

      -David

        From the standpoint of Perl 6 (the language), we've thought about a lot of these things from the standpoint of fundamentals. What you find in the draft concurrency spec is more like a laundry list of things people would like. However, part of the reason we've not bothered much with that document is precisely because concurrency must be built into the design from the ground up, not because we're ignoring the topic. Hence, just off the top of my head, in the basic design of Perl 6 you will find various reassuring tendencies:
        • All blocks are (potentially) closures
        • Data tends to be well-typed even if the user doesn't realize it
        • Emphasis is on reentrancy via use of lexicals rather than globals
        • Most Perl 5 globals are gone or are no longer global
        • The global footprint of a Perl 6 thread can be a lot lighter than a Perl 5 interpreter
        • Globals and other strangely scoped variables must be syntactically distinguished with twigils
        • Strictness is now default, so no accidental globals
        • Mutable vs immutable data is semantically distinguished
        • Default of formal parameters is readonly
        • State variables are explicitly declared and clone as lexical variables do
        • Tied variables must be explicitly declared
        • Context lexicals encouraged over temporized globals
        • Most objects stored in opaque storage
        • Mutating methods are syntactically distinguished
        • Symbolic vs hard reference syntactically distinguished
        • Constants are known to be constant at compile time
        • Hyperops, junctions, and feeds all make specific promises about lack of interactions
        • Exceptions may easily be treated as undefined data when doing parallel operations
        • Lazy lists encourage reentrant programming
        • Patterns are reentrant so they can be used in multiple threads on different strings simultaneously
        • Grammars and other logic programs are designed to be allow multiple "in flight" hypotheses in parallel
        These bits of design all contribute to easier concurrency, but are spread out over all the existing synopses, and most of them are not explicitly labeled as "concurrency support". That is not to say that there are not still many open issues, and as you say, we'll have ample opportunity to discuss them.

        Specifically with regard to STM, while STM doesn't itself address the issue of non-reversible external operations, I think it does potentially address the issue of acquiring the locks in preparation for doing such an operation, since the locks themselves are presumably in memory. And I suspect that STM can be extended to manage anything that can be construed as "memory" as long as it has reversible characteristics.

        Anyway, in many cases I think the compiler will have enough hints to determine whether the code is reentrant and whether the data has to be shared without forcing ordinary users into a monadic lifestyle. And where the compiler is not so sure, it can likely ask the programmer politely for a few more clues. In any case, the Perl 6 language is mutable and strongly versioned, so we can hopefully fix it where it goes wrong.

          For my part, I have had no concerns about the plans for concurrency in Perl 6, at the language level, going back a very long time.

          I don't follow how STM can be used to address locking of non-reversible external operations. There seems to be a total disconnect between the requirements and operational modes of the two:

          STM is optimistic: every thread completes its modifications to shared memory without regard for what other threads might be doing, recording every read and write that it makes in a log. Instead of placing the onus on the writer to make sure it does not adversely affect other operations in progress, it is placed on the reader, who after completing an entire transaction verifies that other threads have not concurrently made changes to memory that it accessed in the past. This final operation, in which the changes of a transaction are validated and, if validation is successful, made permanent, is called a commit.

          But even if it cannot, some other mechanism can be used. Provided that other mechanism is availabe to the language from the underlying runtime.

          My concerns have been, and remain, whether Parrot will have the wherewithal to underwrite the demands and operations that Perl 6 will call upon it to make.


          Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
          "Science is about questioning the status quo. Questioning authority".
          In the absence of evidence, opinion is indistinguishable from prejudice.

        Thank you for taking my concerns seriously. As you can see, many do not.

        When I first read the PPD (18 months or so ago?), and when I was taking part in the background discussion from which it is in large part derived, 3 or 4 years ago, I too allowed myself unbridled optimism.

        Here, today, it is still not possible to start a second interpreter in parrot. And none of the code that has so far been written has been ever been tested for reentrancy. There is no visible segregation between memory that represents code and data at the VM level. There is no segrgation between local constructs and global constructs.

        Say, as the PPD does, that you are going to 'do everything', but make no provision to ensure the constraints that everything imposes upon the rest of the design, means that all of those constraints will be violated all over the code base and will only be discovered once you come to try and implement the vision.

        At that point, you are basically looking at re-writing everything; or the most likely scenario, deferring 'everything' "for now", with the promise of retrofitting it over future releases. Retro fitting threads into a mature architecture is exactly the problem, with exactly the effects that perl 5 iThreads has suffered.

        But, as the latest anonymonk denial shows, there continue to be a large percentage of persons that believe that my concerns for threading are simply because I'm 'stuck' on a broken platform; that thread is spelt F - O - R - K; that event driven architectures are a substitute for threading; and whilst that remains the case, there is little hope for effective threading on Parrot, and by extensions, those languages that run on top of it.

        But, now I am just hand-wringing, so I'll crawl back in my shell and shut up. Again.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
        Are we reading the same document?

        There is what is contained in the PPD; and there is what is contained in the source files.

        For example: Here are a couple of comment blocks drawn from the latest Parrot sources:

        Create a local copy of the PMC if necessary. (No copy is made if it is marked shared.) This includes workarounds for Parrot_clone() not doing the Right Thing with subroutines (specifically, code segments aren't preserved and it is difficult to do so as long as Parrot_clone() depends on freezing).
        Fixup a PMC to be sharable. Right now, reassigns the vtable to one owned by some master interpreter, so the PMC can be safely reused after thread death. In the future the PMC returned might be different than the one passed, e.g., if we need to reallocate the PMC in a different interpreter.

        How do you interpret those?

        My interpretation is that

        1. Parrot generated code is not reentrant. It cannot be called from a multiple threads concurrently.
        2. Parrot data structures (PMCs) are allocated on a per thread (interpreter) basis, and have to be cloned (copied by freezing and thawing) in order to be shared.

        That is, as best as I can divine, repeating all the mistakes of the Perl 5 implementation.

        To understand the fundamental (and I do not use that word lightly here) importance of reentrancy to threading, read some wisdom from people who have done it. Pay particular attention to section 12.3.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

          If you're looking for the problems of tacking on threads afterwards, you can also take a look at the Python Global Interpreter Lock (and the discussion around it). While I'm not a fan of Guido van Rossum's striving for speed for speeds sake, the discussion highlights the problems that you encounter when you don't plan for share-everything threading/lightweight threading/fibers/coroutines from the start.

          Of course, there remain the semantical problems of the global name space of Perl, especially what happens in a share-everything model with the following code:

          sub quote_string { qq{"\Q$_[0]\E"} }; sub send_to_client { my $client_socket = shift; async { print {$client_socket} quote_string($_) for @_; }; }; function send_strings_to_client { local *quote_string = sub { qq{'\Q$_[0]\E'} }; send_to_client(@_); };

          With a share-everything, it's not really clear how overwriting the globs should be handled. I would be for "overwriting (code) glob entries is discouraged" and there should/could be a strict 'thread-globs' pragma that prevents you from assigning to glob entries. This should prevent 95% of all those problems.

          I really sincerely hope this doesn't come off as sarcastic, but...

          How do you interpret those?
          Well... depends on surrounding context. :-) I've not read the source code, but I'll play anyway.

          Create a local copy of the PMC if necessary. (No copy is made if it is marked shared.) This includes workarounds for Parrot_clone() not doing the Right Thing with subroutines (specifically, code segments aren't preserved and it is difficult to do so as long as Parrot_clone() depends on freezing).

          Well on first glance that comment seems to hark back to iThreads' "copy unshared data by default" nastiness... but on second reading (without better context) they're talking about PMCs that represent user code.

          Fixup a PMC to be sharable. Right now, reassigns the vtable to one owned by some master interpreter, so the PMC can be safely reused after thread death.
          I think it's clear that this comment pertains to the "shared everything" model rather than the "shared nothing model". It also sounds like exactly what I'd do for a "shared interpreter pool" scenario in a "shared everything" model.

          In the future the PMC returned might be different than the one passed, e.g., if we need to reallocate the PMC in a different interpreter.
          I definitely cannot devine any meaning from that one... what specifically about those words gives you pause?

          In short, I definitely wouldn't interpret those comments (together or separately) to mean as you've concluded. I'd need much more context (and naturally to read the damn code) before I made any such conclusion.

          Actually, if I must interpret those comments as a whole (a silly exercise at best), I get the following:

          • Shared PMCs are never copied.
          • In the "shared everything" model, code that touches shared PMCs needs to be cloned into the offending thread.
          • They're thinking already about what's safe (or not) when considering caching of PMCs in interpreter pools.

          You see how I did that? ;) I got a completely different meaning from the same comments.

          Seriously though, it's not like there's a CMM traceability document tying specific parts of the parrot implementation to words in the TDD... the parrot development has been highly incremental, striving for specific goals at each stage. I can only go by the discussion I read in the group's threads.

          Larry (below) has put my mind at ease about perl6 wrt concurrency, so now I guess I'll just pay a bit more attention to the relevant groups to see what's really going on wrt concurrency in parrot.

          -David

    Re: Slow evolution of Perl = Perl is a closed Word
    by papidave (Pilgrim) on Sep 11, 2007 at 23:31 UTC
      Perl 5 is still the best language to use to process text data, but the world today needs much more resources:

      • A good IDE, like Eclipse for Java.
      • Good multi-threading.
      • Standard and rich GUI.
      Sadly, I must agree with those who think that the assumptions behind this statement is faulty. In particular, and at the risk of sounding ancient, I question the claim that the world "needs" these things at all:
      • An IDE may be useful to those who like it. I find that multiple xterm's and vim with syntax coloring is more than sufficient to develop some fairly elaborate applications. When you find the need to run in a debugger, IDE's become more beneficial; but I only go there rarely myself.
      • Good multithreading is probably essential on an operating system that has a heavy cost to fork/exec a new process (read: Windows or VMS), but I find that a simple pipe open or backticks gives pretty good results, for most asynchronous activities.
      • As with the prior bullet, "standard and rich GUI" might be interpreted as a good thing when working in an environment where a process needs a window to be useful, but I favor text*. And there's always Tk or HTML, if you need to generate fancy output.
      If you want them, that's marvelous, and I hope you get them. From what I can tell, these goals really aren't that far off, and don't even require Perl6 for practical benefit. I just hope they get implemented in a modest amount of system resources, so that those of us who don't want them won't need another memory upgrade just to get by.

      The opinions expressed in this post are not necessarily those of an entirely rational individual, as he suffered many years programming under the tyranny of Windows before being liberated into his current work under Linux. YMMV.

      * Update: Preference for text input methods subject to change, provided that I grow a third arm (ala Zaphod Beeblebrox) to drive the mouse.

    Log In?
    Username:
    Password:

    What's my password?
    Create A New User
    Domain Nodelet?
    Node Status?
    node history
    Node Type: perlmeditation [id://636279]
    Approved by GrandFather
    help
    Chatterbox?
    and the web crawler heard nothing...

    How do I use this?Last hourOther CB clients
    Other Users?
    Others meditating upon the Monastery: (3)
    As of 2024-03-29 07:31 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?

      No recent polls found