Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/
Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Monday March 05, 2007
05:09 PM

One Example of Irony

[ #32583 ]

comp.lang.ruby likes to discuss Perl now and then, just as Perl newsgroups and lists like to discuss Ruby. I found one discussion particularly amusing, specifically maintaining code written in real DSLs in Perl 6 may be difficult.

Isn't Ruby the language with the community that walks very funny every time someone creates an API that uses symbols?

You'd almost think that speaking the language of your customer were a bad thing... unless you slap a colon on the front of all your nouns, that is, and immediately follow them with fat arrows.

Maybe all DSLs are equal, but some DSLs--the ones that look exactly like Ruby code--are more equal than others.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

One Example of Irony 13 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • An internal DSL of the Ruby kind, and an internal DSL of the Lisp/Perl 6/Pop-11 kind are potentially very different beasts. And hell yes - there are some folk who do turn them into an evil maintenance nightmare. Language writing is a skill and it takes time for folk to learn it.

    There are some folk [perlmonks.org] in the Perl community who think it'll be a maintenance nightmare too.

    I'm not one of them -but being to redefine the syntax of a language is a powerful tool. It'll take time for folk to figure out the best way

    • I'm not one of them -but being to redefine the syntax of a language is a powerful tool.

      Tcl has that built in and I have yet to see it misused to the point of someone saying "Huh?". I think it makes the Tcl community think more than twice when redefining syntax in an app.

      • D. Richard Hipp occasionally raves about how Tcl’s provisions for the creation of new syntax allow his Tcl SQLite bindings to provide control structures and constructs that completely shield the programmer from the details of the database API.

  • I wasn't talking about sigils. I was talking about using a DSL based on a custom parser, regardless of language. Here's the nightmare scenario:
    • Programmer modifies parser within company X
    • Programmer writes DSL based on modified parser
    • Many users at company X begin using DSL
    • Programmer leaves company X.
    • Bugs discovered in modified parser and/or changes need to be made.
    • No one knows how to modify code to handle new requirements (because the programmer didn't bother to document anything). Code freeze ensues u

    • The problem here is not the language allowing a dangerously semi-competent to implement a custom grammar DSL. It is the fact that the programmer is dangerously semi-competent in the first place, which is why he chose to implement a custom grammar DSL despite it being an inappropriate choice under the tasks and concerns at hand.

      Making powerful stuff harder for competent programmer doesn’t give you any insurance against the idiocy of the dangerous ones. Perl 6 (or Perl 5, or Ruby, or Python) seem like

    • I've more often seen:

      • Barely-competent monkey implements a feature using his preferred (read: quirky) development style
      • Barely-competent monkey leaves company somehow
      • Everyone discovers that barely-competent monkeys can barely program and spend way too much time deciphering big balls of mud with clever (read: barely-literate) identifier names
      • Rewrites descend like the Hammer of Zeus

      It seems that these two scenarios have a lot in common, namely the barely-competent monkey. Perhaps hiring barely-compe

      • Competence is not an issue because barely competent monkeys, by virtue of the fact that they're barely competent, will not or cannot create a custom grammar DSL.

        It's the very smart but undisciplined programmers that will be the issue, and there's plenty of those.

        • Same difference.

          You’re seriously saying that very smart but undisciplined programmers won’t find a way to cause damage if you just take the complex toys away from them?

          • No, I'm arguing that the degree of damage is much worse. I can decipher and fix bad Ruby code, for example, because I know the underlying language.

            I could not, however, fix a Ruby backed DSL that's broken and based on a custom grammar, because I wouldn't know the grammar. It's possible I could *learn* the grammar, true, but not everyone can. Besides, now you're talking about more time, with less return on the time I invest.

            As for "complex toys", language designers have to make their own decisions as to

            • I can decipher and fix bad Ruby code, for example, because I know the underlying language.

              You know Ruby's syntax maybe, but who says you know the domain of the business problem the code attempts to solve?

              I maintain that that is much more important than syntax--and if you have undisciplined, barely-competent monkeys who cannot or will not write maintainable code, then your biggest risk is not that they might use powerful language features to do bad things that are hard to unravel.

              Your biggest risk is

            • For example, Matz, for various reasons that include fear of programmers shooting their own foot off, has refused to add Lisp style macros to Ruby.

              Meanwhile, everyone’s using eval and “monkeypatching” like it’s going out of style next year. Recently I saw someone say that missing_method should be avoided because it may break when someone monkeypatches your class. These people certainly have their priorities straight, oh yeah.

              Somehow I don’t see anyone advocating closed cla

            • For example, Matz, for various reasons that include fear of programmers shooting their own foot off, has refused to add Lisp style macros to Ruby.

              Meanwhile, everyone’s using eval and “monkeypatching” like it’s going out of style next year. Recently I saw someone say that missing_method should be avoided because it may break when someone monkeypatches your class. These people certainly have their priorities straight, oh yeah.

              Somehow I don’t see anyone advocating closed cla

        • Discipline is part of competence. If you have undisciplined monkeys as co-workers, your biggest problem is not your choice of programming language. Your biggest problem is that you work with undisciplined monkeys.

          Maybe they're less dangerous if you only let them use antelope bones and dull rocks than if they had power sanders and nail guns, but you're not going to get good work out of undisciplined monkeys no matter how powerful or useless the tools are because they're undisciplined monkeys.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.