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

Re: [extremeperl] Book: Higher Order Perl

Expand Messages
  • Rob Nagler
    ... You are using a type system for machine reasoning. The Haskell evaluator is but one type of inference engine. You probably could use Mycin just as
    Message 1 of 58 , Mar 30, 2005
    • 0 Attachment
      Adam Turoff writes:
      > Absent a strong type system that can be pushed in these directions,
      > I agree with you -- the next best thing is a dynamic type system
      > (like Perl's, or Smalltalk's, or ...) aided by agile development
      > practices.

      You are using a type system for machine reasoning. The Haskell
      evaluator is but one type of inference engine. You probably could use
      Mycin just as easily. There's a Mycin implemenation available in Ruby
      which is a 180 NCLOC. I didn't see one for Perl, but I don't think it
      would be too hard to convert the Ruby to Perl.

      > I haven't read your book, but this sounds like what is commonly
      > known as a domain specific language (DSL). At least, that's what the
      > lispers have been calling it for the last 25+ years. ;-)

      There's a subtle difference. SMOP is a methodology. It involves
      solving the problem simply and refactoring your way to a system that
      represents the concepts succinctly through disciplined elimination of
      redundancy. This is slightly different than what people mean by a DSL
      in Lisp. For example, you might actually build an API, which maps to
      the domain. The methods would mean something to a subject matter
      expert, but the language would be ordinary Perl. This is a SMOP, but
      probably wouldn't be a Lisp DSL.

      > 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. It implies that you are
      already a domain and programming expert. This combination is
      extremely rare, if it ever happens. It is also sets up a poor
      communication scenario with the customer, because you have to either
      sit in a corner learning the domain for an extended period of time, or
      you have to say to the customer, "I get it, and leave me alone".

      Well-designed systems get that way, because end-users give continuous
      feedback, and the programmers listen carefully and adapt the system to
      meet the users needs, which they can't possibly know in advance.

      Rob
    • Tom Vilot
      ... Wait. That sounds like Rob .... ;c) (kidding) ... Wait. That *also* sounds like Rob ... ... (not kidding!)
      Message 58 of 58 , Apr 8, 2005
      • 0 Attachment
        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.