Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is Lisp a Blub Language?

coding.derkeiler.com

Post reply on HN
Print view View original

51–60 of 81 posts

Re: Is Lisp a Blub Language?

#51

Post by jjs »

crististm wrote: post #32
jjs wrote: post #12

Earlier quoted context omitted.

What is ' other than a special mode? I usually implement it as a reader macro. :)

it's a shortcut to quote

it's a shortcut to quote

Yep.

My comment was about implementing one's own Lisp reader.

    (define *reader-macros* `(
      (#\' ,(lambda () (list 'quote (read))))))
instead of

    (case dispatch-char
      ((#\') (list 'quote (read)))
      ...)

Re: Is Lisp a Blub Language?

#52

Post by 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.

Re: Is Lisp a Blub Language?

#53

Post by lispm »

programnature wrote: post #5
lispm wrote: post #3

Earlier quoted context omitted.

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.

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 Full…

Wow, Lisp has Take. I wrote one. It took me a few minutes:

    CL-USER 58 > (take '(a b c d) 2)
    (A B)

    CL-USER 59 > (take '(a b c d) -2)
    (C D)

    CL-USER 60 > (take '(a b c d) '(0 3))
    (A B C)

    CL-USER 61 > (take '(a b c d) '(0 -1 2))
    (A C)

    CL-USER 62 > (take '((a b c d) (1 2 3 4) (5 6 7 8)) 2 2)
    ((A B) (1 2))
That was easy.

Re: Is Lisp a Blub Language?

#54

Post by weavejester »

programnature wrote: post #5
lispm wrote: post #3

Earlier quoted context omitted.

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.

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 Full…

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

So you're saying that variable bindings should be lazy? That if a symbol is not bound to a value, it should be treated as an unevaluated symbol?

I'm not quite certain what your point is. The actual functionality of Take can be easily replicated in most languages, and indeed, most languages have a version of Take called "slice".

But if your example is meant to demonstrate why lazy symbol evaluation is good, then I'm afraid it fails on that point too. There doesn't seem to be anything in your example that is particularly noteworthy.

Could you perhaps explain your point in more detail?

Re: Is Lisp a Blub Language?

#55

Post by lispm »

yummyfajitas wrote: post #50
lispm wrote: post #7

Earlier quoted context omitted.

It looks like you have never programmed in Lisp. A function like Take is easy to write in Lisp. Lisp has many similar functions like that - but with a better interface. > There is a reason you don't see meaning represented by structure in pretty much any other language besides Mathematica. Could it really be that you missed the AI software that has been written in Lisp in the last five decades?

Take is a really terrible example, even python has take built into the syntax (Take[lst, 2] -> lst[0:2]). But Mathematica does have nice pattern matching which few lisps have: SolvePoly[a_*x+b_=0] := { -b/a } SolvePoly[a_*x^2+b_*x+c_=0] := \ { (-b + sqrt(b^2-4*a*c))/2a, (-b - sqrt(b^2-4*a*c))/2a } SolvePoly[_] := "I only took high school algebra" Of course, in principle one could write a pattern matching macro in lis…

The point was not lst[0:2] in Python. See the definition of Take in Mathematica - it is quite a bit more capable.

You need also differentiate between 'pattern matching' and 'rewrite system'. Pattern matching is just taking a pattern, some data and see if it matches.

    (match '(+ (* ?a x) ?b) '(+ (* 123.0 x) z)) -> T
Routines like the above are found in many books about Lisp and have been provided in Lisp libraries for decades.

Specifying rewrite rules with patterns for mathematical purposes (simplification, integration, differentiation, ...) is also almost as old as Lisp. Norvig's book 'Paradigm's of AI Programming' explains how it is implemented in Lisp. These things are at the heart of several computer algebra systems written in Lisp - like Macsyma.

Re: Is Lisp a Blub Language?

#56

Post by 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 :-)

Re: Is Lisp a Blub Language?

#57

Post by swannodette »

olavk wrote: post #46
floater wrote: post #38

Earlier quoted context omitted.

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

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 synt…

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.

Re: Is Lisp a Blub Language?

#58

Post by swannodette »

mixmax wrote: post #56

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…

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.

Re: Is Lisp a Blub Language?

#59

Post by silentbicycle »

cabalamat wrote: post #52

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.

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.

Re: Is Lisp a Blub Language?

#60

Post by jjs »

programnature wrote: post #36

(@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 == d…

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

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.

Post reply on HN