SmallTalk

Well, I guess I'm DifferentlySane? then.  Die types, DIE!  Yes, SmallTalk is type-free.  You can send any message to any object.  Though most objects will simply send back an 'uh, no mate' reply.  You can use RespondsTo: to ask an object whether a given message is one that it likes.  Whilst types let you catch things as a compile error (and SmallTalk is JustInTime? interpretation favouring anyway) they mainly just cost you lots of development time, I think.  --Vitenka (You can probably tie yourself in knots with levels of indirection, if you try hard - so, um, don't do that.)

PeterTaylor suspects Vitenka doesn't write software for a living, and certainly doesn't maintain code written by other people.

It depends on the application. High-level code benefits from compartmentalisation; the bulk of the codebase I (and ~30 other people) am currently working with benefits greatly from having a strong type system. When doing low-level optimisations in specific areas for specific platforms, however, I often find myself fighting against the type system and the high-level cross-platform interfaces, and/or having to do things in wasteful ways in order to comply. The readability and maintainability benefits generally outweigh the disadvantages, though. - MoonShadow

You caught me - I write firmware.  --Vitenka  (Actually, SmallTalk can have type safety, you just need to really want it.  You encapsulate objects inside wrappers.  I do find myself wanting key exchange safety though.  Clarification, I mean a capabilities system.)

By the way, I certainly don't object to structured code in general - but if four different things have a 'value' (or a 'tummy' or whatever), why can't I use them interchangeably and let the compiler figure it out?  --Vitenka

Because you're not using a language with inheritance? ;) - MoonShadow

Just to clarify, I wouldn't dream of using SmallTalk collaboratively.  It'd be an utter nightmare.  Inheritence only solves half the problem.  I can use a specialised-monster as a monster, but not the other way around - even though the relationship may be more complete.  There's just no way to specify it in any language I'm aware of.  (Whee!  Other people also think this.  http://minnow.cc.gatech.edu/squeak/2967 ) --Vitenka

MMmm.  GangOfFour? say favour aggregation over inheritance.  'interfaces' are what you want when you want to use a tummy from different classes.  Might be what you're after, Vitenka?  I try to avoid inheritance like the plague, myself.  (which is easy, because I use only C at work)--Mjb67

It would be like using OO perl collaboratively.  *eww*.  Personally though, I want something more like ML's types.  -- Senji

ML's type-polymorphism is nice.  But even better is ML's module system, which in my opinion has never been surpassed. --Mjb67

Biiiiiiiiig discussion about java's generics system, which was based mostly upon Vitenka not having used Java for about nine months.  It had big problems then, but apparantly is all better now.  Check revision history if you want to.  --Vitenka

Hm. Why would you want to use it the other way around? I'd say needing to do that is a sign that your class hierarchy needs refactoring. Suppose the specialised-monster is one of several with a tummy, but in general monsters don't necessarily have tummies. If you want to do something to a monster's tummy, you need to make sure it has one first. You can have a general dothis() that the specialised versions override, or you can do the check using something like Java's instanceof or C++'s dynamic_cast; those are just different ways of saying "does the monster have a tummy?" - but you need to do it somehow, because if you just try and do stuff to the monster's tummy, the compiler can't know what you want it to do if the monster doesn't have one; and moreover, it's usually a good idea to think long and hard about just why it is you want to do something to the tummy of a monster that may not have one, and whether things will later fail because they assumed you did something to the monster's tummy when you didn't. - MoonShadow

NokkyQuote... :)  "it's usually a good idea to think long and hard about just why it is you want to do something to the tummy of a monster that may not have one" --AC

Heh.  Yes.  The problem with type systems is that they agglutenate into a horrible huge mess.  And especially in an environment with lots of different people, there's a huge resistance to fixing them.  I would prefer no types over badly designed ones.  The same goes for interfaces to a lesser extent.  SmallTalk does in strict typing, but it makes it easy to change things around so that instead of working around types, you just make everything work properly in the first place.  --Vitenka

I've worked on projects entirely without a type system, with badly-designed type systems, and with well-designed type systems. The ones I've found to be the easiest and most pleasurable have been the ones with a well-designed type system, or the low-level ones entirely without where I was working on my own. Anything else was basically a horrible huge mess. Perhaps I've been unfortunate in my experience.. - MoonShadow

Yes, I was right (and the situation is actually worse than I described above)- this issue is explained here http://minnow.cc.gatech.edu/squeak/769.  What an eccentric language.  I like :-) --Mjb67