Various (and almost completely unrelated) questions and opinions

[Chris Pressey]

David Gould wrote:
> On Mon, Feb 19, 2001 at 06:29:19PM -0600, Chris Pressey wrote:
> > David Gould wrote:
> > > On Mon, Feb 12, 2001 at 12:58:58AM -0600, Chris Pressey wrote:
> > > > [...]  Partly what I'd like to see is a sort
> > > > of "Dangerous Erlang" which trades off some of the safety and
> > > > predictability for flexibility and expressivity.  [...]
> > > Hmmm, I am thinking, "typeless Haskell" ;-)
> > Well, not entirely typeless - for that I think you have to go back to
> > the lambda calculus itself or "alternative" languages like Unlambda,
> > where there is only one "type", the function.  [...]
> Well, it was sort of a joke. It is just that since there is a constant
> flamewar on comp.lang.functional about the necessity (or is it morality)
> of strict typing, I decided to learn a little about haskell too.

Ah, understood.  Advocacy is a strange and terrible thing.  Sure, static
analysis is a good thing that saves time and energy.  On the other hand,
it's not impossible to write a program without it, and there are always
other factors to consider.  Erlang's philosophy of being fault
*tolerant* doesn't strictly need static analysis.  But it's always nice
to have it on the side.

All in all, I like ML better as a generic example of a functional
programming language.  It hasn't got all the fancy stuff Haskell has in
it, so (for me) it was easier to understand.  (Then again I'd say the
same thing with respect to Pascal and C in imperative programming.)

> Without insight, it is pretty on the page. Which I find to be a very
> good first discriminator for languages. Ugly source text, ugly all the way
> down. Canonical example: C++.

It's a good rough judgement, but sometimes it lies too.  Perl is ugly to
look at and mostly (but not entirely) ugly underneath.  Python is nice
to look at but (as I understand, not being a big Python programmer) not
entirely nice underneath.

> > I've heard it said that "the number of Haskell programmers worldwide
> > could fit in my bathroom" - Erlang's takeup may not be explosively
> > large, but I think more people are actually *using* it for something,
> > than Haskell.
> Well yes. I do know of a few people doing things with ocaml though, so
> it might be as widely used. But from the little I have looked at it, it
> seems to not quite pass the ugly test. All the let in and in and in ...

O.Caml was one of the original attempts to combine object-oriented and
functional programming, and a pretty naive one in my opinion.  A direct
combination leads to a lot of redundant functionality, which can make
building new code easier ("there's more than one way to do it") but also
makes maintaining existing code harder.  Just my opinion of course, I
know some people who swear by O.Caml.

> > IMO Haskell == sophisticated, Perl == expedient, Erlang == one of the
> > best blends of sophistication & expediency since... well, since C!
> Very good, I like the observation about the blend as applied to C. I used
> (back in the early 80s) to love C, but it gets worse as time goes by and
> really is not a good choice for most of the things people use it for.

Me too.  C is a "systems-construction" language, and as I was doing more
stuff further and further away from "constructing a system", I started
using Perl; mainly for the garbage collection and regexps.

But my day job involves extremely expedient languages like Perl and
Business BASIC and various scripting languages for various specialty
software packages where control is utmost and abstraction is, well,
nearly absent; so it's little wonder I'll cherish any beauty (like
single-assignment) that shows up in an otherwise expedient language.

> I agree, the blend of beauty and ruthless pragmatism in Erlang is rarely
> found.

Erlang, one of the few (only?) functional languages genuinely suited to
a production environment?

> And you can even use the curly braces for something (the essential criteria
> for language success as far as I can tell from the recent historical
> evidence ;-)).

Absolutely :-)

Lon Willett wrote:
> Chris Pressey <cpressey@REDACTED> writes:
>  [snip]
> > Also I like Erlang's eager evaluation much better than Haskell's lazy
> > evaluation.  It is easy enough to build a lazy evaluator in Erlang if
> > you need one.
>  [snip]
> I prefer the eager ("strict") evaluation too, as a default.  But there
> are some nice things that can be done with lazy evaluation: streams as
> lists, some clever data structures, etc.

Well, clever is clever.  I dunno - I'd rather leave being clever, up to
the programmer, I guess.

> And it is not so trivial to
> write a lazy evaluator; any reasonable implementation would require
> changes to the VM.

It all depends on what you want to evaluate.  If you wanted to lazily
evaluate arbitrary Erlang code (complete with send and receive?) then
yes, you'd have to make some major changes.  But I was thinking merely
numerical expressions, like a "symbolic calculator", which would be far
easier; in fact I think there's some example code for one in the
extensions doc.

In fact, if you consider erl_eval et al as part of the language, then
there is your means of delayed (if not formally "lazy") evaluation right
there.

It all depends what you need out of lazy evaluation, and yes, while it
makes possible some clever tricks, are there very many problems that
really call for full lazy evaluation?  It seems to me more real-world,
production-environment problems actually call for eager evaluation -
make sure everything is resolved as soon as possible.  So I see Erlang's
design decision as a fairly wise one.

One of the main drives towards lazy evaluation (it seems to me) is the
desire for if(e,t,f) to be just like any other function, yet for it to
be short-circuiting, so that f isn't evaluated unless e is false.  It
strikes me that lambda functions for t and f could serve this purpose -
but Erlang isn't even in a position where 'if' is supposed to be a
function, so I can't see there being a lot of call for it here.

> I briefly (as in for a few moments; then reality set in and I moved on
> to more pressing matters) considered modifying the beam type system to
> support "promises", or whatever one wants to call the delayed-
> evaluation objects.

I think in Erlang they should be called "funs" :-)

_chris

-- 
"Ten short days ago all I could look forward to was a dead-end job as a
engineer.  Now I have a promising future and make really big Zorkmids."
Chris Pressey, Cat's Eye Technologies, http://www.catseye.mb.ca/
Esoteric Topics Mailing List: http://www.catseye.mb.ca/list.html