Quoting "Derek D. Martin" <[EMAIL PROTECTED]>: > Which is specifically why I made that point immediately after what you > quoted. Now you're just trolling... And my argument all along was > not that Perl has obscurities; it's that it has TOO MANY, and the > people who write perl (in my experience) have a propensity to use them > TOO OFTEN, being not conducive to actually learning perl. I'm > inclined to think you're being intentionally obtuse.
This is primarily becouse perl is, at a core, a functional language. No attempt has ever been made to enforce style or methods within perl. It wasnt built to be pretty, it was built to be efficient. > You are also aware that my first Perl program was a > 1000 line > program for managing host resolution, which worked well enough for us > to use it in production at MCL, with or without the web-based > interface. So you know I'm not trying to damn perl to unusability; > I'm only saying that as languages go, I can see why some people find > it reletively hard to learn, as compared to a lot of other languages. > Myself included. Agreed. But only when coming from a standpoint of attempting to learn the language without applying any sort of engineering logic to it. The people that find it relatively hard to learn have limited exposure to knowing exactly how and why something works, and typically are simply trying to do something with a lanuage they know little or nothing about. By and large, I tend to label these as, no pun meant twards anyone, but, 'Web Monkeys'. This isn't a bad thing, but perl wasn't really evolved for this type of environment. Languages such as Visual Basic and VBScript, or even better, PHP, where.. > - Perl "grew" rather than being designed. Its syntax is a > mish-mash of features from several other languages and/or utilities > all glued together, and as such sometimes seems to be inconsistent > with itself Definatly nailed that one on the head. Thats why it is the way it is. > - Perl does some things which are commonly done in programming > languages very, very differently from the rest Hrm, I'm unsure exactly what you mean, the sentence seems off, but if I read the meaning, its that perl does things differently. This, I have to disagree with. It does things in a very simular manner as C. When treating perl using OO syntax, it looks nearly identical to using C code using OO methodologies by stuffing things in structs and calling it an object. The shortcuts that are provided, or 'magic variables', arent uncommon. There choice of NAMES could be thought of as wierd, I suppose.. ;-) > - Perl has a lot of obscure features and syntax, like the so-called > "magic" variables, that don't lend themselves to readable code Actually, I find most perl code alot easier to read then alot of C, C++, or java code around. You just cant read it as thought it where english. No one that isnt familiar with perl will be able to read them, thats for sure. So readable, yes, but not by an casual observer. > - The people who write Perl by and large seem to prefer a style (if > you can call it that) that promotes neither code readability nor > education Becouse its funcational. It's a thought process I guess. I can pickup most perl modules and be able to read thru and know what they're doing a whole lot easier then many other languages. I think that perhaps its becouse things are more compact within the logic of the code, and hence, you have some very intense things going on in a relatively small space, as opposed to a more human readable form in a more descriptive language, where the cost of readability is obfuscated logic do to the human language.. > - For all its wiz-bang features that make many tasks which are > difficult on other languages much easier in perl, it lacks the > ability to easily manipulate data structures; one of the most > common things done with computer programs. Dealing with arrays of > hashes of hashes is somewhat clumsy, by comparison to other > languages Compare. A data structure within perl is called a module. A module in perl is the equivilant of a structure, or even better, a class, in other languages. I suppose this may be looked at from several standpoints, but from an engineering mindset, this is perfectly natural. Hell, a linked list is, technically speaking, a pointer to a pointer to a pointer to a pointer to a pointer to a pointer to a pointer (repeate adnasuem), and sometimes, the reverse, and, if someones really tricky, an indexed hodgepodge of memory locations. > - learning to do certain common programming tasks in perl is > unneccessarily hard Programing tasks is an interesting way to state it. Programming and engineering are two distinct things, and perl is much more an engineering language. > - reading and maintaining other people's code is unnecessarily hard > The last one is a key point. Maintaining someone else's code in any > language is often difficult, especially if they don't comment their > code and use a style that lends itself to readability. But many of > the features of Perl compound this problem, making for naturally ugly > code. When you sum these things all up, they keep me from reaching > for Perl to do much of anything. You don't have to agree. What you consider ugly, someone looking at program flow and logic considers sheer perfection.. ;-) > I do occasionally use Perl, but I find that it's usually when I want > to do a lot of regexp work, or shell-script-like work, but don't want > to take the performance hit of using a shell script. Otherwise, bash > or C suit me better. Performance hit. Thats kinda funny. And what kind of benchmarks have you performed as a basis for this judgement? I guess I dont see what this means, as to why you do it. > I may only be imagining this, but I could swear it was a predecessor > to Unix, from whence many of these commands originally came (possibly > multics? anyone?) that did have a four character filename limit. > OTOH, I haven't been getting much sleep lately... =8^) Not that I'm aware of, but I wouldnt doubt it. Some of the older guys have any sort of insight as to this? I'm curiouse.... -- Thomas Charron -={ Is beadarrach an ni an onair }=- _______________________________________________ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss