Ask HN: Could a Lisp be Blub?

There are languages that have useful features that lisp lacks. For example, Haskell has lazy evaluation and automatic compiler generated program correctness proofs (a decent type system).<p>Then there are languages that try to be even more powerful than Haskell, for example Epigram, which has dependent types.<p>Lazy evaluation is probably the language feature that is most mainstream that lisp lacks. For those not familiar with the abstraction benefits of lazy evaluation, consider a library for dealing with prime numbers. In a language without lazy evaluation, you are going to need an API with a function for getting the n_th prime number, a function for testing if a number is a prime number, a function for getting the smallest prime number larger than the number x, and a bunch of other functions.<p>In Haskell, the API only needs a single variable, called "primes" that is simply the infinite list of all the prime numbers:<p>primes :: [Integer] -- primes is of type list of Integer<p>Thanks to lazy evaluation, this single variable is all that is needed to support all of the above operations in an efficient way. For example, to get the n_th prime number you simply write (primes !! n)<p>Now, this may look cool, but what does it have to do with abstraction? Since "primes" is a regular list, I can use it with any list function and build more complex things out of it. I can also have a list of all the catalan numbers in the same way, and all my functions that I've written that do cool things with the prime numbers can now be instantly used against catalan numbers.<p>You can manually do lazy evaluation in languages that don't natively have it, but unless you do it everywhere you won't get the abstraction benefits, and if you do do it everywhere then the compiler almost certainly will not be able to optimize it as well as a native implementation.

How could you cripple such things? Well, first, culture. The primary difference between Ruby and Python is culture; the languages enable virtually identical styles of programming in practice (spelled slightly differently, but basically the same), but the cultures encourage different practices, such as how they feel about monkeypatching. Neither of these cultures "cripples" the language, I just use this as an example of the power of culture. You could cripple a powerful language with some sort of powerful pedagogical culture that made the powerful idioms verboten (because they're "too complicated", "unmaintainable", etc.).<p>A good language should make the right thing easier than the wrong thing. You could cripple a language that has all those bullet-point features by making putting hoops to jump through in the way of using macros or first-class functions. A klunky syntax, some sort of extra typing information to be manually added at every macro invocation, extra-verbose S-expressions, etc.<p>A REPL could be crippled by making it less than a full REPL, such that there are things that you still have to build modules for. See Erlang's REPL, which is <i>mostly</i> nice, except you can't define new records or do a handful of other useful things.<p>The most likely way this could happen is a language that tries to be LISP while still looking as much like C(++/#) as possible, and bringing over impedance-mismatched concepts better left in C(++/#). The second-most likely would be in some way constraining the power so as not to scare programmers or so as to avoid some "trap"; for instance, see Java's dropping of multiple inheritance. Thus, even though Java has "OO", it is less powerful than a Java that had MI too. You might have a "first class function" that is somehow limited to be less useful. (Perhaps you get first-class functions, but themselves are not allowed to return functions, only "values".)<p>Do not underestimate the power of language implementors to cripple a language, both intentionally and otherwise.

<i>Could a language ... cater to average programmers and be despised by hackers?</i><p>Who a language "caters to", who an "average" programmer is, and who a "hacker" is are all social constructs which have no relationship to the objective reality of what features are in a language. People who wish to assert their superiority are quite willing to do so regardless of the technical merits of the matter.<p>Thus, rather than wasting one's time with meaningless geek-on-geek pissing matches, you should probably just get back to writing software which solves problems for people. You can do that in most languages -- even in Lisp.

I've been thinking about this again because of the recent re-post of one of pg's Lisp essays (one of the two that originally provoked me into learning Lisp). The essay makes an argument that the answer to your question is roughly "No". The argument goes like this: no language that lacks Lisp-style macros can be as powerful as Lisp. Macros aren't possible without code=data, and code=data comes from sexps. But any language that represents programs as sexps is a variant of Lisp. So the only language that can be as powerful as Lisp is another Lisp.<p>Now obviously we can argue about how to define "powerful", and the whole discussion can easily become another pointless language flamewar. But let's not do that. Let's provisionally grant the essay its definition of "powerful" and the corollary that Lisp macros are currently the apex of that power. The question is, is a more powerful (in this sense) language possible? (You don't have to agree with that definition of "powerful" to find the question interesting, by the way. Just rephrase it as, could another language beat Lisp at its own game?)<p>In my mind I've always referred to the above argument rather pompously (i.e. half-jokingly) as "Graham's Thesis" (because it reminds me of what used to be called Church's Thesis when I studied logic - it's a non-provable-because-non-formal assertion that expresses an intuition about something - in that case computability, in this case programming languages). We can state Graham's Thesis as: <i>Any programming language that's as powerful as Lisp is isomorphic to Lisp.</i><p>So, is this true? The critical thing is code=data. Is there a fundamentally non-Lispy way to represent code as data, that's as good or better for programming than sexps? (That qualifier is important, because there are definitely ways to represent code as data that make a lousy notation for programming, e.g. machine language.) If there is such a representation, then a language based on exposing it as notation could be as powerful as Lisp without being Lisp. But if there isn't, then variations of sexps are the only game in town, and those don't count as new languages. Replacing parentheses with different brackets, as was suggested here either trollingly or stupidly the other day, doesn't cut it.<p>As anyone who's seen a Lisp program and knows the first thing about a compiler knows, sexps are just the simplest notation for a syntax tree. That is, the thing that parsers turn programs in other languages into, Lisp programs just are. That makes sense, because parsers turn source code into data, and Lisp programs just <i>are</i> data. And any language in which you write programs as parse trees is Lisp (or will soon become Lisp as people add the obvious things you'd want in such a language).<p>So Graham's Thesis (man I feel silly writing that) reduces to the following: <i>the only representation of programs suitable as both a data structure and a notation for human programmers is the syntax tree</i>.<p>I'd really like to know if this is true. (Apologies to anyone who read my comment on this here the other day, as I'm repeating myself.) What languages are there whose source code gets turned into something that is fundamentally not a syntax tree? And what would the simplest explicit notation for that structure look like? I think this would be the area in which to look for an answer to the question.<p>There's one thing that makes me think such a representation might not exist: sexps are really just function composition, and function composition is how humans have done math for a long time. But if one does exist, I'd like to see it. There are a lot of people here with much wider backgrounds in programming languages than mine, so perhaps someone can just answer this.

Yes: <a href="http://weblog.raganwald.com/2006/10/are-we-blub-programmers.html" rel="nofollow">http://weblog.raganwald.com/2006/10/are-we-blub-programmers....</a>

Any language could be "blub". You're talking about a power continuum. If something more flexible than lisp gets discovered, then lisp could ostensibly be less powerful than <i>"New Language X"</i> for the developer.

Clojure risks heading that way; for all its beauty, clojure is losing its <i>culture</i> fast! You can already see Design Patterns being shoehorned on top of it, Java programmers will embrace it and extend it in earnest.<p>The sort of applications being written with the language are a huge factor in making it attractive to other users. All the truly beautiful languages had operating systems or huge desktop applications written in them; you used the language to extend something already powerful. It rewards your programming. Clojure will most likely become a server-side programming language, with little user interaction.

The blub argument is about not understanding that there are tools out there that do things that you can't currently imagine due to your immersion in your current toolset or a very narrow world view.

Cadence's SKILL seems to be a pretty good attempt. Looking at it still gives me the willies.<p><a href="http://en.wikipedia.org/wiki/Cadence_SKILL" rel="nofollow">http://en.wikipedia.org/wiki/Cadence_SKILL</a>