When extensibility goes bad
in [Lisp]
|
From: Jon Harrop on 22 Jun 2008 10:59 John Thingstad wrote: > P� Sun, 22 Jun 2008 12:56:14 +0200, skrev Jon Harrop > <jon(a)ffconsultancy.com>: >> Consider the enormous waste of time and effort involved in maintaining >> Lisp >> code like this. In practice, Lispers just give up, write naive code and >> kiss goodbye to performance. That is precisely what I was alluding to. > > No we just write a macro to do the expansion. You aspire to write an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a modern pattern match compiler but, in practice, the Lisp community lacks the direction and team skills required to do that so they end up writing many incompatible pattern match compilers, none of which are worth having. This is "when extensibility goes bad". > Or use method combination for type inference. Which doesn't even handle this trivial example let alone real code. > Code like this is typically only a few percent of the actual code in a > real application. Of course, everything that Lisp makes unnecessarily difficult is rarely seen in Lisp code. > Most of the time is spent on more mundane stuff like managing windows, > printing reports, managing databases and the like. All of which would be done using pattern matching if it were available. > This code example is so obviously tailored for OCalm type matching it > actually says little about actual performance on a application level. Pick an application, any application. > Earlier this week I wrote some code to pretty print 100!. You can look it > up. Now how would that code look in OCalm or F#? Do you want anything beyond the library function run in a REPL that already does pretty printing: Math.BigInt.factorial 100I -- Dr Jon D Harrop, Flying Frog Consultancy http://www.ffconsultancy.com/products/?u
From: Kenny on 22 Jun 2008 14:20 Jon Harrop wrote: > All of which would be done using pattern matching if it were available. I wonder if you are aware that the Harrop harp has but one string? Anyone who has followed your lame attempts to build a business and extraordinary success at making yourself unlikable cannot help noticing it: all you ever talk about is pattern-matching. Pattern-matching is fun, I used it once. But no stupid pet trick, not even Cells, suffices for everything. The most regular error in language design is, "Hey! Let's use it for /everything/!". Welcome to the club. The only thing I read from your pattern obsession is that F# offers nothing else. hth, kenny
From: Slobodan Blazeski on 23 Jun 2008 08:37 On Jun 22, 8:20 pm, Kenny <kentil...(a)gmail.com> wrote: > Jon Harrop wrote: > > All of which would be done using pattern matching if it were available. > > I wonder if you are aware that the Harrop harp has but one string? > Anyone who has followed your lame attempts to build a business and > extraordinary success at making yourself unlikable cannot help noticing > it: all you ever talk about is pattern-matching. Pattern-matching is > fun, I used it once. Bleh, pattern matching is poor man unification. If you like pattern matching don't learn prolog, you'll be disappointed about artificial limits of pattern matching in the name of the performance. Oh you learned prolog already? And about performance, I couldn't care less.I have a 8 cores doing nothing 99.999% of the time. Memory consumption is even less of an issue, with my 16GB of RAM even running a hog of an OS, and don't get me even started about the HD. The only area that still needs performance I'm interested in are games, and after buying a new GPU even my 7 year old Celeron 2.4 runs all of them without a glitch. Screw performance, F#/OCaml are solving the wrong problem. Lisp has fine unification lib, and even it's 1000 slower than F#/OCaml who cares? Not me certainly. Even on my year old laptop DualCore 2G Ram I could run a whole company. Processing power is dirt cheap nowdays. > But no stupid pet trick, not even Cells, suffices > for everything. > > The most regular error in language design is, "Hey! Let's use it for > /everything/!". Welcome to the club. > > The only thing I read from your pattern obsession is that F# offers > nothing else. > > hth, kenny
From: Robert Maas, http://tinyurl.com/uh3t on 24 Jun 2008 01:16 > > This code example is so obviously tailored for OCalm type matching it > > actually says little about actual performance on a application level. > From: Jon Harrop <j...(a)ffconsultancy.com> > Pick an application, any application. Let me jump in here and suggest an application: You have Received lines from lots of spam. You want to classify them according to patterns, typically per the e-mail software that generated them, except you don't have access to the software run by all the mail servers in the world that are involved in sending you spam, so you can look only at the final product, what appears in the headers of the spam you receive, and try to guess what patterns there are in the formats you see. What sort of algorithm would you propose for that task, indepedent of the language you might try to program it in? Then after we agree on that answer, I'll ask everyone here which programming language makes implementation of that algorithm easiest, most "obvious", most straightforward, nevermind efficiency at this point. Now let's say the result of the previous software task was that there are fourteen different patterns of format of Received lines in the corpus of spam you've been studying. Next you want to write a parser for each of those patterns, or even better a single parser that can simultaneously recognize the pattern and parse it. The result of each parse would be a parse tree, whose structure is specific to the particular pattern it's parsing. But whereever a low-level syntax element is common to more than one high-level pattern, you want to recognize that syntax element as "the same" element and tag it the same way each time it appears regardless of what pattern it appears in. What sort of algorithm would you propose for that task, indepedent of the language you might try to program it in? Then after we agree on that answer, I'll ask everyone here which programming language makes implementation of that algorithm easiest, most "obvious", most straightforward, nevermind efficiency at this point. In both cases, save mention of programming languages for later. First (now) the informal description of the two algorithms-of-choice, with no reference to any specific programming language, only reference to standard types of data structures, such as nested lists, hash tables, binary search trees, etc. and algorithms that make efficient/comprehensible use of those data structures, such as regression analysis of local text-string statistics, compilers from BNF tables to one-pass dispatch tables, recursive descent parsers, etc. > > Earlier this week I wrote some code to pretty print 100!. You > > can look it up. Now how would that code look in OCalm or F#? Hey, I was going to ask what you mean by that. Do you mean expressing the numeric value in some radix and then inserting commas every third group from the right and then inserting line breaks (with indentation on all lines except the first, or right-adjust to right margin all lines with first line starting midway in the line)? Or do you mean completely factoring the numeric value and collecting like prime factors then formatting the factorization expression to make optimal use of lines of output? Or what??
From: Robert Maas, http://tinyurl.com/uh3t on 24 Jun 2008 01:53
> > All of which would be done using pattern matching if it were available. > From: Kenny <kentil...(a)gmail.com> > I wonder if you are aware that the Harrop harp has but one string? What is he, the musical equivalent of a "hacker"? His instrument has only one string, but he's very good at making do with that one string, carefully pinching it between his fingernails at various points along its length to shorten the wavelength hence raise the frequency without damping the oscillations too much? I've seen other musical hackers on TV, one who could blow musical tunes through his underarm, one who could blow musical tunes through his puffed mouth, one who could tap musical tunes on his tummy or arm I forget which. When I was a kid, my father used to blow tunes through a leaf of grass folded in half. I myself have demonstrated playing a few simple tunes using a old party horn where the spiral-windup paper part has long torn off, but I'm nowhere near as skillful as those musical hackers I've seen on TV. Then there was that singer from South America (Yma Sumac or something like that) who could sing five octaves with her vocal cords. Quick, Google search: <www.yma-sumac.com> (Inca princess / Peruvian diva) <http://en.wikipedia.org/wiki/Yma_S%C3%BAmac> (her extreme vocal range "well over three octaves"^[1], which was commonly claimed to span four and even five octaves at its peak^[2]^[3].) ... Yma Sumac recorded an extraordinarily wide vocal range of more than four octaves, from B[2] to C#[7] (approximately 123 to 2270 Hz). She was able to sing notes in the low baritone register as well as notes above the range of an ordinary soprano. ... ... * Voice of the Xtabay (1950), Capitol Records H-244 (10" LP)^[13] * Inca Taqui (1953), Capitol L-243 (10" LP) * Voice of the Xtabay, Capitol W-684 (both of the above on one 12" LP) I remember that title "Voice of the Xtabay" as the record that my parents had, but I don't remember whether it was a 10-inch or 12-inch. > The most regular error in language design is, "Hey! Let's use it for > /everything/!". Welcome to the club. Yeah, Java is sorta like that, object-oriented in the strict sense that everything must be in a Class, and every Class must therefore define a type of structure with methods, even in the degenerate case where no instance variables are defined hence any instances of the class are empty of any data, and all methods are static so there's no point in ever making an instance except possibly as a marker, and in fact no instances of that Class are ever made because nobody has found a use for an object of that Class as a marker. Lisp is so much the opposite, starting with REP with APPLY and EVAL (and now FUNCALL), adding special forms and macros in a clean way, fully developing procedural programming and going a decent ways along functional programming, then introducing lexical closures and using them to emulate various levels of continuations and lazy evaluation and currying and OOP, and introducing a flexible reader with dispatch characters and reader macros which allow extending the syntax to support some classes of DSLs without needing to write a DSP (Domain-Specific Parser) from scratch, and finally settling on CLOS for fullfledged OOP beyond anything C++ or Java can do, and nicely integrating *all* those modes of programming in a consistent environment. Sure, at the time it was ANSI-standardized, it was still missing a few important things, such as UniCode support. > The only thing I read from your pattern obsession is that F# offers > nothing else. Ha ha, with friends like Harpo, Ocaml doesn't need enemies! I hope I never post anything that degrades Common Lisp as badly as Harpo degrades Ocaml. |