David Greene <firstname.lastname@example.org> writes:
No problem with Perl either, or Python. Tcl is much less well-known.
Note that I don't particularly like any of these languages but I'm trying
not to let personal preference get in the way.
Neither I do. This sub-thread started with a discussion about the
feasibility of leaving behing DejaGNU and using `bash' instead or:
> If a language conceals the differences between POSIX and Microsoftian C
> for interprocess control, hides badly non-POSIX filepaths from me, and
> has a reasonable track record of forward compatibility, and has a
> reasonably universal build process, I'll consider crash-learning the
> language if I'm not already working in it.
Then I proposed Tcl as an example of such language. Maybe Perl, Python,
Ruby, Lua and others are okay too, but:
How many people know Tcl? That has a direct impact on maintanability.
DejaGNU is built around Expect, wich is a Tcl extension, so LLVM is
already using Tcl. Tcl is pretty simple. You can learn Tcl in minutes,
although there are some very common pitfalls (related to quoting issues,
OTOH, right now I'm reading llvm-config and GenLibDeps.pl, wich are
Perl. I don't know Perl at all, but more or less I understand what I'm
reading (1). This is because whoever wrote those scripts did it well. Had
similar experiences with Python: from knowing nothing at all to
extending functionality of an existing large application in minutes.
So the real issue, IMHO, is not the language itself, but *who* does the
job. To a large extent, he has the right to choose the tool he
prefers. If he does a good job, rejecting it on the basis of the
language used would be foolish, as anyone could maintain the code with
(1) Fortunately, I have no need to understand the code that has this
comment on top of it:
# To understand this code, you'll need a working knowledge of Perl 5,
# and possibly some quality time with 'man perlref'.