Loading ...
Sorry, an error occurred while loading the content.
 

Re: [extremeperl] Book: Higher Order Perl

Expand Messages
  • Adam Turoff
    ... No, you re using BDUF to be dismissive of DSLs. DSLs can be lightweight. ... Um, no it doesn t. At $WORK, I m managing with a DSL to configure webapps.
    Message 1 of 58 , Mar 31, 2005
      On Mar 31, 2005, at 1:07 AM, Rob Nagler wrote:
      > Adam Turoff writes:
      >> Refactoring your way into a DSL is certainly one way to do it. I'd
      >> argue that designing a DSL is a better way to do it.
      >
      > In XP, we call this Big Design Up Front.

      No, you're using BDUF to be dismissive of DSLs. DSLs can be
      lightweight.

      > It implies that you are
      > already a domain and programming expert.

      Um, no it doesn't.

      At $WORK, I'm managing with a DSL to configure webapps. It's in XML
      because the people who will work with it already grok XML, and anything
      else (even YAML) represents extra effort. The "language" (if you can
      call it that) describes a simple domain -- the 17 knobs and dials that
      can be tweaked in these products. The programming effort is exceedingly
      modest.

      These files are processed and converted into classes at runtime. You
      can dismiss this as "just a config file", but this looks, acts, smells
      and behaves just like a DSL. No BDUF whatsoever.

      -- Adam
    • Tom Vilot
      ... Wait. That sounds like Rob .... ;c) (kidding) ... Wait. That *also* sounds like Rob ... ... (not kidding!)
      Message 58 of 58 , Apr 8, 2005
        Greg C wrote:

        >
        >
        > Consider: projects A and B have identical goals. In project A, you
        > have free
        > rein in your choice of software and hardware tools. However, the
        > manager sets
        > arbitrary deadlines, likes to stand behind people and criticize their
        > code as
        > they type,


        Wait. That sounds like Rob ....
        ;c) (kidding)

        > On project B, the choice of langauge and hardware are made for you and
        > there's
        > only one computer per two programmers. On the other hand, the manager
        > sees his
        > people as people, negotiates requirements and schedules on a realistic
        > basis,
        > trusts his people, follows a set of best practices (be it XP or some
        > other) and
        > chases everyone out of the office at 5:30.


        Wait. That *also* sounds like Rob ...

        :c)

        (not kidding!)
      Your message has been successfully submitted and would be delivered to recipients shortly.