Uh - PosterPage?. SmallTalk is a ProgrammingLanguage?. It is also deeply tied into a graphical environment. It's sorta like logo.
Except it's pure object orientation goodness. Everything is an object. Including classes. Everything is done via messages. (Message are objects. Code is an object.)
It's.. It's nice. I am using [squeak] which is very nice. A bit hard to get used to the UI but nice. But it has many many many library objects.
Has anyone else already played with this, and can give me some tips for getting going? I've got to the 'do some maths and print it out' stage (well, a bit past that) but I haven't yet find a way to do input, or put buttons on the screen and so forth. --Vitenka
PeterTaylor tried playing with it once and couldn't work out how to get that far. He does, however, challenge "saner and cleaner" - the thing has no type system worth a bean.
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, SmallTalkcan 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
I've heard this about SmallTalk and wonder if anyone else has: SmallTalk is an interactive system. Patches are applied to the run-time system by basically running a script that sends various messages to the run-time environment on startup. Every now and again the list of patches gets very long, so you run a special method of the run-time environment object called something like 'Generate'. Generate makes a new run-time environment image that will have the state of the image that you ran generate on. Generate has happened about 3 times in the history of the main SmallTalk run-time system, and some of the old patch scripts have been lost. That means that there is no source code for the SmallTalk kernel... --Mjb67
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
Suggest refactoring some of this to a general computer languages page? It's gotten a bit off the topic of smalltalk ;) --vitenka