newbie conceptual question [from haskell list]

[D. Tweed]

On Thu, 26 Jul 2001, Frank Atanassow wrote:

> My reaction to that is: you are not programming in C. If you restrict
> yourself to nice subsets of a programming language, then obviously your
> programs will satisfy better properties.

That's certainly a resaonable position to take. All I'm saying is that in 
a purely  pragmatic sense, if we say that I'm not programming in C,
what proportion of the people out there who compile their programs with C
compilers aren't programming in C either?

I still think that, from the purely pragmatic point of view of giving
arguments as to why someone using an imperative language (in the way
that people actually do use those languages, _rather than in a 
way that they conceivably could use them_,) would be better off using a
functional language it's more convincing to argue about the problems that
_actually do affect them_ and can be handled better in a functional
language than to talk about the extreme problems that very rarely occur in
practice.

> Viewed in this way, Haskell is a
> (completely different) subset of C. But of course you lose the opportunity
> for the compiler and standard tools (which includes the standard semantics)
> to take advantage of these nicer properties, and are justified then in
> complaining to the language designers, "Hey, why did you put all this cruft
> in there? I don't need it, and it makes it harder to use the language!"

I've never written a Haskell program using functional dependencies, or
existential classes, ... 

> The point of having a language, IMO, is that its laws govern, _universally_,
> all the programs you can write in it. Otherwise you would just say, "Yeah, C
> is really hard to reason about, but if you consider all my C programs
> _individually_ the sublanguages they are written in actually satisfy nice
> properties."

Clearly that would be true, but there's a really extreme clumpiness in
the distribution over the state space: virtually all my programs are
written in the same sublanguage. 

> So, in the limit you might specialize your `language'
> differently to every single program you write. By that token, then, all
> programming languages become equal, and we have reduced this discussion to
> triviality.

That sounds nice in principle. However, I don't think that there are in
the actual world out there enough coders to write `imperative language
with scalar variables', `imperative language with scalar variables and
subroutines' (language A), `imperative language with scalar variables,
subroutines, and structured values' (language B), ... Equally, I don't
want to write a program in language A and then, on the day I decide it's
getting so complicated I need structures, have to rewrite it in language
B. In reality every language out there is a compromise between nice
features, having a feasibly sized user base and tool-writing base,
wrangling on standards comittees and just plain luck/human stupidity/etc.
Given that this is the case and that I've decided that, for whatever
reason, I'm writing code that will be compiled using a C compiler, do I
face lots of problems and bugs due to all the weird and excessive `cruft'
in the C language? I still honestly believe that I don't: most of the
problems that I face would be exactly the same in a much simpler
imperative language. And I think they're fundamentally due to the
imperative assignment has a (simple to state and understand) semantics
which simpy cannot be used to reason effectively about programs.

(BTW, your point about tools being potential better in the simpler
language is taken, although I still doubt that there's much that they
aren't doing already that would suddenly become tractable in such a
language.)

> I am not denying that you can have a nice imperative language (although I
> think that `just' a global store is too unstructured to support good
> metaproperties for reasoning).

Ah, that's strange because I _am_ asserting that. What I'm asserting is
that it's the very fundamental concepts like assignment to variables that
make effective reasoning very difficult for most of the bugs that
actually occur in the code that people write.