use Perl

• Reply (Score:1)

  by cosine (8058)

  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/ [cosine.org]
  • Re:Reply (Score:1)

    by Aristotle (5147) <pagaltzis@gmx.de> on 2007.08.16 11:54 (#57018) Homepage Journal

    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 [perl.org] (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 [cpan.org]”.

    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.

    Reply to This

    Parent

    • Re: (Score:1)

      by cosine (8058)

      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: (Score:1)

        by Aristotle (5147)

        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