Is Lisp a Blub Language?

http://coding.derkeiler.com/Archive/Lisp/comp.lang.lisp/2007-07/msg00060.html

by ehsanul • 16 years ago

39 76 16 years ago

coding.derkeiler.com

Pattern matching is the missing feature. I keep thinking about switching to Clojure from Mathematica, but then I think "How can anyone get anything done in Clojure? It doesn't even have pattern matching."

Its not something that can get patched in a library, because the way symbols and evaluation need to work is different (and simpler) than in a Lisp. There is no distinction between macro-s and nonmacros - everything is just a tree transformation.

The main benefit of first-class pattern matching is that your function definitions get a lot more succinct and expressive, since you can encode quite a lot of information in the structure of the arguments, and elegantly unfold the definition from the short and common case to a parameterized sequence of generalizations.

lispm13• 16 years ago

Putting structure assumptions into function argument lists is not necessarily a good idea. One exposes the implementation.

Pattern matching function definitions are easy to do in Lisp.

But given the nature of Lisp, much of the pattern matching then needs to be done at runtime - which leads to less efficient code and invites people to write totally inefficient code.

programnature7• 16 years ago

Consider the Mathematica function Take[], which would save millions of man hours if it existed in other languages.

Take[{a,b,c,d},2] --> {a,b}

Take[{a,b,c,d},-2] -> {c,d}

Take[{a,b,c,d},{1,3}] -> {a,b,c}

Take[{a,b,c,d},{1,-1,2}] -> {a,c}

Take[{{a,b,c,d},{1,2,3,4},{5,6,7,8}},2,2] -> {{a, b}, {1, 2}}

etc. In my book this is clearly useful, and its only scratching the surface. ( {} is actually List[] in Mathematica FullForm ... )

The point of symbolic representation is to represent the intended meaning. Its nothing about the "internal" implementation. Using symbols and simple tree structures to compactly express stuff is extremely powerful, and not coincidentally the essential way that human language works.

Sure, with a sufficiently dynamic language you can implement such functionality. The problem with Lisp is that by default symbols want to evaluate, and if you want to treat them symbolically you have to operate in a "special" mode. This makes things too complicated. There is a reason you don't see meaning represented by structure in pretty much any other language besides Mathematica.

smanek• 16 years ago

I certainly miss ML-style pattern matching when I'm in Lisp. I sometimes find myself (poorly) simulating the idea with a whole bunch of multi-method specializers.

Based on my limited experience, it seems like you'd really need a more static type system to make the most of pattern matching though. Are there any dynamically typed languages with powerful/useful pattern matching?

_delirium• 16 years ago

As far as doing it in Lisp goes, this is an interesting attempt: http://common-lisp.net/project/cl-match/doc/clmatch.htm

lispm13• 16 years ago

Prolog

kunley• 16 years ago

Erlang of course.

noelwelsh2• 16 years ago

What exactly do you mean by pattern matching? I understand it in the ML sense. The Lisp language I use, PLT Scheme, has extensible pattern matching: http://docs.plt-scheme.org/reference/match.html The implementation isn't simple but the techniques are published (see "Pattern matching for Scheme" http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.2...) so any Lisp language could implement this. Clojure has less powerful pattern matching, but it does the most common stuff.

The linked article is really about Common Lisp, where the issue is a standard that hasn't been updated in a long time. This doesn't stop individual implementations from making their own advances but in my limited knowledge of the CL implementations this doesn't seem to be occurring.

lispm13• 16 years ago

you might check sometimes the documentation of CL implementations for the advances that they provide over the standard

aerique• 16 years ago

This is actually occurring. Most advances are made in cross-platform libraries (networking, regexps, threading, pattern matching, lazy evaluation, etc.) but some implementations have their own extra that make them interesting (by no means an exhaustive list):

ABCL (http://common-lisp.net/project/armedbear/) runs on the JVM.

CCL (http://www.clozure.com/clozurecl.html) has excellent integration with Objective-C and Cocoa on OS X.

ECL (http://ecls.sourceforge.net/) is easily embeddable in C / C++.

The commercial offerings Allegro CL (http://www.franz.com/products/allegrocl/) and LispWorks (http://www.lispworks.com/) keep on improving and extending their own implementations in interesting ways.

programnature7• 16 years ago

Good question. Here is what I mean:

1. Pattern matching as the basis for function definition, to determine which code executes and expedite argument destructuring.

2. Patterns themselves should have first-class representation (preferably symbolic), so you can generate them in one place and use them in another.

3. Implicit in this is that the structure of the language is systematic enough to make this worthwhile, meaning something s-expression based, or perhaps something like Scala that achieves similar ends in a much different way.

Zak5• 16 years ago

A little bit of googling gave me the sense that pattern matching in Mathematica is different from the pattern matching present in several functional languages. Please let me know how these Clojure features differ from that:

Clojure has pattern matching for the arguments in a function definition similar to ML or Haskell. It's often used as a more verbose alternative to optional args, but it's more powerful fundamentally.

Clojure has destructuring in binding forms like let, described here: http://clojure.org/special_forms

Clojure has multimethods which let you pick the method to use based on an arbitrary dispatch function.

There's a pattern matching macro that seems to be the beginning of a DSL for predicates: http://www.brool.com/index.php/pattern-matching-in-clojure

programnature7• 16 years ago

There is 1 mechanism instead of 4, and it also happens to be the fundamental basis of evaluation.

There is no way to measure "absolute power" of elegance, which is the issue being gotten at here.

Not to say Mathematica has it gotten it perfect either, because it hasn't. But I have yet to see a superior implementation, and have seen a lot of clunky ones in my search.

jpr2• 16 years ago

If you don't know how to write a pattern matching library in Lisp, you don't really know Lisp and should probably refrain from spreading misinformation about it.

jjs4• 16 years ago

Blubness of a language comes from its practitioners not knowing about useful features from a higher-level language (or not grasping the utility of such a feature).

If your favorite Lisp lacks a certain feature you want, it's easy to add, making Lisp the anti-Blub.

(And if your favorite Lisp makes it hard to add it, you've picked the wrong favorite!)

fauigerzigerk2• 16 years ago

Some things are difficult to add even to Lisp. Static typing being an example.

lispm13• 16 years ago

right, that's a good example

magv• 16 years ago

Difficult, but not impossible. Qi and Typed Scheme are two examples.

noelwelsh2• 16 years ago

As MagV mentioned, Typed Scheme (http://www.ccs.neu.edu/home/samth/typed-scheme/) is an example of static typing in a lisp-like language. I've used it, and it is great. It interoperates smoothly with the normal dynamic typed Scheme. Typing is at the module level (a module must be either statically or dynamically typed) and contracts (http://doc.plt-scheme.org/reference/contracts.html) are used to enforce invariants at module boundaries.

olavk2• 16 years ago

Some features are not easy to add. For example, one important feature of Python is that the language is designed with consistency and readability in mind, and combined with the "preferably one obvious way to do it"-ideal means that code written by other people is easier to read and understand. This makes code and knowledge sharing easier, and the network effect creates a blooming ecosystem for libraries.

How do you easily add that feature to your favorite Lisp?

floater2• 16 years ago

Your example is a feature of the Python philosophy (or community) not the Python language.

randallsquared• 16 years ago

With Common Lisp, you'd create a library with a package, say, consistent-lisp, and clone all the features of common-lisp into it, except with consistent, readable names and with any other fixes like argument order, etc. The actual language part of this is not hard to do, it's the community part that's difficult.

Estragon• 16 years ago

Were there any interesting suggestions in the reply to the op?

Zak5• 16 years ago

I find in certain cases that I'm looking across the power spectrum from the Lisp point of view. I recently ported some code from Haskell to Clojure and occasionally found myself missing Haskell's amazingly expressive type system. Trying to give Lisp such a type system would make a lot of things that are currently easy in Lisp hard or impossible.

There are certain kinds of mutually exclusive features that make certain kinds of problems easier or harder. Examples that come to mind are mutability vs immutability and static typing vs dynamic. Most of the things I sometimes find lacking in the Lisps I'm familiar with are of this sort.

silentbicycle5• 16 years ago

> There are certain kinds of mutually exclusive features that make certain kinds of problems easier or harder.

Right. The fundamental problem with the whole "blub" argument is that there isn't one linear continuum of language power. There are problems for which Erlang's supervision hierarchy and distribution primitives or Prolog's backtracking are a killer feature. This doesn't mean they're "More Powerful than Lisp", just better suited to certain kinds of problems because they committed to some very specific trade-offs.

But, these same trade-offs have far-reaching implications for the language semantics, so you can't just use macros to graft them on after the fact. You can embed a mini-Prolog in Lisp, sure, but adding fully native logic variables (as in Prolog or Oz) would be far from trivial.

defdac• 16 years ago

So how many here can take any problem and use any language to solve it language-optimally with all known best practices with the least amount of code?

How do you figure out that one language is better than another for a given context where hundreds of people with 10 years of experience with language X would solve a problem faster and more elegant with language Y and zero experience?

Are the people finding certain languages unreadable and ugly really the people that should decide what language to use for a problem at hand? Or the experienced craftsmen with expertise in their old, ugly and "unredable" language?

Personally I find it rather funny and ironic that noobs are the ones driving the language of choice because they have learned how good their new and powerful language is - and because they are having trouble reading anything else.

In this way the noobs get an edge over Old-timers with years of experience that actually know how to write beautiful code in their old ugly language.

The noobs doesn't realize this until their favourite language is considered old and obsolete by even newer noobs, and they start to call themselves Old-timers..

I think most people will have a native language where they express themselves better and more elegant than any other language. They will probably solve any problem faster with their native language compared to the optimally correct besserwisser language. I bet their solution would be more readble and elegant too, compared to be using a language they don't have any experience with.

programnature7• 16 years ago

(@lispm Looks like our symbolic language flame war has exceeded yc metrics)

Yes, I understand what ' does. You are manually controlling evaluation. The same way, once upon a time, people manually controlled garbage collection.

Having a+a explode by default means that the whole time you have to be juggling what is intended to be used symbolically or not. This seems to not be a 100% perfect realization of the code == data paradigm.

I'm glad you now agree that structure is a good way to encode meaning. Now, what is a more idiomatic way to manipulate that information? Walking the tree manually, or expressing those patterns of structure directly?

Unfortunately, in Lisp, you need to "evaluation manage" those structures. And its not just quote, its the whole macro language with its own idiosyncrasies. Its just a lot easier to have a single elegant system with the right defaults.

I'm the kind of person who implements models of computation as a recreational activity. I've probably wished for more granular evaluation control 1% of the time, but having civilized pattern matching (and representation) has vastly increased productivity and code density.

lispm13• 16 years ago

I haven't said anything about encoding of meaning, you are dreaming.

You are the kind of person of Xah Lee...

silentbicycle5• 16 years ago

Do you know Prolog? It sounds like it might appeal to you. Rather than evaluating expressions, it does pattern matching (unification, really) on data structures, rewriting and evaluating them as specified. It can pass around uninstantiated variables and do depth-first search* through known facts/rules to find complete matches, backtracking when it hits dead ends or alternative solutions are requested.

Rather than saying Prolog has pattern matching, it almost makes more sense to say it is pattern matching. It's very central to its model of computation.

* Breadth-first and other search techniques are easy to write, depth-first is just the default.

jjs4• 16 years ago

Yes, I understand what ' does. You are manually controlling evaluation. The same way, once upon a time, people manually controlled garbage collection.

I don't think you've thought this through.

If (+ a a) evaluated to (+ a a), then code would not be data, because there would be no code, only data.

There is a compiler for this ideal, pure-declarative language: it's called cat.

Alternatively, you could have a separate bracket type for evaluation, but that doesn't solve your complaint.

Unfortunately, in Lisp, you need to "evaluation manage" those structures. And its not just quote, its the whole macro language with its own idiosyncrasies.

The macro language is called Lisp.

Its just a lot easier to have a single elegant system with the right defaults.

If you don't grasp macros, then Lisp will seem useless to you. This is actually the origin of the term Blub.

I'm the kind of person who implements working Lisps as a recreational activity. I guarantee you that adding a (def/pat ) pattern matching function definition form is just a macro away (and already exists in some Lisps).

At that point, you don't need to manually quote your patterns, which I believe addresses the remainder of your objections.

cabalamat2• 16 years ago

No.

I'll explain why: all languages are in some sense equally expressive, because they are Turing-complete. But some languages don't have particular abstractions, for example classes; so in that sense they are not expressive, because you can't express those abstractions.

But Lisp has macros. This means that any abstraction it doesn't yet support, you can add.

silentbicycle5• 16 years ago

No, because you can't add language invariants (guarantees that thing X will never happen), and without invariants such as pervasive immutability, certain features are impossible to add.

While it's possible to add features to Lisp that are at odds with its fundamental model of evaluation, it's usually done by adding an interpreter (or, occasionally, compiler) for a nested sublanguage. There are several interpreters in SICP and EoPL, several Lisp books have a mini Prolog, etc. This is handy (and Lisps do make it relatively easy), but you can't graft something like Erlang's entire semantics onto Lisp with just macros.

cabalamat2• 16 years ago

> No, because you can't add language invariants (guarantees that thing X will never happen)

That's true. Macros aren't a perfect solution.

> without invariants such as pervasive immutability, certain features are impossible to add.

As are certain optimisations.

> While it's possible to add features to Lisp that are at odds with its fundamental model of evaluation, it's usually done by adding an interpreter (or, occasionally, compiler) for a nested sublanguage.

Indeed, which is in a certain sense cheating.

If one is designing a language, and one hopes that one's language will become popular, then it's likely (in fact inevitable) that the language will be used for tasks that the designer hasn't anticipated. So how can a designer cater to this? Macros are one way, and IMO a powerful one.

Another is to make the language so that it is easy to mix-and-match it with other languages, so that it can call code in other languages, be called by other languages, use common data structures and serialisation formats, etc. Implementing in the JVM goes some way to meeting this goal.

ramchip3• 16 years ago

Macros aren't always a great solution. I think Haskell is the best example: many features, such as the lazy evaluation, the type system, and especially referential transparency would be very hard to add on Lisp without making it very verbose and ugly. Here's an example:

http://marijn.haverbeke.nl/monad.html

mixmax2• 16 years ago

Aren't all languages blub languages depending on the usecase?

If you write AI programs c++ is a blub language. How can you get anything done without macros?

If you program drivers PHP is a blub language. How can you get anything done without direct access to the hardware?

If you're doing webapps lisp is a blub language. How can you get anything done with a syntax that's so different from HTML and so difficult to read?

The whole premise of a blub language depends entirely on what you're trying to accomplish - the right tool for the right job.

Disclaimer - I'm not much of a programmer, so maybe my examples don't hold up, but you get the idea :-)

swannodette2• 16 years ago

I actually picked up Clojure because I was:

Tired of having to write C++ to get decent graphics performance.

Tired of having to write C++ to get decent audio performance.

Tired of my cool dynamic web programming languages not being fast enough to do the above.

Tired of Python, Ruby, C++, C, Java, Objective-C, JavaScript having so little to offer in the way of elegant concurrency.

So I picked a Lisp because it could do more.

zephjc2• 16 years ago

Disclaimer noted, but as to your lisp/HTML example, HTML and lisps actually have a lot in common - if you strip away the end tags and the angle brackets, you get something very lispy looking

    <div>
      <span>Hello</span>
    </div>

has the same (prefix) order of operators and operands as

    (div
      (span "Hello"))

Off the top of my head, the "hiccup" package for Clojure has an 'html' function (macro?) that translates just that sort of stuff directly into html

ramchip3• 16 years ago

Also, AFAIK people generally use Lisp to generate HTML, not as a replacement to HTML.

mixmax2• 16 years ago

Interesting. Do you by any chance have links to some newbie resources? Maybe it's worth reading up on some sort of lisp. Clojure maybe?

ramchip3• 16 years ago

A "blub language" isn't an inferior language, or one with less features. It's a language in the middle of the ladder that goes from assembly to the ideal language. All the languages you described except Lisp are, in PG's mind, blub languages. Notice that Lisp can be applied to every of your examples: just use it as a code generator (which is very commonly the case for HTML, and I've seen it done for C as well), or use an appropriate dialect (eg. bitc for low-level, arc or clojure for web programming, CL for AI).

What you're describing is just a less powerful or a less appropriate language.

Is Lisp a Blub Language?

Related Stories