Live data from Hacker News

μLithp - a Lisp in 27 lines of Ruby

fogus.github.com

51–60 of 104 posts

Re: μLithp - a Lisp in 27 lines of Ruby

#52
post #49
post #47

Before this devolves into another farcical, Lisp arm-chair punditry: at 9 operators it's pretty much a kernel untyped lambda-calculus with pairs. And just that. The implementation is as trivial as the concept is profound. The discussion should be about the lambda-calculus, not Lisp, which is a far more complex beast. And much less about Lisp dialects, Greenspun's, or the usual BS topics that invariably appear on any…

If I had a little more time I would have written the uLithp eval in uLithp. The stark simplicity of that never fails to take my breath away.

Even then, it should inspire people to study the fundamentals, not go into big-language punditry :-D

Re: μLithp - a Lisp in 27 lines of Ruby

#54
post #52
post #49

Earlier quoted context omitted.

If I had a little more time I would have written the uLithp eval in uLithp. The stark simplicity of that never fails to take my breath away.

Even then, it should inspire people to study the fundamentals, not go into big-language punditry :-D

Well, I can't control everything. :-)

Re: μLithp - a Lisp in 27 lines of Ruby

#55
post #47

Before this devolves into another farcical, Lisp arm-chair punditry: at 9 operators it's pretty much a kernel untyped lambda-calculus with pairs. And just that. The implementation is as trivial as the concept is profound. The discussion should be about the lambda-calculus, not Lisp, which is a far more complex beast. And much less about Lisp dialects, Greenspun's, or the usual BS topics that invariably appear on any…

The fun part that distinguishes an early Lisp from the pure lambda calculus is the mixing of strict evaluation and call-by-need. I had to hack that a bit by making a distinction between Procs created with proc vs those with lambda and by tearing apart function bodies. I forget how the original Lisp made the distinction. It looks like I need to re-re-re-re-re-read the Lisp 1.5 manual.

Re: μLithp - a Lisp in 27 lines of Ruby

#56
post #54
post #52

Earlier quoted context omitted.

Even then, it should inspire people to study the fundamentals, not go into big-language punditry :-D

Well, I can't control everything. :-)

That was a wishful "should"; a naive statement made in the hopes of it becoming self-fulfilling, an impersonal prayer to the universe. Not an imperative directed at you.

Besides, we have better uses for you ;-)

Re: μLithp - a Lisp in 27 lines of Ruby

#58
post #50

Yeah, 27 lines. Unless you count the ~120 lines of sexpistol. https://github.com/aarongough/sexpistol

My s-expression reader is 34 lines. https://github.com/fogus/ulithp/blob/master/src/reader.rb A minimal Lisp (the bare minimal) does not require sexprs though.

A minimal Lisp (the bare minimal) does not require sexprs

Really? Why not? I realize that McCarthy's original spec used recursion equations, but that notation is more complicated than s-expressions.

Re: μLithp - a Lisp in 27 lines of Ruby

#59
post #27
post #7

Earlier quoted context omitted.

If you don't know what Lisp is, and are a programmer, it's high time to go read about its basic principles. Lisp is very simple and very powerful. Those who don't learn it are doomed to reinvent it, badly ( cough XSLT cough ).

I'm not exactly a programmer. Could you explain how Lisp can be simple and powerful?

Could you explain how Lisp can be simple and powerful?

You've asked a profound and important question, not so much about Lisp as about systems in general. A system is simple when it doesn't have many pieces. But if the pieces it starts with are very general, and the system provides good ways to put them together, then you can build complex things out of a tiny initial set.

Think of a classic Lego set. There are only a few "primitives" (different kinds of Lego piece). And there is an easy and standard way to put them together. Starting from these simple initial conditions you can construct very complex structures. Lego is simple and powerful at the same time.

How do you build a complex Lego structure? You start by putting a few pieces together to form a cluster. And then you make a second cluster and you join the two clusters together to make a third, and so on. The critical property here, the reason why Lego stays simple all the way, is that the "operation" you use to join two clusters is exactly the same operation you use to join two individual pieces – you interlock their knobby bits. In this sense your clusters are still "Lego pieces", just custom ones that didn't ship with the initial set: they still have knobby bits suitable for joining up with any other piece. This quality is sometimes called "regularity", meaning that the initial properties of the system are preserved as you put things together into ever more complex forms.

Suppose that weren't the case and that each time you reached a certain level of complexity you had to learn a new technique for building further. That would make Lego much less simple-and-powerful. You could still build complex things, but it would be harder and more complicated. And there would probably be a bunch of things that, while you technically could build them, it would be so hard and complicated to do that nobody would bother.

Programming languages also consist of a set of initial pieces and ways of putting them together. But most languages don't have the quality of regularity that Lego has. Their initial pieces aren't universal enough to get away with having only a few, so they need many more of them, and that means they're not simple, and that means they're not simple-and-powerful. There are, however, a few programming languages that do have this regularity. Lisp is one of them. Smalltalk, Forth, and APL are others.

The really interesting thing is that this kind of simple-and-powerful system enables you to do qualitatively different things as complexity grows — not because other languages can't do them, but because they make it too much trouble to bother. For example, because Lisp programs are Lisp pieces in the same sense that Lego structures are Lego pieces, it's easy to write Lisp programs that take other Lisp programs as their inputs and do meaningful things with them. That is a powerful technique, and because it's so easy, Lisp programmers exploit it heavily, more than is practical in most other languages, and that means they can do more with less.

This quality of simple-and-powerful is in my view very important and underutilized for managing software complexity. We don't yet understand it all that well, because the programming languages that achieved dominance to date don't have it.

Re: μLithp - a Lisp in 27 lines of Ruby

#60
post #9

You should use Docco for your page, I find it much more readable: http://jashkenas.github.com/docco/

I'm quite familiar with Docco having helped implement something similar for Clojure.[1] I wanted to use org-mode. Sorry it's not readable.

[1]: http://github.com/fogus/marginalia

Post reply on HN