Slashdot Log In
Lisp and Ruby
Posted by
kdawson
on Sun Jan 14, 2007 07:58 AM
from the sittin'-in-a-tree dept.
from the sittin'-in-a-tree dept.
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Performance, anyone? (Score:2, Insightful)
Yeah, it's cool to virtualize, introduce dialects, interpret, etc. etc. Now, for the first time ever, we have cheap mainstream computer hardware that's capable of handling all these ideas in an acceptable way. But, isn't it a huge waste of resources? What about performance?
I mean, take Lisp and its performance. Compare it to Ruby's. Matz said himself that Ruby started as a kind of Lisp reconsideration. And you call this progress?
The thing is that you can implement a dynamic language that isn't painfully s
Re: (Score:2, Funny)
Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
As long as it can send mail, that's the only feature that matters (and whose rule is that?).
Re: (Score:3, Funny)
Re: (Score:3, Funny)
(format-for-slashdot(report-answer(probably
Re:Performance, anyone? (Score:4, Interesting)
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.
Parent
Re: (Score:3, Interesting)
1: It is popular among people who are solving problems LISP is well suited for.
2: There are other languages that are more suited for what most developers do.
3: There are other languages that are more successfully marketed.
I've earned more money in less time using COBOL than any other language but you don't hear me telling kids to pick it up.
Nor do you see me selling COBOL for new projects.
I don't think all of this "what language is 'leet" talk is productive or illuminating. You ha
Re:Performance, anyone? (Score:4, Informative)
Parent
Re: (Score:2)
Ruby manages to be slower than PHP, and sometimes considerably, which is a true achievement (I can say, as a PHP developer, unfortunately).
Also from friends who had played more with Ruby and with Rails, Ruby's ability to create dialects m
Re:Performance, anyone? (Score:5, Informative)
"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 [epita.fr]
I wouldn't have thought that would be a very fair comparison to make for Ruby.
Parent
Re:Performance, anyone? (Score:5, Insightful)
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.
Parent
MOD PARENT UP (Score:4, Insightful)
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.
Parent
Re: (Score:3, Interesting)
I mean, take Lisp and its performance. Compare it to Ruby's. Matz said himself that Ruby started as a kind of Lisp reconsideration. And you call this progress?
Right. Common Lisp is very fast; on an architecture that's not register-starved the Steel Bank compiler can produce code that is faster than C++ running the same algorithms, and Lisp is a lot more flexible. While I like the Lisp semantics, I find the syntax a little, uh, minimalist, and I prefer Smalltalk[1], which has a similar amount of flexibility. Smalltalk running in the Squeak VM is fast enough to run video CODECs written in Smalltalk on a relatively modern laptop, and is faster than Ruby.
I still
Re: (Score:3, Interesting)
Re: (Score:3, Interesting)
True Dat. Between Perl, Python and Ruby. Ruby is the slowest by far. And be careful how you write your code. Sometimes attaching method.method.method is about the worse way you can go, even though they claim it is the Ruby Way. Bah! I'll take perl. At least it has docs.
Genuine question about perl vs ruby (Score:4, Interesting)
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 (Score:5, Insightful)
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.
Parent
Re: (Score:2)
It becomes crystal clear very soon when you look at ruby that its syntax is not even in the slightest sense as complicated as perl's. But then again, most people went to perl in the first place to be able to leverage that characteristic. So why move away from it?
The only real reason that I can think of, it that as someone progresses as a programmer, he/she may find that his/her tastes change gradually.
Re: (Score:3, Interesting)
The thing with Ruby this far is that it's still in its first major version by version number. There's not one bit of the Ruby design that I'd like to change dramatically, but there's a bunch of problems that arise from its current implementation. The one-pass compiling (which while surely easier to imp
Re: (Score:3, Informative)
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
Re:Genuine question about perl vs ruby (Score:4, Informative)
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 [ruby-lang.org]. 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.
Parent
Re: (Score:3, Insightful)
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. Since I tend to use a lot of my programming time dealing with text of some kind, regular expression are important to me.
Ruby is a nice language. It's easy to work with. But it's got some maturing to do and I do hope they spend at least a version working on s
Re:Genuine question about perl vs ruby (Score:4, Interesting)
Cumbersome? Which is this, Perl or Ruby? Trick question -- it's both. What exactly about Ruby's way is cumbersome?
Parent
Re:Genuine question about perl vs ruby (Score:5, Informative)
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.
Parent
wow, I have no idea what that just meant! (Score:5, Funny)
Re:wow, I have no idea what that just meant! (Score:4, Informative)
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.
Parent
why not go all the way? (Score:3, Informative)
Because you'll end up at Lisp. (Score:5, Insightful)
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.
Parent
Re: (Score:3, Interesting)
It is so powerful because it directly allows the programmer to access and modify what amounts to the AST of his or her program.
If you want a really good demonstration of this, take a look at Erlang. Erlang has a feature as powerful as Lisp macros called Parse Transforms. The compiler spits out the parse tree as a set of nested tuples and passes this to a user-suppled function. This then returns a transformed version of the parse tree. This has exactly the same power and expressiveness as Lisp Macros. The difference is that every Lisp programmer uses macros, because they are as easy to use as function, while almost no Erlang p
Re:Because you'll end up at Lisp. (Score:4, Insightful)
Lisp has its weaknesses, but expressiveness and abstraction are not among them.
Parent
I use Common Lisp because of its 'white hot' speed (Score:2)
The problem is that Ruby has very poor runtime performance. As a result, I often use Common Lisp (Franz for commercial development, but also LispWorks, and SBCL). What kind of runtime performance will this proposed Lisp (it is all just talk for now) have?
Common Lisp is a great language. Several years ago, with some great input from the Lisp community, I wrote a free 50 page tutorial "Loving Lisp, or the Savvy Progra
Re:I use Common Lisp because of its 'white hot' sp (Score:5, Insightful)
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)Parent
Re: (Score:3, Interesting)
Re:VB already gets the respect it deserves... (Score:5, Insightful)
Parent
Re: (Score:3, Insightful)
Re:VB already gets the respect it deserves... (Score:5, Insightful)
Parent
Re: (Score:3, Interesting)
Additionally, if VBA didn't exist you'd have to write C++ to do simple macro'ing in Office products. It's profitable, but it bites the big one as far as i
Re:VB already gets the respect it deserves... (Score:4, Interesting)
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.
Parent
Re: (Score:3, Interesting)
There are a number of interesting, unproven, and contradictory assumptions built-in to your statement:
1) All VB code is a mess
2) VB applications are successful e
Re: (Score:3, Insightful)
Re:VB already gets the respect it deserves... (Score:4, Insightful)
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.
Parent
Re: (Score:3, Insightful)
In the long run VB is a hinderance and not a help. It's better to have a clean separation then a flashy IDE if you intent to keep your application alive for more then a few days.
Re: (Score:3, Interesting)
I guess you don't want to try SNOOZ, which is my COBOL-ification of VB.
Re:VB already gets the respect it deserves... (Score:5, Insightful)
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.
Parent
Re: (Score:3, Insightful)
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
Re: (Score:3, Interesting)
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.
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.
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 opportu
Re:VB already gets the respect it deserves... (Score:4, Insightful)
Nice bit of flamebait. Moving right along...
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 [wikipedia.org].
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.
Parent
Re:VB already gets the respect it deserves... (Score:5, Insightful)
Parent
Re: (Score:2, Flamebait)
karma (Score:3, Insightful)
Well, they better do want to program, because that's what they'll be doing most by going for the "ease" of VB: writing patches and more patches to correct bugs, doing excessive maintanence due to lots of improper, parameterless copy-pasting code and lots of rewrites from scratch once the whole thing eventually collapses under its own weight...
that, or hire real programmers with real tools from the get-go...
Try Perl with Win32::OLE (Score:3, Informative)
is still alive though not supported my Microsoft (VB6).
I think you meant 'by' not 'my', a typo (it happens to all of us).
But there's the rub. You never kn