On 8/26/2012 1:51, Orchid Win7 v1 wrote:
>> You keep asserting that it's easier in Haskell to do some of these
>> things than it is in Erlang or C#. But you've yet to actually provide
>> any evidence of this beyond vigorous assertions.
>
> And you keep asserting that Haskell is a bad language, without much evidence
> either. :-P

No I didn't. I simply said a tiny elegant language where you can do 
everything in libraries is usually not superior to a language designed for 
the kind of coding you're doing.

> Erlang is /obviously/ much better at hot code swapping than Haskell
> currently is. This is not in debate. But you keep asserting that Haskell
> /can never/ be as good as Erlang.

It can't be as good at Erlang as what's built into Erlang. OK, granted, 
Erlang may not be the best example, because it's a hacky kludge of a 
language, but you know what I mean. Were Erlang not based on an interpreter 
written in Prolog, taking the same concepts and building them into a 
language (like Hermes or NIL perhaps) instead of having them as libraries is 
superior.

> Because it's somehow /impossible/ for
> somebody to come up with a Haskell implementation that does what Erlang
> does. You still haven't explained why that is.

Because when you write a library, you get inefficiencies, you get different 
people using different libraries, you get non-portability, and you get weird 
type sorts of things, and incompatibilities between libraries. No, really. 
That's what happens. I used to be a big fan of these very meta languages 
(and I still am), but it turns out that once they're too meta, every program 
takes tremendously more study to understand and modify.

There's a reason that LISP, Tcl, and FORTH didn't really take off any more 
than Haskell did.

> Likewise, C#.Net gives you access to the entire .Net platform library. This
> has vastly more functionality than what's available for Haskell. This is
> because C# is MORE POPULAR than Haskell, and NOT because Haskell is badly
> designed.

No. It's because C# and .NET are *explicitly designed* to provide access to 
vast libraries.

> My argument was never about how much external stuff is available for
> Haskell. My argument was that Haskell is a clean, simple language that
> manages to solve the same problems that other languages can only solve using
> a vast swathe of complicated "features" hard-wired into the language.

> C# has methods and inheritance and subtype polymorphism and dynamic dispatch
> and delegates and lambda abstractions and broken multiple inheritance and
> reflection and... Haskell just has first-class functions. Solves all of the
> above, with a fraction of the complexity. It's simpler to explain, it's
> simpler to use, it's simpler to read. That's what I'm talking about.

And the problem comes when you look at the use of a first class function and 
try to figure out what is happening with it. And methods, inheritance, 
subtype polymorphism, and dynamic dispatch are all the same thing. Delegates 
and lambda abstractions are all the same thing. So you're listing a whole 
bunch of ideas that let you express exactly what you mean precisely, and say 
"but they're all subsumed by this really general mechanism."

Basically, you're saying "we could use a very simple and straight-forward 
Haskell language, and replace methods and inheritance and subtype 
polymorphism and ... and access to vast libraries with libraries that take 
functions as function. But then those libraries would not only be as 
complicated as the features you're decrying(*), but they'd also vary from 
program to program. You'd never know whether the library you're using has 
the same semantics, because it's not part of the standard and just a library.

(*) Yes, they would be, because a specific functionality built into the 
compiler and language are going to be simpler than a hand-crafted library in 
source code trying to provide the same functionality on top of a generic base.

It would be like driving a car with a mouse and keyboard. There's a reason 
that all those "features" are there, and that reason is that they let you 
say what you mean, instead of building a structure that says what you mean.

Why do we have while loops, for loops, recursion, if statements, case 
statements, if then elseif and else, when all we really need is an if and a 
goto?

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message