Choosing Perl/Python for my particular niche

[Fred Ma]

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 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]

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]

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 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.
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$&."'!#+sexisexi ixesixeseg;y~\n~~dddd;eval

[Cameron Laird]

In article <c4**********@nets3.rz.RWTH-Aachen.DE>,
Tassilo v. Parseval <ta**************@post.rwth-aachen.de> wrote:

Also sprach Fred Ma:

[Fred Ma]

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/developerwork...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]

"Fred Ma" <fm*@doe.carleton.ca> wrote in message
news:40***************@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]

Fred Ma <fm*@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.

[Jim Keenan]

Fred Ma <fm*@doe.carleton.ca> wrote in message news:<40***************@doe.carleton.ca>...

Hello,
[snip 4 paragraphs]

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.

Okay. 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 .

Jim Keenan
Brooklyn NY

[Cameron Laird]

In article <40***************@doe.carleton.ca>,
Fred Ma <fm*@doe.carleton.ca> wrote:

[Cameron Laird]

In article <ro***********************@reader1.panix.com>,
Roy Smith <ro*@panix.com> wrote:

[Cameron Laird]

In article <40***************@doe.carleton.ca>,
Fred Ma <fm*@doe.carleton.ca> wrote:

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.

[Donn Cave]

Quoth cl****@lairds.com (Cameron Laird):
....
| I *really* don't know how to respond to this; a
| sentence with "sed", "conditional" 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, do**@drizzle.com

[zatoichi]

Cameron Laird wrote:

In article <40***************@doe.carleton.ca>, 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.

Since you happily use Perl, Python or Tcl, I have a question. How do you
decided which one to use? :-)

Robert

[Cameron Laird]

In article <1080406261.496998@yasure>, Donn Cave <do**@drizzle.com> wrote:

[Cameron Laird]

In article <kJ********************@adelphia.com>,
zatoichi <ca*****@linuxmail.org> wrote:

Cameron Laird wrote:

In article <40***************@doe.carleton.ca>,

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.

Since you happily use Perl, Python or Tcl, I have a question. How do you
decided which one to use? :-)

Robert

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 <cl****@phaseit.net>
Business: http://www.Phaseit.net

[Tassilo v. Parseval]

Also sprach Cameron Laird:

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*.

When it comes to embedding C/C++ into Perl, SWIG is the last thing that
I'd recommend. It may be capable of transforming such a library into a
Perl module on its own with no user intervention. However, C/C++ doesn't
map particularly well onto Perl from an interface point-of-view: A 1:1
translation of a C++ API doesn't look particularly good.

Those things should be done manually. How much work this is depends on
the library. Some only require a few lines of XS. XS' learning curve is
admittedly a bit steep. Not because it is difficult in itself but rather
because the documentation leaves a few things to be desired. There are
some actions on completing perlxstut.pod on its way right now, though.

There is also Inline::CPP, although I don't think it is as mature as
Inline::C. And since you have mentioned Tcl, even that can be inlined
with the help of Inline::Tcl.

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$&."'!#+sexisexi ixesixeseg;y~\n~~dddd;eval

[Cameron Laird]

In article <c4**********@nets3.rz.RWTH-Aachen.DE>,
Tassilo v. Parseval <ta**************@post.rwth-aachen.de> wrote:

[Fred Ma]

"Tassilo v. Parseval" wrote:

Also sprach Fred Ma:

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.

You might be right. Some digital CAD data is stored in XML.
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.
SNIP
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.

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.

Thanks for the commentary on Perl, for clarifying the source of unweldiness in
big Perl projects, as well as its nonuniversality.

Fred

[Petri]

In article <40***************@doe.carleton.ca>, Fred Ma says...

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.

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

[Paddy McCarthy]

Hi Fred,
If there are particular C/C++ packages of algorithms that you use then
you might try searching for the package name +python on the web. You
might find someone who has already turned the library into aPython
module.

There are several Scientific libraries for Python that have good
graphing capabilities as well as speed advantages for certain
operations. - Try installing the Enthought Python distribution for
windows at: http://www.enthought.com/python/

Another good page is ScriptEDA:
http://www-cad.eecs.berkeley.edu/~pinhong/scriptEDA/ - I was using the
gate-level verilog parser a month ago.

On Scripting language choice, I find TCL to be in many EDA tools, but
its datastructures and syntax make it a language I use when I have
to, rather than a language of choice.

Perl IS used a lot in EDA but I like to think of it as being dangerous
in a lot of hands as great Engineers start scripting larger and larger
applications in Perl and usually end up with something that is hard to
maintain and hard to write. Perl does have its sweet spot - I do like
the `perl -p -i -e` mewthod of making sed like alterations to files
in-place, butthe languages support for subroutine arguments - compared
to Pythons; and the need to compute and pass around references to
lists and hashes for simple nested datastructures - things like that
shout small programs only to me.

Python is my language of choice for a large amount of programming in
the EDA field (when given the choince :-).

Perl has a large library, Python has a large library - what you need
to do is do some web searches for libraries in your field to see which
is more appropriate -

When I have to write an algorithm from scratch then I do it in Python.
It does get out of the way and allow me to concentrate on the
algorithm most of the time. (Although I wish it had constrained random
generation of integers like Vera or Specman :-).

I hope I've helped, Paddy.

[Cameron Laird]

In article <40***************@doe.carleton.ca>,
Fred Ma <fm*@doe.carleton.ca> wrote:

[Fred Ma]

Hi, Paddy,

Wow, there's more information coming in than I expected. Having
a bit of a nonengineering day (at least not at the ground level)
keeping up. I did ask for it.

Paddy McCarthy wrote:

Hi Fred,
If there are particular C/C++ packages of algorithms that you use then
you might try searching for the package name +python on the web. You
might find someone who has already turned the library into aPython
module.
Actually, verilator (does verilog to SystemC, which is a C++ library
that provides HDL simulation capability) is a Perl-based module.

As for the glue functionality I need to modify the my original verilog
source, there's no specific functionality. I'm still trying to think
of ways in which to modify to code to work around the translation
limitations of verilator. So the filter will be very much ad-hoc.
There are several Scientific libraries for Python that have good
graphing capabilities as well as speed advantages for certain
operations. - Try installing the Enthought Python distribution for
windows at: http://www.enthought.com/python/

Another good page is ScriptEDA:
http://www-cad.eecs.berkeley.edu/~pinhong/scriptEDA/ - I was using the
gate-level verilog parser a month ago.
Wow. The screen shots on for enthought are impressive. The software at
scriptEDA reminds me that I'm an a newbie in this area. The level to
which interfacing environments and languages have been brought boggles
the mind. I think that I need to take a bite of Perl and/or Python
before I even consider looking at the offerings there with any degree
of appreciation. For the computation engine and post-process/graphing,
I'll stick with C++/matlab for now, due to lack of thesis time, and
because I've got a familiar system (or "idiom"?) setup to use them
together. As I mentioned in another post, I'll start with Perl as
the starting point, and keep tabs on Python, something that is feasible
because of its readability.
On Scripting language choice, I find TCL to be in many EDA tools, but
its datastructures and syntax make it a language I use when I have
to, rather than a language of choice.

Perl IS used a lot in EDA but I like to think of it as being dangerous
in a lot of hands as great Engineers start scripting larger and larger
applications in Perl and usually end up with something that is hard to
maintain and hard to write. Perl does have its sweet spot - I do like
the `perl -p -i -e` mewthod of making sed like alterations to files
in-place, butthe languages support for subroutine arguments - compared
to Pythons; and the need to compute and pass around references to
lists and hashes for simple nested datastructures - things like that
shout small programs only to me.
I got the same impression, but there have been other explanations given
in this thread for the unweldiness of big projects, as well as the fact
that this is not universal. Myself, I will be using "P..." for glue
functionality, so I won't run the risk of creating dangerously
unmaintainable code (finger crossed here). Besides, it's for the thesis,
which has to be finished soon, so I won't have the problem of looking
back a ways to figure out code written long ago. By the time I get to
an industrial situation (fingers crossed, since jobs are leaving North
America), I hope to have a bit for breathing time to ramp up on Python.
Python is my language of choice for a large amount of programming in
the EDA field (when given the choince :-).

Perl has a large library, Python has a large library - what you need
to do is do some web searches for libraries in your field to see which
is more appropriate -
Well...I did it...verilog to SystemC boils down to verilator unless one
has money to shell out. Despite its professed limitations, I am still
astounded to read even the help pages. That degree of sophistication,
for free. Kind of makes the thesis look like small time, though of
course, the challenges are of a different nature.
When I have to write an algorithm from scratch then I do it in Python.
It does get out of the way and allow me to concentrate on the
algorithm most of the time. (Although I wish it had constrained random
generation of integers like Vera or Specman :-).

I hope I've helped, Paddy.

A great deal. Thanks.

Fred

[Fred Ma]

Cameron Laird wrote:

In article <ro***********************@reader1.panix.com>,
Roy Smith <ro*@panix.com> wrote:
.
.
.

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.

Me, too, to a large extent. I think you overstate Tcl's
advantage, though, Roy, in a couple of ways. First, I
agree that Tcl is objectively easier and more reliable
in embedding; Python still has blemishes in ease-of-use
and portability in this role. It can be hard getting
all of Python embedded correctly, especially, in my ex-
perience, when working on multiple platforms.

However, Tcl has historically been so easy that it hasn't
bothered documenting the process. Python has a definitive
(if aging) embedding manual that I regard as more inviting
than what Tcl offers.

Also, ctypes, Boost and Pyrex *are* successful, and appear
to me progressing faster than any of their Tcl cousins.

Yet another way to look at the comparison is that a sig-
nificant number of people rely on SWIG, and, to them,
Tcl and Python are indistinguishable.

Follow-ups narrowed. Most of Perl's response to all of
this is, "Wait 'til 6!"

Thanks, Roy & Cameron, for the glimpse into TCL. I had just
a passing bout with it in trying to use Synopsys's TCL based
shell. It was far too brief to be a fair assessment, since
the documentation wasn't quite up to it, and I fell back to
their conventional shell (which itself was suppose to be
a brief detour to get some design information mulched out
from some verilog files). Certainly didn't get to the level
of using it to interface to C libraries. For the most part,
however, I'll be using "P..." for data conversion rather
than coordination of different library routines. I've got
a pretty good template worked out with matlab on top and
C++ on the bottom. I'll probably stick with this model until
I graduate. I'm looking at "P..." to help with converting
design information from verilog to SystemC (C++ library for
digital hardware simulation) so that I can use it in the
matlab/C++ model, but it won't be part of the main line of
computation.

Fred

[Fred Ma]

Paul McGuire wrote:

"Fred Ma" <fm*@doe.carleton.ca> wrote in message
news:40***************@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

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]

Petri wrote:

In article <40***************@doe.carleton.ca>, Fred Ma says...

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.

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 week 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]

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

[Fred Ma]

Paul Prescod wrote:

Neither Pyrex nor Inline::C are going to be great for C++. They were
both created by C programmers for C programmers (I'd like to see this
change about Pyrex some day). BOOST::Python, on the other hand, is
probably a good fit.

I just checked out Boost (visited there before based on a pointer
by Scott Meyers, author of a book on the STL). I wasn't quite
prepared to put the time into getting to know libraries at
that time, and I really needed to get to know basic standard
C++ library before delving into expansions of them, but the
example for the python interface looks very cool. My current
use of a "P..." type scripting language, though, wouldn't be to
replace my matlab wrapper around C++ (the main engine until I
graduate). It would be to mulch data to get it in a palatable
form for the engine code. It's good to know about the python
interface, though, for future investigation. Thanks.

Fred

[Michele Simionato]

cl****@lairds.com (Cameron Laird) wrote in message news:<10*************@corp.supernews.com>...

Some scientists are very successful with "slash-and-burn"
techniques. That manifests itself in this area as "con-
science-free" coding: they write whatever programs get
them the results they're after, and don't care that no
one else can reproduce their results, nor can they them-
selves, six months later. A LOT of that goes on.

It makes me uncomfortable. A lesson I've learned over
and over is that computer programs live far longer than
you expect. It pays to do 'em better at the beginning,
'cause you're likely to live with them quite a while.

I'm not a successful scientist, though; odds are long
against me ever being one.

The relation between programming and science is rather complex.
There are still lots of sciences where the programming part is
very minor and the "slash-and-burn" technique is the right thing
to do. For instance, I have worked with very successful scientists
using "slash-and-burn". Their requirements were the following:

1. we want to spend at most 5% of our time doing coding and 95% doing
science;
2. our group is composed by two persons and our code will never be
released;
3. if a Ph. D. student reach the group and has to study the code, we
will explain it to him in person;
4. the largest program we will ever write is a thousand lines long;
for the rest we will use standard routines and write as little code
as possible;
5. we don't care at all about fancy graphics: the output will be a list
of numbers write on a file and displayed by gnuplot;
6. all we care is numerical performance in floating point computations;
the logic of the program will be trivial.

They actually used old fashioned Fortran 77 and I think they made the perfect
choice given their requirements; they essentially had to do numerical
integrations and solving differential equations, tasks were Fortran is
incredibly strong. Other persons I know doing particle Physics and doing a
good deal of programming (good deal means something like 50% of their time
spent on programming; spending more than 50% means that you are actually
a programmer, and scientists don't want to do that) were using a mixture
of Fortran and C. Here I am referring to people doing numerically
intensive tasks; I have seen a trend to switch to C++ for large projects,
since there is a perception than C++ scales better than Fortran. In
any case, the core routines are still in Fortran and always will be.
For scripting tasks, scripting languages are used; I know a few
astronomers who were using Perl to control the telescope movement.
Many physicists/astronomers use Python too. Specialized languages
and tools (Mathematica, Maple, Matlab, Octave, Yorick, etc. etc.)
have their place.

Finally, it may be weird in XXI century, but there are still scientists
not doing programming. For instance, the only programming language I used
for my scientific research was Latex, to write the papers; my reseach tools
were paper and pencil and blackboard, which are still as effective as
ever.

Michele Simionato

[Ville Vainio]

>>>>> "Cameron" == Cameron Laird <cl****@lairds.com> writes:

Since you happily use Perl, Python or Tcl, I have a
question. How do you decided which one to use? :-)

Robert

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

[Max M]

Fred Ma wrote:

I took a look at your website. I've decided to go Perl for now,
and ramp up on Python on the side.

That's fine. Good luck. Many of us have tried it.

Just remember, that when you have been swimming under the dark cold
waters of Perl for a few weeks, you can allways swim up to the surface
and gasp a few fresh breaths of python.

You will then find that those few breaths will take you as far as the
previuos weeks did.
;-)

regards Max M

[Fred Ma]

Michele Simionato wrote:

1. we want to spend at most 5% of our time doing coding and 95% doing
science;
2. our group is composed by two persons and our code will never be
released;
3. if a Ph. D. student reach the group and has to study the code, we
will explain it to him in person;
4. the largest program we will ever write is a thousand lines long;
for the rest we will use standard routines and write as little code
as possible;
5. we don't care at all about fancy graphics: the output will be a list
of numbers write on a file and displayed by gnuplot;
6. all we care is numerical performance in floating point computations;
the logic of the program will be trivial.

They actually used old fashioned Fortran 77 and I think they made the perfect
choice given their requirements; they essentially had to do numerical
integrations and solving differential equations, tasks were Fortran is
incredibly strong. Other persons I know doing particle Physics and doing a
good deal of programming (good deal means something like 50% of their time
spent on programming; spending more than 50% means that you are actually
a programmer, and scientists don't want to do that) were using a mixture
of Fortran and C. Here I am referring to people doing numerically
intensive tasks; I have seen a trend to switch to C++ for large projects,
since there is a perception than C++ scales better than Fortran. In
any case, the core routines are still in Fortran and always will be.
For scripting tasks, scripting languages are used; I know a few
astronomers who were using Perl to control the telescope movement.
Many physicists/astronomers use Python too. Specialized languages
and tools (Mathematica, Maple, Matlab, Octave, Yorick, etc. etc.)
have their place.

I want to start by emphasizing that I don't disagree with you.
I've spent a great deal of a previous degree in solution
methods for couple PDEs, as well as problem formulations that
come up with PDEs. I know of the tools that you mentioned.

I would like to point out that many science problem are not
as much numerically based. Many of them can be regarded still
as "physically" based science. For example, physical design
phase of digital circuit design relies on optimization
algorithms, albeit applied to a specialized class of problems.
There are genetic algorithms that evolve neural nets for
various applications (many of them physically based). These
less numerical applications use more abstraction in computational
models, so C++ has a place for these.

Of course, it is arguable that the computation models and
methods are a separate thing from the physical problems
that motivate them. So it all depends on how each person
interprets "science".

Fred

[Charlton Wilbur]

>>>>> "CL" == Cameron Laird <cl****@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 weeks
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

[Fred Ma]

Charlton Wilbur wrote:

>> "CL" == Cameron Laird <cl****@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 weeks
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]

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]

Fred Ma <fm*@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
rm***@pobox.com

[Fred Ma]

Peter Hickman wrote:

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.

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]

Robin Munn wrote:

Fred Ma <fm*@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.

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

[U-CDK_CHARLES\\Charles]

On 30 Mar 2004 22:23:50 GMT, Fred Ma <fm*@doe.carleton.ca> wrote:

Robin Munn wrote:

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.

Well, here's two cents American, leaving the exchange calculation as an
excercise for the reader.

My first task at my last job was to automate a test that could run from
the Solaris prompt. Knowing C, I tried to script it in csh, which
proved difficult--redirecting stderr was needlessly convoluted.

Then I read "csh scripting considered evil" and decided to give the
Bourne shell a whirl. Though the syntax had a learning curve, once I
cracked that nut, the project "Just Worked."

Being a C programmer (embedded systems mostly) it was "Easy" to learn to
use Python as "C without the compile"

It took some playing before I realized the strength of Python as a
prototyping language and stopped trying to write C code in Python.

Of course, NOW I'm trying to learn how NOT to write C++ code in
VisualBasic, so go fig.

[Cameron Laird]

In article <40***************@doe.carleton.ca>,
Fred Ma <fm*@doe.carleton.ca> wrote:

[Cameron Laird]

In article <40***************@doe.carleton.ca>,
Fred Ma <fm*@doe.carleton.ca> wrote:

[Fred Ma]

Cameron Laird wrote:

In article <40***************@doe.carleton.ca>,
Fred Ma <fm*@doe.carleton.ca> wrote:
.
.
.

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

.
.
.
# python -c "print 3 + 5"
8

I was 99.99% sure that it was possible (heck, if tcsh and bash can do
it, python surely can). It's a little easier to squish it into a simple
command in a pipeline for a terse/compact "language" e.g. sed. On a
side-note, I've abused sed before by embedded sed scripts into bash
scripts without actually writing the sed script:

Bash_Command | \
sed \
-e 'Expression1' \
-e 'Expression2' \
-e 'Conditional1 {' \
-e 'Body_of_Conditional1' \
-e 'More_of_Body' \
-e '}' \
| More_Bash_Commands

Not that I want to do everything in sed, of course. And for
perl/python, there is probably not much reason to mix commands
with bash, since (unlike sed) they have the shell functionality.

I've put in a request to my sysadmin to install python. The
way to get hooked on it is to start small, with mundane tasks
(same as with any new shell, I suppose). If it doesn't get
installed due to lack of priority, I can always get it
bundled with my next cygwin update. Cygwin is an absolute
blessing. Everything comes prebuilt (lots of stuff) and
you have superuser priveleges, as well as simultaneous
access to Windows. Just as long as your HDD isn't FAT
(that prevents chmod from working).

But I digress.....

Fred

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

[Cameron Laird]

In article <40**************@doe.carleton.ca>,
Fred Ma <fm*@doe.carleton.ca> wrote:

[Fred Ma]

Cameron Laird wrote:

I've put in a request to my sysadmin to install python. The
way to get hooked on it is to start small, with mundane tasks
(same as with any new shell, I suppose). If it doesn't get
installed due to lack of priority, I can always get it
bundled with my next cygwin update. Cygwin is an absolute
blessing. Everything comes prebuilt (lots of stuff) and
you have superuser priveleges, as well as simultaneous
access to Windows. Just as long as your HDD isn't FAT
(that prevents chmod from working).

Oh! Apparently Win* is the platform of interest; that
hadn't occurred to me.

There's a LOT to say specifically on the topic of Python-
for-Windows-system-administration. You might want to
start with Mark Hammond's book.

I'm no great fan of CYGWIN for my own use, although I
certainly recognize it's been historically important.
It occurs to me that perhaps we haven't made adequately
clear how easy it is to install native Python on Windows.
It should take less time doing it than talking about do-
ing it. I'm not arguing with your approach; I just want
to ensure we've been clear about the alternatives.

Actually, didn't mean to cause a great deal of confusion here,
but solaris is the main platform. But I access solaris boxes
from a PC. And since I have a mapped network drive, I can use
PC tools to work on my unix files.

I agree, installing stuff on windows is easy. My comment about
cygwin is that it's even easier than easy. I just have to check
off the Python box. That gives me opportunity to try it for
small things.

By no means am I comparing cygwin to other unix environments for
the PC. I enjoy it out of convenience. Most of my stuff is on
the solaris, and cygwin gives me a nice posix shell without
leaving the windows environment.

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