James Watson
Posts: 2024
Nickname: watson
Registered: Sep, 2005
|
|
Re: Steve Yegge on Rhinos and Tigers
|
Posted: Jun 18, 2008 5:18 PM
|
|
> > > You are right. Smalltalk doesn't try to evaluate all
> > paths
> > > of execution. No one is saying it does.
> >
> > Well the claim was that SmallTalk can give you the same
> > kind of information that static analysis can.
>
> Really? Who by? I think the claim had to do with the
> usefulness of the IDE.
The post in question was by Todd Blanchard:
>Static typing enables deterministic refactoring, code analysis, code navigation, code completion, etc.
You know, I'm sick to death of this lie. Every Smalltalk I ever used had better code navigation, refactoring, and code completion tools than the best Java systems. And they had it first.
Enough with this myth. Its BS.
Note the term 'deterministic'.
> > In order
> > for it to do so, it would have to be able to evaluate
> all
> > possible execution paths. So, in a way, yeah, someone
> was
> > making that claim.
>
> I disagree. Static typing doesn't evaluate all execution
> paths either. If it did there wouldn't be a need for casts
> or runtime exceptions.
I didn't say that static typing evaluates all execution paths. Static typing allows certain kinds of provability in a program. Casts are needed when you step outside of the provability of the type system.
Please understand that this is not a opinion. I'm not saying what you get with static typing is worth the cost. I'm not saying static typing is good in this subthread. But these are factual statements I am making. There really isn't room for debate.
> >
> > The advantage of static typing is that it allows for
> this
> > kind of analysis. The disadvantage is that in order
> for
> > that to be the case, the kind of code that you can
> write
> > is limited.
>
> Static typing doesn't allow for the kind of analysis you
> speak of, but it does provide for "static type safety".
> This is not the same as "program correctness".
What kind of analysis in particular are you referring to. I have really only said that static typing allows for the kind of static typing that static analysis provides which is clearly a trivially true statement. Again, I haven't said that it's worth it. In fact I've stated that it's at least sometimes definitely not worth it.
> > I once read another Steve Yegge blog about how many
> people
> > use the "all Turing Complete languages are equivalent"
> > argument with regard to static typing vs. dynamic
> typing.
> > He makes a claim that this is true but that in a lot of
> > f cases, this means that you must write an interpreter
> in
> > the static language to get the functionality of the
> > dynamic language. In other words, you must implement a
> > dynamic language in your static language.
>
> Yeap. Which is why static programs are usually much longer
> then the dynamic equivalent.
> > Assuming this
> > is true, and it seem intuitively so to me, there is in
> > fact no way to build certain classes of programs in a
> > statically-analyzable way.
>
> Bang on. This is the plain fact of the matter. You cannot
> verify an imperative program for correctness by using
> static analysis. To do this you need to program in a pure
> functional style with no state and no side effects.
I guess it depends on how you define 'correctness' but I don't think there is any language that can prove a program is correct.
> > I think this is true and I believe that it's also true
> > that these programs are useful. But this also means
> that
> > languages that do support these types of programs
> cannot
> > provide the kinds of features that a statically
> compiled
> > language does.
>
> This is incorrect. You can annotate a dynamic program with
> static types and check these statically.
Look, I understand you are passionate about this and I respect that and I can say that you have personally contributed to my opening my eyes to the value of dynamic typing. But you can't have it both ways. You can't logically argue that we can write programs that are not statically analyzable and are statically analyzable.
> > It's trade-off and there's no magic
> > solution that will eliminate it.
> You can have both. Dynamic at runtime and static at
> compile time.
Just to be clear, 'dynamic language' really means something different that 'dynamically typed language'. The above could be construed as conflating the two. A give program (or portion thereof) is either fully statically typed or it is not. Deterministic static analysis cannot be achieved without full static typing. Casts are a perfect example of this. They cannot (in general) be proved to be safe by the compiler.
> Strongtalk shows this is possible. The issue
> is that for a dynamic language the type system needs to be
> a lot more expressive to allow for the greater number of
> programs possible. Even then for an imperative program
> you still need to defer certain checks to runtime. Either
> that or restrict your dynamic language to what you can be
> sure is "type safe" at compile time (which I guess is on
> definition of a statically type safe language :)).
Yes. The last sentence is the point. Static analysis allows for proving that certain parts of an application will not fail. Anywhere in your program where you step outside of this will not be provable in that way.
Again, I'm not saying that this in itself is a killer argument for static typing. The existence of casts demonstrates that it's often useful to step out of those bounds and being able to do even more unprovable things is very useful.
|
|
Previous Topic
