Newsflash: resorting to `eval` is a failure in your language

Aristotle on 2007-08-06T00:04:46

Even if the Rubyists think it’s fashionable and trendy.

Oh yeah, and Cosine Jeremiah has never heard of do. That’s OK, you don’t need to know a language before you can opine on its sucktitude.

Besides, what a great design! I mean, evaluating another source file every time you instantiate an object in that class? Awesome! If I had to maintain his code I’d refactor that part out of existence with a quickness!

---

ugh

rjbs on 2007-08-06T02:41:35

I'd reply, but... I have to log in? Ugh.

I really hate the "I do not understand the language, and therefore I hate it" school of blogging.

Huh?

djberg96 on 2007-08-06T04:38:04

So, Perl, Python, Ruby, etc are failures because they even have eval then? Or, are you merely criticizing people who actually use it?

Re:Huh?

Aristotle on 2007-08-06T05:00:24

I thought the title stated my position clearly: if you have to use eval, it’s a sign of something missing from the language (and if you don’t have to but do, it’s a sign of weakness as a programmer).

That doesn’t mean a language is bad if it has eval. If it helps you understand, just substitute goto for eval; both forms of the statement are completely congruent.

urine my do's

slanning on 2007-08-06T14:22:16

I'm glad that we in the Perl community are good pissers, because I think we're going to win this contest!

Thanks for playing

Aristotle on 2007-08-06T14:53:04

Better luck next time.

Re:urine my do's

chromatic on 2007-08-07T00:59:02

That's a horrible pun. I like it.

Reply

cosine on 2007-08-16T14:39:33

I think your aversion to eval is a mistake, but if it is not then you are not going to convince me with your current line of thought. I posted my reply: http://www.cosine.org/2007/08/16/languagepowered-domain-specific-language/

Re:Reply

Aristotle on 2007-08-16T16:54:17

How am I supposed to argue with your example? You showed a design wherein a class reads a config file every time it is instantiated. I have no idea how that can be construed as useful; the fact that you use eval is incidental and at best draws attention away from the fact that you are reading a config file on every instantiation. After all, “the config file is code!” Do you really need to recompile the code every time someone makes an instance of it? Sorry, that example just doesn’t cut it.

In any case I stand by my assertion that resorting to eval reveals a weakness in the language or in the programmer. There are some things that you cannot easily do in Perl without eval, and where the roundabout way confers no benefits over eval; these are things that I consider weaknesses in Perl.

Anyway.

You write:

Ovid’s most important point is that DSLs can also be implemented by coding your own lexer and parser instead of using eval. I did fail to mention that, but I think it lends yet more credence to my previous assertion: that Ruby has better support for DSLs than Perl. Otherwise, the Perl crowd would not be so much against using eval (on strings) instead of writing the parser.

I have no idea how you get from Ovid’s point that DSLs should be parsable without the full host language executing the code, to the idea that Perl programmers are against eval because the language is lacking in DSL support. I don’t even know what the latter is supposed to mean. In my best effort to understand that paragraph I cannot find anything more than a non-sequitur.

Not to mention that I don’t agree with Ovid on what a DSL is, so lumping all the Perl types together based on his assertion is… silly at best.

The closest I have ever seen in Perl was a configuration file made up of a large number of variable assignments.

That’s silly. Perl has this handy function called do (I believe I wrote about it in my last entry, didn’t I?) which will let you eval a file; and the code in the string passed to eval (and by extension, in the file loaded by do) can return a value, so the file could consist of the initialisation of an anonymous hash, which will be passed back to whoever invoked do to load the file. It is very easy to use Perl as the configuration language for programs written in Perl.

I believe the Perl community’s recommended way to do this with about the same amount of code would be to have modules instead of configuration files for each vulnerability.

In the case of that program, yes, that would be the right approach.

With a DSL I do not have to mess with package overhead or making sure my @INC array will contain the directory with my vulnerability information.

Where “DSL” is a grandiose way to say “string eval”, “mess with package overhead” is a grandiose way to say “apply proper programming discipline so that code in one of the files doesn’t trample all over code in the other”, and the other part is a grandiose way to say “I didn’t know about Module::Pluggable”.

I have also written a fetchmail/procmail hybrid in 512 lines of Ruby.

I did the same in Perl. It’s about 60 lines plus a bunch of CPAN modules – mostly glue to bind Mail::POP3Client to Email::Filter…

My personal configuration file for this is about 60 lines, but there is no reason you would need more than 5 if you wanted very basic functionality.

… except for, I wrote it the other way around: the 60 lines of glue code are in a module, and what would be the “configuration file” in your case is, in my case, simply a short Perl program that uses the module. In this way I get to avoid the necessity for making up any conventions at all.

What did I gain, in addition to the benefits I noted above, in my DSL for the fetchmail/procmail hybrid?

I think you lost track of your argument about Perl vs Ruby. All of the benefits you listed are completely incidental to the fact that you were using Ruby. There is no qualitative difference our independently conceived designs, judging from the description you gave.

Re:Reply

cosine on 2007-08-16T18:53:50

I'll just take this to mean we still have irreconcilable differences in our opinions here. :) I appreciate the time you took to respond.

Re:Reply

Aristotle on 2007-08-16T19:34:47

Basically my opinion is that anyone who thinks Perl, Python and Ruby differ in any sort of significant fashion hasn’t seen a lot of languages. The three are close to identical. Sure, there are lots and lots of superficial differences – they optimise in different directions, and that is what ends up making me prefer Perl and you Ruby and still others Python. But their fundamental premises are completely identical so there is no substantial difference in terms of expressiveness, overall. Ruby wins at some things, Perl at others, and Python takes its share of victories.

(Btw, Javascript 1.x falls in the same class as these three.)

If you haven’t, try to look past the echo chamber of ’90s dynamic languages and dig into some really different languages. Try Smalltalk. Pick up Haskell. Look at Forth. Read about Prolog. Write some XSLT. With a broader view of programming languages you should realise that the differences between Perl, Python and Ruby (and Javascript) are no more than cosmetics. Important cosmetics in terms of mental model (and therefore many people will naturally take to one of these, and not so much to the others – whereafter they promptly proceed to confuse this with superiority of their preferred language), but cosmetics nonetheless.

And I still don’t know what “DSL support in a language” is supposed to mean and how Ruby is purportedly better at it than Perl.