SJS([EMAIL PROTECTED])@Sun, Feb 17, 2008 at 07:31:52PM -0800:
> begin  quoting David Brown as of Sun, Feb 17, 2008 at 06:53:11PM -0800:
> > On Sun, Feb 17, 2008 at 06:36:41PM -0800, SJS wrote:
> > 
> > >http://groups.google.com/group/fa.haskell/msg/b1e0673a38ce3995?
> > >
> > >An article by a guy who really wanted to make Haskell work,
> > >but he's having some difficulties, and so he offers up some
> > >criticism of Haskell.
> > 
> > I don't get the impression he's really gotten that far with
> > Haskell.
> 
> He comes right out and says it's only been a couple of weeks.
> 
> How much time does it take to become minimally proficient in the
> language?  If two weeks of continuous study and experimentation
> can't get someone past the point of "OMG this sucks" and within
> sight of the promised land, then there's a problem somewhere.
> 

I have to agree with the point Chuck makes in a separate post...
Learning a language, and learning a paradigm are very different.
I /think/ you would agree that learning the paradigm is more
difficult, given your recent comments about learning recursion via
scheme.  Learning both a new language and a new paradigm usually
means I'm going to have to make several attempts.  And I usually
measure difficulty by how many attempts I have to make, rather than
the amount of time.  I'm self-taught, inexperienced, busy, and I'm
anal about the quality of my code even when I'm only starting out.


> It's a matter of /where/ the problem lies.

I've been looking in to Common Lisp for a while, now. (I skipped
out on the SICP group mostly because I didn't want to get
side-tracked).  I've found that my experience learning Lisp is a
lot like when I was learning python and OOP at the same time.  I'd
played with Apple Basic, shell, and some programmers told me,
"learn one and the rest are easy."  I know SJS will want to blame
python ;-)  but I think the problem had to do with unlearning my
wrong assumptions, overcoming ignorance, and learning an entirely
new way to "parse" problems. 

> 
> > He has hit one difficulty of Haskell right on the head, the
> > notion of higher-level programming.  When good Haskell
> > programmers write modules to use, they are generally done with
> > lots of abstraction and meta-programming.  This essentially
> > means that learning how to just use their library involves
> > learning the new meta-language they've created for its purpose.
> > The result is quite elegant once you've learned it.
> 
> That's the claim.

Conceptually, I see little difference between the meta-languages
that David mentions, and the APIs that have to be learned with any
other language. When a certain API stinks, we don't /usually/ blame
the language; we blame the API.  It seems inconsistent to blame the
language if a module is poorly documented or the meta-language is
poorly designed in haskell.

> That's what the author of the article appeared to believe. He's
> just not seeing the return on his investment of time and effort.
> 
> I think his criticisms of documentation and the lack of _good_
> tutorials is probably more on the money.  Good documentation is
> important, and hard.
 
Learning language and paradigm (and often jargon and the community)
all at once can make documentation seem useless.  It's usually not
until after I've done some time working out basic concepts that the
documentation actually starts to be useful, even if the docs are
plentiful and clear,

Consider how many people say "I tried to learn vi, but it
*SUCKED*!"   There are cheat sheets, books, helpfiles, and
documentation all over the place, but they have to purge themselves
of wanting to reach for the mouse before *any* of that
documentation will mean anything to them.  Only the persistent go
from "vi sucks! it can't do /anything/ I want" to "Notepad sucks!
It can't do /anything/ I want!"  The return on investment can be
slow in coming, but it has been worth all the effort.


> (I had much the same reaction to J2EE... at first, not much
> documentation; then lots of documentation that was basically
> useless, because the folks that actually understood the system
> *and* had the skills to write clearly weren't the ones writing
> the documentation. The result was, mostly, utter crap for
> documentation, and a whole lot of hype.)
 
I agree with your point about good documentation being difficult to
write.  I'm not sure your anecdote really fits, though. You were
dealing with extensions to a language you already knew and enjoyed;
doesn't seem like that much of a new paradigm. I might be wrong.

> > >I find the criticism about a small change requiring a
> > >significant rewrite to really catch my eye; I further find his
> > >point about SQL to be really appropriate.
> > 
> > With Haskell's strong type-checker, refactoring the code is
> > fairly easy to do.  Unfortunately, the design model behind it
> > tends to lend to that needing to be done more often than other
> > models.
> 
> If you're rewriting, then it's no longer refactoring.
> 
> If you want to make a small change in the behavior, that's not
> refactoring either; and if you have to redesign and rewrite
> (which is the assertion being made, as I read the article) to
> extend or modify some functionality, then all the refactoring
> support in the world won't help.
> 
> > However, I think it is more a sign of someone writing code who
> > doesn't know the language very well.  Haskell is a very hard
> > language to learn, and in most languages you tend to write
> > pretty bad code when you don't know the language.
> 
> If it's THAT hard of a language to learn, then it's doomed to
> utter failure.
 
I wouldn't be surprized.

Natural human languages are hard, too.  Almost everyone uses one,
and they require many years to learn.  If you want to speak
publicly, it takes longer to develop the skills required for that.
Being that language is so difficult, why isn't it obsolete by now,
or at least simplified and regularized?  Languages are constantly
changing, but we /value/ the ability to insinuate, imply, praise,
insult, curse, bless, and use puns.  Its uses go way beyond the
obvious purpose of plain communication.

Of course, thinking and speaking are rather universal, whereas most
people never have to select a programming language, so the
comparison isn't entirely fair.  And, being easy to learn /is/ a
good thing in a programming language.  Still, I hate to see a good
tool be passed over because the effort required to learn it is
significant.  Seems rather like pointy-haired reasoning to overlook
the results that could come from mastery.

> > >I *like* the idea of making some of these new languages
> > >embeddable or trivially callable from existing languages.
> > 
> > The problem is that Haskell's entire execution model is so
> > completely different this is pretty hard to do.  Given that,
> > it's not that bad at both calling to C and calling back into
> > Haskell, at least once I learned the meta-language for doing so
> > :-)
 
David, would you mind expanding on that statement, please?

> Note that he's talking about IDL -- so one can reasably be
> assured that he's willing to adopt a relatively decoupled system.
> The execution model is irrelevent, given that a programmer could
> provide a parameterized call and receive some sort of an answer.
  
If he's going to play with CORBA, I'm reasonably assured that
he's willing to spend lots of time studying complex (and ugly)
APIs. ;-)

> > In Haskell, calls to functions don't necessarily do work, and
> > infinite recursion is often fine.
> 
> In languages like C and Java, the programmer often doesn't CARE
> what really happens on the far side of the function call. "Here's
> my parameters, what's my answer?"
> 
> If Haskell can't bend itself to that sort of an interface, then
> it's really not very useful at all.
> 
> > What's interesting is that he didn't even mention the usual
> > problems people have with Haskell: space leaks.  It's not
> > always very clear when computations will run and it can be very
> > easy to build up a large data structure of potential
> > computations, instead of computing the desired result.
 
What does the above mean?

> Maybe he's not as stupid as you seem to think he is.
> 

I didn't think David implied stupidity at all, only inexperience
(which I can strongly identify with).  After I get some lisp under
my belt, I may very well give haskell a try.  It seems only fitting
since Haskell Curry was my grandpa... well, maybe not.  He does
have a great last name, though.  ;-)

Wade Curry -- NOT Haskell Curry's grandson!
syntaxman

-- 
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg

Reply via email to