Dynamic Freedom

Good example. Just think, if our highways were like this they would be safer, motorcycles would not have to worry about being hit by cars or trucks.

Comment on Dynamic Freedom by Rich Demers

The bad habits of the politicos must be catchy, especially the one where everything that someone says is "spun" into a reason for supporting its exact opposite. Pathetic.

Imagine traveling a road network that had different width tracks...
Imagine traveling roads which restrict access by pedestrians, or bicycles,
or low-powered motorbikes ... (The M roads in Britain)

Imagine traveling roads which restrict access by trucks ... (We have those also)

Chaos? What chaos?

Comment on Dynamic Freedom by James Robertson

Analogies are just that - analogies. Isaac, you make the mistake of reading too much specificity into this....

Actually, James, I think the analogy is quite good. Restricting access by vehicle type or size would make travel safer, but at a much higher cost and much less flexibility. Does this sound similar?

James - your example is a PERFECT example for type-safety, not against it. It just sounded alright because you picked some reasonably homogenous groups... but let's think.. we are designing a new freeway... and what obvious groups do we have floating around? umm. Cars, trucks, motorbikes .. yes. but what about PEDESTRIANS? SkateBoarders? RollerBladers? We let them on the freeway, and someone is going to DIE.

So.. we make a footpath - and allow any non-powered-vehicle and we make a freeway and allow MotorisedVehicle.. And gee our type-safety (with a little inheritance thrown in) - has saved lives. BUT it's not arbitrarily extensible. Ok... lets instead allow anyone AllowedOnFreeway on the freeway. And lets allow anyone AllowedOnFootPath on the footpath. A little type safety, a few interfaces, a little more work, and we guarantee unlimited extensibility, complete safety and no ambiguity.

Type safety is a good thing - thanks for the perfect example! :)

Comment on Dynamic Freedom by James Robertson

The VM for VW is in C. The entire Smalltalk system is written in itself.

James - your example is a PERFECT example for type-safety, not against it. It just sounded alright because you picked some reasonably homogenous groups... but let's think.. we are designing a new freeway... and what obvious groups do we have floating around? umm. Cars, trucks, motorbikes .. yes. but what about PEDESTRIANS? SkateBoarders? RollerBladers? We let them on the freeway, and someone is going to DIE. So.. we make a footpath - and allow any non-powered-vehicle and we make a freeway and allow MotorisedVehicle.. And gee our type-safety (with a little inheritance thrown in) - has saved lives. BUT it's not arbitrarily extensible. Ok... lets instead allow anyone AllowedOnFreeway on the freeway. And lets allow anyone AllowedOnFootPath on the footpath. A little type safety, a few interfaces, a little more work, and we guarantee unlimited extensibility, complete safety and no ambiguity. Type safety is a good thing - thanks for the perfect example! :)

Sure, this might be safer, but is it better? I think not. If you have roads for cars, others for motorbikes, others for trucks, others for skateboarders, etc. you end up with a vastly more complicated structure. Not to mention, a much more expensive infrastructure that takes longer to complete.

And you forget special cases. What if a dangerous killer is on the OnFootOnly road? How do you bring police reinforcement fast? Or if a plane has problem and needs to land? Type-safety is good as long as a special case arise, and in the software business, they seem to happen quite often. This is why the flexibility of dynamic typing is a good thing.

What's more, with dynamic languages, you can often check types yourself if you really need to; just add code at the beginning of a method to check the class of the parameters passed. Since Smalltalk is such a dynamic and introspective language, I am pretty sure you could automate most of it, and even have a decent static typing system.

> Sure, this might be safer, but is it better?

Yes.

Dunno what sort of world you're programming in... but lets see... four extra days of programming time versus losing $1,000,000 on that bank transfer... or not notifying the customer of their flight change... or landing that plane 4 metres BELOW ground level hmmmmm... in programming, safer == better. ALWAYS. Because the impact of extra programming time is known and controllable. The impact of an unexpected bug is NOT.

Let's look at our specific metaphor, while we are playing with it. Do you honestly suggest we do away with footpaths, and have little old ladies walking down the middle of the freeway?

> If you have roads for cars, others for motorbikes, others for trucks, others for skateboarders...

Did you actually read my post?

> And you forget special cases. What if a dangerous killer is on the OnFootOnly road?

Sure, I can't protect against ALL problems. But I CAN protect against a car driving down the footpath. Any protection is better than no protection at all.

> What's more, with dynamic languages, you can often check types yourself if you really need to; just add code at the beginning of a method to check the class of the parameters passed.

Hmm... and what do we do if we do get the wrong thing? FAIL THE OPERATION. I would prefer something to tell me when I'm building the system that this will cause a failure - not to have the plane suddenly stop flying because the stewardess turned the video system on too early. Read the literature on the relative costs of detecting a bug early in the development cycle, compared to late. Runtime checks tend to trigger at... well... runtime. That's a BAD THING.

Just because a system is dynamic, it doesnt mean that any object can go anywhere. In a dynamic system the car wont be going down the footpath, however, in the case that it must then there is a reduced time to allowing it to do so. As apposed to a system system. There seems to be some confusion between a dynamic systems ability to change and the safety in making that change. No one is suggesting things done get tested and caution is thrown to the wind. In a static system there are still times when you want to bang the hampster through the star shaped hole ! In a dynamic system it just makes less of a mess.

Sounds like a cool game.

Please see the rebuttal to the comments regarding type safety issues and how they are best solved. Validations Are Best Done At Runtime With Full Language Symantics.

James, thanks for your vote of liking the metaphore of typed rails and free road networks. I developed it during a major typed v.s. dynamic discussion over at Lambda the Ultimate. Over 80 pages when printed. Yikes. It provided some of the inspiration for the current series of articles and insights regarding the source of the flexible power of dynamic langauges and why I choose them.

I read Peter's post, but with no obvious way to submit a comment on that page, I have come back here. I'll start first stating my amusement at the "you're wrong because.. well.. I say so" approach to argument :)

Anyway. Most of the post is devoted to pointing out that you can do type-safety in Smalltalk. Gee.. Who cares? I'm not attacking Smalltalk I think it has a lot of good things about it, which is why I read Smalltalk blogs. For that matter, in more traditional languages, you can have complete dynamic types. You can just declare something as an "object".

The argument that I put forwards though was that (please think outside the confines of any particular language) - the conceptual mode of programming towards a specific locked type is SAFER and therefore BETTER. i.e. - a software program made with a higher level of type safety will have less bugs than a software program without - that's all I'm saying - and that concept wasn't addressed at all.
"oh but I've done a big software project without type safety". Well done. Congratulations.
Doesn't say whether it was a good idea

I will make some more assertions - if you disagree with these, there is no point in discussing anything, because I see these as "proven" statements. They are part of the frames of reference, not part of the argument...

1> edit time checking is superior to compile time checking is superior to runtime checking. Just read any McConnell book, or look up ANY metrics on programming. The cost of a bug or error goes up exponentially the later it is detected. It's a documented fact.

2> Safer = better. I don't know about you, but I am a senior architect / developer in the real world. Many of the programmers I work with wouldn't be able to spell encapsulation, let alone explain what it means. If, when I build the core libraries people use, I give someone a way of doing something stupid... rest assured - they will..

So - back to the core discussion. Is it (conceptually) better to code with type safety, or better not to. Of course, practically, we all use both. For instance if I made a collection class - I'd make the base collection class with "objects", and then specialize it for each class I actually use. Of course something like templates/generics give us the best of both worlds - and strongly typed functional languages like Miranda, with pattern matching go even better... but lets look at the extremes - if you are forced to make a choice, which way should you go?

Now - to argue the dynamic type problem, I'll throw out two statements which I'll then support - those statements together logically demonstrate the need for type safety: a) dynamic types are only safe if you have a clear and complete understanding of the objects you are working with. and b) in a large system with a lot of programmers of various skills and experience, it is impossible to have a clear and complete understanding of the objects you are working with.

So.. looking at a) We've done the road example. Let's go back to the train track example, and we can very easily see why even if you can, it is dangerous to do something that wasn't expected by the designers. Suppose in the real world, we have two states, NSW and Queensland, that evolve their train system differently, and end up with different gauges. They eventually decide to communicate, and we have a massive amount of trouble doing so. We end up with all sorts of kludges to stop at the border, transfer cargo and so forth - and it ends up costing us millions and millions... That's bad right?

Well - suppose instead initially - they had both looked up the US standard. And followed that.  The gauges are compatible. Yay.. lots of saved money. However... what we didn't know - and when they drove the trains on and started using the lines, no one thought to mention it, because it didn't occur to anyone - was that NSW early in development had had better suspension technology. Over the years, the superior trains in NSW had allowed much tighter corners than you ever saw in Queensland.

So.. What happens when the press all gets ready and watches for that first passenger train to come screaming down the lines from Queensland? Yes. That's right. The train derails, and hundreds of people die.

A contrived example, sure - but it applies to every part of the system. If I pass a control object to a graphics collection, I EXPECT, because I'm guaranteed - that that object will be able to draw itself. There is zero possible benefit, and an enormous amount of possible danger of passing an object that can't draw itself to a function that draws all the objects in the collection. While we can say "oh yeah, and this expects objects that behaves as follows" - why shouldn't we ENFORCE that? Even though it might be slightly more work, it is guaranteed to be superior in 100% of cases.

And, going to statement b) the reason it is necessary is because in the real world, you have no idea who will next use the class that you've just written. They could be a complete idiot, they certainly won't understand all the assumptions you've made and the thinking you've done to produce the class - and won't have the time to read all (or any of) the documentation you've provided with it. All they see is a function call that they have to send values to.

The greater restrictions, guards, pre/post conditions etc you can place on that function, the BETTER the resulting system will be. ALWAYS. Because the average programmer is a complete idiot

Comment on Dynamic Freedom by James Robertson

Darren:
You say: "edit time checking is superior to compile time checking is superior to runtime checking"

Well, yeah. And in Smalltalk, edit time = compile time. And using SUnit, edit time = compile time = test time. So if there's a problem, we catch it when we write the code (assuming we are doing TDD). This is sooner than you'll catch it in any of the popular static languages. So if this is your premise, you want to do TDD in Smalltalk.

You then say: "I don't know about you, but I am a senior architect / developer in the real world. Many of the programmers I work with wouldn't be able to spell encapsulation, let alone explain what it means. If, when I build the core libraries people use, I give someone a way of doing something stupid... rest assured - they will."

Ok, I'll be blunt - you are working with the wrong people. Static typing won't save you if your staff doesn't understand basic development. They'll be making algorithmic errors abd worse. If this is the problem you have, then you are chasing the wrong problem.

As to your train example - Ariane V. Type checking doesn't solve your problem. If you have bad/non careful developers who use the wrong module - even though said module males the compiler happy - you still end up with an exploding rocket. Ditto your train. You have to run tests. Static typing verifies nothing of real interest for you in this case; testing will. If you rely on static checks, you'll end up very, very sad

Then you say: "You are not daily dealing with people who's entire programming experience is that 4 day introduction to VB course.. But that's the sort of person who ends up using my libraries, and I need every bit of safety I can get my hands on." If you are happy with false safety, sure. What you've actually done is tied the hands of the end developers in the name of protecting them - and the worst part is, you haven't actually accomplished anything. If your developers make algorithmic errors (the most common and worst kind) - compiler checks won't help you.

Ultimately, you are worried about the most irrelevant problems, and pretending that it solves the big issues.

Darren: "a software program made with a higher level of type safety will have less bugs than a software program without"
Seems like you are talking about static-type-checking, not type-safety.

"Type safety is the property that no primitive operation is ever applied to values of the wrong type."
p205 Programming Languages: Application and Interpretation

                 statically-checked      not statically-checked
type-safe        ML, Java                Scheme, Lisp, Smalltalk
not type-safe    C, C++                  assembler