Choosing Perl/Python for my particular niche

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Fred Ma

    Choosing Perl/Python for my particular niche

    Hello,

    This is not a troll posting, and I've refrained from
    asking because I've seen similar threads get all
    nitter-nattery. But I really want to make a decision
    on how best to invest my time. I'm not interested on
    which language is better in *general*, just for my
    purpose. My area of research is in CAD algorithms,
    and I'm sensing the need to resort to something more
    expedient than C++, bash scripting, or sed scripting.
    What I hope to do is a bit multifaceted. What I don't
    do dabble in is web apps (though I'm not sure of the
    similarities). No XML processing or database
    interaction in what I do.

    One thing I expect to have to do is to modify design
    files. For example, there is a tool which takes ASCII
    hardware desscription language (HDL) and converts it
    to a C++ (augmented by hardware simulation library).
    The translator is freeware, so has limitations which I
    have to make up for by tweaking the HDL code. In the
    past, I've eeked out sed scripts for such tasks, but
    would appreciate a more traditional language. Since
    Perl is used alot in digital IC design, I took a stab
    at that, motivated by the simple need to convert my
    mail aliases from one mail reader to the other. It
    took a while to do, and I'm concerned at the difficulty
    level. If I did this kind of thing constantly, I
    would probably get proficient and use the power behind
    it, but it's not my main area.

    The alternative is Python, which is easier to read
    from what I've read. My concern there is that I cut
    myself off from large availability of stuff that's
    out there. For example, I use a PC-to-solaris
    viewer called VNC, and I've banged my head against the
    startup script to change it a bit for my situation.
    Likewise, the above translator uses Perl extensively
    in its operation, as well as it's building and
    installation. If I wasn't passingly familiar with
    Perl, I would have had a much harder time installing
    it. Being in the approximate area digit circuits,
    I'm concerned about being on the band wagon, if only
    to avoid reinventing things, or impediments to sharing
    things.

    An additional usage scenario is to (if reasonable)
    replace my shell scripting e.g. I just converted to
    bash from tcsh to write scripts that push a document
    through a series of filters, or simply as a wrapper
    around a tough-to-use utility e.g. pstops. A final
    example is to take a file of design information and
    do more than tweak it e.g. extract all the information
    about interconnection s between circuit building blocks,
    including which is the source block, and which are the
    destination blocks. Typically, this information will
    be read by matlab scripts and passed to my C++ code
    (I've managed to avoid writing code to parse the
    input file from C++).

    Whichever way I go, I would like to avoid the overhead
    of learning both Perl and Python. I will sculpt out some
    time in a miserly fashion to slowly get to know one. Since
    I spend most of my time exploring the algorithm in Matlab or
    C++/STL, there's only so much time to pick up higher level
    languages (it took years before I shelled out the time
    to switch from tcsh to bash). One of the things that
    makes the decision not clear is that despite Python's
    claim to a gentler learning curve and clearer code, I
    often like the expedience of sed e.g. a terse one-liner
    that can be pipelined with other shell commands. I
    also note that Perl's unweldiness only comes for big
    projects, and I don't expect to using Perl quite that
    way.

    I've seen mention of parrot and perl6, which is quite a
    ways off. I'm not sure how much that should weigh into
    my decision, since it isn't real yet.

    Thanks for any comments/suggestions.
    --
    Fred Ma
    Dept. of Electronics, Carleton University
    1125 Colonel By Drive, Ottawa, Ontario
    Canada, K1S 5B6
  • Fred Ma

    #2
    Re: Choosing Perl/Python for my particular niche

    Just wanted to add another example of stuff that
    I encounter alot of. As in many computer languages,
    various kinds of scopes are delineated by things
    like braces or begin/end statements. I often find
    it valuable to find an occurance of certain things
    (e.g. certain data declaration) within certain
    scope structures. Sed is convenient for that:

    /SomeStartPatter n/,/SomeEndPattern/{
    Do some stuff,
    including conditional branching
    }

    To avoid the hassle of writing a script file and
    filtering the input source file to an output source
    file, I often use gvim's awesome pattern matching
    and macro recording abilities. A sed script file
    can look pretty cryptic, especially when I want
    to search across physical lines (lots of conditional
    flow to append things to the hold buffer, etc..).
    For that reason, I tend to stay with quick/dirty
    practices in gvim. Crypticness (though not of the
    same variety) is one of the things that I found
    hard about ramping up on Perl, to the degree that
    I did. As I hinted earlier, a fair comparison would
    account for the fact that its power would be more
    apparent if I became adequately guru-like, but
    realistically, I will not spend enough time with
    it on a regular basis to expect that. Here again
    is a dichotomy; I appreciate the sed terseness because
    I can make a command line pipe stage out of it, but
    the same brevity in a scripting language can make for
    rough going. Maybe it's wishful thinking to expect
    one language to cover all the bases that I initially
    mentioned.

    Fred
    --
    Fred Ma
    Dept. of Electronics, Carleton University
    1125 Colonel By Drive, Ottawa, Ontario
    Canada, K1S 5B6

    Comment

    • Tassilo v. Parseval

      #3
      Re: Choosing Perl/Python for my particular niche

      Also sprach Fred Ma:
      [color=blue]
      > This is not a troll posting, and I've refrained from
      > asking because I've seen similar threads get all
      > nitter-nattery. But I really want to make a decision
      > on how best to invest my time. I'm not interested on
      > which language is better in *general*, just for my
      > purpose. My area of research is in CAD algorithms,
      > and I'm sensing the need to resort to something more
      > expedient than C++, bash scripting, or sed scripting.
      > What I hope to do is a bit multifaceted. What I don't
      > do dabble in is web apps (though I'm not sure of the
      > similarities). No XML processing or database
      > interaction in what I do.[/color]

      Who knows, though. The desire to do certain things grows with the skills
      one acquired.
      [color=blue]
      > One thing I expect to have to do is to modify design
      > files. For example, there is a tool which takes ASCII
      > hardware desscription language (HDL) and converts it
      > to a C++ (augmented by hardware simulation library).
      > The translator is freeware, so has limitations which I
      > have to make up for by tweaking the HDL code. In the
      > past, I've eeked out sed scripts for such tasks, but
      > would appreciate a more traditional language. Since
      > Perl is used alot in digital IC design, I took a stab
      > at that, motivated by the simple need to convert my
      > mail aliases from one mail reader to the other. It
      > took a while to do, and I'm concerned at the difficulty
      > level. If I did this kind of thing constantly, I
      > would probably get proficient and use the power behind
      > it, but it's not my main area.[/color]

      That sounds like a text-processing task. Perl's strengths in this area
      are well-known, so there's no need to go into that deeper. Most
      scripting languages (and that includes Python) can be used here.
      [color=blue]
      > The alternative is Python, which is easier to read
      > from what I've read. My concern there is that I cut
      > myself off from large availability of stuff that's
      > out there. For example, I use a PC-to-solaris
      > viewer called VNC, and I've banged my head against the
      > startup script to change it a bit for my situation.
      > Likewise, the above translator uses Perl extensively
      > in its operation, as well as it's building and
      > installation. If I wasn't passingly familiar with
      > Perl, I would have had a much harder time installing
      > it. Being in the approximate area digit circuits,
      > I'm concerned about being on the band wagon, if only
      > to avoid reinventing things, or impediments to sharing
      > things.[/color]

      This is a strong reason to use Perl. While it may not always be
      desirable to toe the line, here it is. The availability of tools that
      can easily be integrated into one's own work will save you a lot of
      work on the long run. I didn't know that Perl was particularly strong
      in the field of IC design. If so, good then.

      Apart from this particular case, it's generally a good thing when
      pre-written code exists that can be used. The amount of such code for
      Perl is immense (several thousand libraries) and gathered all in one
      place (the CPAN) with a unified interface to access and install them and
      a vast infrastructure built around it.

      I don't know how much or whether at all the situation for Python has
      significantly improved over the recent past. A while ago at least there
      was no such thing.
      [color=blue]
      > An additional usage scenario is to (if reasonable)
      > replace my shell scripting e.g. I just converted to
      > bash from tcsh to write scripts that push a document
      > through a series of filters, or simply as a wrapper
      > around a tough-to-use utility e.g. pstops. A final
      > example is to take a file of design information and
      > do more than tweak it e.g. extract all the information
      > about interconnection s between circuit building blocks,
      > including which is the source block, and which are the
      > destination blocks. Typically, this information will
      > be read by matlab scripts and passed to my C++ code
      > (I've managed to avoid writing code to parse the
      > input file from C++).[/color]

      As with text processing, both Python and Perl offer all the essential
      things needed for that. On a cursory glance, the score of them is tied.
      [color=blue]
      > Whichever way I go, I would like to avoid the overhead
      > of learning both Perl and Python. I will sculpt out some
      > time in a miserly fashion to slowly get to know one. Since
      > I spend most of my time exploring the algorithm in Matlab or
      > C++/STL, there's only so much time to pick up higher level
      > languages (it took years before I shelled out the time
      > to switch from tcsh to bash). One of the things that
      > makes the decision not clear is that despite Python's
      > claim to a gentler learning curve and clearer code, I
      > often like the expedience of sed e.g. a terse one-liner
      > that can be pipelined with other shell commands. I
      > also note that Perl's unweldiness only comes for big
      > projects, and I don't expect to using Perl quite that
      > way.[/color]

      Perl wins when it comes to one-liners and maybe replacing shell scripts.
      As I tend to forget the syntax of bash's scripting language easily, I've
      replaced it entirely with Perl.

      Perl's bad reputation for big projects is probably due to the variance
      of those people using Perl. One large group is sys-admins who use Perl
      in an entirely different way as compared to someone building larger
      systems. However, there are enough very large Perl projects that show
      that it can be used for that just as easily (at least as long as one
      keeps the sys-admins away from the source;-).
      [color=blue]
      > I've seen mention of parrot and perl6, which is quite a
      > ways off. I'm not sure how much that should weigh into
      > my decision, since it isn't real yet.[/color]

      It shouldn't. Perl6 is mostly yet another leap towards fitness for large
      projects. I don't think it will gain much for those more hackish tasks.
      Also, no one quite knows when Perl6 will be due.

      Tassilo
      --
      $_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_ $;//::niam/s~=)]3[))_$-3(rellac(=_$({
      pam{rekcahbus}) (rekcah{lrePbus })(lreP{rehtona bus})!JAPH!qq(r ehtona{tsuJbus# ;
      $_=reverse,s+(? <=sub).+q#q!'"q q.\t$&."'!#+sex isexiixesixeseg ;y~\n~~dddd;eva l

      Comment

      • Cameron Laird

        #4
        Re: Choosing Perl/Python for my particular niche

        In article <c43dvk$adq$1@n ets3.rz.RWTH-Aachen.DE>,
        Tassilo v. Parseval <tassilo.parsev al@post.rwth-aachen.de> wrote:[color=blue]
        >Also sprach Fred Ma:[/color]

        Comment

        • Fred Ma

          #5
          Re: Choosing Perl/Python for my particular niche

          Cameron Laird wrote:[color=blue]
          >
          > Where to begin? I'm seriously surprised that you haven't
          > mentioned Tcl, originally created to serve CAD needs, and
          > still more prevalent than either Perl or Python in CAD,[/color]

          I was under the impression (rightly or wrongly) that Tcl
          was good at interfacing to, and controlling, CAD tools.
          I was more motivated by the need to massage data, though
          they probably overlap greatly. My experience with Tcl is
          limited to using Synopsys DC shell to do unconventional
          things, like traverse my design hierarchy (originally
          in verilog) flattening and stripping out things. At the
          time, the documentation for their dcshell was more
          complete than for their Tcl version of the same. But
          it's good to know that Tcl is an option to Perl and Python,
          at least for some things.
          [color=blue]
          > from all I know. Perl is indeed present, too, although,
          > in some ways, PythonCAD <URL: http://www.pythoncad.org/ >
          > is the most interesting action in this domain. All three
          > languages have enough to recommend them, and are close
          > enough in their capabilities, that I feel comfortable ad-
          > vising you to choose the one that suits *you* best. If
          > you like thinking in Perl, choose that; you'll miss out
          > on a few Python capabilities, but you'll be as productive
          > as with any other choice.[/color]

          Good to know that at a personal level, I can run faster with
          whichever one I feel more comfortable with (though I have
          yet to explore Python for personal comfort). I was also
          trying to take into consideration the prevalence of Perl
          in digital design.

          Along this line, I should clarify that by CAD, I don't mean
          general purpose computer aided drawing. I mean software
          that helps designers in digital design, much of which is not
          graphical. In fact, my area is more combinatoric
          optimization and graph theory-ish than drawing. Sometimes,
          I forget that CAD has a much more general meaning than this.
          [color=blue]
          > Either Perl or Python is going to satisfy you for algorithmic
          > experiments much, MUCH more than Matlab or C++. Make the
          > switch, *now*.[/color]

          I'm surprised to hear that. Perhaps it's related to the
          confusion above (due to the initial generality of my
          description). My thesis research deals with evolutionary
          algorithms (EAs) for programming coarse grain reconfigurable
          logic platforms. They tend to be heavy on computation, and
          I migrated to C++ for the speedup compared to matlab.
          Matlab has been made fast for highly vectorizable
          computation, but the restrictive conditions for such speedup
          was, too restrictive. I saw some examples of genetic
          algorithms in Perl (or perhaps it was Python), but assumed
          (maybe prematurely) that it was much slower than C++. Other
          factors also contributed to this impression, including the
          fact that I augment the evolutionary search with local searh
          heuristics, giving rise to complicated control flow in the
          code. So I've used C++ for the computation engine code, and
          shell/data-massaging scripts for "glue" activity. Matlab
          I'm using because I've got alot of familiarity invested in
          its graphing capabilities (to assess data rather than
          drawing). I'm also pretty familiar with its compact
          vectorized operations, which helps for data massaging in the
          post-processing phase.
          [color=blue]
          > Either Perl or Python can adequately substitute for shell
          > in the uses you describe. They pipeline fine themselves;
          > 'fact, I'm working on an essay on how they're *better* at
          > pipelining.[/color]

          Actually, I was thinking more along the lines of pipelining
          Perl commands in a bash command pipeline, along with other
          commands. But it's good to know that they pipeline within
          their own scripts (if I understand you correctly), and for
          general shell scripting.
          [color=blue]
          > "The translater is freeware, so has limitations ...": I
          > don't understand how to read this. Has it been your
          > experience that commercial CAD packages are perfect, and
          > without limitations?[/color]

          The man page for "verilator" says this: "many limitations and
          lack of features compared to a commercial simulator". One
          of the things that prompted me to ask about Perl/Python is
          because I'm looking at making many changes throughout a
          number of files in order to accommodate the limitations.
          Regardless of limitations carried by commercial tools, these
          are the ones that I have to deal with.
          [color=blue]
          > I work with VNC a lot, too. You seem to believe that
          > there's a special relation between VNC and Perl; do I
          > have that right? That surprises me. If anything, I'd
          > say Tcl leads in that domain <URL:
          > http://www-106.ibm.com/developerwork...library/l-vnc/ >.[/color]

          I described my experience with VNC just as an example of the
          various situation in which I had to make sense of Perl
          scripts. The vncserver script is written in Perl, at least
          for TightVNC, and for older versions of RealVNC I seem to
          recall. That's the extent to which I delved into VNC, since
          my area of study (and thus the area where I spend most of my
          time) is in "CAD" algorithms, as described above. I was
          driven more by a need to expediently get a certain
          kind/level of functionality from VNC rather than the
          intention of developing it.
          [color=blue]
          > I generally favor Python over Perl; in the absence of
          > more details, I think there's mild evidence that those
          > who don't specialize in programming are happier over the
          > long term with the readability of the former. They're
          > very close, though. The one most certain advantage
          > Python boasts is a dimension that I'd think important
          > to you, although you haven't mentioned it: Python's
          > interfaces to C++ are MUCH easier to manage than Perl's.
          > Perl6 will change this. For now, though, it's FAR
          > easier to practice "dual-level programming" with Python
          > and C++. If you have a large existing library of C++
          > work, I think that tips the balance toward Python.
          > Understand, SWIG and other alternatives make Perl-to-C++
          > links possible; with Python's facilities, though,
          > including Pyrex, they're *fun*.[/color]

          That's good news, from my standpoint. I don't know what
          level of programming qualifies a person to be "specializi ng
          in programming", thus leading to more satisfaction with
          Python. I've tried to read my own C++ code after half a
          year, and have gained a new appreciation for the importance
          of readability. So I'm still fine-tuning my idea of
          adequate commenting. Since I'm working on my thesis rather
          than commercial code, I don't have large amounts of generic
          C++ library code. Just a big-ish heap of routines/functions
          for the problem that I'm investigating, as the algorithms
          that I choose to try morph.

          My impression is that you think Python would be more
          appropriate for my situation. Just wondering if you can
          comment on the merit of having lots of Perl code around. It
          seems to be prevelant in a digital design tool environment.
          It may not matter all that much to me right now, but it
          would be nice to be on the same wavelength as others if I
          find myself in a team situation. As I mentioned, there have
          already been situations where a nodding familiarity with
          Perl has helped in making use of other people's tools.
          [color=blue]
          > There's more to say; I'll be back later.[/color]

          Thanks for your comments, and looking forward to hear any
          further comments.

          Fred
          --
          Fred Ma
          Dept. of Electronics, Carleton University
          1125 Colonel By Drive, Ottawa, Ontario
          Canada, K1S 5B6

          Comment

          • Paul McGuire

            #6
            Re: Choosing Perl/Python for my particular niche

            "Fred Ma" <fma@doe.carlet on.ca> wrote in message
            news:40652B0D.7 C313F77@doe.car leton.ca...
            <snip>[color=blue]
            > One thing I expect to have to do is to modify design
            > files. For example, there is a tool which takes ASCII
            > hardware desscription language (HDL) and converts it
            > to a C++ (augmented by hardware simulation library).
            > The translator is freeware, so has limitations which I
            > have to make up for by tweaking the HDL code.[/color]

            If you eventually find yourself in the Python realm, please look into the
            pyparsing text parsing module, more information at
            http://pyparsing.sourceforge.net/. I have implemented an easily-extended
            99% Verilog parser using this module, and it may provide some shortcuts for
            you in dealing with your HDL files.

            -- Paul McGuire


            Comment

            • Roy Smith

              #7
              Re: Choosing Perl/Python for my particular niche

              Fred Ma <fma@doe.carlet on.ca> wrote:[color=blue]
              > I was under the impression (rightly or wrongly) that Tcl
              > was good at interfacing to, and controlling, CAD tools.[/color]

              Tcl is an interesting language, and well worth learning, although it
              certainly has its share of quirks.

              The product I work on has close to 20,000 lines of Tcl code doing
              network discovery via SNMP. The low-level SNMP protocol is accessed via
              hooks done in C. It's not very fast, but it's as fast as it has to be,
              and I shudder to think how many lines of C or C++ the whole system would
              have been.

              The real strengths are twofold:

              1) It's easy to learn. Even easier than Python. We take guys who are
              networking types with no programming experience and get them doing
              useful development in Tcl in just a few days.

              2) It's dead simple to embed in a C/C++ application. This is one place
              where it really outshines Python. It's literally two lines of C to get
              a Tcl interpreter up and running. It's equally trivial to extend Tcl by
              providing functions in C. Compare this to the native Python/C
              interface, boost.python, or swig, and you really appreciate the
              difference!

              For most general purpose tasks, I reach for Python first. But if I
              needed to provide a quick scripting interface to an existing C library,
              or wanted to embed some easy scriptability into a large C/C++ app, Tcl
              is what I would be looking at.

              Comment

              • Jim Keenan

                #8
                Re: Choosing Perl/Python for my particular niche

                Fred Ma <fma@doe.carlet on.ca> wrote in message news:<40652B0D. 7C313F77@doe.ca rleton.ca>...[color=blue]
                > Hello,
                >[/color]
                [snip 4 paragraphs]
                [color=blue]
                >
                > Whichever way I go, I would like to avoid the overhead
                > of learning both Perl and Python. I will sculpt out some
                > time in a miserly fashion to slowly get to know one.[/color]

                Okay. You are at Carleton University, which was the site of Yet
                Another Perl Conference::Can ada in May 2003. So you have an excellent
                pool of local Perl experts to draw upon -- and there are many more not
                far away in Montreal, Toronto and Kitchener/Waterloo. Look them up
                via http://www.pm.org/groups/north_america.html .

                Jim Keenan
                Brooklyn NY

                Comment

                • Cameron Laird

                  #9
                  Re: Choosing Perl/Python for my particular niche

                  In article <40657D14.3FBE7 E82@doe.carleto n.ca>,
                  Fred Ma <fma@doe.carlet on.ca> wrote:

                  Comment

                  • Cameron Laird

                    #10
                    Tangent on embeddability (was: Choosing Perl/Python for my particular niche)

                    In article <roy-3EDA29.08465327 032004@reader1. panix.com>,
                    Roy Smith <roy@panix.co m> wrote:

                    Comment

                    • Cameron Laird

                      #11
                      Re: Choosing Perl/Python for my particular niche

                      In article <406532F7.D56DC 671@doe.carleto n.ca>,
                      Fred Ma <fma@doe.carlet on.ca> wrote:[color=blue]
                      >Just wanted to add another example of stuff that
                      >I encounter alot of. As in many computer languages,
                      >various kinds of scopes are delineated by things
                      >like braces or begin/end statements. I often find
                      >it valuable to find an occurance of certain things
                      >(e.g. certain data declaration) within certain
                      >scope structures. Sed is convenient for that:
                      >
                      > /SomeStartPatter n/,/SomeEndPattern/{
                      > Do some stuff,
                      > including conditional branching
                      > }
                      >
                      >To avoid the hassle of writing a script file and
                      >filtering the input source file to an output source
                      >file, I often use gvim's awesome pattern matching
                      >and macro recording abilities. A sed script file
                      >can look pretty cryptic, especially when I want
                      >to search across physical lines (lots of conditional
                      >flow to append things to the hold buffer, etc..).
                      >For that reason, I tend to stay with quick/dirty
                      >practices in gvim. Crypticness (though not of the
                      >same variety) is one of the things that I found
                      >hard about ramping up on Perl, to the degree that
                      >I did. As I hinted earlier, a fair comparison would
                      >account for the fact that its power would be more
                      >apparent if I became adequately guru-like, but
                      >realisticall y, I will not spend enough time with
                      >it on a regular basis to expect that. Here again
                      >is a dichotomy; I appreciate the sed terseness because
                      >I can make a command line pipe stage out of it, but
                      >the same brevity in a scripting language can make for
                      >rough going. Maybe it's wishful thinking to expect
                      >one language to cover all the bases that I initially
                      >mentioned.[/color]

                      Comment

                      • Donn Cave

                        #12
                        Re: Choosing Perl/Python for my particular niche

                        Quoth claird@lairds.c om (Cameron Laird):
                        ....
                        | I *really* don't know how to respond to this; a
                        | sentence with "sed", "conditiona l" and "convenient "
                        | leaves me at a loss.

                        I personally find sed more frustrating than useful, for anything
                        past the common one-line application. But I know of a very
                        accomplished sed programmer for whom it's the other way around -
                        not only can he solve complex problems in sed, he once professed
                        to be baffled by the common structured-procedural languages.
                        I reckon him to be a person of extraordinary intellect, because
                        of his exceptional ability with sed, but he was pretty firmly
                        convinced that he couldn't do much with a programming language
                        like C or Python. Of course not a programmer by trade. I believe
                        he never did go on to prove himself wrong on that.

                        In my opinion, it's a matter of very deep learning about how to
                        solve problems. Most of us were introduced to programming with
                        procedural languages - BASIC, assembler, Pascal, FORTRAN and so
                        on, which for all their differences are essentially the same in
                        principle when it comes to solving a problem. We can move from
                        one of these languages to another fairly easily, but not sed -
                        what's the point of such a useless language! But here are these
                        few, mostly non-programmers, who started with sed and can do
                        amazing things with it. We see a crippling lack of features,
                        where they see spartan elegance, because at a very fundamental
                        level they get it and we don't.

                        Donn Cave, donn@drizzle.co m

                        Comment

                        • zatoichi

                          #13
                          Re: Choosing Perl/Python for my particular niche

                          Cameron Laird wrote:[color=blue]
                          > In article <40657D14.3FBE7 E82@doe.carleto n.ca>,[/color]
                          [color=blue]
                          > My current instinct is that you'll be happiest with Perl--
                          > but it's a close choice, all around. I'm most accomplished
                          > in Tcl, and would happily use it, or Perl, or Python. It
                          > seems to me, though, that it's crucial that you be able
                          > to exploit libraries that pertain to your domain, and, in
                          > particular, optimized engines for linear algebra, graph
                          > theory, and linear and mathematical programming. Tcl
                          > lacks the weight that Perl and, to an increasing extent,
                          > Python can boast in their libraries.[/color]
                          Since you happily use Perl, Python or Tcl, I have a question. How do you
                          decided which one to use? :-)

                          Robert

                          Comment

                          • Cameron Laird

                            #14
                            Fundamental differences (was: Choosing Perl/Python for my particular niche)

                            In article <1080406261.496 998@yasure>, Donn Cave <donn@drizzle.c om> wrote:

                            Comment

                            • Cameron Laird

                              #15
                              Re: Choosing Perl/Python for my particular niche

                              In article <kJCdnZOwIr75Jf jdRVn-gQ@adelphia.com >,
                              zatoichi <catcher@linuxm ail.org> wrote:[color=blue]
                              >Cameron Laird wrote:[color=green]
                              >> In article <40657D14.3FBE7 E82@doe.carleto n.ca>,[/color]
                              >[color=green]
                              >> My current instinct is that you'll be happiest with Perl--
                              >> but it's a close choice, all around. I'm most accomplished
                              >> in Tcl, and would happily use it, or Perl, or Python. It
                              >> seems to me, though, that it's crucial that you be able
                              >> to exploit libraries that pertain to your domain, and, in
                              >> particular, optimized engines for linear algebra, graph
                              >> theory, and linear and mathematical programming. Tcl
                              >> lacks the weight that Perl and, to an increasing extent,
                              >> Python can boast in their libraries.[/color]
                              >Since you happily use Perl, Python or Tcl, I have a question. How do you
                              >decided which one to use? :-)
                              >
                              >Robert[/color]

                              Most often, whatever is already at hand. It'll be interesting
                              some day to come across an organization that doesn't already
                              have a standard in place.
                              --

                              Cameron Laird <claird@phaseit .net>
                              Business: http://www.Phaseit.net

                              Comment

                              Working...