|
|
Re: Steve Yegge on Rhinos and Tigers
|
Posted: Jun 27, 2008 1:19 PM
|
|
> > > Hi Paul,
> > >
> > > A favorite paper of mine.
> > >
> > > If you read Meijer carefully, you'll find that he
> > > advocates *static typing* with use of type inference
> to
> > > avoid the verbosity and heavy type system engagement
> > > currently foisted on programmers by most static
> > languages
> > > (e.g. Java). I don't think he's asking for a language
> > with
> > > both static and dynamic typing in the manner of Ecma
> 4.
> > > He's more or less stating he wants static typing
> where
> > the
> > > compiler infers types whenever possible.
> > Yes. He also mentions scenarios where the compiler just
> > doesn't know. In some languages such scenarios are
> deemed
> > "unsafe" by default and you are forced to code around
> the
> > compiler even though you know that what you wanted to
> > express is perfectly safe. Instead in scenarios where
> the
> > compiler cannot know sif the code is safe statically
> you
> > could choose to defer type checking to runtime where
> the
> > runtime will know and can make an accurate choice to
> trap
> > a true error if required. This is the "dynamic typing
> when
> > needed" bit, and Eric uses the way Arrays and
> invariance
> > works in Java as an example. If they had taken the same
> > approach with generic collectons we would not have the
> > horrible use site declarations and type bounds we have
> > now.
>
> Methinks you are misreading/misunderstanding what he
> wrote. He never mentions use of dynamic types proper, only
> inferred types -- big, big difference. Regarding the array
> example, we're still in the realm of static types; albeit
> the covariance on the array does have issues. That's a
> trade-off he is will to make in order for generics to be
> more practical. It has nothing to do with dynamic types.
>
The language performs a dynamic type check at runtime. The title of the paper is "Static typing when possible dynamic typing when needed". Now how you choose to interpret "possible" and "neeeded" is open to debate, but the fact that Eric is advocating both approaches together isn't.
> > >
> > > Re:
> > > > I believe we will better educate programmers once we
>
> > > > drop the fallacy that we can rely on tools.
> > >
> > > Well, that's a rather bold statement. I'm part of a
> team
> > > that would utterly collapse without tools. Tools that
> > > depend on a static type system. Extremely useful
> tools
> > > that cannot exist without a static type system. If
> you've
> > > ever used IntelliJ IDEA on a large project, you'd
> know
> > the
> > > class of tools I'm referring to. In fact I just
> finished
> > a
> > > semi-large task of extracting an abstract API to
> > decouple
> > > a module so that its implementation is not available
> at
> > > compile time, only the API is exposed. This involved
> a
> > > storm of refactoring, code navigation, code
> completion,
> > > etc. I can't imagine having to do that without tools.
>
> >
> > I didn't say we don't need tools, what I said is that
> > tools cannot infer whether your code is safe. They
> never
> > will.
> > >
> > > Man has limitations. We can't keep large software
> > systems
> > > in our heads. Time spent fumbling about in a codebase
> > is
> > > not time well spent. It turns out computers are much
> > > better at remembering where things are, what
> references
> > > what, what has what, and the like. Computers are even
> > > better and faster at making changes based on this
> > > information. Ultimately, tools that save us from our
> > > limitations are a good thing. If static typing helps
> in
> > > this regard, then why not leverage it to the best of
> > our
> > > ability? As Meijer states in his paper, we certainly
> > have
> > > room for improvement.
> >
> > Again I think you are choosing to hear only half the
> > message. Tools help with somethings (like traping
> certain
> > kinds of programming errors early), but writing safe
> code
> > isn't one of them. Programmers write safe code.
> >
> > This is self evident.
> >
>
> "Safe" code? "Self evident"? Interesting.
>
> To what degree can you "rely" on your ability to refactor
> code on a large project without proper tools?
I don't rely on tools I rely on my tests (or executable design specifications as I prefer to call them).
>How long
> would it take you? How "safe" would the code be? After
> all, you refactored your tests too; are you sure those
> tests can be relied upon after your refactor? And, again,
> how time consuming would the task be? With a dynamic
> language you don't have proper tools.
Wow thats a bold statement. Would you like to back it up?
> Not today, not ever.
> Not unless you are using the fabled smalltalk environment
> that does everything IDEA does. Static languages have a
> clear advantage wrt solid, *deterministic* tools.
IDEA maintains an in memory image of your code, and idea it took from Smalltalk. If you check my earlier posts I have already said that static languages have some benefits including tooling. What I am also said is that static laguages also have certain limitations and draw backs. A fact that you seem to be blind to.
What I said in the post you responded to is that tools do not produce safe programs, good programmers do. Dwell on this a bit before responding and you will realise that it is unrefutable.
Regards,
Paul.
|
|
Previous Topic
