to RG - Lisp lunacy and Perl psychosis
in [Lisp]
|
Prev: The correct choice for implementation (was: A simple web clientlibrary)
Next: Solved Re: Emacs speedbar doesn't show .lisp and .asd files
From: Tad McClellan on 10 Mar 2010 16:53 ["Followup-To:" header set to comp.lang.perl.misc.] Ron Garret <rNOSPAMon(a)flownet.com> wrote: > In article <a4ofp5p0026pmis1a5cc4t8dg9cst9ugfv(a)4ax.com>, > J?rgen Exner <jurgenex(a)hotmail.com> wrote: > >> Ron Garret <rNOSPAMon(a)flownet.com> wrote: >> >Maybe I don't qualify as a journeyman I can't follow that Perl code, and >> >for exactly the same reason that I can't follow Brainf*ck code: too much >> >punctuation. What does !~ mean? >> >> perldoc perlop: >> Binary "!=" returns true if the left argument is numerically not equal >> to the right argument. > > What does that have to do with what I asked? Nothing, but it does go a long way in supporting your point about punctuation being hard to read correctly. :-) -- Tad McClellan email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/" The above message is a Usenet post. I don't recall having given anyone permission to use it on a Web site.
From: J�rgen Exner on 10 Mar 2010 16:57 Ron Garret <rNOSPAMon(a)flownet.com> wrote: >In article <a4ofp5p0026pmis1a5cc4t8dg9cst9ugfv(a)4ax.com>, > J?rgen Exner <jurgenex(a)hotmail.com> wrote: > >> Ron Garret <rNOSPAMon(a)flownet.com> wrote: >> >Maybe I don't qualify as a journeyman I can't follow that Perl code, and >> >for exactly the same reason that I can't follow Brainf*ck code: too much >> >punctuation. What does !~ mean? >> >> perldoc perlop: >> Binary "!=" returns true if the left argument is numerically not equal >> to the right argument. > >What does that have to do with what I asked? Sorry, my bad: Binary "!~" is just like "=~" except the return value is negated in the logical sense. >> > What do the curly braces denote? >> >> Depends on where they are used. Some common uses include enclosure of >> code block (perldoc perlsyn) and indexing of hashes (perldoc perldata). > >Yes, that is exactly the problem. Perl is not content with assigning >semantics meaning to every single symbol on the keyboard, it *overloads* >those symbols, so even if you *could* look them up you *still* wouldn't >know what they meant without first deciphering the context. You mean like lead and lead in English? Or + and + in C which, gasp, can be used for char, short, byte, int, long, float, pointers, and a myriad of others? >> > What is /\d/? >> >> perldoc perlre: > >And how is one supposed to know that "perlre" is the right thing to look >up here? Because you were looking at a function who's first argument is a regular expression and therefore checking out the documentation about regular expressions as mentioned at the root level of the documentation in "perldoc perl" seems like a good idea? >BTW, these are all rhetorical questions. > > >> It's all there. Granted, in particular perlop is hopelessly overloaded >> and therefore information is hard to find, but you are very welcome to >> improve it. > >And why on earth would I want to do that? No, seriously, what's the >payoff? That is not a rhetorical question. What will I be able to do >if I invest effort into learning and/or improving Perl that I cannot do >just as easily and just as well in, say, Python? True, for you it would be a major drawback because you couldn't rant about it any longer. [...] >> >Except that it doesn't. It distinguishes between scalars, >> >lists, and hash tables, but not between integers, floats, and strings. >> >> Why would you want to distinguish between them on such a low level? > >Why would I want to distinguish between types at all? So are you suggesting that e.g. C's distinction between short, byte, char, int, long, unsigned, double, ultra-special-extra-big .... would be even better? Typing is an aid to the programmer to avoid errors by inadvertently using incompatible data types. However if the programming language automatically converts between different data types according to context and I can use them safely without ever thinking about a conversion, then that is as big a step forward as not having to manually deal with memory allocation and garbage collection of dynamic data structures. >> >It distinguishes between strings and regular expressions, >> >> Well, those are very different animals. Strings are data while REs are >> code. > >Potato, potahto. Strings are code when you feed them to EVAL. I think I did mention eval(). And yes I also mentioned that eval() (as well as RE when used with /e which is just an eval in disguise) breaks the paradigm. But still this is only one very specific place which you normally would not use in every-day code. Actually people are strongly advised not to use eval for strings unless they know exactly why they need to do it. >> >It has all kinds of weird punctuationy things >> >that you can't look up, like $@ and !~ and <>. >> >> Yes, you can. See perldoc perlvar, perldoc perlop, perldoc perlop. > >Let me be more precise: that you can't look up unless you know the >secret incantation. Where's the problem? Any item with a $ up front is a variable, so you will probably find it in perldoc perlvar. The other two take arguments and do some computation. So chances are good you will find them either as functions (perldoc -f .....; no luck there) or in perldoc perlop as suggested by the root of the perldoc tree. >> >It fails silently where >> >it should produce errors. It violates universally accepted conventions >> >about what, for example, double quotes mean. For example, this: >> > >> >print "The widget costs $12.75."; >> >The actual behavior of that code snippet is not justifiable under any >> >sane language semantics. >> >> If you don't want variables ($12) to be interpolated, then don't use >> quotes that interpolate variables: >> >> print 'The widget costs $12.75.' > >Yes, I know that. But what kind of brain damaged language allows >numbers to be the names of variables in the first place? (That's >another rhetorical question BTW.) A language that wants something better than \12 as a variable name for captured content from the 12th RE group? jue
From: ccc31807 on 10 Mar 2010 18:17 On Mar 10, 5:56 pm, Ron Garret <rNOSPA...(a)flownet.com> wrote: > Python > dominates Perl in every conceivable way IMHO. I did a project in Python, once, and it turned out well. Python is a sweet language, and I understand that they are now teaching it as the first language at both MIT and GaTech. > I've had one firsthand > experience with Perl in production that turned out very badly. Was that because Perl was a bad match for the project? Or because the developers were incompetent in Perl? I've done several major database projects in Perl, and a great number of minor projects in Perl, and my experience is that the match of a technology to a task sometimes is a management decision, and managers sometimes make bad decisions. > If > you're productive in Perl, more power to you. But you won't be working > for me. I won't be working for you anyway. I've reached my level of incompetence, and I intend to stay there! ;-) CC
From: Tamas K Papp on 10 Mar 2010 19:19 On Wed, 10 Mar 2010 10:02:01 -0800, ccc31807 wrote: > On Mar 10, 11:03 am, Tamas K Papp <tkp...(a)gmail.com> wrote: >> > Not my intent to start a flame war. Please reread my post. >> >> Yeah, sure. Cross-posting something like this usually promotes peace >> and happiness. > > You still haven't read my post, or if you did you haven't comprehended > it. There's nothing in it that works against peace and happiness. I I have read your post and understood it, but I am not really interested in getting into meta-discussions. >> >> Here's the point: to call one language horrible and an abomination >> >> because you don't understand it, and ignoring the horribleness and >> >> the abominable in another language because you do understand it, >> >> doesn't make any sense. >> >> You failed to show anything horrible or abominable in CL. > > That's right. There isn't anything horrible or abominable in either of > the two languages. It certainly wasn't my intention to create that > impression, just to opposite in fact. So when you said "ignoring the horribleness and the abominable in another language because you do understand it", what another language were you referring to? Perl, CL, or something else? > Somehow, you think that I've said exactly the opposite of what I meant. > Either I wasn't clear in my writing, or you weren't clear in your > reading. I'll try one more time. > > <emphasis>Calling a language horrible because you don't understand it is > a mindless prejudice.</emphasis> > A > Do you understand that? I contrasted a bit of working Perl code (which > appears to be abominable) to a deliberately obfuscated bit of Lisp code > to make that point. I really don't understand why you think I have > insulted CL, when I undertook to say that insult based on ignorance is > pointless. When you made a statement about "ignoring the horribleness and the abominable in another language", I thought you meant Common Lisp. Did you mean Perl? Tamas
From: Ron Garret on 10 Mar 2010 19:41
In article <ce68ccd0-22e2-472d-9cc3-06a2cf00a29f(a)y11g2000yqh.googlegroups.com>, ccc31807 <cartercc(a)gmail.com> wrote: > > I've had one firsthand > > experience with Perl in production that turned out very badly. > > Was that because Perl was a bad match for the project? Or because the > developers were incompetent in Perl? Why must those be the only possibilities? It was because the Perl code, which had been working fine for months, suddenly started failing silently and intermittently, and I was told there was no way to do the equivalent of wrapping the whole script in the equivalent of a TRY...EXCEPT form in order to catch the error. Whether this was in fact true or whether the entire engineering team was incompetent I do not know. But they seemed pretty bright and capable otherwise, so it would be pretty odd for them all to be mistaken about this. rg |