| Markus 2007-08-16, 4:31 am |
|
Don Geddis wrote:
> development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de (Markus E.L. 2) wrote on Tue, 14 Aug 2007:
> I wrote:
>
> On the contrary, I've followed this entire thread, and it is you that had a
> limited understanding of the discussion.
Have I, indeed?
>
>
> Any existing language already has its semantics defined. It obviously doesn't
> make sense to talk about source code that, within a given language, is already
> well-specified to not have semantics. Why would you think that _anyone_ would
> ever attempt to discuss such an issue?
Reread the dialog between M Blume and Pascal Constanza: Pascal is
asking why statically typed languages can't just run programs anyway
if they fail the type checker. To which M Blume replies that that
doesn't make sense. Against which Pascal insists that those programs
have semantics anyway. Program texts that fail the type checking, mind
you, in a statically typed language.
> No, of course the real question was, how _could_ some new language (either a
> brand new one, or perhaps a modification of an existing statically or
> dyanamically typed language) be defined?
Congratulations. Now finally you succeed to ask the right
question. Which neither you nor Pascal did.
> What, in the abstract, are the benefits of static vs. dynamic
> typing?
The benefits of static typeing are primarily that you have to discuss
with a certain class of people what static typing is good for and read
their not-to-the-point "examples".
Minor benefits involve catching a certain class of errors and
documenting data flow, pre conditions and postconditions (not
exhaustively).
> Pascal's claim, which I support, is that the way semantics are defined -- by
> choice! -- in typical statically typed languages (leaving aside, for the
> moment, some of Jon Harrop's comments on some more advanced "static"
> languages), eliminates some useful language features that are valued by
> programmers who prefer dyanamically typed languages.
It might be that those features are valued by programmers that prefer
dynamically typed languages. No doubt: There must be a reason that at
least some of them abhor static types so much (apart from the
misleading idea that "dynamic" sounds, well, and flexible,
whereas "static" sounds uncreative and klunky). The more intresting
question is wether the use of those "features" makes a program better
(even if more "powerful") and wether prefering those features or
requiring them makes aforesaid programmers better programmers. For my
part I've already decided. You too, seem to have made your
decision. From that perspective any discussion is useless.
> This is in contrast to an earlier claim that static typing is
> clearly the right way to go for future programming,
A contradiction only exists, if "future programming" actually needs,
e.g. eval. You're missing a logical link in your argument.
> and that in the future "of course" all respected programming
> languages will use static typing, and dynamically typed languages will only
> be good for "toy scripts".
"only be good" != "used mostly". You've already been pointed to what
Ingo realy said. Why do you insist to distort it? because without your
case breaks down or at least looses most of its urgency?
> The response to this original prediction was to show that there are code
> fragments -- not necessarily from any language currently in existence
> (although most of them run today in Lisp), but rather from some a
> hypothetical future language -- that may be useful to the programmers, but
> which are not amenable to being labelled "well typed" by a static type
> checker.
Yes, in some sense, there are constructs that won't be passed by
statical typing as we know it (Hindley-Milner e.g). (1) I'm not sure
wether it is possible to prove that any static typing algorithm won't
be able to type the fragments in questions. I doubt, because it might
give the construct a type like "universal type" (meaning the big union
type I've been talking about some days ago) and that should do the
trick mostly. The border between static typing and (emulated, perhaps
partial) dynamic typing is not so clear cut. (2) In the "usefulness"
part of your argument I see a certain weakness. As I said: I grant
that in some sense such constructs "exists" (meaning: I could give a
meaning to this "exist" by carefully identifiying "same" semantics in
(hypothetical) differently typed languages with the same syntax. But
it still has to be shown that they are useful.
> The response to _that_ example was: "badly typed code has no semantics".
"badly typed code in statically typed languages".
That response was much earlier. Since you changed the topic (and never
before said your piece about "rather from some a hypothetical future
language", this reply was quite right. If we talk about static
typeing, badly typed code has no semantics in no statically typed
language I know of (and specifically not in the ML-dialects from which
the dialog Pascal-Matthias started).
> Which is at best highly misleading (if what was meant was simply that some
> existing statically typed languages _define_ such code fragments to have no
> meaning),
Exactly. You never said that you want to design a new language. And if
you had, a number of other questions would have to be asked.
> and at worst simply false (if something useful was meant, such as
> that no possible language could ever assign semantics to such kinds
> of code).
We didn't say so.
[color=darkred]
> Was the topic not about a contrast between the possibilities of static typing
> vs. dynamic typing, and their effects on language design? How could one even
No. The topic was about "why can't I run that code anyway?".
> have such a discussion if you are unwilling to think about dynamic typing?
> How would you ever resolve such a topic by only considering existing
> languages already defined with static type checkers?
Only in the sense that "running a badly typed program" makes no sense
at all. Which was the answer Pascal and you got. Because you
formulated the wrong approach, mind you: Nobody of you two aske "Can I
extend the semantics of an existing statically typed language so that
....?" or described the "hypothetical future language" with mixed
static/dynamic typing or fallback to dynamic typin when static typing
fails.
> Without even considering possible future statically typed languages,
> much less existing dynamic languages.
>
> I really don't see what you think this discussion is about.
Nor do I know. Do you mind to sum up what your hypothesis and/or
question is at the moment? From the beginning please, so that we do
not start with a different interpretation of something somebody has
said earlier in this thread.
>
>
> Well ... yes. Finally some insight arrives.
Surprise: Why did you never use the word "extension" before? I did
days ago (wondering that neither you nor Pascal where able to
formulate what you probably want).
> This whole thread might have been short circuited if the static typing fans
> had merely said: "static/dynamic typing is a tradeoff, with the following pros
> and cons, and we are part of the programming community that prefers the static
> side of the tradeoff."
Honey, we did say that from the beginning, but instead of accepting
what we claim we gain from the trade we got told that even our winings
are bogus since all that could be achieved with test as easy and
anyway. You might understand that we didn't want to leave it at that,
though I note a certain fatigue in replying.
> Instead of: "static typing is the future; all modern languages use it;
Yeah, yeah. Our fault.
> languages that use dynamic typing are relics of the past, soon to be extinct
> or only used for toy scripts. But no educated, serious, mature programmer
> could possibly make the tradeoff that the benefits of dynamic typing are worth
> the cost of losing the static type checker. Only ignorant, uneducated, naive
> programmers believe such primitive nonsense."
Hm. Did Ingo really write this?
> You've taken the first step towards a larger world, where you might consider
> some hypothetical future programming language that offers the benefits of
> BOTH static and dynamic typing. There is no reason, in principle, why the
> two styles could not co-exist (in some future language).
One of the reasons that won't come to pass is, that a language with
full dynamic typing would have to integrate an interpreter or a run
time system which would retain the full type information. And that
would mean, we'd forego the opportunity to compile to targets that are
rather different from the language itself. And we'd leave
opportunities for optimization.
> But first, you'd have to understand the benefits that some programmers find
> in dynamically typed languages...
Eval. Well ... -- sorry, that doesn't convince me.
-- Markus
|