One Example of Irony

chromatic on 2007-03-05T22:09:44

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.


Apples and oranges

Adrian on 2007-03-06T08:12:35

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 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 to approach it, and to learn the new skills they'll need to maintain it.

Re:Apples and oranges

sigzero on 2007-03-06T13:04:19

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.

Re:Apples and oranges

Aristotle on 2007-03-06T17:01:46

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.

Nightmare Scenario

djberg96 on 2007-03-06T16:36:04

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 until rewrite in another language can commence.
  • Money wasted, managers fired, much teeth grinding.

But, nah, that would never happen, right? Wrong. I've seen a similar scenario play out here.

Re:Nightmare Scenario

Aristotle on 2007-03-06T17:12:09

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 bad choices for someone who needs such insurance anyway. I really don’t see how you can pick anything but Java or maybe C# if that’s your line of thinking.

Re:Nightmare Scenario

chromatic on 2007-03-06T19:12:22

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-competent monkeys is not the best way to succeed in software development.

Re:Nightmare Scenario

djberg96 on 2007-03-07T19:28:48

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.

Re:Nightmare Scenario

Aristotle on 2007-03-07T19:46:14

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?

Re:Nightmare Scenario

djberg96 on 2007-03-07T20:34:14

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 what's appropriate. 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.

Anyway, this is all academic. We won't know for certain until a couple years after the release of Perl 6. You're free to hope for the best, but I'm expecting the worst.

Re:Nightmare Scenario

chromatic on 2007-03-08T02:33:45

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 that they will do anything. It doesn't matter what they do, if they have access to your source code. They may never know about symbol tables or run-time code evaluation or method aliasing or macros or code generation or monkey patching, but you can be sure that they'll pull a stupid trick such as writing files and reading them in line by line because they don't know how to use arrays.

They're barely competent! They're undisciplined! They're monkeys! Want to fix your coding problems? Start by getting rid of monkeys, not by complaining about powerful tools that competent developers might be able to use productively.

Re:Nightmare Scenario

Aristotle on 2007-03-08T05:13:04

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 classes and the removal of eval despite the serious problems the Ruby community is having with them.

You’re free to hope for the best, but I’m expecting the worst.

I’m expecting the average. Dangerous programmers will be dangerous with whatever they have at hand and good programmers will put the things at hand to good use. Whether the thing at hand is the ability to define custom grammars is a red herring because what matters is whether the programmers are dangerous and/or incompetent or not.

Re:Nightmare Scenario

Aristotle on 2007-03-08T05:28:00

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 classes and the removal of eval despite the serious problems the Ruby community is having with them.

You’re free to hope for the best, but I’m expecting the worst.

I’m expecting the average.

Re:Nightmare Scenario

chromatic on 2007-03-08T02:26:45

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.