Random Hacks: Why Ruby is an acceptable LISP

"Why Ruby is an acceptable LISP" by Charlie Lindahl

Thu, 13 Dec 2007 20:18:46 -0500

I worked for a number of years on LISP machines at Texas Instruments in the 80s

One of my points is : it’s the environment. Not just the IDE; in LISP and Smalltalk environments EVERYTYHING is written in the language in question/use (with the exception of machine-specific low-level stuff required to talk to the OS / machine architecture).

What this means (not great for a general business case, but incredible for learning and expressive power) is that I can actually take apart / customize / study the underlying OS and/or tools.

So, for example, say you don’t like the way EMACS works. Go grab the source (a keystroke away in LISP IDEs) and go plowing through it with the IDEs/debuggers and rewrite it to your specifications.

I learned the Macintosh Toolbox structure by running Lisp on the Mac and dissecting the window data structures (on the fly / realtime ) without needing to have source code.

Once Ruby gets to the point of this kind of power in the environment, inspection, and debugging it’ll be amazingly powerful.

Quite good now from what I’ve seen so far.

My $.02

Charlie Lindahl
Houston, TX

"Why Ruby is an acceptable LISP" by Timmy Jose

Thu, 18 Jan 2007 06:18:08 -0500

For a programmer used to C/C++ and JAVA and having merely studied the rudimentaries of Lisp in college ( as part of A.I ) and having had to content myself by looking at Ruby from the sidelines till now, I found this thread extremely interesting. It was all a bit one-sided though with Lispers outnumbering Rubyists (?) by a huge ratio! In my opinion, the syntax of Lisp seemed to be more in tune with my liking than Ruby’s. I think I’ll take the plunge with Lisp and see where Ruby fits in later. Good job on the discussion people!

"Why Ruby is an acceptable LISP" by A Total Coward

Wed, 17 Jan 2007 21:50:32 -0500

bill a: your links to LoaL are all 404s. Did this stuff every see any daylight?

"Why Ruby is an acceptable LISP" by David A. Wheeler

Mon, 15 Jan 2007 01:35:39 -0500

One problem with traditional Lisp notation is that it’s fairly hard to read—and as programs get bigger, it gets worse. It’s especially nasty when you use operators that are traditionally infix operators, e.g., (+ 3 (* 2 3)) may be a regular syntax, but even Graham admits it’s awkward.

I’ve developed a notation called “sweet-expressions” which I think are easier to read. A sweet-expression readers can read normal s-expressions, but can also accept other formats. It still works with all the macro constructs, etc., of Lispy languages. More info is here: http://www.dwheeler.com/readable/

"Why Ruby is an acceptable LISP" by Eric Kidd

Sun, 14 Jan 2007 21:20:26 -0500

Chris Rathman: I thought I’d mention my pet project to translate the SICP examples into these languages.

Oh, that’s really cool. Thanks for the link!

"Why Ruby is an acceptable LISP" by gar37bic

Sun, 14 Jan 2007 15:46:48 -0500

I also often ‘scrape’ (with permission) HTML, SQL, CVS, PDF, DOC and other files off the net, to generate input data for our company’s data mining operation, for example corporate federal and SEC filings.

And right now I’m scripting OpenOffice to do file format conversions to .DOC …

"Why Ruby is an acceptable LISP" by gar37bic

Sun, 14 Jan 2007 15:43:08 -0500

This is a great discussion, and has been very informative for me. I’m thinking about which language I want to tackle next, primarily for research into areas such as neural networks.

In my real life, I spend a lot of time writing heuristic filters based on regular expressions – (typically using PCRE: ‘perl-compatible regex’, though I don’t use Perl) – to do things like parse, filter, sanitize and combine multiple legacy datasets into one ‘canonical’ set. This often requires running other programs to pre-sort incoming data streams, and then maintaining arrays of match-probability scores for possible matches. How would these languages address problems such as these?

"Why Ruby is an acceptable LISP" by Chris Rathman

Sun, 14 Jan 2007 11:01:34 -0500

Since the topic is a comparison between Ruby and Lisp (and Simplicus expressed an interest in comparing Ruby with Haskell or ML or other FP languages), I thought I’d mention my pet project to translate the SICP examples into these languages.

http://www.codepoetics.com/wiki/index.php?title=Topics:SICP_in_other_languages

I’ve still got a lot to learn about Ruby, but in translating the first chapter and a half the main quirks I had with Ruby were (1) it’s lack of Tail Call Optimization – an attibute shared with Python and JavaScript (many in the Lisp community consider the lack of TCO to be a bug); and (2) the distinction between named and anonymous functions. As far as I can tell, you can curry lambdas, but you can’t curry named functions – Erlang works this way as well.

"Why Ruby is an acceptable LISP" by scripting geek

Wed, 13 Dec 2006 06:48:37 -0500

Very interesting and enjoyable discussion!

I did LISP and Scheme for a few years in the early 90s, doing AI at Berkeley. Looking back over that code some years later, just for fun, I was struck by the total impenetrability of my earlier LISP excretions. The resulting tangle of sexp was so nasty, I would have opted for ritual seppuku if required to decipher the stuff. But that’s just me and my substandard LISP code.

On another tangent.. I’m finding the impassioned arguments about language properties very interesting, but ultimately somewhat irrelevant, at least insofar as productivity is concerned.

I think that nowadays the breadth and quality of the available open source libraries is a much larger factor in the appeal of a language as a useful tool than are the theoretical upper limits of its expressive capability.

Learning to live with somewhat clunky metaprogramming facilities as opposed to super-powerful macros is infinitely easier, I think, than lacking libraries for half the stuff you need done on a daily basis.

It sounds as though LISP is still far behind the Python/Ruby camps insofar as that’s concerned, and for this reason alone I wouldn’t give it another look at this time. And, at least in my case, I learned that power of program-as-AST that’s so nice for computers is not so good for human comprehension, as we do not make good recursive tree evaluators. Beyond a modest level of nesting and layering, things start to look very nasty indeed.

Python/Ruby on the other hand are very readable, with plenty of useful idioms captured by grammar or sugar, and have APIs to easily interact with just about everything. With tools such as these, I alone can replace a small department of C programmers, and that’s very appealing.

"Why Ruby is an acceptable LISP" by Eric Kidd

Thu, 26 Oct 2006 08:13:52 -0400

Oh, I’m a huge fan of Haskell. The syntax is nice and dense (though occasionally a bit alien), and monads are a remarkably powerful abstraction.

There’s a whole class of designs which can be easily expressed with monads (unification, backtracking, transactions, continuations-as-a-library, localized state, modular parsers, and so on). A lot of these designs can’t be implemented cleanly with Lisp macros (unless you write a code-walker, or an entire embedded language).

It also seems that monads are most useful when you can have more than one of them, and when you can overload your monadic operations depending on the return type of your function. This is the biggest barrier I’ve found to using monadic code in Scheme.

Haskell is a fairly hard programming language, and I doubt it will ever go mainstream. But it’s by far one of the most interesting languages on the scene, and I learn a lot programming in it. My biggest complaint is the lack of subtyping, which is fixed by O’Haskell.

If I had to recommend four languages to learn, I’d recommend Ruby (because it’s so fun), Lisp/Scheme (for the macros), Oz (for unification, concurrent logic and constraints) and Haskell (for monads and for the deeply mathematical style).

"Why Ruby is an acceptable LISP" by memeplex

Tue, 24 Oct 2006 21:01:44 -0400

Lack of community and codebase are strong impediments for every but a few language. Also most new languages are missing a standard ffi which let them easily access c/c++ legacy code, preferable via bindings autogenerated by tools like swig. In this regard, Lisp has cffi, which is a good thing. But anyway, you won’t get too far away without people doing the heavy lifting, all that enormous amount of binding code should be generated, patched and tested. It seems like the way to go for small communities is to parasite mature and well established runtimes, and to compile to their intermediate binary representation. Of course I’m talking of java and .net/mono/pnet here. They’re doing their thing pretty well, performance is more than acceptable, and taken as intermediate languages (which msil is more than java bytecode) they can even be compiled to native code (take for example gcj). I love scheme programming but I’m also fond of new oo+fp languages, namely scala or nemerle. Because of the reflection capabilities of this cross-language/cross-platform runtimes, binding is far easier than it is for C/C++ native stuff. Sometimes it’s just a matter of importing modules and start using them. Admittedly, a generic runtime it’s not the same than a standard library tailored to an specific language. But then those standard libraries could be build faster on top of the facilities offered by the runtime, and in case they are still not complete, one can always resort to the generic api, it’s not a cul-de-sac. Also you can easily bind to c/c++ if you really need it: there are mature swig modules for java and c#, while there aren’t others for a lot of cool, tiny languages. I’m currently programming in bigloo scheme targeting the jvm, and in scala too (they both are able to generate code for the clr also, although support isn’t that mature already). I think it’s the way to go for languages with small communities. And in any case, these intermediate platforms promote code reuse, offer advanced interpretation/compilation techniques (while there could be lack of support for specific techniques, like tail-recursion, that’s a price to pay), powerful development environments, etc etc. Just how I’m feeling like lately.

"Why Ruby is an acceptable LISP" by William James

Tue, 24 Oct 2006 12:56:48 -0400

Quicksort in Ruby:

def qsort ary
  return ary  if ary == []
  pivot = ary[0]
  left, right = ary[1..-1].partition{|x| x < pivot }
  qsort( left ) + [pivot] + qsort( right )
end

"Why Ruby is an acceptable LISP" by schemer

Thu, 19 Oct 2006 18:04:23 -0400

Argh. I made some bad typos to my post: I meant lack of non-imperative i/o in my prior statement.

Also, I forgot to note several prominent scheme hackers have implemented monads in scheme, though unfortunately there’s no standardized example…

Lazy evaluation in scheme is also doable as you mentioned, even though I haven’t yet gottten the srfi for stream-define and friends working properly (apparently the my implementations’ modules are not compatable with it without extra macros)

I also don’t grasp why the srfi for memoized streams uses set! when it could just use a helper function (but then again, I would say that this is a problem of mutable define in scheme)

"Why Ruby is an acceptable LISP" by schemer

Thu, 19 Oct 2006 17:55:57 -0400

Simplicus, I would agree that pattern matching and guards are awesome, even in the absense of types.

I mainly code in Scheme, but I was absolutely blown away by Monads and lazy evaluation when I tried Haskell. I can’t belive most programmers consider those aspects of Haskell a turn off, both are techniques which I was earlier trying to reinvent while programming in Scheme while not even realizing it.

However, from personal experience, I would have to note that there is no reason why scheme can’t have those features; (There are libraries for pattern matching as you presumed, and there are

As for what I think makes scheme less “functionally dense” than Haskell are:

Scheme’s mutable define, mutable cons, and non-imperative i/o are what make it less functional than Haskell. Of course, these features that I mentioned aren’t really fundamental properties of the language, both in my opinion are historical cruft that I hope someday will be fixed…

On the other hand, I’d love to see a sexpr Haskell. :)

As for ruby, I don’t consider it to be “functional,” (although I wouldn’t be surpised if ruby programmers were fond of hofs) because as far as I know, it doesn’t have tail-call optimization. With Common Lisp, even though it doesn’t have tco, every major compiler out there (CMUCL, SBCL, probably also CLisp) optimizes tail calls, so I have no particular problem with CL, assuming a very non-idiomatic style to CL.

TCO is a big deal for me, because in Elisp I have to use destructive maps/filters to avoid exceeding the functional call depth, that’s really annoying…

"Why Ruby is an acceptable LISP" by Simplicus

Tue, 03 Oct 2006 19:22:46 -0400

Why compare Ruby with Lisp and not with Erlang, Haskell or ML or other FP languages?

I find this discussion very fruitful in many aspects. Yet the most interesting part of it for me personally is to what extent Ruby is a functional language? Or using Eric terminology how “functionally dense” Ruby really is?

I have no doubts that Lisp and Scheme in particular can be used for functional programming (FP). Nevertheless both of these languages can be used equally well for non-functional programming also.

Now back to my question: Why compare Ruby with Lisp and not with Erlang, Haskell or ML, or other “true” (Haskell) or “more functional” (Erlang, ML) FP languages?

I understand that from the above mentioned FP languages only Erlang has no strict types and two others (Haskell and ML) are strict. Nevertheless, I think that we can still compare “functional density” of those with Ruby’s.

I have 20+ years of programming experience, starting with DEC PDP-11 Macro Assembler and most of later work in OOP, such as C+ and then Java which I started to play with its first alpha release. That time I liked Java a lot compared to C++. During that “old times” I had also a chance to get to know CLOS and was charmed with its powerful ideas (lists = code = data, generic functions, MOP, to name a few), uniformity and simplicity. Unfortunately, that time (and today as well) I couldn’t find a way to do my living working on Lisp or Scheme projects, though I did some work in AI related areas (and learned many other “small” and “big” languages including Prolog) .

About three years ago I started to research FP quite seriously, trying to find programming tools (languages) more powerful then Java and other OOP languages that I could use to implement some of the ideas waiting in silo quite for a long time already.

I started with Scheme, then ML and now Haskell which I like most for its clarity and power. In between I am looking at Erlang and Ruby. Returning back to “FP density” Scheme and Lisp lack some powerful constructs that ML and Haskell have and that I find very important for uniformity, clarity, readability and expressiveness of the language. (Mind you, I love them all Haskell, Scheme and Lisp :)

These things are:

1) Guards (Haskell)

2) Pattern matching (Haskell, ML, Erlang)

3) List comprehensions (Haskell)

Guards example:

max :: Int -> Int -> Int
max x y
    | x >=y     = x
    | otherwise    = y

Example of both pattern matching and comprehensions – quick sort in Haskell is simple as that:

qSort :: [Int] -> [Int] 
qSort [] = []
qSort (x:xs) = 
  qSort [ y | y <-xs, y<=x] ++ [x] ++ qSort [ y | y<-xs, y > x]

This code is very close to informal definition of quick sort:

“To sort the list take off the head ‘(x:xs)’ and then split the result in two parts: the first containing the elements no larger then ‘x’ and the second exceeding ‘x’. Sort these two parts and then concatenate ‘x’ with results of these two sorts”

Isn’ it clarity and readability?

Isn’t purely functional notation is better then a notaion produced by macros?

What Ruby gives as equivalent to Guards, Pattern matching and List comprehensions?

I am not even talking about extremely powerful strategy of lazy evaluation that allows Haskell only evaluate a function argument when it is really needed (on demand) to compute the overall result. This in turn makes computations less expensive and allows language to describe infinite data structures.

As almost everything else, lazy evaluation can be implemented in Lisp and Scheme. Any ideas how to do this in Ruby?

After Haskell, Ruby syntax looks too eclectic for me (foo, @bar, baz :faz => xxx), ‘blocks’ and ‘yields’ makes me feel sorry for functions as first class objects, “meta programming” seems for me to be a perfect tool to hide and obscure what is really going on behind the code I see right now (because methods can be added to classes in other source files), etc…

Maybe I am totally wrong about Ruby and will drastically change my opinion after more experience with it, we’ll see.

As for this discussion it would be interesting to know what you guys think about:

1) The question I started this message with

2) Why Haskell (and FP in general) is not as widespread as Java, Python & Ruby? And all these sad things are happening in spite of:

a. Though not so big but very strong and dedicated community of Haskell developers.

b. Constantly growing set of open source Haskell applications, tools and libraries.

"Why Ruby is an acceptable LISP" by taw

Sun, 01 Oct 2006 15:23:17 -0400

You might be interested in RLisp, which is Lisp directly connected to Ruby runtime and very tightly integrated with Ruby.

It is very alpha, but can do really cool stuff like HTTP server that uses webrick (from standard Ruby library) and macros.

I think even at this early stage it is probably one of the most practical Lisps for scripting-style of programs, due to access to all Ruby libraries.

The biggest problem right now seems to be culture shock, as RLisp has Ruby/Python-style let (this is the most controversial part, I don’t have any idea why), a “real” object system (based on message passing and everything-is-a-Ruby-object), and lists are arrays (so cdr/cons copy).

Enjoy :-)

"Why Ruby is an acceptable LISP" by KristofU

Tue, 26 Sep 2006 04:55:22 -0400

I’m a C++ programmer, and was looking for a new language to learn and do stuff more elegantly. Ruby just sucked me right in. There is almost nothing to learn, it’s just there. You can slice and dice and juggle and the result is always a working program. You like for-statements? Well, you can use for-statements. You like iterators? Well, you can use iterators. Make object functors or lambda’s, whichever you prefer. Ruby doesn’t force anything upon you, there is time to learn to appreciate the finer features, while still churning out working apps in the meantime. I’ve also briefly tried Haskell, Scheme and Erlang, but I have to say, I couldn’t get anything done. Compared to Ruby, quite an anti-climax.

"Why Ruby is an acceptable LISP" by Pebblestone

Fri, 08 Sep 2006 07:13:50 -0400

Miquel:

Try CLSQL, it supports multiple DBs and on multiple lisp implementations. And I just used it in my last project.

"Why Ruby is an acceptable LISP" by Miquel

Thu, 07 Sep 2006 23:42:52 -0400

I have to say that I work with lisp everyday and it is very powerful. I just haven’t got the motivation to make a decent interface to mysql for my web applications. That is why I chose Rails.

Oh Well..

However, when the db support arrives, I am going back.

"Why Ruby is an acceptable LISP" by William James

Sat, 26 Aug 2006 01:09:45 -0400

This version will work properly even if the list doesn’t contain 49; also, the variable y has been eliminated.

def maxi a,b; (yield a) > (yield b) ? a : b; end
[1,2,3,-4,-10,-43,49,49,8934].inject([[],0]){|a,n|
  break a  if n==49
  a[1] = maxi(a[1],n){|x| x.abs}
  a[0] << n ; a }

"Why Ruby is an acceptable LISP" by William James

Fri, 25 Aug 2006 05:19:17 -0400

Here are some Ruby equivalents of some Lisp examples:

(iter (for x in '(-1 2 -10 4))
      (finding x maximizing (abs x)))

[-1, 2, -10, 4].inject{|a,b| a.abs > b.abs ? a : b}
# or
[-1, 2, -10, 4].sort_by{|n| n.abs}.last

(iter (for x in '(1 2 3 -4 -10 -43 49 49 8934))
         (until (= (sqrt 7) x))
         (collect x into collection)
         (finding x maximizing (abs x) into y)
         (finally (return (list collection y))))

(By the way, I don’t think this Lisp will work as advertised. (= (sqrt 7) x) seems wrong.)

def maxim a,b; (yield a) > (yield b) ? a : b; end
y = 0
[1,2,3,-4,-10,-43,49,49,8934].inject([]){|a,n|
  break [a,y]  if n==49
  y = maxim(y,n){|x| x.abs}
  a << n }

"Why Ruby is an acceptable LISP" by Eric

Mon, 26 Jun 2006 08:13:48 -0400

I suppose it depends on your geographic location: I’ve spent at least 6 of the last 10 years working with Lisp and Scheme on both academic and commercial projects. But then again, I like to work on cool, offbeat stuff, and I live in the greater Boston area—two factors which, together, correlate highly with Lisp.

If you’ve been working in AI, and you’ve never seen Lisp, the odds are extremely good that your work started after the late 80s. That’s when a combination of Moore’s Law and gross business incompetence killed off half the Lisp companies.

Nonetheless, you should probably learn Lisp if you want to take full advantage of Ruby: The book Practical Common Lisp contains 10 times as much meta-programming advice as all the Ruby documentation I’ve seen, combined.

"Why Ruby is an acceptable LISP" by someone

Sat, 24 Jun 2006 09:10:51 -0400

Do Lisp coders write programs or do they just sit around talking about their language?

It seems to be in use deep within the halls of CS departments and AI research, but in years and years of working with software, managing systems, writing for more OSes and problem domains than I can keep track of, I haven’t encountered a scrap of Lisp code or even a similar project to my own in which someone was using Lisp. I don’t mean to flame, but I’ve seen roughly a thousand times more talking about Lisp than the using of it.

I’ve always meant to learn Lisp, but I get the sense that I’ll be applying the knowledge more on usenet than on actual programs.

I’ve recently discovered Ruby, and of all its amazing strengths ( I’ll put at the top of the list ~~- at least as far as something that you’ll probably see on any open vim session on my workstation these days -~~ is the enumerable module ) nothing quite matches the friendliness and helpfulness of its community. Ruby seems to be the first language to really get that languages are software and programmers are users.

Programming communities need collective nouns. An obfuscation of Perl hackers. A stalwart of C coders. A furrow of assembly wranglers. An effusing of Ruby hackers. An ulcer of CSS authors. A grumbling of Lisp coders.

"Why Ruby is an acceptable LISP" by Notav A.

Tue, 13 Jun 2006 10:25:44 -0400

(apply (lambda (a b) (+ a b)) ‘(1 2))

can be done with:

lambda{|a,b| a+b}.call(*[1,2])

"Why Ruby is an acceptable LISP" by Eric

Sun, 21 May 2006 16:21:23 -0400

Try this:

obj.meth arg1, arg2, *more_args

It’s roughly equivalent to Scheme’s “apply.”

Why Ruby is an acceptable LISP

Eric Kidd — Sat, 03 Dec 2005 11:30:00 -0500

Years ago, I looked at Ruby and decided to ignore it. Ruby wasn’t as popular as Python, and it wasn’t as powerful as LISP. So why should I bother?

Of course, we could turn those criteria around. What if Ruby were more popular than LISP, and more powerful than Python? Would that be enough to make Ruby interesting?

Before answering this question, we should decide what makes LISP so powerful. Paul Graham has written eloquently about LISP’s virtues. But, for the sake of argument, I’d like to boil them down to two things:

LISP is a dense functional language.
LISP has programmatic macros.

As it turns out, Ruby compares well as a functional language, and it fakes macros better than I’d thought.