Slashdot Mirror
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."
...absolutely none. It's a horrible language. The only thing it has going for it is the reasonably useful IDE (although even that irritates me most of the time).
Goten Xiao
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 slow. Take Lua for instance. Eh, if only it had Unicode support.
Build a tool even an idiot can use and only an idiot will want to use it. -S.O.B.
VB has been improved and perfected it's called Delphi, the IDE of VB, the power of C++, Components, Databases, everything you could need and now it's run by developers - www.codegear.com
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!
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?
The power of VB doesn't lies in its methodology or programming techniques. But in ability to churn out an application faster to production. There is always a demand of non-critical business apps that are required for small production cycle. Here nothing can beat VB. Its so easy (i agree with its limitations) to learn. Throw in WIN32 API and it gets even powerful. I had been associated with one of the heaviest apps ever done in VB, running at 80+ locations in US (in late 90s) and is still alive though not supported my Microsoft (VB6).
I truly respect Java and C++ and others. But for its contributions in business apps VB deserves its due respect.
Sorry the post went little off-topic. Readers' and moderators' desecration anticipated.
Eclipse PDE and Me
If you're gonna have a "Ruby inspired by Smalltalk", why not be done with it and give it Smalltalk syntax as well? Smalltalk syntax is great: very readable, very simple. And with Objective C, it has enjoyed some resurgence.
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.
I love programming in Ruby and use it a lot for both small utilities and some Rails web apps.
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 Programmer's Secret Weapon" that is a free download from the open content page on my web site.
There is not a good Lisp free implementation that runs on several platforms including Windows and that not makes all the code I write there GPL instead of the license I would like.
Having said that, I'm really waiting for news of SBCL running in Windows with threading and all.
However, that's not enough, I would like to have Threads standarised in Lisp and also a GUI for Lisp that's like wxWidgets for C++.
Also, Emacs sucks, and it's the best IDE there is for Lisp. I know some people are mouse-impaired and live for and by the keyboard, but we Starcraft players know better, we must use both very fast. (I have found myself using the odd and hand twisting keyboard commands of Emacs in more sane software, and I was shocked in awe.)
So in short: I would like to use Lisp for a lot of projects, but I can't without investing USD$2000+ (and I can't do it for now). And I would like a better IDE.
Compare that with PHP, Perl, Phyton, Ruby, Java and C++: All of them have non-GPL infecting complete implementations that are available for Windows.
Notes: I tried wxCL but it didn't compiled out of the box in my mingw instalation. I couldn't make it run at all. ECL is LGPL but as the LGPL requires that code linked statically has also to be under the LGPL, then ECL has a license as infectious as the GPL.
We are Turing O-Machines. The Oracle is out there.
BTW, I started work on a second edition of "Loving Lisp, or the Savvy Programmer's Secret Weapon" two weeks ago - if you download the PDF for the current edition and like it, then check back in a couple of months.
... make it Spinning Wheel.
Hatredman
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.
I am TheRaven on Soylent News
Let's suppose you have absolutely no construction experience. But you decide you need a place to put your rakes and shovels, so you build youself a shed. As would be expected, it's a piece of trash. Yeah, you can put your rakes and shovels in there, but it leaks, shingles blow off during storms, and the door frame is warped. So you call in a professional builder to fix it up.
Do you know what that builder would do? He'd laugh at your piece of shit, and probably refuse to fix it. He'd likely recommend that he just rebuild it from scratch, doing it right. Sure, your shed "performs a useful function" for you. But sometimes it's just better, from a financial standpoint, just to get things done right the first time, which often requires getting a professional involved.
That's the main problem with VB. It lets those without the necessary understanding build applications that end up being used for some business purpose. But of course, those applications have many flaws, and are often dumped on a professional to fix. It'd have been best if the professional had just done the work from the get go, getting it done properly.
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)Diplomacy is the art of saying, "Nice doggie!" until you can find a rock.
Interpreted is still slower than Compiled. Always will be. However, the reason that that problem has *somewhat* gone away is that machines are fast enough now that for *most* situations (UIs being one example), that is not a problem. However, for some problem domains (eg scientific programming), speed will never cease to be an issue. The faster the machines we have, the more we will throw at them. Lattice calculations work better with a smaller lattice spacing, and a faster machine allows a smaller spacing.
However, most of the interpreted languages which have appeared to resolve their speed issues have done so by some form of on the fly compilation. So yes, ruby could move up to even with the lisps in that way.
SIGSEGV caught, terminating
wait... not that kind of sig.
I used to do PHP. Black days really. In retrospect I can no longer understand how I could stand it at all. I wasted so much time on idiosyncrasies of the interpreter it hurts to think about it. Ever wondered why your variables suddenly, unexpectedly changed only to find out some nutter activated register_globals on this particular installation. Btw. try this: if ("0" == false) print "This sucks!";
;-)
:-) It's really nice. No side effects. Compare that to PHP!
Then I really discovered Perl5. Played with it before, but never really used it much. Anonymous subs! Closures! Regexp operators! Construct code at runtime! I got to appreciate the simplicity of Perl, though the sigils (\%@) drove me crazy at times. I also enjoyed Perl golfing a lot, though not at a very high level.
Then came along Ruby. I loved it instantly! It was how Perl should have been. It also has probably the best introduction to it of ANY language. Check it out, it's worth it.
Regarding things I really love in Ruby: Blocks and Rubys Object system. Through these two things you can write code without temporary variables. Functional programming sneaked up on me through the backdoor.
Interrestingly - Perl6 got much more like Ruby, and adds tons of new stuff (Rules, etc.) I did not fully explore it, but intend to. I did not find a suitable entry into it yet.
The only sad thing is, knowing Ruby I today have no strong drive to learn Python though very interresting projects (OLPC) use it. Perhaps OLPC will get my point of entry for Python.
Meme of the day: I browse "Disable Sigs: Checked". So should you.
"Build a tool even an idiot can use and only an idiot will want to use it."
And now we know why there will never be a "Linux on the Desktop".
It sounds like he's just trying to invent a lisp heritage for ruby to appeal to people who don't know what lisp is, but have heard that its "the most powerful language in the universe!". To quote the link:
* take a simple lisp language (like one prior to CL).
* remove macros, s-expression.
* add simple object system (much simpler than CLOS).
* add blocks, inspired by higher order functions.
* add methods found in Smalltalk.
* add functionality found in Perl (in OO way).
If you follow steps 1-4, you end up with smalltalk minus the methods that get added in step 5. This whole thing could be reduced to:
* perlify smalltalk
Claiming that ruby is perlified lisp is contrived and silly. Take lisp and remove s-expressions and now you don't have lisp.
I weawy wuv wuby.
Maybe what is meant is that Ruby's usefulness in many situations is acceptable when compared to LISP. I'd even disagree with that because Ruby lacks what good LISP implementations have: a way to declare types and thus make it easy for the compiler to optimize crucial code and avoid the slowness of dynamic typing. Also its approach to objects is entirely totally different from Ruby's. LISP's option to declare variables and hint the compiler, together with its extensive support for macros is second best when compared to static typing with inference as in OCAML, but still better than nothing of that sort, as in Ruby.
But while Ruby might be comparably useful for some, it certainly and definitely IS not LISP in nearly any practical meaning of the word "is". The main distinction is the basic feature of LISP: that its main datastructure is at the same time the representation of code. That is probably what is most typical for LISP and totally, utterly absent in Ruby. I am not saying anything here about the usefulness of this property, just that it is this property of the language that makes a LISP a LISP and therefore prevents Ruby from being a LISP.
One could dive deeper to see a couple of other significant differences in the language design to further argue that Ruby is definitely NOT LISP.
Personally, when it comes to usefulness, I have nearly totally given up on LISP. Ruby is a nice language, but has serious performance and a couple of other issues. When I want to use a well-designed language that is at the same time practical I use Ocaml (which also has a couple of practical shortcomings). Unfortunately, in most cases, one has to choose a language entirely for pragmatic reasons so one will end with something like *shudder* Java.
....because it's a superset of all dynamic languages available today*.
If you use it, you get a blinding flash of recognition... then you see how productive you can be when everything is "under one roof".
By the way, it's "Smalltalk", not "SmallTalk"... the language was created way before conjoined capitalized words ruled the earth.
BWilde
(Still, take the other poster's words about Lisp seriously)
If you want to do bigger more complex things like writing web servers, why do you want to stick to a scripting language? Regardless, pike is a fast scripting language, and has a C-style syntax. There are webservers written in it (caudium, roxen) that perform well for a scripting language.
"Download a copy of InstantRails and take 60 minutes to create your own full blown webapplication."
No, make a dinky little toy web app. Even DHH himself doesn't use such blatent exagerations to push rails. Yes its faster than coding everything from scratch, no it is not magic and you can't write anything non-trivial with it in 60 minutes. Do you seriously think anyone anywhere would be using anything but rails if it actually offered a 100x development speed improvement?
"If you think you can do faster and better in Perl, I bow to you mighty Perl God."
Catalyst is for perl what rails is for ruby. There's no need to switch to ruby just to get a web framework.
He asked why to switch to ruby from perl, and you basically ignored ruby altogether and talked about rails. He never even mentioned if he even does web development, how would rails help him if he doesn't do DB driven web development? Ruby itself doesn't offer much over perl, basically just cleaner OO support. If you are already used to perl then I don't think it makes any sense to switch. If you do DB driven web dev and would benefit from rails, then it still makes more sense to stick with perl and just use catalyst (or maypole for trivial 60 minute type stuff) than to switch to ruby just for rails.
Pragmatic programmer loyalists and newbies picking up the "hot" language are the same thing, just people following fads. They will move on to the next fad when it comes along just like they always have. The fact that rails has so many PHPisms in it and most of the ruby community points to it as a shining example of what ruby can do would indicate that you're right, very few of them are experienced or educated programmers.
There's also the group being tricked into thinking development speed and the number of characters in your source code are the same thing. This is where the answer to your "how does this help me..." question comes it. It doesn't help you, obviously. But it creates an illusion of faster development, which is what draws people in. Who cares that 90% of your time is spent maintaining the code, not writing it. You can wow people with an upfront display of seemingly fast coding, and ignore the fact that in the long run, that code is useless and needs to be re-written correctly. Its just a cheezy magic trick, but as long as people are jizzing over "criss angel" (why would you pick a porn name for chicks to be a "badass" magician?) they will be jizzing over ruby.
Comment removed based on user account deletion
I beg to differ. I have done VB and found for many purposes Perl is faster, cleaner and easier than VB. Python too is better than VB, and also supports win32 api. As does Ruby (I am currently switching over though I still use Perl as I am very fluent in it). Add in an IDE such as Eclipse or Komodo, and you can do perfectly fine desktop or web apps rapidly.
.Net, 3 years from now it could be 'Microsoft McFoo'. OSS languages seem to be more consistent and incremental in thier changes. Major changes changes tend to occur only after much debate and input from the entire community, not just an arbitrary decision by a few marketing types.
.Net was actually the best thing that happened to VB.
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 know when MS is going to pull the rug out from under you. Right now its
VB6 was horribly crippled. No good object support, reflection, etc. Nothing that made it better than COBOL.
putting the 'B' in LGBTQ+
"VB is programming for people who don't really want to program."
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...
I don't feel like it...
Does that mean your Ruby AI book is on hold? That's something I'd really like to read.
That's an interesting troll -- you make the claim that Ruby is vaporware even though it's been out for several years, and has a number of "killer apps" already available (Rails being the most obvious). Not very effective, though. You didn't even get a troll mod.
Keep practicing.
As a programmer and programming language enthusiast, and being intimately familiar (hmm) with both Ruby and Common Lisp, there are a couple of things I miss in either language.
In Ruby, I miss macros and the consistent, simple syntax that makes Lisp code so easy to parse and generate And, of course, I miss the Lisp reader. I've created a Lisp reader and writer for Ruby, but they produce (or print) Ruby _data_, not code.
In Common Lisp, I miss all the practical things that come with Ruby; mostly networking and string manipulation. SBCL just seems much less practical out of the box. That's a pity, because Common Lisp is a great language with many great features (macros, obviously, but CLOS and the condition system are also very powerful).
I end up writing much more code in Ruby than in Common Lisp, but, knowing Lisp so well, I know what I'm missing, and it hurts. Also, Ruby is _horribly_ slow, and objects take ridiculous amounts of memory (130 bytes for a simple cons cell?).
Please correct me if I got my facts wrong.
We might see an upsurge of interest in functional programming soon because it lends itself to parallelization. Clock speeds are no longer going to improve exponentially, and pure FP languages like Haskell and Erlang are naturally positioned to take advantage of multicore machines. For someone like me, who's interested in grokking FP better for that reason, neither Lisp nor Ruby seem like a natural choice, since both have side-effects. To me, Ruby is just another scripting language: a Perl with a cleaner syntax, and OO not bolted on (but not as mature in its implementation and libraries). If you're interested in general-purpose programming rather than scripting, and you want a programming language that permits both imperative and FP styles, OCaml would seem like the natural choice, because it compiles to very fast native code, and is available in a mature, high-quality, open-source implementation.
Find free books.
"Scheme is not Common Lisp, though."
Right. My perfect Lisp one be one with Scheme syntax and semantics, CL's performance, Java's libraries and perhaps a little less parenthesis.
Right now, that would be Haskell, except the library isn't anywhere as big as Java's. yet.
I don't feel like it...
I think Rubinius is a great project in its own right. Ruby is a very nice language to work with, but the current "official" implementation is terribly slow. Implementing it on top of a Smalltalk VM should give quite a speed boost, which should help make Ruby more useful for more applications. Of course, speed improvements and lots of other Good Things are also planned for Ruby 2.0 (AKA Rite).
Please correct me if I got my facts wrong.
Great! The three things I miss most from Ruby are (1) the ability to easily read and write programs (which Lisp provides, both through the built-in reader and printer and by virtue of the syntax being really simple and consistent), (2) macros (which Lisp provides, but can also be easily implemented once you have (1)), and speed (which will probably be severely improved by Rubinius).
Many Lisp implementations lack practical things like networking and string manipulation functions or integration with Unix. A Lisp dialect with all the functionality of Ruby will certainly have these.
Please correct me if I got my facts wrong.
"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"
So what your saying is that they take the code written by one set of non-developers (VB coders) and dump it on another group of non-developers (IT staff).
* C++ compared to C
This is just silly, you can write C programs in C++, and since the back end is usually shared you will end up with identical code. At most you can say that some of the C99 performance features have not yet found their way into C++, but that would go the opposite way of what you suggest. They used to be equally fast, but it has now (temporarily) become possible to write faster code in C.
* Interpreted compared to Compiled
True yesterday, true today, true tomorrow. Anyway it is not a language but an implementation issue.
* Java compared to C++
Does Java support value semantics for user defined types now? If not, it is still as true as ever. Eliminating unnecessary pointers is a huge win in many (most?) applications, and Java made it impossible by making everything (except build-in types) pointers.
* Servlets compared to CGI
Have no idea.
Maybe one day it wont. But truthfully, I hate Ruby on Rails evangelists more than any other type of evangelist.
Years of research have been performed on the topic of generating fast code from dynamic languages, particularly Lisp dialects, but most if not all Lisp implementations will still generate slower code for than gcc will for
Please correct me if I got my facts wrong.
The Ruby AI book is still a work in progress, but I decided to finish the second edition of the Lisp book first because it is a smaller effort. I have also done about 60% of my professional programming in Common Lisp in the last year, so I have Lisp on my mind. I use Ruby about 25% of the time now, and Java for most of the rest.
Ruby does rock!
``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 Programmer's Secret Weapon" that is a free download from the open content page on my web site.''
I read the first part of it, up to about the point where you claim that garbage collection is worth a few percent of performance. You might want to add that garbage collection can actually make your program _faster_, as has been demonstrated in some studies.
Please correct me if I got my facts wrong.
I was writing an application, where I needed to create a simple scripting system for it, and couldn't include any other pre-created scripting system, and I wanted to do it quickly. I was trying to use the absolute minimum code, and minimum overhead for parsing and running the code.
I realized, when I was done, that I had essentially created a variant of Lisp. It didn't quite have the same Lisp syntax or standard functions or whatnot... but basicly, it was Lisp. Lisp is the type of language that you can re-create by accident!
And that is why I think that Lisp didn't fade to obscurity, despite not ever being very widely used (Lisp zealots, please don't bother to flame!). Not because Lisp is particularly useful (I can think of a few areas where it would be useful, but it is more useful as ad addition to a standard OO language than an all-in-one tool for software development). But the design of Lisp, both in the language and how it is implemented, is just so *ELEGANT*. It is kind of like the programming language version of Legos - The way it works is just nifty. It has a certain functional simplicity with what it does. It sounds cheesy, but it is very zen.
And a Lisp interpreter is EASY TO IMPLEMENT!!! I wouldn't even know where to begin to write a C++ compiler... I would have to dust off a few books and really re-learn a lot of stuff that I have long forgot. But Lisp? Dead simple.
I probably won't ever use Lisp professionally, but I am happy that I had to write some Lisp programs in an AI class back in the day.
I base my comments on what is actually stated. I don't have any way to anticipate the excuses that come later.
"How much percent of actual professional VB developers is out there? (that is what I meant by "in the industry")"
Do you know a lot of VB developers writing hobby applications at home that are considered "in the industry"?
some studies, eh?
You also got the facts wrong. Geoffrey Grosenbach placed an initial bet on Rubinius which got the whole donation thing started.
Meme of the day: I browse "Disable Sigs: Checked". So should you.
"MVC isn't an abstraction (abstraction of what, in any case?), it's a compound pattern.
Your wrong when you say it isn't an abstraction (all patterns are abstractions), but your right to question what it is an abstraction of.
"Lisp has an unfortunate association with AI from the 1980s, but it is not specifically an AI language, it's just a language that makes hard problems like AI possible."
Prolog
"The only thing I guess I wouldn't use Lisp for is low level code, like drivers or other "OS level" stuff, because *nix is so heavily C oriented."
Genera
"The basic problem for Lisp is inertia. I'm starting a project right now to work on air-traffic algorithms. In these sorts of research projects, the usual "design -> implement" methodology goes out the window. Instead, you get a loop between design and implementation. You pick some initial algorithms, implement them, simulate the system, use the results of simulation to improve the algorithms, and repeat."
The same philosophy applies to Forth.
Thus the need for the new term 4GL.
Right you are - sometimes when very new objects are GCed, they can be collected faster than malloc'ed memory blocks. Objects that are in older generations can take much longer to GC -- I will update the book text -- thanks.
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?:
So, if Ruby is a dialect of Lisp, then it ought to be possible to compile Ruby to Common Lisp and then execute the result on the fast Common Lisp runtime, right?
That would be awesome - speed and library size are the only things keeping me away from Ruby (same as 3 years ago... still waiting for Ruby on Perl6 VM).
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Servlets compared to CGI
I assume you mean Servlets CGI v. Perl CGI. CGI defines the interface - ie, how the information arrives on the server. CGI scripts/programs can be written in C, sh, Perl, Python, yadda yadda. Just because Perl was the first language to really take off using the CGI, it doesn't mean it's the only one.
Hell, even PHP uses the CGI :)
-- Trinity in high heels carrying a whip: The donimatrix - there is no spoonerism
I've created a variant of Lisp's native s-expression format called "sweet-expressions". A sweet-expression reader can read typical s-expressions as-is, but it also lets you use indentation, infix, and more traditional function notation. Yet you can still use all of Lisp's macro power, including quasiquotes and so on. Programs are still lists, it's just that the lists are now readable.
See http://www.dwheeler.com/readable/ for more info.
- David A. Wheeler (see my Secure Programming HOWTO)
"A great democracy must be progressive or it will soon cease to be a great democracy." --Theodore Roosevelt
You seem very confused. Catalyst is flexible, and lets you use whatever components you want. But no, you do not "have to choose" anything, use the defaults if you don't have a reason not to. If you are coming to catalyst having already used mason in other projects, you will probably want to use mason for your views in catalyst, so it lets you do this easily. If you haven't used any templating module before, then just stick with the default TT and get coding.
But if I take a look at my code from then:
Yes, I was not a good programmer back then. But as time passed by, I grew up and saw that PHP sucked, even as I tried to use some development standard, I got no help from PHP.
Then I started to use Rails. Oh my god, how happier I am now. How coding flows better.
And just to say I'm not fair comparing a framework to a simple language, I've tried CakePHP and it is plainly ugly (compared to Rails).
I'm yet to try Symphony, that may change my mind. But I really don't think so.
And finally, about performance, do you have like thousands of users? DO you really need scalability? Then use Java.
Gee, and here I was thinking that (write '(a b c)) and (setf a 'b) had side effects.
Are you adequate?
eval($i);$i="',rekcah 6lreP rehtona tsuJ'tnirp=_$";