Languages that don't suck after Perl?
Tim Smith
I've been mostly programming in Perl for several years. Not fancy Perl.
Just keeping it simple, so that any maintenance programmer that comes
after me will only need to be an intermediate Perl programmer to
understand the code.
I've found that as I've spent more time in Perl, my tolerance for other
languages has gone down. I keep finding myself muttering "why is this
stupid language making me go through so much work just make a simple
data structure that I only will need for a few lines?" or "why is it so
damned hard in this language to take this hash of names and values and
turn it into an SQL insert statement to store these values in my table?".
Java seems particularly annoying after Perl, if I'm trying to do any
text processing or database work.
Has anyone else noticed this? If so, what languages have you found are
not annoying after Perl?
--
--Tim Smith
Mirco Wahab
> I've found that as I've spent more time in Perl, my tolerance for other
> languages has gone down. I keep finding myself muttering "why is this
> stupid language making me go through so much work just make a simple
> data structure that I only will need for a few lines?" or "why is it so
> damned hard in this language to take this hash of names and values and
> turn it into an SQL insert statement to store these values in my table?".
>
> Java seems particularly annoying after Perl, if I'm trying to do any
> text processing or database work.
>
> Has anyone else noticed this? If so, what languages have you found are
> not annoying after Perl?
For Perl's usual problem domain, none.
If speed is important, I'd say that contemporary C++ starts
to get somehow usable, especially after the Boost libraries
became mature and widely available.
After starting with using Boost::Regex, this made me
completely drop the "Embedding Perl" approach. But
getting along with the intricacies of C++ and Boost
requires a deep understanding of the language and
hard work to get it work.
Regarding Hashes, there is the good old C++ hash_map imple-
mentation available (used to be in std or std/ext) - this is
(about as ) fast (as Perl's hashes). Same point as above - you
need to know what to do and where to search for stuff in
order to get along.
Even some Perl idioms (map, grep) can be approximated
using STL container algorithms.
In my opinian, C++ is somehow 'perlish' because it
supports TIMTOWTDI.
my €0.02
Regards
M.
Tad J McClellan
> I've found that as I've spent more time in Perl, my tolerance for other
> languages has gone down. I keep finding myself muttering "why is this
> stupid language making me go through so much work just make a simple
> data structure that I only will need for a few lines?" or "why is it so
> damned hard in this language to take this hash of names and values and
> turn it into an SQL insert statement to store these values in my table?".
>
> Java seems particularly annoying after Perl, if I'm trying to do any
> text processing or database work.
>
> Has anyone else noticed this?
I tell people:
Using Perl is like digging a ditch with a backhoe.
Using C is like digging a ditch with a shovel.
Using Java is like digging a ditch with a spoon.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
Leon Timmermans
>
> For Perl's usual problem domain, none.
>
Full agreement.
> If speed is important, I'd say that contemporary C++ starts to get
> somehow usable, especially after the Boost libraries became mature and
> widely available.
>
I concur.
> After starting with using Boost::Regex, this made me completely drop the
> "Embedding Perl" approach.
Actually, I'm working on making embedding perl into C++ easier.
> But getting along with the intricacies of C++
> and Boost requires a deep understanding of the language and hard work to
> get it work.
True. C++ is a big language. Once you really know it it's a bliss, but
halfway many people seem to hate its syntactic complexity. Then again,
same has been said of Perl.
> Regarding Hashes, there is the good old C++ hash_map implementation
> available (used to be in std or std/ext) - this is (about as ) fast (as
> Perl's hashes). Same point as above - you need to know what to do and
> where to search for stuff in order to get along.
The new and official (since TR1) version is called unsorted_map.
> Even some Perl idioms (map, grep) can be approximated using STL
> container algorithms.
>
Yeah, though the method (explicit iterators) is quite different.
> In my opinian, C++ is somehow 'perlish' because it supports TIMTOWTDI.
>
Yeah, though there's something else too. Like Perl and unlike many
languages (Java and PHP in particular), it has very orthogonal
containers (it doesn't try to pretend arrays and hashes have too much in
common). I very much prefer that.
Regards,
Leon Timmermans
Charlton Wilbur
TS> I've found that as I've spent more time in Perl, my tolerance
TS> for other languages has gone down. [...] Has anyone else
TS> noticed this? If so, what languages have you found are not
TS> annoying after Perl?
It depends largely on the problem. For quick text wrangling and
database access, it's hard to beat Perl. But if you want to do
low-level text processing (like an LALR parser), native UIs, or
low-level bit twiddling, Perl gets frustrating quickly itself.
(For most of those, I'd go to C or Objective-C.)
Also, if you rely on the language to enforce discipline (which is an
attribute of many corporate shops), Perl is best avoided, because it
relies on the programmer to enforce discipline. The best argument in
favor of Java in the 'enterprise' is 500 lines of Perl code written by
an ignoramus who fancies himself a hacker.
Charlton
--
Charlton Wilbur
cwi...@chromatico.net
Sherman Pendley
> Has anyone else noticed this? If so, what languages have you found are
> not annoying after Perl?
For many of the tasks for which I'd use Perl - none. I don't find
Python or Ruby to be annoying, but neither do I see them offering
anything I can't already do in Perl.
For mid-level code, I like Objective-C. Dynamic typing and message
passing help make it much less annoying than C++. Still no central
location for class libraries though, which is mildly annoying. CPAN
is, IMHO, one of the most essential ingredients in Perl's recipe for
non-annoyance.
sherm--
--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
Veli-Pekka Tätilä
> I've found that as I've spent more time in Perl, my tolerance for other
> languages has gone down. I keep finding myself muttering "why is this
> stupid language making me go through so much work just make a simple
> what languages have you found are not annoying after Perl?
language. I had to pick it up recently and after an initial great dislike
that had to do with lack of programmer convenience and the Perlish TIMTOWTDI
I found myself greatly enjoying its simplicity and minimalism, even
preffering it to Perl at times given some small convenience wrappers. To me
it is a clean redesign of many of the cool, core mechanisms already in perl
with a much more orthogonal and less messy legacy-free design. It was about
the quickest language for me to learn, ever, since there's so much I've
learned in Perl over the years that can be directly applied in a Lua
context. I guess this is true for many other dynamically typed langs,
though.
Frankly, I'm happy that when I program in Lua I have a feeling I've mastered
most of the language well, and can hold a significant subset in my head,
where as I always have to go and re-read the man page for the more obscure
Perlisms whose limitations and obscurities annoy me.
Lua is also very clean and punctuation free syntactically, which is an
important difference if you ever have to code legally blind based on
synthetic speech and Braille, granted this is very unlikely. Perl regexp,
which I love for saving me from having to cursor through text linearly with
speech in my text editor, are about the most horrible speech read, though,
you have to go character by character to parse them mentally with a naive
screen reader like Hal for Windows or Gnome's Orca.
Here are some examples of Perl and Lua similarities. If you know Perl
hashes, Lua hashes work much the same. Except that they can be indexed with
any type other than nil (undef), including ints for fast arrays. And in
stead of type globs and packages, you have just global hashes mapping
strings to data and a bit of syntactic sugar. Rather than explicit
dereffing, you have separate, very simple ref types for tables, functions
etc..
Again, Lua OOp after Perl was quite palatable: classes and objects are
hashes. Rather than blessing, just overload indexing on a per object basis
such that it looks in the class hash for methods and data fields not found
in the object. You can also give a code ref for multiple inheritance,
autoloading, or whatever rather than a hash to look missing fields in. In
Lua, Accessing string keys of a hash with a dot and calling functions like
methods, are just a bit of true syntactic sugar around indexing a hash and
passing the invocant as the first arg. Where Perl has ISA, Overload, bless,
tie, package etc... all Lua has are tables, and the ability to set their
operations.
In fact I've written a bit of a conversion guide for folks who already know
Perl and need to learn Lua for one reason or another. This works best for
folks who have a similar, rather informal way of thinking of coding,than I
do:
http://vtatila.kapsi.fi/luatut.html
Be warned this is just an initial version, and I'm only an intermediate
Perler rather new to Lua. Still, loads of shortcuts can be taken if you know
Perl. here's my explanation of Lua patterns, which is not long:
Quote
Quantifiers and Character Classes
The primary simplification is that a quantifier may only follow a character
class, you cannot quantify a parenthesize subexpression or a capturing
group. *, question ? and + work exactly like their greedy counter parts in
regexp. The only other quantifier is minus - which is like the lazy star, *?
Character classes are locale sensitive in Lua and Perl. Syntactically, in
stead of backslashing symbols, you use the percent sign for the same thing.
%a, %u and %l for alphabetic, caps and lowwercase letters, %d and %x for
ordinary and hex digits, %c, %p and %z for control, punctuation and null
characters. Uppercased versions of these classes are the complements, much
as in Perl. Additionally, %% is a percent sign and the dot %. is any
character, including new lines, unlike in regexp by default.
Bracketed sets of characters including character ranges and classes as part
of them can be used much as in regexp. Exception: you cannot augment a
character class with a range. You can, however, invert a range with a
leading caret [^...].
Finally, lua patterns may also contain %b followed by two characters. The
construct will match an expression with the counts of these characters being
balanced, e.g. %b() for matching nested parens. Again, a balanced expression
may not be quantified but may be captured.
Capturing Groups and Anchors
Parens in Lua patterns neither group nor change precedence, they only
surround bits of patterns to be captured. captured are numbered from 1
onwards and referred to in the same pattern as %1, %2 and so on. %0 in a
replacement is the whole matched string. An empty pair of parens
exceptionally captures the 1-based match position in stead.
The only anchors in Lua patterns are the caret ^and dollar $, which always
only anchor at the beginning and end of the whole pattern, new lines in
matched text don't affect their meaning.
End quote.
--
With kind regards Veli-Pekka Tätilä
Accessibility, Apps and Coding plus Synths and Music:
http://vtatila.kapsi.fi
Jürgen Exner
>
>I've been mostly programming in Perl for several years. Not fancy Perl.
>Just keeping it simple, so that any maintenance programmer that comes
>after me will only need to be an intermediate Perl programmer to
>understand the code.
>
>I've found that as I've spent more time in Perl, my tolerance for other
>languages has gone down. I keep finding myself muttering "why is this
>stupid language making me go through so much work just make a simple
>data structure that I only will need for a few lines?"
A large part of your annoyance with other languages comes from you being
familiar with Perl at this time and you are thinking in Perl, and
therefore you are trying to mentally translate a Perl script into a
program in some other language. This happens on a subconcious level and
most likely you are not even aware of it.
It is just like learning a new language. As long as you are thinking in
your native language you will form a sentence in your native language
and then try to translate it. Ain't gonna work that way. You will always
run into "why is that language so awkward!"
Once you are familiar enough with the new language to think in that
language, then you realize that things are simply expressed in a
different way and it's not more awkward than your own, it is just
different. This becomes very apparent when trying to translate in the
opposite direction. Suddenly your native language is so awkward to use
because again you are translating between languages instead of thinking
in the right language from the beginning.
jue
Ted Zlatanov
TS> I've found that as I've spent more time in Perl, my tolerance for other
TS> languages has gone down. I keep finding myself muttering "why is this
TS> stupid language making me go through so much work just make a simple
TS> data structure that I only will need for a few lines?" or "why is it so
TS> damned hard in this language to take this hash of names and values and
TS> turn it into an SQL insert statement to store these values in my table?".
TS> Java seems particularly annoying after Perl, if I'm trying to do any
TS> text processing or database work.
TS> Has anyone else noticed this? If so, what languages have you found are
TS> not annoying after Perl?
I feel the same with Lisp, which is almost as comfortable for me as
Perl. Also, SQL is actually a very nice language for some tasks, and
learning it gives a fresh perspective on Perl and others. I'd recommend
those two if you're interested in learning more. Ruby may also be of
interest to you.
If I find myself wondering why a language doesn't provide X, I often
find that X is not the best approach in that language. C-style macros,
for example, are not a part of Perl and they are very convenient, but
Perl doesn't need them in 99% of the cases.
Ted
Ben Bullock
> Has anyone else noticed this? If so, what languages have you found are
> not annoying after Perl?
I find that Perl is annoying once you've got used to the conveniences of
Visual Basic. For example, if I want to resize a text button in Visual
Basic, I just click the lower right corner and the text button is
automatically resized to the size of the text it contains. Perl doesn't
have this kind of convenient feature, so I'd say Perl was pretty annoying.
Also, Perl's object system is very clunky and messy compared to C++. I'd
say that Perl's object system is downright annoying. Further, Perl is
extremely slow compared to C or C++, especially for numerical
calculations. It's annoying. But most of these { } languages like C and C+
+ and Perl are annoying compared to Fortran 77, because in Fortran 77
it's quite easy to remember all the syntax of the language.
On the other hand, JavaScript's regular expressions and string
substitutions are annoying and clunky compared to Perl's. You can use
like $1 on the right hand side, but if you try to get the value of $1
outside the regular expression, it just complains about it.
In summary, I think most computer languages are annoying in one way or
another. Perl is probably more annoying to learners than many other
languages.
Tad J McClellan
I should probably point out that if their might be a water main
where you're digging, then C would be a good choice.
And if their might be ancient artifacts where you're digging,
then Java would be a good choice.
Andrew DeFaria
Tim Smith <reply_i...@mouse-potato.com> wrote:
I've found that as I've spent more time in Perl, my tolerance for other languages has gone down. I keep finding myself muttering "why is this stupid language making me go through so much work just make a simple data structure that I only will need for a few lines?" or "why is it so damned hard in this language to take this hash of names and values and turn it into an SQL insert statement to store these values in my table?".
Java seems particularly annoying after Perl, if I'm trying to do any text processing or database work.
Has anyone else noticed this?
How to Shoot Yourself in the Foot in Any Programming Language
The proliferation of modern programming languages (all of which seem to have stolen countless features from one another) sometimes makes it difficult to remember what language you’re currently using. This guide is offered as a public service to help programmers who find themselves in such dilemmas.
C
You shoot yourself in the foot.
C++
You accidentally create a dozen clones of yourself and shoot them all
in the foot. Providing emergency medical assistance is impossible since
you can’t tell which are bitwise copies and which are just pointing at
others and saying, “That’s me, over there.”
JAVA
After importing java.awt.right.foot.* and java.awt.gun.right.hand.*,
and writing the classes and methods of those classes needed, you’ve
forgotten what the hell you’re doing.
Ruby
Your foot is ready to be shot in roughly five minutes, but you just
can’t find anywhere to shoot it.
PHP
You shoot yourself in the foot with a gun made with pieces from 300
other guns.
ASP.NET
Find a gun, it falls apart. Put it back together, it falls apart again.
You try using the .GUN Framework, it falls apart. You stab yourself in
the foot instead.
SQL
SELECT @ammo:=bullet FROM gun WHERE trigger = ‘PULLED’;
INSERT INTO leg (foot) VALUES (@ammo);
Perl
You shoot yourself in the foot, but nobody can understand how you did
it. Six months later, neither can you. (via Andy)
Javascript
YOu’ve perfected a robust, rich user experience for shooting yourself
in the foot. You then find that bullets are disabled on your gun.
CSS
You shoot your right foot with one hand, then switch hands to shoot
your left foot but you realize that the gun has turned into a banana.
FORTRAN
You shoot yourself in each toe, iteratively, until you run out of toes,
then you read in the next foot and repeat. If you run out of bullets,
you continue anyway because you have no exception-handling ability.
Modula2
After realizing that you can’t actually accomplish anything in this
language, you shoot yourself in the head.
COBOL
Using a COLT 45 HANDGUN, AIM gun at LEG.FOOT, THEN place
ARM.HAND.FINGER. on HANDGUN.TRIGGER and SQUEEZE. THEN return HANDGUN to
HOLSTER. CHECK whether shoelace needs to be retied.
LISP
You shoot yourself in the appendage which holds the gun with which
you shoot yourself in the appendage which holds the gun with which
you shoot yourself in the appendage which holds the gun with which
you shoot yourself in the appendage which holds the gun with which
you shoot yourself in the appendage which holds ….
BASIC
Shoot yourself in the foot with a water pistol. On big systems,
continue until entire lower body is waterlogged.
FORTH
Foot in yourself shoot.
APL
You shoot yourself in the foot, then spend all day figuring out how to
do it in fewer characters.
Pascal
The compiler won’t let you shoot yourself in the foot.
SNOBOL
If you succeed, shoot yourself in the left foot.
If you fail, shoot yourself in the right foot.
Concurrent Euclid
You shoot yourself in somebody else’s foot.
HyperTalk
Put the first bullet of the gun into the foot of the left leg of you.
Answer the result.
Motif
You spend days writing a UIL description of your foot, the trajectory,
the bullet, and the intricate scrollwork on the ivory handles of the
gun. When you finally get around to pulling the trigger, the gun jams.
Unix
% ls
foot.c foot.h foot.o toe.c toe.o
% rm * .o
rm: .o: No such file or directory
% ls
%
Paradox
Not only can you shoot yourself in the foot, your users can too.
Revelation
You’ll be able to shoot yourself in the foot just as soon as you figure
out what all these bullets are for.
Visual Basic
You’ll shoot yourself in the foot, but you’ll have so much fun doing it
that you won’t care.
Prolog
You tell your program you want to be shot in the foot. The program
figures out how to do it, but the syntax doesn’t allow it to explain.
Ada
After correctly packaging your foot, you attempt to concurrently load
the gun, pull the trigger, scream and shoot yourself in the foot. When
you try, however, you discover that your foot is of the wrong type.
Assembly
You try to shoot yourself in the foot only to discover you must first
reinvent the gun, the bullet, and your foot. After that’s done, you
pull the trigger, the gun beeps several times, then crashes.
370 JCL
You send your foot down to MIS with a 4000-page document explaining how
you want it to be shot. Three years later, your foot comes back
deep-fried.
Python
You try to shoot yourself in the foot but you just keep hitting the
whitespace between your toes. (via Marco Azaro)