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: Tim X on 11 Mar 2010 17:08 Alessio Stalla <alessiostalla(a)gmail.com> writes: > On Mar 11, 1:17 pm, Tim X <t...(a)nospam.dev.null> wrote: >> Alessio Stalla <alessiosta...(a)gmail.com> writes: >> > On Mar 11, 8:32 am, Tim X <t...(a)nospam.dev.null> wrote: >> >> >> P.S. If anyone knows of a CL library that will allow me to interact with >> >> an Oracle database AND allow me to call stored procedures, passing data >> >> in both directions and access ref cursors, *PLEASE* let me know - I >> >> would still prefer to use CL for these jobs over perl. >> >> > If it's a viable option for you, you could use ABCL on the JVM and use >> > Oracle's JDBC driver. >> >> Yes, I was thinking about that as a possible option. Don't know anything >> about ABCL and was hoping to stick with a familiar ANSI implementation >> such as SBCL or even CLISP. Don't know anything about the >> interface/mapping between ABCL and java libs and wsn't sure if I was >> going that route whether I would be better off just jumping into clojure >> as I've been thinking about finding some project to try it out. > > The Java access API is derived from ACL's jlinker (http:// > www.franz.com/support/documentation/current/doc/jlinker.htm). The > notable differences are: > > - ACL's API assumes the JVM is a different process, while ABCL runs in- > process, so it lacks all the functions for managing the connection > with the JVM; and > > - ABCL's API has the option to be a bit less verbose, letting ABCL > choose automatically the method to call from the argument types, at > the cost of a runtime performance hit. For example: (jcall (jmethod > "java.lang.Comparable" "compareTo" "java.lang.Object") instance obj) > vs (jcall "compareTo" instance obj). There's also the JSS library > maintained by Alan Ruttenberg which is even less verbose, has more > features and is more efficient (wrt ABCL's abbreviated API). Interestingly, one of the things I have to fix is a severely broken Java spring based web api, which is partly broken because of the use of techniques like the above to derive stored procedure arguements. It is going to be hard for me to again accept java style verbosity. I had hoped I'd escaped that nightmare back in 98. > >> Is there much that would take getting accustomed to in ABCL that may >> feel 'foreign' and how ANSI compliant is it? > > It is mostly ANSI compliant; it lacks the long form of define-method- > combination and fails 30-something tests from the GCL ANSI test suite > (IIRC 21k+ tests). > Compared to other, more mature implementations with a larger user > base, it lacks a number of things that are usually taken for granted; > for example, the MOP is incomplete, the debugger could be improved in > many ways (e.g. it doesn't show local variable information), the > compiler doesn't use type information very much, etc. > Oh, and it's the only CL implementation I know of where = fixnums are > not always EQ, due to boxing imposed by the JVM. None of those seem particularly problematic. As long as the close link with Java doesn't leave too much of a bad taste in my mouth, it could provide what I want. > thanks, Tim -- tcross (at) rapttech dot com dot au
From: Peter J. Holzer on 11 Mar 2010 17:28 On 2010-03-10 17:45, Ron Garret <rNOSPAMon(a)flownet.com> wrote: > Most of what I have to say about this has already been said by other > people, but since this post is addressed specifically to me I'll respond > nonetheless. > > In article ><19c5b00d-c1e0-4016-9f72-37229cbf42b9(a)g19g2000yqe.googlegroups.com>, > ccc31807 <cartercc(a)gmail.com> wrote: > >> On February 27, in a thread on c.l.l, RG had this to say about Perl: >> <quote> >> >> But Perl is just an >> >> abomination through-and-through. I do not deny that many people find it >> >> a productive tool, and about ten years ago having developed a certain >> >> level of respect for some of those people I determined to learn Perl >> >> just to see what those people got out of it. So I picked up a Perl >> >> book, but I could not get past the first few chapters without recoiling >> >> in revulsion. It was just horrible. >> </quote> >> I wanted to reply but also wanted to take some time to think about my >> reply. [long fullquote deleted - please quote only the parts necessary for context] >> One language isn't better or worse that the other, they are just >> different, and the expression of RG's opinion is simply a value >> judgment, which others may or may not share. > > Certainly my opinion is only my opinion. But in my opinion it is not > true that "one language isn't better or worse than the other." > Brainf*ck, Whitespace, and Unlambda, for example, were specifically > designed to be bad languages, and they are. Agreed. > Perl was not specifically designed to be a bad language, but it is > (IMHO of course) for many of the same reasons that the aforementioned > languages are bad. I don't think so. It doesn't meet your aesthetic criteria, but it is a powerful programming language which can be used to write everything from simple throwaway scripts to large, complex software systems, in a readable, testable, maintainable way. It is true that the syntax is rather complex - probably one of the most complex ones in popular programming languages. This is intentional: Firstly, because Larry tried to throw all the good bits from lots of programming languages in (when I first encountered Perl I called it "the PL/1 of nineties"), and partly because he modelled it after natural languages, so like natural languages it has a complex, irregular, context-sensitive syntax with lots of shortcuts. He probably went too far - Perl syntax could be cleaner and less visually cluttered without losing expressivity. Lisp is the opposite - it has an extremely minimalistic syntax, and for my taste it goes too far in the direction of simplicity and purity. A lisp program may be easy to read for a lisp compiler, but it isn't easy to read for me. I need more visual structure. > You write: > >> I think any journeyman programmer can follow the logic even if he >> doesn't understand Perl or the data structures > > 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? What do the curly braces denote? What > is /\d/? And if I don't know the answers, how do I look them up? (Yes, > I tried Perldoc. It didn't help.) Well, all of these are described in perldoc, so I don't understand why reading it didn't help. > The Lisp code, by contrast, has only three items of punctuation that I > have to understand: parentheses, double quotes, and the colon. All the > rest is English words. Some of those words might be mysterious (like > CONS) but at least I can plug those into a search engine to obtain > additional clues. And the double quotes mean exactly what they mean in > common usage, so that leaves only two punctuation marks to deal with. That doesn't necessarily make the language easier to learn or read. On the contrary, I think lisp offers too few visual clues - everything looks the same to me. (but then I've never used lisp in anger, so in part this is simply because I'm not used to it) > Also, others have mentioned this but it's worth reiterating: you've > taken actual working Perl code and compared it to a Lisp example > specifically designed to be pathological. While Carter's code wasn't specifically designed to be pathological it was pretty bad, too. But how would the same code look in well-written Lisp? (Ben already showed well-written Perl). >> Perl uses sigils ($, !, %, &) to signify a token's usage. > > No, Perl uses sigils to indicate a variable's data type, not a token's > usage. Except that it doesn't. Right. It doesn't do that but for a completely different reason: The sigil has (almost) nothing to do with the variable's data type. Instead it is an article, like in many European languages. English is a bad example, because it has only one definite article (the), so let's use Italian: il - singular male la - singular female i - plural male le - plural female Gender doesn't have any meaning in Perl, but we can distinguish between singular ($) and plural. And there are two types of plural - ordered (lists, arrays: @) and unordered (hashes: %). So $ denotes singular: $ x - one x $ a[2] - one element (with index 2) of the array a $ h{'k'} - one element (with key 'k') of the hash h @ denotes an ordered plural: @ a - the whole array a @ h{'a', 'c', 'b'} - the elements with keys 'a', 'c', 'b' of hash h, in that order. % denotes an unordered plural: % h - the whole hash h Note that I have used $ with a scalar variable, an array variable and a hash variable and I have used @ with both an array variable and a hash variable. So they clearly don't "indicate the type of the variable". I have written a space after the sigil to emphasize that it is a "word" in Perl's grammar and not a part of the variable name. Normally you omit the space. (Side note: Sigils are used differently in Perl6) > It distinguishes between scalars, lists, and hash tables, Yes, but in a different way than you seem to think. Also, these three are rather fundamentally different (although awk and JavaScript seem to think that hashes and arrays are the same thing). > but not between integers, floats, and strings. Right. It doesn't do that. Should it? From a performance POV maybe - a 4byte int takes a lot less memory than a perl scalar value. But from a correctness POV using representative types doesn't buy you much - you may represent both the area of your living room and the milage of your car as a floating point number but that doesn't mean that the sum of both makes any sense. For that you need a much more strict type model. > It distinguishes between strings and regular expressions, No, not really. At least not any more than it distinguishes between numbers and strings. And that distinction is relatively recent. > but not between strings and code. Huh? Yes, it does. You can compile a string into code, but you'll have to do that explicitely. > It has all kinds of weird punctuationy things that you can't look up, > like $@ and !~ and <>. Of course you can look them up. All of them are documented and the Perl docs aren't that bad (although I agree that they could be better). You can't use google to search for them, but the same is true for any keyword or variable name which happens to be a common English word (although for opposite reasons). > It fails silently where it should produce errors. That's debatable. Perl is in the C tradition of returning an error value instead of throwing an exception, but that is only "silent" if the Programmer carelessly ignores the return value. > 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. "Universally accepted" is rather strong given that most shells, most templating languages and many scripting languages use a similar expansion mechanism. The expansion mechanism in Perl has a few shortcomings, but the fact that Perl has such a mechanism is a feature, not a bug. Apart from a few pathological examples like the one above, simply embedding variables or (very) simple expressions in a string is less cluttered and easier to read then constructing the string with concatenation operators or formatting functions. And Perl *does* have simple strings, you know. hp
From: Peter J. Holzer on 11 Mar 2010 17:48 On 2010-03-11 00:41, Ron Garret <rNOSPAMon(a)flownet.com> wrote: > 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. Well, they were wrong, but Perl doesn't throw exceptions silently. When a Perl program dies, you get a message telling you exactly where and why. So when the program "failed silently and intermittently" there was probably some error in the program logic which caused it to exit prematurely. Wrapping the whole script in eval{} doesn't help here because no exception is thrown. You'll have to analyze the logic flow of the program to find that - I don't think that's any different in lisp (yes, lisp is (or was) very popular in AI research, but automatically finding logical errors in programs is still an unsolved problem, AFAIK). Perl comes with a simple framework for unit tests. And because it comes with Perl and is so simple to use, it is very common for Perl programmers to write tests. There are also various ways to trace program execution (from simple print statements to log4perl to smart comments to running the whole thing in the debugger). If your colleagues didn't use the tools they had and just said "it doesn't work and we don't know why and can't find out" I'd call them incompetent. But I don't know what they did, so I won't. In any case I very much doubt that it is much easier to find the bug in a lisp program which "suddenly started failing silently and intermittently" than in a Perl program which does the same. hp
From: Peter J. Holzer on 11 Mar 2010 17:54 On 2010-03-10 20:20, ccc31807 <cartercc(a)gmail.com> wrote: > On Mar 10, 1:48�pm, J�rgen Exner <jurge...(a)hotmail.com> wrote: >> That code is abominable and obfuscated, but of course you can write >> abominable and obfuscated code in any programming language. > > That code is hard read, but it's not obfuscated. The variable 'names' > represent scalar values, in this case, an 'integer' used as a key. The > convoluation comes from Perl's awkward syntax for multi-level data > structures, Now I'm curious: How is Perl's syntax for multi-level data structures awkward? Which language does it in a less awkward way? I'd like to see your code snippet translated into a "less awkward" language. (I do find the dereferencing of array and hash refs awkward, but you didn't use that here) hp
From: Peter J. Holzer on 11 Mar 2010 18:06
On 2010-03-10 20:54, John Bokma <john(a)castleamber.com> wrote: > J�rgen Exner <jurgenex(a)hotmail.com> writes: >> ccc31807 <cartercc(a)gmail.com> wrote: >>>On Mar 10, 1:48�pm, J�rgen Exner <jurge...(a)hotmail.com> wrote: >>>> That code is abominable and obfuscated, but of course you can write >>>> abominable and obfuscated code in any programming language. >> [...] >>>$fac{$sec{$key}{'id1'}}{'location'} >> >> Thank you for confirming my point. >> >>>This isn't harder than C pointers. >> >> Saying something isn't harder than C pointers is like saying a desease >> isn't worse than the Bubonic plague: it gives very little comfort to >> people suffering from it. >> Actually C pointers are probably among the worst concepts ever invented >> in computer science. > > They are not "invented" they are somewhat a 1:1 mapping to > assembly. I've never had problems with C pointers but that's most likely > also because I had programmed in Z80 assembly [1] (and some motorola > processors) for a few years before programming in C. I started with BASIC (think early 1980's here - line numbers and goto), then did a little bit of Pascal and assembly (6502 and Z80) before learning C. Seeing the similarities between assembly and C has been a real eye opener for me - suddenly I understood Pascal pointers (which even more restrictive than Perl references). > I do agree, however, that it would've been nice if C had references like > Perl, and (harder to get to) pointers as they are now. Actually, C pointers are quite ok in theory (for example, you can't make a pointer into an array point outside of the array (except "just after" it). The problem is that (almost) all C compilers omit the necessary run-time checks for performance reasons and because of binary compatibility constraints (you would need "fat pointers" to implement them). > That, and a better standard library. Yup. That one is very haphazard and seriously dated. > Disclaimer: haven't programmed in C for a while. Me, too. hp |