Shae Matijs Erisson writes:
> I also use HUnit, but I don't think that single-case unit testing is as
> powerful as generative testing.

Does the generative tool automatically compute the boundary
conditions?

> And I choose Haskell because I am convinced I can do a better job for my
> clients with Haskell than I can with other languages I have used.
> I mostly get paid to write Python for Zope/Plone, but I do use Haskell when
the
> language of implementation is not important to my clients.
> (Including unit tests for Zope using Haskell's XmlRpc library.)

What do you mean by "better job"?  Done faster?  Higher quality?

Rob

On Mar 29, 2005, at 7:20 PM, Rob Nagler wrote:
> I don't value strong-typing.  I value close relationships with other
> programmers so that we can communicate effectively about programming.
> Stong-typing and compiled interfaces are designed for organizations
> with programmers who don't have close relationships and who are poor
> communicators.

Um, I think you're confusing strong typing with the type system commonly
found in C, C++, Java and friends.  That's *not* strong typing in any
sense of the term if it were, this nonsense wouldn't be possible:

	 double d = 3.14159;
      int i;
      i = *(int*)&d;  /* ick.  I need to wash my hands now... */


Terrence brought one particularly surprising example of a benefit
of strong typing earlier today -- an infinite loop found in the
compiler, not at runtime:

	 http://perl.plover.com/yak/typing/samples/slide027.html

Sure you can find those bugs by running the program (and watching
it overflow the stack), or through pair programming.  But the paper
that Shae pointed to

	 http://research.microsoft.com/Users/simonpj/Papers/financial-
contracts/contracts-icfp.htm

describes a system to define financial contracts that are *also*
checked for validity.  Also by the compiler, without running code.
Coincidentally, that system can also evaluate those contracts, instead
of just modelling them.

No, you can't do that with C's type system.  No, that type system isn't
designed for organizations dealing with programmers who don't know how
to communicate with one another.


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.  A strong type system allows you to turn the knobs
from 11 all the way to 20 or 30.  ;-)

>> HOP can only get you so far.  There are other concepts that don't
>> map easily to Perl, or at least seem trivial and useless until you
>> see them used in their original context.
>
> Please elaborate.

See above.

> The last chapter of my book talks about
> Subject Matter Oriented Programming (SMOP), which basically is the
> theory that refactoring is the best teacher.  If you truly want to
> eliminate redundancy in imperative code, you will have to invent or to
> learn about another paradigm.

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.  ;-)

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.

> It's very interesting to me that Java is getting all the stuff Perl
> had (like closures) many years ago.  Before long, it'll have eval.

Yep.  And those came from Lisp.  And Perl6 is getting macros, also
from Lisp.

Paul Graham talks about this in _The Hundred Year Language_

	 http://www.paulgraham.com/hundred.html

In _Beating the Averages_, he talks about "The Blub Paradox", where you
don't know what features you need from more powerful languages if you're
stuck using a less powerful language:

	 http://www.paulgraham.com/avg.html

-- Adam

Sorry for starting a new thread; I just joined this list.  I was told
about the thread regarding different paradigms of programming and how
"Perl" allows one to handle many different and thus one doesn't need to
learn other languages.  Pulling out one quote from Rob Nagle from the
thread:

  > Here's a bold statement: you don't really need to learn a new
  > programming language, if you know Perl. Perl allows you to think like
  > you would in Haskell, C, Java, Lisp, etc. You do need to learn all
  > that Perl offers, and that's where HOP fits in.

Rob, I'm sorry, but this is completely wrong.  It reminds of me of a
kid in a writing class who explained to our prof that he doesn't need
to visit foreign countries because he has the Internet.  I didn't know
whether to laugh or cry.

Another example:  I speak French.  I don't speak it as well as I used
to, but I can still hobble along a bit.  As soon as I started learning
French, my grades in English shot up quite a bit.  Aside from some odd
idiomatic constructs in both languages, there's little that can be
expressed in one that can't be expressed in another, but that hardly
suggests that learning French is a useless exercise.

More examples:  when I learned Java, my OO Perl knowledge and ability
improved tremendously.  There's not much in Java that I can't do in
Perl (the reverse is not true, oddly enough), but even Java's "almost
OO" implementation was tremendously useful.

And then we get to Smalltalk.  Take a gander at this code
(http://squeak.org/tutorials/cphoenix_tutorial/intro.html):

1.  hello: times
2.   (times > 100)
3.      ifTrue: [ Transcript show: 'You will get bored!']
4.      ifFalse: [1 to: times do: [:i | (Transcript show: 'Hello
World') cr]]

(I added the line numbers)

Line two is not a conditional.  It's a constructor that returns a
boolean object.  Lines 3 and 4 are the "ifTrue" and "ifFalse" messages
that are sent to the boolean instance.  The object decides how to
handle (and even ignore) those messages.  There really aren't if/else
statements in Smalltalk.  And what does that mean for this argument?
After I started thinking about that for a while and examining my OO
code, many of my if/else statements were actually encapsulation
violations.  By rigorously excising them, my code became simple, more
correct and easier to maintain.  By diving into another programming
culture, I learned more about my own.

Maybe you can do without other programming languages for the bulk of
your work, but you cannot replicate their culture in Perl.  You cannot
truly understand what it is to be French without living over there.
Think of Java:  so much Java code out there is merely procedural code
wrapped in classes.  There's nothing OO about it (and the same is true
of many Perl OO modules).  However, those who write that code are quite
likely to claim they understand OO.

So my subject was rather tongue-in-cheek, but it's not too far off.
MMy code currently only touches the full power of logic programming.
It doesn't allow modules, there are no definite clause grammars (yet)
and operator support is limited.  What does most of that mean?  Who
knows?  One will never know if one only goes by my code.

Cheers,
Ovid

Adam Turoff <adam.turoff@...> writes:

>  But that
> doesn't address the fact that functional programming in Perl loses
> something in translation.

Haskell is a powerful synthesis of 2 ideas: pure functional
programming _and_ strong typing. Perl lacks both of these. So, you
lose 2 things masterfully combined by trying to learn the Haskell
mindset from Perl only.

> It may be subtle, or it may be significant, but *something* is lost.

The significant one is Monad-style programming: functions combine with
container types to produce new container types.

--
	 Carter's Compass: I know I'm on the right track when,
	    by deleting something, I'm adding functionality.

Adam Turoff <adam.turoff@...> writes:

>
> Here are some other goals for learning a new language:
>    - learn how to say more with less code
>    - become more productive

Autrijus' recent perl.com interview echoes this. He solved a
binary-file parsing problem in Haskell, creating a solution that scales
linearly. Autrijus also points out some serious performace weaknesses,
limitations, and absences from Perl:

<quotes src=http://www.perl.com/pub/a/2005/03/03/pugs_interview.html>

Perl 5 is doomed because it has no COW - Copy-on-Write

Using Haskell to develop OpenAFP.hs led to programs that eat constant
2MB memory, scale linearly, and are generally 2OOM faster than my Perl
library.

Oh, and the code size is 1/10.



</quote>

--
	 Carter's Compass: I know I'm on the right track when,
	    by deleting something, I'm adding functionality.

Rob Nagler <nagler@...> writes:

> What do I have
> to learn from Haskell that I can't learn by refactoring Perl code and
> reading Perl resources?

*YOU* have very little to learn because your Perl code is very
type-oriented and every expression in every line is super tight with
no excess state laying around.

You use Perl in a very functional way because you place a premium on
declarative thinking, probably due to your background in Electronics.

But Perl does not enforce the standards for coding that you employ. It
adds 5 and 5.0 just as happily as 5 and 5. etc etc.

--
	 Carter's Compass: I know I'm on the right track when,
	    by deleting something, I'm adding functionality.

chromatic <chromatic@...> writes:

> On Tue, 2005-03-29 at 12:57 +0000, Terrence Brannon wrote:
>
>> In a strongly typed functional language, reasoning by proof gives you
>> 100% _certainty_ that a certain function works for all input. There is
>> no need to test.
>
> Surely you left off the disclaimer that you have defined the function
> correctly

I did but a function is a small clear statement about how input(s)
transform into output reliably, time after time, without fail and
without intermediate state.

> -- or does your typechecker magically reason that a square
> root function that takes an integer may sometimes return an irrational
> number?

1/ You really should take a look at the Maybe monad in Haskell
sometimes. It addresses a lot of issues that Perl programmers run into
when chaining together methods where a method in the middle might
return something to break the chain. The "may sometimes" in your
sentence above is a well-typed strategy of computation in Haskell. It
is a collection of if-thens, try-throw-catches in Perl and other
languages.

2/ The haskell sqrt function takes a datum of typing Floating and returns
a datum of the same:

terry@Abulafia:~$ ghci
    ___         ___ _
   / _ \ /\  /\/ __(_)
  / /_\// /_/ / /  | |      GHC Interactive, version 6.2.2, for Haskell 98.
/ /_\\/ __  / /___| |      http://www.haskell.org/ghc/
\____/\/ /_/\____/|_|      Type :? for help.

Loading package base ... linking ... done.
Prelude> :type sqrt
sqrt :: forall a. (Floating a) => a -> a
Prelude>

--
	 Carter's Compass: I know I'm on the right track when,
	    by deleting something, I'm adding functionality.

Rob Nagler <nagler@...> writes:

> Shae Matijs Erisson writes:
>> I also use HUnit, but I don't think that single-case unit testing is as
>> powerful as generative testing.
>
> Does the generative tool automatically compute the boundary
> conditions?
>

T Moertel developed the Haskell-inspired CPAN module Test::Lectrotest for
this purpose:

      http://search.cpan.org/~tmoertel/Test-LectroTest-0.3200/


--
	 Carter's Compass: I know I'm on the right track when,
	    by deleting something, I'm adding functionality.

The guys at the office keep laughing at me, because I can't stop
trying to explain what I mean.

Someone at my office mentioned Gerry Weinberg's comment that you need
to "refill the well" if you are a consultant.  You need a way of
becoming better at what you do.  That same someone said he would like
to learn Haskell to learn how Haskell programmers think.  I then posed
the following question:

If you had a week to refill your well, would you like to spend it
learning Haskell from a book or programming with Dan Ingalls
programming Smalltalk?  (Said programmer is already a Smalltalker.)

If you don't know how Dan Ingalls is, substitute: Guy Steele, Paul
Graham, James Gosling, Richard Stallman, Don Knuth, Butler Lampson,
etc.

Do you learn programming from people or languages?  I think the answer
is people.  You learn by working on real systems written by real
people.  The more skilled the people who wrote the systems you work
on, the more experience you will gain by working on them.  You'll see
patterns that aren't in any textbooks or language comparison classes.
You'll learn the tradeoffs skilled programmers make when faced with
complicated problems.

My co-worker said he didn't have the opportunity to work with any
gurus so my point is moot.  I disagree.  I can read the source to
Emacs to learn how Stallman thinks, or perhaps gcc.  If I am a
Pythoneer, I can look at doclifter by Eric Raymond to get an idea of
what a great hacker would do with Python.  You could look at bOP, if
you wanted to look at how a
Basic-Fortran-Pascal-C-Modula-2-Java-Tcl-Perl-etc programmer might
program a declarative application framework in Perl.  And so on.

Learning another system from the code is quite difficult.  However,
the best programmers I know, are also the best code readers.  They can
pick up anything and fix it or make it better.

If you want to be a better programmer, don't learn a new language,
rather learn how someone else solved a complicated problem in a small
amount of code in a language you already know.

Rob

On Mar 30, 2005, at 8:12 PM, Terrence Brannon wrote:

>  >> In a strongly typed functional language, reasoning by proof gives
> you
>  >> 100% _certainty_ that a certain function works for all input.
> There is
>  >> no need to test.
>  >
>  > Surely you left off the disclaimer that you have defined the
> function
>  > correctly
>
>  I did but a function is a small clear statement about how input(s)
>  transform into output reliably, time after time, without fail and
>  without intermediate state.

Well, the still doesn't do it.  Even if you can prove a small section
of the code is correct, that does not necessarily mean that it's
complete.  Further, as various components fit together, you still have
trouble proving that the entire system is both complete and correct.
To say that there is no need to test is an indication of a) unclear
thinking, or b) me coming in late to the discussion and missing some
context.

Cheers,
Ovid

[Non-text portions of this message have been removed]

Curtis Poe writes:
> 1.  hello: times
> 2.   (times > 100)
> 3.      ifTrue: [ Transcript show: 'You will get bored!']
> 4.      ifFalse: [1 to: times do: [:i | (Transcript show: 'Hello World') cr]]

Code!  Notice the bug?  Here's a refactoring that eliminates
redundancy and the bug:

     hello: times
	 (times > 100)
	     ifTrue: [self print: 'You will get bored!']
	     ifFalse: [times timesRepeat: [self print: 'Hello World')]];

     print: s
	 Transcript show: s; cr

I am not a Smalltalker, but I suspect there's a way to do this in
Smalltalk:

     sub hello {
    	 my($times) = @_;
	 print(STDOUT
	     map("$_\n",
	    	 $times > 100 ? 'You will get bored!'
	    	 : map('Hello World', 1 .. $times),
	     ),
	 );
     }

> My code currently only touches the full power of logic programming.
> It doesn't allow modules, there are no definite clause grammars (yet)
> and operator support is limited.  What does most of that mean?  Who
> knows?

But what's it for?  What problem are you trying to solve?

Rob

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

Terrence Brannon writes:
> <quotes src=http://www.perl.com/pub/a/2005/03/03/pugs_interview.html>
>
> Using Haskell to develop OpenAFP.hs led to programs that eat constant
> 2MB memory, scale linearly, and are generally 2OOM faster than my Perl
> library.
>
> Oh, and the code size is 1/10.

Code!  I love code.  Here's the source:

http://search.cpan.org/~autrijus/Parse-AFP-0.23/lib/Parse/AFP.pm

Now when I hit some new code, I get the lay of the land:

$ find lib -name \*.pm | wc
     207     207    4929

Whoa!  207 perl modules?   This must be a huge system.  Oh wait, let's
look around:

$ wc $(find lib -name \*.pm) | colrm 8 | sort -n -u | wc
      19      19     152

Me smells redundancy, me does:

$ wc $(find lib -name \*.pm) | grep -c ' *11 '
168

Egads!  168 perl modules which are exactly 11 lines long.  And,

$ wc $(find lib -name \*.pm) | grep -c ' *11 *33 '
154

Gad zukes!  154 have exactly 11 lines and 33 words.  And,

$ wc $(find lib -name \*.pm) | grep -c ' *11 *33 *269* '
95

Holy Redundancy, Batman!  Almost half modules have exactly 11 lines,
33 words, and 269 characters.

There's plenty of low hanging refactorings just from this quick
analysis alone.  Unfortunately, for all that code (2,809 lines), there
are only two tests (89 lines) which use the same input file (752
bytes).  I suspect that if I were to try and refactor the code, I'd
break something that wouldn't be covered by the existing test cases.
Oh well.

Rob

Terrence Brannon writes:
> *YOU* have very little to learn because your Perl code is very
> type-oriented and every expression in every line is super tight with
> no excess state laying around.

If you buy into refactoring, your code can be that way, too.

> You use Perl in a very functional way because you place a premium on
> declarative thinking, probably due to your background in Electronics.

I doubt it.  I put a premium on problem solving, whatever the
problem.  I hate repeating myself, especially when it comes to finding
the same bug over and over again.

> But Perl does not enforce the standards for coding that you employ. It
> adds 5 and 5.0 just as happily as 5 and 5. etc etc.

I believe you need lots of discipline to program.  If you believe that
purely functional programming is the best way to satisfy your
customers, you program that way, in any language, even if all you have
is an assembler.  No language or methodology is going to protect the
customer from undisciplined programmers.

Rob

Terrence Brannon writes:
> > Does the generative tool automatically compute the boundary
> > conditions?
>
> T Moertel developed the Haskell-inspired CPAN module Test::Lectrotest for
> this purpose:

Lectrotest is a simple random tester.   You have to define the
boundary conditions yourself when you hopefully have already done that
in the code.  Is this what QuickCheck does?  (Another reason not to
learn Haskell. ;-)

Rob

Rob Nagler <nagler@...> writes:

> Here's our language for defining SQL queries in Perl for our domain:
>
>     {
>  version => 1,
>  can_iterate => 1,

<snip code>

HaskellDB allows higher-order database queries, and I don't think this does.
I used to work with multi-page SQL queries in some trust management code.
We always wished for some way to pass one bit of SQL as the parameter to
another bit of SQL. HaskellDB allows that ( see test/higher-order.hs )
and checks that the resulting relational query is somewhat sane.
One advantage of combinators is that they can be composed with each other.

> We don't end up with legal SQL, because the definition of what is
> legal depends on the run-time binding to the database vendor we are
> using.  That's on reason why we defer errors to the SQL interpreter
> and avoid parsing any SQL in our library.  (Our model allows you to
> inject SQL directly at different points in the processing.)

SQL is still one step away from relational operations.
You could directly output the relational operations you're producing and turn
that into SQL for each backend, and you'd be able to do some sanity checks in
the process.
--
Programming is the Magic Executable Fridge Poetry, | www.ScannedInAvian.com
It is machines made of thought, fueled by ideas.   | -- Shae Matijs Erisson

Rob Nagler <nagler@...> writes:


> No language or methodology is going to protect the
> customer from undisciplined programmers.

I would love to have some quantitative data on this. I really think
Junior Haskellers would write cleaner code than Junior Perlers. The
stateless orientation of Haskell ensures this.

Furthermore, refactoring is more possible in Haskell than Perl because
expressions in Haskell are akin to database SQL or a
spreadsheet - they are order independant and self-contained. For Perl
neither of these must be true. In Haskell, they must be true.



--
	 Carter's Compass: I know I'm on the right track when,
	    by deleting something, I'm adding functionality.

Rob Nagler <nagler@...> writes:

> Does the generative tool automatically compute the boundary conditions?

You give a condition, QuickCheck generates a random input and stuffs that into
your condition to see if it's true. If it fails you see what input failed.

prop_RevUnit :: [Int] -> Bool
prop_RevUnit x =
     reverse [x] == [x]

This condition states that the reverse of an input is equal to the input.
Randomly generated inputs rarely pass this test. (only lists of length 1 or 0)

prop_RevApp :: [Int] -> [Int] -> Property
prop_RevApp xs ys = reverse (xs ++ ys) == reverse xs ++ reverse ys

This claims that list reversal is distributive over list concatenation.

Properties are half the work with QuickCheck, the other half is generators.
Usually it's pretty easy.

For ICFP2003 we generated random terrain with this datatype and generator:

data Terrain = Road | Start | Goal | Impassable Char

instance Arbitrary Terrain where
     arbitrary = frequency
                 [(10,return Road),
                  (7,return (Impassable 'g')),
                  (2,return Goal),
                  (1,return Start)]

We then used that to generate totally random maps.
If you want maps that fulfill a particular condition such as 'connected from
start to goal' you define that condition and use ==> which filters generated
data according to a predicate.
Or you can define a separate generator that always produces connected maps.

In my opinion, this sort of generative testing is a better approach that single
case unit testing. It can require more work to get the more general testing.
I bet you're not surprised.

QuickCheck has been ported to Common Lisp, Python, Perl.
The ports do lose something in the process, for a variety of reasons.

> What do you mean by "better job"?  Done faster?  Higher quality?

Done faster, higher quality, and more 'code as communication'. Want details?
For more on 'communication' see a recent post of mine to the shootout list:
http://lists.alioth.debian.org/pipermail/shootout-list/2005-March/001296.html
And if you have any ideas on how to do a 'code as literature' critique website,
I would really like to know. Maybe there's already such a thing for Perl?
--
Programming is the Magic Executable Fridge Poetry, | www.ScannedInAvian.com
It is machines made of thought, fueled by ideas.   | -- Shae Matijs Erisson

Rob Nagler <nagler@...> writes:


> (Another reason not to
> learn Haskell. ;-)

Haskell took 1st and 2nd in the main draw of the ICFP 2004 Programming
Contest. Would you like to compete in ICFP 2005 using Perl?

On the other hand, as I have stated elsewhere:

    http://sequence.complete.org/node/40

Haskell would have a hard time if the problem at hand required any
real-world tools. There is no equivalent of the following in Haskell:
       - CGI.pm - the CGI support in Haskell doesnt even have cookies
       - Mail::Box - thousands of man-hours have gone in to mapping the
         Mail RFCs in to hundreds of Perl objects. In a time-critical
         application requiring this functionality Haskellers would still
         be writing Mail::Box while Perlers would type use Mail::Box
         and go on
       - Date::Manip/Date::Calc - huge packages for handling dates
       - Bricolage - where's the enterprise-class content mgmt system
         written in Haskell?


--
	 Carter's Compass: I know I'm on the right track when,
	    by deleting something, I'm adding functionality.

Rob Nagler <nagler@...> writes:

> Curtis Poe writes:
>
>> My code currently only touches the full power of logic programming.

> But what's it for?  What problem are you trying to solve?
>


How else are you going to solve the 8 queens problem? lol
I guess I find it hard to see the practical use of logic programming.

There is a dynamic logic language written using 4 Haskell files :

       http://homepages.cwi.nl/~jve/dynamo/

That shows how close Haskell is to the lambda calculus and predicate
logic.



--
	 Carter's Compass: I know I'm on the right track when,
	    by deleting something, I'm adding functionality.

Rob Nagler <nagler@...> writes:

> If you want to be a better programmer, don't learn a new language,
> rather learn how someone else solved a complicated problem in a small
> amount of code in a language you already know.

Within Perl, I can list 3 books that refilled my well:

1/ Effective Perl Programming. This was the book that really opened my
eyes to what could and should be done with Perl. Here I learned to use
one metaphor instead of 5 lines of code.

2/ Object-Oriented Perl. This, along with Damian's modules were quite
astounding.

3/ It sounds like Higher-Order Perl might be the 3rd book to knock my
socks off. But I have strong faith that spending my free time learning
Haskell is the most productive thing I could be doing right now.

Honorable mention goes to Data Munging with Perl. He took the topic
that is Perl's sweet spot and managed to articulate in words, sections
and chapters what Perl covers in giant steps in domain after domain.

And finally, observing the new submissions to CPAN on a daily basis
really helps you see what problems people have and how they solve
them. I really wish Rose::DB had come out a few years back and I am
doing my best to master DBIx::SQLEngine having enjoyed and been
enthralled by the object wizardry of Class::DBI.

> >
> Rob
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

--
	 Carter's Compass: I know I'm on the right track when,
	    by deleting something, I'm adding functionality.

Rob Nagler <nagler@...> writes:

> 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 don't think you would get the same benefits from using an expert system as a
type system. The HM type system has various guarantees (like termination) that
are important for a usable type system.
Anyway, I doubt type theory is on-topic here.

> 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".

I don't believe this is true in Haskell. Using any monad in Haskell is both
extending the Haskell language itself, and defining a DSL as well.
One reason monads are so popular in Haskell is that they allow you to define
pieces of a DSL separately and then stack them on top of each other easily.
This is a *much* bigger deal than you may think upon first read.
I can add new features to my DSL by wrapping it into another monad
transformer.
Examples are monad transformers for errors, continuations, state, failure,
read-only state, and write-only state. And you can make any monad you create a
transformer as well. That means DSLs in Haskell do not require big design
upfront. Monads encourage you to separate concerns into their own
self-contained chunk that can then be reused separately.
For details see http://www.cse.ogi.edu/~mpj/pubs/modinterp.html and
http://nomaware.com/monads/html/introIII.html

> 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.

Yeah, I totally agree that well-designed systems require iteration between the
customers who use the systems and the programmers who write them.
There are some neat papers about this from the Smalltalk refactoring people.
'Refactoring your way to Frameworks' or something to that effect.
--
Programming is the Magic Executable Fridge Poetry, | www.ScannedInAvian.com
It is machines made of thought, fueled by ideas.   | -- Shae Matijs Erisson

On Mar 30, 2005, at 9:44 PM, Rob Nagler wrote:
>  > My code currently only touches the full power of logic programming. 
>  > It doesn't allow modules, there are no definite clause grammars
> (yet)
>  > and operator support is limited.  What does most of that mean?  Who
>  > knows?
>
>  But what's it for?  What problem are you trying to solve?
>
>  Rob

Rob,

You just lost your case with that question.  Most general purpose
programming languages can solve any problem a Turing machine can solve.
   Contrary to popular belief, Prolog can do just about anything Perl can
do.  Some things it can do better.  Some things it can't.  Those who
don't have experience with different programming languages and
paradigms often ask questions like "what's it for?"  Hell, I remember
asking that question when I first encountered OO.

To answer your question:  In Perl, you twist and munge your data until
it eventually looks like your goal.  With logic programming, you
describe your goal in logical terms and the computer figures out how to
twist and munge your data for you.  As a result, logic programming is
sometimes called "specification based" programming because with a
well-thought out specification, you can translate it to Prolog and
you're done (well, that's the theory, anyway).

This leads easily to applications such as natural language processing,
theorem proving, expert systems, inductive logic programming, etc.
However, you can do CGI programming in Prolog if you want.  You can use
it to process text files.  "What problem are you trying to solve" is a
silly question in this context.  I can solve any problem I reasonably
need to.  The question is, "what problems are better suited to Prolog?"
   No one's building theorem proving systems in Perl, to the best of my
knowledge.

(Side note: Prolog has some limitations and I'm not arguing that it's
the best choice.  If you're interested, I hear good things about
Mercury)

So, since you're so convinced that you really don't need to learn
languages in other paradigms in order to understand them (you can learn
all you want about France from the internet, right?), I have to ask:
have you had any serious exposure to any of these languages?  If so,
which ones?  (C and Java would be awful examples).

Cheers,
Ovid

[Non-text portions of this message have been removed]

<quote url=http://www.extremeperl.org/bk/refactoring>
if a routine is used only in one place, you keep it private within a
module. THE FIRST TIME IT IS USED ELSEWHERE, YOU MAY COPY IT. If you
find another use for it, you refactor all three uses so that they call
a single copy of the routine. In XP, we call this the Rule of Three,
[1] and basically it says you only know some code is reusable if you
copy it two times. Refactoring is the process by which you make the
code reusable.

</quote>

I am lucky I was not chewing on a hard candy when I saw that, or I
might've flat-out choked. I don't think it requires 2 uses of
something to copy it. The second time you need something, you refer to
the initial use.

--
	 Carter's Compass: I know I'm on the right track when,
	    by deleting something, I'm adding functionality.

On Thu, 2005-03-31 at 04:12 +0000, Terrence Brannon wrote:

> > Surely you left off the disclaimer that you have defined the
> > function correctly

> I did but a function is a small clear statement about how input(s)
> transform into output reliably, time after time, without fail and
> without intermediate state.

Sorry, defining the word "function" doesn't convince me that you'll
never ever accidentally mistype something and that the compiler will
always reliably and dutifully tell you about it.  Don't make me quote
Knuth.

> > -- or does your typechecker magically reason that a square
> > root function that takes an integer may sometimes return an
> > irrational number?

> 2/ The haskell sqrt function takes a datum of typing Floating and
> returns a datum of the same:

No, when you implement your own square root function with Newton's
approximations and say Int -> Int but neglect to consider the case where
the incoming integer is negative, what does the compiler do?  Does the
magic of strong static typing in a purely-functional language extend to
finding bugs in your misunderstanding of the expected input and bugs in
your clear statements about how to transform input into output reliably,
time after time?

If so, how does it do that?

If not, that's my point.

Don't say "I'd never do that", because it's just an example.  I could
give you a dozen more complicated examples, but I didn't.  Deal with it.

Don't say "I don't write bugs", because I've read your code.  I write
bugs too.

Don't say "That's why you need perfect specifications and a perfect
understanding of the domain before you write code", because I'm a
programmer too.

I'm happy to talk about how compile-time type inferencing and purely
functional programming approaches reduce the frequency of certain
classes of bugs, but don't try to feed me a line that they prevent
completely anything but typos without some degree of proof.

-- c

. . . THE FIRST TIME IT IS USED ELSEWHERE, YOU MAY COPY IT. . . .

  . . . I don't think it requires 2 uses of something to copy it. The
second time you need something, you refer to the initial use.

I would argue that you don't know what you're refactoring -to- until
you've seen the code pulled in three different directions. While
copying may have a bad connotation to it, I would argue that it's ok
in an XP project, where the code is in a state of constant
refactoring.

Rob

This discussion is starting to take a democrats vs. republicans
kind of feel.  Someone described that as the meeting of two
irreconcilable viewpoints:
   - the status quo is bad, so favor change
   - change is unwarranted, so favor the status quo

On the one hand, we have Rob who is fairly convinced that
with a multi-paradigm language like Perl, any practice or
technique worth adopting can be done through discipline,
social engineering and practice.

On the other hand, there's everyone else who subscribe to
the belief that if you want to learn truly new approaches
to programming, the best approach is to try new languages.

There are advantages and disadvantages to each position, and
neither is entirely right or wrong.  They're just different
approaches.  TMTOWTDI and all that.  ;-)

On Mar 30, 2005, at 11:32 PM, Rob Nagler wrote:
> If you had a week to refill your well, would you like to spend it
> learning Haskell from a book or programming with Dan Ingalls
> programming Smalltalk?  (Said programmer is already a Smalltalker.)
>
> If you don't know how Dan Ingalls is, substitute: Guy Steele, Paul
> Graham, James Gosling, Richard Stallman, Don Knuth, Butler Lampson,
> etc.

True, but there comes a point where there are no truly new ideas
to find if you keep drinking from the same well.

Case in point: if you compare FORTRAN I to Fortran 95, you'll see
the same basic language, but some important differences.  Modern
Fortran feels like an Algol derivative with a syntax that dates
back to the 1960s.

Another example - Factor is easily one of the most interesting
new languages I've seen in quite a while.  It's basically Forth,
with some inspiration from the functional programming world, including
a type inferencing engine that reminds me of Haskell.

These principles extend beyond languages that begin with the
letter 'F'.  Perl, for example, has a string of influences that
is long as my arm.  Perl 6 has a string of influences easily
twice as long.  All of those came from "outside the Perl community".

> Do you learn programming from people or languages?  I think the answer
> is people.  You learn by working on real systems written by real
> people.

True.  Ultimately, we do learn from each other.  And there are many ways
to learn.

I find that I learn more from someone like Gerry Sussman, whether I'm
reading a text he's written, studying his code, listening to him give a
   keynote, or watching him teach (thanks to some recordings converted to
Quicktime).

Most of what I've learned from Kent Beck isn't from the code he's
written,
but about what he's written about the projects he's worked on.  Ditto
Paul Graham, Joel Spolsky, and Richard Gabriel.

I also learn by working on real systems.  *Both* are valuable.  If
you're
going to learn from a text, you really need to find a *good* one, just
like you need to work on a really robust system to learn anything
useful.

-- Adam

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

Terrence Brannon writes:
> Haskell took 1st and 2nd in the main draw of the ICFP 2004 Programming
> Contest. Would you like to compete in ICFP 2005 using Perl?

Not unless they paid me.  We choose Pro Bono projects for their value
to the community and our business.

Rob

Shae Matijs Erisson writes:
> In my opinion, this sort of generative testing is a better approach that
single
> case unit testing. It can require more work to get the more general testing.
> I bet you're not surprised.

There are several camps, and there is lots of data supporting both of
them.  Here's an interesting study supporting partition testing over
proportional or random testing:

http://www.chillarege.com/fastabstracts/issre99/99122.pdf

I think the type of test methodology depends on the problem and the
programming language.  For example, for C programs, I like random
testing, because there are so many subtle ways to screw up.  For Perl,
I prefer partition testing.  I tend to think about problems in terms
of examples, and those examples end up being test cases.

One of the big advantages of partition testing is that it helps with
the design.  Random testing is no help in test-first design.

> QuickCheck has been ported to Common Lisp, Python, Perl.
> The ports do lose something in the process, for a variety of reasons.

So has xUnit, but is merely being popular.  PG thinks there's little
value in being popluar.

> > What do you mean by "better job"?  Done faster?  Higher quality?
>
> Done faster, higher quality, and more 'code as communication'. Want details?

How much of this is your skill vs. language choice?  If you were to
have a "shootout" with a company that does, say, Perl, and your company
that does, say, Python, which would win?

> http://lists.alioth.debian.org/pipermail/shootout-list/2005-March/001296.html

Here's a quote from the above:

> The problem I see is that it's easy to directly test LOC, CPU time,
> RAM usage, but it's really hard to test readability and good use of
> idioms.  At some level that's like unit testing poetry.

I believe there is a simple test.  How easily can your partners take
over your code and vice-versa?

> I would really like to know. Maybe there's already such a thing for Perl?

Aesthetics are not the same as readability.  Literature is about
aesthetics.  Readability means a peer can read your code as easily as
their own.

Rob