Home > Archive > PERL Miscellaneous > March 2004 > Choosing Perl/Python for my particular niche
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Choosing Perl/Python for my particular niche
|
|
| Fred Ma 2004-03-27, 11:58 pm |
| 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  ed 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 interconnections 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 2004-03-27, 11:58 pm |
| 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:
/SomeStartPattern/,/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
| |
| Tassilo v. Parseval 2004-03-27, 11:58 pm |
| Also sprach Fred Ma:
> 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.
Who knows, though. The desire to do certain things grows with the skills
one acquired.
> 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 ed 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.
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.
> 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.
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.
> 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 interconnections 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++).
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.
> 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.
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;-).
> 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.
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{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
| |
| Cameron Laird 2004-03-27, 11:58 pm |
| In article <c43dvk$adq$1@nets3.rz.RWTH-Aachen.DE>,
Tassilo v. Parseval <tassilo.parseval@post.rwth-aachen.de> wrote:
>Also sprach Fred Ma:
| |
| Fred Ma 2004-03-27, 11:58 pm |
| Cameron Laird wrote:
>
> 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,
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.
> 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.
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.
> Either Perl or Python is going to satisfy you for algorithmic
> experiments much, MUCH more than Matlab or C++. Make the
> switch, *now*.
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.
> 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.
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.
> "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?
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.
> 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/developerwor.../library/l-vnc/ >.
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.
> 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*.
That's good news, from my standpoint. I don't know what
level of programming qualifies a person to be "specializing
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.
> There's more to say; I'll be back later.
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
| |
| Paul McGuire 2004-03-27, 11:58 pm |
| "Fred Ma" <fma@doe.carleton.ca> wrote in message
news:40652B0D.7C313F77@doe.carleton.ca...
<snip>
> 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.
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
| |
| Roy Smith 2004-03-27, 11:58 pm |
| Fred Ma <fma@doe.carleton.ca> wrote:
> I was under the impression (rightly or wrongly) that Tcl
> was good at interfacing to, and controlling, CAD tools.
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.
| |
| Fred Ma 2004-03-28, 10:22 pm |
| Paul McGuire wrote:
>
> "Fred Ma" <fma@doe.carleton.ca> wrote in message
> news:40652B0D.7C313F77@doe.carleton.ca...
> <snip>
>
> 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
Hi, Paul,
I took a look at your website. I've decided to go Perl for now,
and ramp up on Python on the side. I think a parser has a higher
level of intelligence than regex'ing, but I hesitate to jump into
it at the moment because thesis time is running out. I may do some
adhoc regex'ing, either with sed/Perl/gvim (it's quick and dirty,
but suitable for the time crunch of my current circumstance, which
is a hard deadline on the thesis). Also, I'm doing the quick-and-
dirty because of limitations of an *existing* verilog parser (and
translator) which I don't want to delve into right now, for the
same reason. But thanks for the heads up. If things work out in
the long run, and I get to know Python, I know there is a verilog
parser to keep an eye out for.
Fred
| |
| Fred Ma 2004-03-28, 10:22 pm |
| Petri wrote:
>
> In article <40652B0D.7C313F77@doe.carleton.ca>, Fred Ma says...
>
> The translator, is it doing the Verilog stuff you mention later in the thread?
> Why not check if you can't replace the translator altogether with an existing
> Perl module:
> http://search.cpan.org/search?query=verilog&mode=all
>
> Well, I know nothing about your problem area, but it's a tip in case you hadn't
> thought about checking CPAN.
>
> Petri
Actually, I was spending much of last w installing many
of those tools! The translater (verilator) is Perl-based,
written by Wilson Snyder (author of many of those tools)
and relies on many of those tools. But thanks for the tip...
Fred
| |
| Fred Ma 2004-03-28, 10:22 pm |
| Jim Keenan wrote:
>
> You are at Carleton University, which was the site of Yet
> Another Perl Conference::Canada 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 .
Thanks for the pointer, Jim.
Fred
| |
| Ville Vainio 2004-03-28, 10:22 pm |
| >>>>> "Cameron" == Cameron Laird <claird@lairds.com> writes:
[color=darkred]
Cameron> Most often, whatever is already at hand. It'll be
Cameron> interesting some day to come across an organization that
Cameron> doesn't already have a standard in place.
Many organizations don't, esp. if the actual product they produce is
not written in either of the languages. Some code may exist, but there
is no "official" standard. And if there is, there is a good
possibility of changing it if you are able to demonstrate clear
technical superiority in skunkworks projects. And w/ Python, you
are. Been there, done that :-).
--
Ville Vainio http://tinyurl.com/2prnb
| |
| Charlton Wilbur 2004-03-29, 3:33 am |
| >>>>> "CL" == Cameron Laird <claird@lairds.com> writes:
CL> Try 'em both briefly, choose one that makes a
CL> good impression, and get back to your engineering work.
CL> You'll be glad you upgraded to a 'P' language.
You, sir, have written a clear, fair-minded, and reasonable post. The
Backbone Cabal will be revoking your Usenet license shortly.
(I concur, by the way: Python has a couple of traits that would drive
me, with close to 10 years of Perl experience, bonkers; but they don't
drive everyone bonkers, and they obviously suit some people, or they
wouldn't be in the language. The OP ought to spend a couple ws
playing with each language and pick the one that seems to suit his
style better.)
Charlton
--
cwilbur at chromatico dot net
cwilbur at mac dot com
| |
|
| In article <40661C14.8365E058@doe.carleton.ca>,
Fred Ma <fma@doe.carleton.ca> wrote:
>
>On the topic of speed, It's surprising to hear that this can be
>possibly rivaled by Perl/Python, considering that even my matlab code
>is about 10x slower than C++. That's with extensive profiling and
>round-about coding styles to exploit vectorization tricks, and no such
>effort in the C++ code.
The reason people say this is because algorithmic experimentation is
cheap in Python/Perl. An O(NlogN) algorithm in Python/Perl will lose to
an O(N^2) algorithm in C/C++ with a few elements, but as the data set
grows, the O(NlogN) algorithm will pull ahead.
--
Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/
"usenet imitates usenet" --Darkhawk
| |
| Fred Ma 2004-03-29, 8:36 pm |
| Aahz wrote:
>
> In article <40661C14.8365E058@doe.carleton.ca>,
> Fred Ma <fma@doe.carleton.ca> wrote:
>
> The reason people say this is because algorithmic experimentation is
> cheap in Python/Perl. An O(NlogN) algorithm in Python/Perl will lose to
> an O(N^2) algorithm in C/C++ with a few elements, but as the data set
> grows, the O(NlogN) algorithm will pull ahead.
The STL library brings in some efficiently implemented algorithms
to the C++ world instead of having programmings roll their own code.
The problem I saw with matlab was the overhead in between calling
such algorithms. For example, all the individual built-in's work
fast, but the moment you call your own function, you lose all the
speed that was painfully obtained by carefully crafted code. In
fact, if you rely on loops containing complex control flow, it
hinders matlab's acceleration technology (which vectorizes loop
operations). Same with many operators. In another response, I
mentioned that to ensure that one wouldn't run into similar
difficulties with Perl/Python would require a real-sized
application to be implemented and tested, with all the features
such as overhead between function calls -- a nontrivial task. So
that's put off as a possibility until after graduation, since
there's more than enough to try to achieve before then.
Anectdotal accounts are welcome, of course. Meantime, I'm
looking at Perl/Python for mulching design data to feed various
apps (notably, my algorithms, or to adequately change verilog
files to accommodate limitations in a tool like verilator, as
an example).
Fred
--
Fred Ma
Dept. of Electronics, Carleton University
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6
| |
| Fred Ma 2004-03-29, 8:36 pm |
| Charlton Wilbur wrote:
>
>
> CL> Try 'em both briefly, choose one that makes a
> CL> good impression, and get back to your engineering work.
> CL> You'll be glad you upgraded to a 'P' language.
>
> You, sir, have written a clear, fair-minded, and reasonable post. The
> Backbone Cabal will be revoking your Usenet license shortly.
>
> (I concur, by the way: Python has a couple of traits that would drive
> me, with close to 10 years of Perl experience, bonkers; but they don't
> drive everyone bonkers, and they obviously suit some people, or they
> wouldn't be in the language. The OP ought to spend a couple ws
> playing with each language and pick the one that seems to suit his
> style better.)
Well, it looks like trying them both out in the long term is in fact
what I'll be doing. Thanks.
Fred
--
Fred Ma
Dept. of Electronics, Carleton University
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6
| |
| Peter Hickman 2004-03-30, 4:42 am |
| Fred Ma wrote:
> 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.
Both perl and python will allow you to do this. in perl
#!/usr/bin/perl
while(<> ) { print uc $_; }
this script will read from stdin and write an uppercased version of the
input to stdout and can be used in a pipeline.
You can to the same in python and of course the guts of the loop can be
as big or small as you like. There is also a s2p tool that converts sed
scripts into perl, but rewiting would be a better bet as s2p can produce
some crufty code.
To be honest you could just flip a coin and go with that if you have no
specific requirements.
Perl may be easier to sell to your boss than python but if you just went
ahead with it you could use anything.
| |
| Robin Munn 2004-03-30, 1:36 pm |
| Fred Ma <fma@doe.carleton.ca> wrote:
> Hello,
>
> This is not a troll posting, and I've refrained from
> asking because I've seen similar threads get all
> nitter-nattery.
[snip: poster is basically asking "Should I learn Perl or Python?"]
While availability of libraries for your specific tasks is a major
factor to take into consideration, I'd say that even more important is
to figure out which language fits your brain.
I first learned Perl, then Python. I now use Python almost exclusively,
because I found that Python fits my mental "map" much better than Perl
does. To me, it seemed like in Perl, everything was a string. Sure, you
could have objects and classes, but they felt strange and awkward -- how
do I translate the "bless" keyword into my mental model? Whereas
Python's object model translated perfectly into my mental map, to the
point where programming in Python gave a clarity that I never had when
using Perl. It's hard to explain why, exactly -- it just seemed like
when using Perl, I was always going back down to the level of details,
the trees in the forest. Python allows me to look at the entire forest.
I can still go down and look at trees if I need to, but I don't have to
operate in that mode all the time.
Your mileage *will* vary. There's no substitute for experience. Set
yourself a simple task (say, writing a sieve of Eratosthenes program)
that you could do in about an hour with a language you're familiar with.
Then write the same program in Perl and in Python, and see which one
fits *your* brain better.
--
Robin Munn
rmunn@pobox.com
| |
| Fred Ma 2004-03-30, 6:36 pm |
| Peter Hickman wrote:
>
> Fred Ma wrote:
>
> Both perl and python will allow you to do this. in perl
>
> #!/usr/bin/perl
> while(<> ) { print uc $_; }
>
> this script will read from stdin and write an uppercased version of the
> input to stdout and can be used in a pipeline.
>
> You can to the same in python and of course the guts of the loop can be
> as big or small as you like. There is also a s2p tool that converts sed
> scripts into perl, but rewiting would be a better bet as s2p can produce
> some crufty code.
>
> To be honest you could just flip a coin and go with that if you have no
> specific requirements.
>
> Perl may be easier to sell to your boss than python but if you just went
> ahead with it you could use anything.
Hi, Peter,
My boss is my thesis supervisor. I'm going with Perl and keeping a
tab on Python. I expect to do most of my hacking in Perl, since I
see it around everywhere, composing in Python, and one-liners in
Perl/sed. About invoking Perl as part of a simple command in a
pipeline, I mean that one doesn't even have to write a script for it,
similar to sed
Command1 | sed -e Expression1 -e Expression2 ... | Command_N
This might also be possible in Python, in which case so much the better.
I'll find out (or someone might answer in a follow-up post). Thanks
for your view on the two.
Fred
--
Fred Ma
Dept. of Electronics, Carleton University
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6
| |
| Fred Ma 2004-03-30, 6:36 pm |
| Robin Munn wrote:
>
> Fred Ma <fma@doe.carleton.ca> wrote:
> [snip: poster is basically asking "Should I learn Perl or Python?"]
>
> While availability of libraries for your specific tasks is a major
> factor to take into consideration, I'd say that even more important is
> to figure out which language fits your brain.
>
> I first learned Perl, then Python. I now use Python almost exclusively,
> because I found that Python fits my mental "map" much better than Perl
> does. To me, it seemed like in Perl, everything was a string. Sure, you
> could have objects and classes, but they felt strange and awkward -- how
> do I translate the "bless" keyword into my mental model? Whereas
> Python's object model translated perfectly into my mental map, to the
> point where programming in Python gave a clarity that I never had when
> using Perl. It's hard to explain why, exactly -- it just seemed like
> when using Perl, I was always going back down to the level of details,
> the trees in the forest. Python allows me to look at the entire forest.
> I can still go down and look at trees if I need to, but I don't have to
> operate in that mode all the time.
>
> Your mileage *will* vary. There's no substitute for experience. Set
> yourself a simple task (say, writing a sieve of Eratosthenes program)
> that you could do in about an hour with a language you're familiar with.
> Then write the same program in Perl and in Python, and see which one
> fits *your* brain better.
Well, my bout with Perl took much, much more than an hour.
It worked, though. It's probably not enough experience to
get a good look at the strength of Perl. For example, I
am a vim user (an editor), which is cryptic at first, but
let's you fly when you get to know it. I'm not saying that
all things cryptic are efficient in the end, just that a
brief bout won't always uncover the strengths. As a
"working model", I've decided to use Perl as the workhorse,
and keep tabs on Python as time permits. If my mental map
works better with Python, it's ease of ramping up will
allow the better fit to shine through despite the lesser
time I spend with it. Then it will naturally take a more
prominent role. Thanks for the advice on checking out both.
It seems to be the most realistic, and in line with what
many have suggested.
Fred
--
Fred Ma
Dept. of Electronics, Carleton University
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6
| |
| Cameron Laird 2004-03-31, 10:40 am |
| In article <4069F371.B4D08F58@doe.carleton.ca>,
Fred Ma <fma@doe.carleton.ca> wrote:
|
|
|
|
|