Lisp and Ruby

sdelmont writes "The developers of Rubinius, an experimental Ruby interpreter inspired by SmallTalk, have been discussing the possibility of adding a Lisp dialect to their VM. Pat Eyler collected some ideas and opinions from the people involved and it makes for some interesting reading. For many, Ruby already is an acceptable Lisp, and the language itself started as a 'perlification' of Lisp (even Matz says so) so it is perhaps fitting and might help explain why the whole idea feels right. Now, if someone added support for VB and gave it the respect it deserves, the world would be a better place."

Comments

Re:VB already gets the respect it deserves...

[Timesprout]

Yeah, how dare MS make it easy for developers and even non developers to quickly create applications to fulfil their requirements.

Genuine question about perl vs ruby

[thanasakis]

I am not trying to start a holy war thread about perl vs ruby, just looking for someone that can enlighten me regarding the following question.

Having perl as it is, what are the reasons to take a look at ruby. Mind you, I am not saying that these reasons do not exist, I guess I was just lazy to find it out by myself and then again, nobody has yet offered any compelling reason. I have taken a good look at ruby, clean syntax and all, but really I couldn't find something really compelling.

An interesting phenomenon is that most stuff that people perceive as a reason to go to ruby from perl, are available in perl too, but somehow they offer those stuff an novel.

Please don't take me the wrong way, I can testify that ruby is indeed a kick ass piece of work, I am trying to find real reasons to use it along side with perl.

So, fire away your opinions!

Re:Genuine question about perl vs ruby

[JanneM]

To me, as an old Perl programmer, Ruby basically feels like what Perl 6 should have become: keeping with the idea of making things discoverable for the programmer and not having to work around syntax, but greatly cleaned up and with objects as an integrated part of the language, not so tacked-on as in Perl 5.

Ruby still has some pretty significant drawbacks, of course; it's slow, and has little support for Unicode (not that surprising, seeing it's from Japan). The libraries aren't as mature yet either; Perl has many year's headstart there so again no surprise. All of these are improving, though.

Re:Genuine question about perl vs ruby

[morgan_greywolf]

Having perl as it is, what are the reasons to take a look at ruby. Mind you, I am not saying that these reasons do not exist, I guess I was just lazy to find it out by myself and then again, nobody has yet offered any compelling reason. I have taken a good look at ruby, clean syntax and all, but really I couldn't find something really compelling.

Having Perl as it is, what are the reasons to take a look at Python? Having Python as it is, what are the reasons to take a look Ruby? Having Ruby as it is, what the reasons to take a look at Perl? Having Python as it is, what are the reasons to take a look at Perl?

Because they're different languages with different strengths and weaknesses. Just as Lisp and Ruby are different, and Python and Perl are different, so is Perl and Ruby.

A good staring point for you would be to read this article differentiating Perl and Ruby. Working back from that description, if you have experience in programming in languages other than Perl, you should be able to figure out what the advantages are of Ruby over Perl and vice-versa.

Re:Genuine question about perl vs ruby

[Jonathan]

1) Object Orientation is consistent throughout the language. Perl provides ways to make objects, but none of the built in functions or datatypes are objects, making your code a schizophrenic mess of objects and non-objects.

2) Consistency -- In Perl it is needlessly difficult to do ever simple tasks like making arrays of arrays or arrays of hashes -- you have use a weird syntax to get at references. I never could remember it and always had to look it up whenever I needed an array of arrays in Perl. In Ruby, everything is a reference to an object so you don't have to worry about it -- a[0] = [1, 2] does exactly what you want -- puts an array [1, 2] in the first element of array a.

I used to be a big Perl fanboy -- I did most of my programming in Perl from 1992-1999. But when I discovered Ruby I went for it and never looked back. What's cool about it is that its syntax is so clean that it is basically a version of the pseudocode I have in my head. In the Ruby community there's a phrase for it -- "the principle of least surprise" -- things just work.

Obviously, if you really like Perl, nothing is going to make you change. But if you are just keeping with Perl because of inertia, then you ought to look around at other scripting languages. Ruby is my favorite, but most modern scripting languages are cleaner than Perl.

Re:Genuine question about perl vs ruby

[CoughDropAddict]

Actually there is a good reason to look at Perl given Ruby. Regular Expressions. Ruby has a object and method for doing regular expressions but compared to Perl it's very combersome and is even lacking some of the properties that Perl's regex has.

Cumbersome? Which is this, Perl or Ruby?

"Hello, World!" =~ /Hello, (\w+)!/;
print $1;

Trick question -- it's both. What exactly about Ruby's way is cumbersome?

Re:Genuine question about perl vs ruby

[Anonymous Coward]

the reason is not-invented-here syndrome or a strawman argument against Unicode's ideograph system.

Asians complain about having to share codepoints for characters (see Han Unification). A lot of people think the whining is mostly racist in nature; however, there are a few legitimate complaints in there, for instance many characters that Han Unification forced to share codepoints actually have different glyphs depending on which language it's written in, even if they all shared a similar source. Unicode's official stance is that the application should identify the language being used and select the correct glyph for that particular character from a font designed for that language (which basically makes it impossible to create a single definitive Unicode font). Explanation of both the glyph problem and the not-invented-here issues here. More on glyphs.

As for the "major encodings" currently in use, Shift-JIS was basically forced onto them by Microsoft who took their existing JIS encoding (based on ISO-2022) and broke it. There's about 1000 websites of people telling the world just what they thought of that, yet not-invented-here or not, the Shift-JIS system sucks. Consider the fact that it uses two separate non-contiguous sets of codepoints (compare graphs of the non-unicode encodings here.

It's easy to say "not-invented-here", it's harder to admit that the foreigners had no clue what they were doing and broke it :P

it could just be a vocal minority

Of course it's a vocal minority, the majority just want their computers to work.

wow, I have no idea what that just meant!

[tommyhj]

This is just one of those stories that us non-linux, non-programmers have absolutely no idea of what means! Which insidentally makes it rather funny to read :-) I mean, adding Lisp to Ruby's SmallTalk?

Re:wow, I have no idea what that just meant!

[kruhft]

Lisp is the oldest, still in use, high level programming that exists today. It's the core of emacs, and was standardized into Common Lisp in the early 90's. It basically has no syntax other than words and nested parenthesis (() :-), has an extrememly powerful macro system, and a loyal following of elders that hang out in comp.lang.lisp on usenet. As well, the great Emacs is basically a lisp interpreter (or Operating System) that happens to have a text editor above it.

Smalltalk is another high level language where everything is an object. It has syntax, supports many interesting high level concepts like persistance, and has some nice development environments and pseudo OS projects, one of which is called Squeak.

Ruby is a newer high level language from Japan, that was designed to combine the high level concepts of Lisp, but added some syntax to reduce code verbosity and increase expressiveness. The Lispnicks say this is unnecessary complexity that reduces the power of the language; people that were raised on languages with syntax find the expressiveness more familiar, easy to use and powerful.

I'm still undecided.

Re:VB already gets the respect it deserves...

[S.O.B.]

From a technical perspective it might suck but it works a lot of people (especially non-programmers) to get real work done.

And when that program gets too big for them to maintain (or they just don't feel like it anymore) they dump it on their IT area and we're stuck maintaining or converting an app in a technology we wouldn't have chosen that looks like it was designed by a pack of drunken monkeys.

Build a tool even an idiot can use and only an idiot will want to use it.

Re:Performance, anyone?

[Lucas.Langa]

As funny as your comment is, it made me wonder... There is a very loud pro-Lisp community that tells everyone who is not using Lisp that they should since it solves most of the problems they have in the first place. OK, fair enough. But I have that strange feeling that assuming the developers to be usually very smart and very lazy, we would see them all convert to Lisp if it really was the ultimate answer [1].

And what makes me think that Lisp was and still is widely ignored? There are a couple of points here but the most important is: we don't really see a large, consistent standard library for Lisp. So we could easily turn the Greenspun's 10th Rule backwards to say: any sufficiently complicated Common Lisp program contains an ad hoc, informally specified, bug ridden, slow implementation of half of Java's standard library.

So, where's the catch? Why isn't Lisp popular if it's so 1337?

[1] But we know it's 42.

Re:Performance, anyone?

[Wolfbone]

"I mean, take Lisp and its performance. Compare it to Ruby's."

Which Lisp? One which (as most implementations of Common Lisp do these days) appropriately and reasonably gets compared to the output of a C compiler?:

http://www.lrde.epita.fr/cgi-bin/twiki/view/Public ations/200606-IMECS

I wouldn't have thought that would be a very fair comparison to make for Ruby.

Because you'll end up at Lisp.

[Anonymous Coward]

What most people don't realize is that Lisp is the inherent representation of virtually all programming languages. This is even true for languages like C, Java, Smalltalk, and Ruby. We can plainly see this by the very fact that basically every compiler or interpreter for those languages parses the language into an abstract syntax tree. And that's exactly what Lisp is: a textual representation of an AST. It is so powerful because it directly allows the programmer to access and modify what amounts to the AST of his or her program. This is something that a language like C isolates to the compiler, or at best the preprocessor.

What fewer people realize is that Smalltalk is Lisp with a slightly different syntax. The concepts are basically identical, however. So suppose the Ruby developers do all the hard work needed to switch their language over to a Smalltalk-like syntax. Do you know what will happen next? They'll ask themselves what could be improved next. And the first thing that'll happen is a consideration of making the syntax and semantics of the language more Lisp-like. And that's just because Lisp represents the most inherent aspects of what a programming language is.

Re:Because you'll end up at Lisp.

[calambrac]

I would have to disagree with your statement that Lisp doesn't let you group things. Not only does it let you group things, it lets you write entire languages built specifically for the things you want to group. Macros in Lisp are effectively little compilers that are very easy to write, that let you make whatever language is most useful for working with the concepts you want to "collect, isolate, and distinguish". Combine this with CLOS and generic and functional programming techniques, and you have one of the best languages around for dealing with concepts at a very high level.

Lisp has its weaknesses, but expressiveness and abstraction are not among them.

Re:VB already gets the respect it deserves...

[Iamthefallen]

That says far more about your circle of friends/co-workers than it does about the language.

Re:VB already gets the respect it deserves...

[Flodis]

Build a tool even an idiot can use and only an idiot will want to use it.

I'd like to change that to "Build a tool even an idiot can use and expect idiots will try to use it."

I've been on the receiving end of many a poorly designed VB app, but is that the language's fault?

Assume we collect a random number of 3rd graders' essays. We can safely assume they will be pretty badly written. Do you automatically blame 'english' for the essays being bad? Maybe you also tout another language as superior just because the only ones you know speaking that other language are all 20+, and have picked up a bit or two about telling a story.

Btw, english is not my first language, and I think the VB slamming that is so fashionable around slashdot is just stupid. Not that I think there's any doubt about either after this.

Re:Performance, anyone?

[ravenlock]

If I build a new and presumably better (in my own opinion) programming language starting off with Lisp, and my implementation turns out to be less powerful and slower than an average CL implementation, is that progress?

It is if it helps introduce the concepts behind Lisp to a lot of people who never would have dared to venture into Lisp otherwise. Ruby was the first language with functional constructs I tried (very much due to the excitement around Rails). Now I'm reading up on Lambda Calculus and learning Haskell, and I'm not at all sure it would have happened, were it not for Ruby.

Re:VB already gets the respect it deserves...

[hclyff]

This is exactly the kind of reply I would expect from a VB developer or "non developer". By "quickly create applications to fulfil their requirements" you probably mean "create a horrible unmaintenable mess which not even the original author will touch, and which has is almost certainly going to be rewritten by a developer at some point in future". Enabling non developers make production code is *NOT* a good thing, I think most people with some experience in the industry will agree with this.

Re:VB already gets the respect it deserves...

[TheRaven64]

Before VB, NeXT released a Rapid Application Development environment. It used Objective-C, which can be used as a language almost as high-level as VB in some ways, and higher-level in others. It also allows programmers who know what they are doing to do all the sorts of evil things that give C such a bad reputation. The language, however, is largely irrelevant. The frameworks are the important thing (these days you can use Smalltalk, Java, Ruby, Python or IO with descendants of the frameworks).

When you write code using the OpenStep frameworks, designed by NeXT and tidied up by NeXT and Sun, the path of least resistance is a clear model-view-controller separation. Someone asked me last week 'do you always follow strict MVC separation in your code?' I hadn't really thought about it, but I tend to because the framework just makes that the obvious way of working. In contrast, VB encourages you to keep model information in the view objects.

This is just one example. A good framework means that you implement good design patterns without thinking. If you do this, then your application will be more flexible and maintainable when you come to make changes to it in the future (or, more importantly, when someone else does). Developing with OpenStep is slightly harder than developing with VB. Maintaining an OpenStep application is far easier than maintaining a VB application.

MOD PARENT UP

[TheRaven64]

I have noticed a lot of interest in more interesting languages, like Lisp, Smalltalk, Haskell and Erlang recently from people who a few years ago would have been C, maybe Python programmers. I think a lot of this is due to the fact that people have been introduced (finally) to a relatively mainstream language that goes beyond the slightly-higher-level-than-assembly pure-imperative (with maybe a hint of OO) style that has been common for the last few generations of 'new' languages.

I don't think I'd use Ruby for anything (except maybe as a teaching language), but I can't deny that it has done a superb job of introducing a new generation of programmers to the benefits of a true high-level language.

Re:I use Common Lisp because of its 'white hot' sp

[Not_Wiggins]

The problem is that Ruby has very poor runtime performance.

Not so much in response to the post, but to add to it...
I'm not that old, but I remember the same being said for:

• C++ compared to C
• Interpreted compared to Compiled
• Java compared to C++
• Servlets compared to CGI

The list could continue. Just wanted to highlight that "performance" is a short-lived reason to avoid a language. 8)

Re:Performance, anyone?

[pivo]

I suggest you forget about Lambda calculus and learn Lisp just like you'd learn any other programming language. Peter Seibel has made his excellent, non-migraine-inducing book "Practical Common Lisp" available for free on like at http://www.gigamonkeys.com/book/ He leads you through building a streaming MP3 server in Lisp, which is quite fun.

Re:VB already gets the respect it deserves...

[HiThere]

You never heard of Python, Ruby, or Smalltalk? That explains your problem.

For years even though I swore at VB I didn't really hate it. Then I caught it in an arithmetic mistake. I, a human, caught a computer at an arithmetic mistake. Understand, I'm not talking about the program, I traced the error down to one specific statement in a program, placed print statements before and after it. VB made an arithmetic mistake. Then I started to wonder about all the larger numbers that I hadn't checked over the years.

That was the last program that I ever wrote that used VB for arithmetic. The next one I used an external Eiffel program to do the arithmetic. The one after that I had it all happen in an Excel spreadsheet. Since them I've moved to Python and Ruby...and totally off of MS systems.

I don't believe that anyone who is a decent programmer likes VB, though many use it due to coercions of various forms. (You mention interesting jobs.) Most people probably haven't noticed that it sometimes lies. (And maybe they've stopped doing that. This happened in MSAccess2000, around 2000.)

No dialect of BASIC has ever been a decent programming language, throughout it's history. (Well, there are lots of versions that I haven't tried, so that's excessive. Some people said that Pick Basic was quite good.) It strongly encourages bad programming habits and discourages several good ones. There are dialects of BASIC in which it is actually impossible to write a decent program. Or a stable one (different group). This isn't to assert that it can't be very convenient. Especially in environments that are designed to encourage it's use.

Re:VB already gets the respect it deserves...

[S.O.B.]

And yet it performs a useful function for the business... If you don't like it, you could always move to a different job or business.

Nice bit of flamebait. Moving right along...

Or.

Perhaps you might want to extend your remit to advocating the technologies you would choose, to the business management. Perhaps you might even want to create a development environment for personnel to produce adhoc applications in the technologies you prefer. Or shock, horror, you could even provide that service within the IT department and actively go looking for opportunities to improve productivity.

My company does all of that. We have a list of technologies that are approved, in containment and being retired. The department I work for is the likely place for these types of requests to be handled and we have a triage process that takes any request that comes in to well publicized email address and discusses it with the client to determine their needs and estimate the effort. If the client wants to go ahead it is prioritized and put in the schedule. Most times when they realize how much thought and effort it really takes to do it right they let us do it for them.

Even with all that there's always a guy (surprisingly never a woman) who read VB for dummies over the weekend and now thinks he knows as much as the entire IT department of a multi-billion dollar company. Unfortunately, what he doesn't realize is that writing a program is only a small piece of the problem. Once it's there you have to support and maintain it and that takes time. Then people begin asking for enhancements that he starts bolting on anywhere he can but it's getting harder and harder because he has no concept of design. Now his boss is telling him that he's spending too much time on it and it's not what he's getting paid for anyway. Then it gets dumped on IT and now we have to maintain it.

And anyone who says why don't you tell them that they'll have to keep maintaining it themselves or pay to have us migrate it to an approved technology has never worked in a large shop where politics often wins out over reality.

Besides, IT areas do a lot more than write programs. Coding is maybe 15-25% of the actual effort. There is analysis, design, integration (with other internal/external apps), regression testing and deployment to name a few. That's not to mention on-call support, enhancements and regulatory compliance not the least of which is SOX.

I don't have a problem with trained VB developers it's just that the simplicity of the tool and Microsoft's marketing give untrained people a false sense of ability.