Various (and almost completely unrelated) questions and opinions

[David Gould]

On Wed, Feb 21, 2001 at 03:29:10PM -0600, Chris Pressey wrote:
> David Gould wrote:
> > Have you looked at Oberon?
> 
> Only briefly.  I used to use Pascal a lot and Modula-2 some, but
> eventually got kind of sick of Wirth languages.

This happens, but Oberon is I think the nicest of all the Wirth efforts.
 
> Well, yes.  That's a valid argument for cost-conscious programming.  Of
> course, it also happens to be an argument against polymorphism,
> inheritance, and any other feature that makes it hard to "judge the cost
> by the syntax."
> 
> I mean, you can already say
> 
>   add(X,Y) when number(X), number(Y) -> X + Y;
>   add(X,Y) when element(1, X) == image -> LiC(X,Y).
> 
> which means it's already possible to write Erlang code which is hard to
> judge the cost of by looking at the application.

Sure, but by that standard, any function call is obscure at the limit. What
I meant, I think, is that viewing the source text and searching in the
source text gives the reader at least a fighting chance to find what is
going on. In the Erlang example you give, the definition is explicit, the
rule to select which definition is explicit, and text searching will find
the definition. In the countercase (why is it always C++?), overloading
something like "+" combined with some overuse of inheritance and a macro
or two makes it almost impossible to tell what "+" gets resolved to without
stepping it in a debugger or reading the entire program and libraries.


> What is worse to me is the unorthogonality - that I can't say integer(X)
> or tuple(X) outside of a guard and mean the same thing.

Ok, I think I agree. If it looks like a function, it should be a function.

This is my main problem with python, some code things are functions and some
are subroutines that do not return a value. 

> But this all points to the fact that what I am thinking of is in fact a
> different language than Erlang, and I shan't complain about these
> characteristics of Erlang in the future.  No overloading, guards are a
> form of type constraint, and so forth, for the sake of predictability
> and ease of cost judgement.

Please do not fall out of love so fast... and I certainly do not speak for
the Erlang designers, so maybe overloading is coming soon.

-dg

-- 
David Gould                davidg@REDACTED               510 536 1443
If simplicity worked, the world would be overrun with insects.