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

31–40 of 81 posts

Re: Is Lisp a Blub Language?

#31

Post by fauigerzigerk »

lispm wrote: post #29
fauigerzigerk wrote: post #27

Earlier quoted context omitted.

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

right, that's a good example

On the other hand you could make an argument that static typing isn't actually a language feature as much as it is a step in the process of programming.

Static typing consists of (a) tagging variables with their type and (b) running a program that uses these type tags to check and/or rewrite the program.

It's easy to add type tags to a lisp program. It's just that Lisp doesn't specify that second program that checks and transforms the first. So I would say Lisp is half way there when it comes to static typing.

That's a pretty contrived argument though... :-)

Re: Is Lisp a Blub Language?

#32

Post by crististm »

jjs wrote: post #12
programnature wrote: post #10

Earlier quoted context omitted.

What is ' other than a special mode? The fact is that symbols are treated more systematically in Mathematica, and that makes it easier to assemble and dissemble symbolic structures of all sorts. Sounds like a case of blub. You look at Mathematica and see some weird stuff that is probably equivalent in power to multimethods or whatever, I look at Lisp and think how can I possibly live without civilized pattern matchin…

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

it's a shortcut to quote

Re: Is Lisp a Blub Language?

#33

Post by Zak »

magv wrote: post #30
fauigerzigerk wrote: post #27

Earlier quoted context omitted.

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

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

It's hard to add static typing (and get much utility out of it) without forcing its use. If you do that, you lose dynamic typing.

Re: Is Lisp a Blub Language?

#34

Post by hga »

programnature wrote: post #16
noelwelsh wrote: post #8

Earlier quoted context omitted.

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

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, mean…

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

Re: Is Lisp a Blub Language?

#35

Post by lispm »

fauigerzigerk wrote: post #31
lispm wrote: post #29

Earlier quoted context omitted.

right, that's a good example

On the other hand you could make an argument that static typing isn't actually a language feature as much as it is a step in the process of programming. Static typing consists of (a) tagging variables with their type and (b) running a program that uses these type tags to check and/or rewrite the program. It's easy to add type tags to a lisp program. It's just that Lisp doesn't specify that second program that checks…

no, adding type declarations to Lisp is the easy part. when it comes to static typing, standard Common Lisp offers very little.

Declaring types? That has been done. In Common Lisp:

    (defun twice (n)
      (declare (number n))
      (the number (* n 2)))
The difficult parts are:

* the type system and its capabilities

* make the operations of the type system sound

* determining sub-types

* type inference

* integration with the rest of the language (where data objects also have something like types)

Common Lisp provides lots of infrastructure for all kinds of things, but very little for a type system. For example in Lisp one can determine the value of an expression via EVAL, but there is no function to compute the type of an expression (other than a type of the computed value).

Re: Is Lisp a Blub Language?

#36

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

Re: Is Lisp a Blub Language?

#37

Post by olavk »

jjs wrote: post #14

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

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?

Re: Is Lisp a Blub Language?

#38

Post by floater »

olavk wrote: post #37
jjs wrote: post #14

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

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

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

Re: Is Lisp a Blub Language?

#39

Post by silentbicycle »

lispm wrote: post #9
smanek wrote: post #4

Earlier quoted context omitted.

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?

Prolog

Prolog has unification, which is considerably more powerful than just pattern matching. The semantics of Prolog require the ability to unify data structures with some parts not-yet-specified, and backtrack later if they cannot be bound to something valid. In contrast, pattern matching happens all at once and is unidirectional. (Though even basic pattern matching is tremendously useful, IMHO.)

Erlang's pattern matching is somewhat like Prolog's, but with backtracking removed. (Backtracking clashes with Erlang's other semantics.)

Re: Is Lisp a Blub Language?

#40

Post by silentbicycle »

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…

> There is a reason you don't see meaning represented by structure in pretty much any other language besides Mathematica.

Actually, this is done in Lisp and Prolog all the time.

Off the top of my head: J, K, Haskell, and Joy have take functions, and writing them in Lisp and Prolog is not difficult.

Post reply on HN