newbie conceptual question [from haskell list]
Thu, 26 Jul 2001 17:17:02 +0200
D. Tweed wrote:
> 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?
Interesting point. That says something about C.
> 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
I could agree that that follows, but I have no evidence that all or even
most C programmers program in the same restricted subset, or any proper
subset at all.
> I've never written a Haskell program using functional dependencies, or
> existential classes, ...
I find them indispensible, and I know for a fact that I am not the only one
around our office who feels that way. Though, the people around here
(Utrecht's software technology group) are not exactly typical programmers...
> 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.
I can believe this holds for your programs, but, uh... your clumps are not
necessarily in the same place as other people's clumps.
Please don't misinterpret that. :)
> > 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.
<sigh> Everything I say seems to sound nice in principle. Maybe I am just a
Anyway, the point of my quoted remark above was that I would like to have
more concrete boundaries for evaluating languages. I was trying to
demonstrate that equating the properties of a language with the properties
of any of its subsets is nihilistic. I gather that your claim is that most C
programmers use the same subset, or at least one among a family of subsets.
> 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.
Hallelujah! I understand what you're saying now!
You're saying that C is bad, not because of the cruft, but because of
> > 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.
OK, I understand. I used to share this view, and I agree except that I don't
think assignment is bad, only unrestricted assignment on a global store.
What convinced me is this paper, which you should read:
author = "Uday S. Reddy",
title = "Global State Considered Unnecessary: An Introduction to
journal = "Lisp and Symbolic Computation",
volume = "9",
number = "1",
pages = "7--76",
year = "1996"
You can get it here:
Frank Atanassow, Information & Computing Sciences, Utrecht University
Padualaan 14, PO Box 80.089, 3508TB Utrecht, The Netherlands
Tel +31 (0)30 253-3261 Fax +31 (0)30 251-3791