|[12 earlier articles]|
|Re: Current work in compiler/language design. firstname.lastname@example.org (Nick Rothwell) (1991-11-21)|
|Re: Current work in compiler/language design. email@example.com (1991-11-21)|
|Re: Current work in compiler/language design. firstname.lastname@example.org (1991-11-21)|
|Current work in compiler/language design. email@example.com (1991-11-22)|
|Re: Current work in compiler/language design. firstname.lastname@example.org (1991-11-25)|
|Re: Current work in compiler/language design. email@example.com (1991-11-26)|
|Re: Current work in compiler/language design. David.Chase@Eng.Sun.COM (1991-11-26)|
|From:||David.Chase@Eng.Sun.COM (David Chase)|
|Date:||Tue, 26 Nov 91 15:47:04 PST|
> Isn't there a FORTRAN journal in SIGPLAN?
Last time I checked, there were ACM journals and/or SIGs for ADA and APL,
too. In both cases (and Fortran too) I'd suggest that a reasonable thing
to do is look hard at the languages to see what it was that they did
right, instead of dismissing them in favor of the latest Pet Rock.
> Thirdly, give me one software principle that functional
> programming violates.
Dan Friedman was once (and may still be) fond of pointing out that
functional programming forces you to make state explicit when there is
state. Thus, your random generator function must make it explicit that it
has state (though there is nothing about functional programming that
demands that it reveal details of that state). In turn, this pushes state
up into your Monte Carlo integration algorithm. I'm not really sure if
this is a bug or a feature, since in the local sense the state-passing can
be sugared away, and in the global sense I think you might want it.
However, some people clearly hate it (but then some people clearly hate
C++, Lisp, and Ada, so the "some people hate it" test is not a very
reliable indicator of anything).
Return to the
Search the comp.compilers archives again.