
Is Lisp a Blub Language? - ehsanul
http://coding.derkeiler.com/Archive/Lisp/comp.lang.lisp/2007-07/msg00060.html
======
Zak
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.

~~~
silentbicycle
> 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.

------
jjs
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!)

~~~
olavk
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?

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

~~~
olavk
The philosophy is hardcoded in the design of the language. For example, the
BDFL has explicitly stated he doesn't want macros because it will hurt the
readability (1), and he rejected support for multi-line anonymous functions
because he didn't find a syntax which he thought was clear and readable
enough. Clearly this is a very different philosophy than the one behind Lisp.

(1) The quote from Guido: _Programmable syntax is not in Python's future -- or
at least it's not for Python 3000. The problem IMO is that everybody will
abuse it to define their own language. And the problem with that is that it
will fracture the Python community because nobody can read each other's code
any more._
([http://mail.python.org/pipermail/python-3000/2006-April/0002...](http://mail.python.org/pipermail/python-3000/2006-April/000286.html))

~~~
swannodette
_Programmable syntax is not in Python's future -- or at least it's not for
Python 3000. The problem IMO is that everybody will abuse it to define their
own language. And the problem with that is that it will fracture the Python
community because nobody can read each other's code any more_

I like Python and use it everyday, and I this is simply FUD. Sadly it's the
kind of argument I hear coming too often from people in the Python community
unfamiliar with Lisp when attempting to critique powerful Lisps.

~~~
demallien
Is it really FUD though? Having gone through a few bruising experiences with
different libraries having incompatible object systems built in Javascript, I
have come to appreciate the advantages of only having one way to implement
certain types of structures.

It doesn't need to be hard-coded into the language though - a decent Standard
Library showing how things _should_ be done, and a culture maintained by the
community would be enough. That would allow everyone the freedom to do what
they want if they say a definate advantage in breaking with convention, whilst
making it easy for people to generate libraries that are interoperable...

~~~
lispm
I think macros do have certain disadvantages (they make debugging seem to look
harder, more syntax, etc, ...).

But I find things like extensive use of MOP also make maintenance of
programming more challenging.

Common Lisp has never tried to take away 'power' from users.

Scheme had a different philosophy: reduce everything to the most basic and
pleasing constructs. But that approach has its own disadvantages - if one
arrives at the bottom of programming language constructs, working 'upwards' is
a problem.

Take for example the argument lists: Common Lisp has things like keywords,
optional and rest arguments. Plain Scheme only has rest arguments. Adding
other argument interpretation is possible, but is only really use if the
language would support it and would make use of it.

------
programnature
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.

~~~
noelwelsh
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...](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.2004))
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.

~~~
programnature
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.

~~~
hga
How close does Qi
(<http://en.wikipedia.org/wiki/Qi_%28programming_language%29>) come to what
you desire?

------
mixmax
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 :-)_

~~~
zephjc
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

~~~
mixmax
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?

~~~
Zak
Generating HTML from Lisp is very easy and natural. Of course, there are
situations where it might be better to use an HTML template, and there are
libraries for that too. Here are a few more examples of HTML generation in
Lisp:

A tutorial about writing an HTML-generating DSL in Common Lisp:
[http://gigamonkeys.com/book/practical-an-html-generation-
lib...](http://gigamonkeys.com/book/practical-an-html-generation-library-the-
interpreter.html)

The Common Lisp HTML generation library most people actually use[0]:
<http://weitz.de/cl-who/>

HTML generation in PLT Scheme's Continue framework: [http://docs.plt-
scheme.org/continue/index.html#(part._.Rende...](http://docs.plt-
scheme.org/continue/index.html#\(part._.Rendering_.H.T.M.L\))

Arc's built-in HTML generation (powers this site):
<http://files.arcfn.com/doc/html.html>

[0] I'm not actually certain about that, but I think it's the most popular.

------
defdac
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.

------
cabalamat
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.

~~~
silentbicycle
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.

~~~
cabalamat
> _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.

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

------
programnature
(@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.

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

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

