Georg: I did live in the Smalltalk world. I find it annoying that everything thinks otherwise because I wasn't awed into silence by that environment. I'm not saying that using Smalltalk is a waste of time, or that it doesn't have some great features, many of which still haven't been replicated elsewhere. But when I had to make the choice between the Smalltalk environment and the rest of the world, eventually I chose the rest of the world. Georg, haven't you too? My point is that it is a flaw to force people to make that choice. Most of the time Smalltalk loses that battle -- if not right away, eventually.
Isaac: Then maybe you should talk about "Where Squeak Went Wrong"? -- maybe, but I think Squeak's goals are more modest and academic than Smalltalk's as a whole. Smalltalk had great ambitions (does it still have them? maybe not...). I don't think it has fulfilled those ambitions. I'm open to an argument that Smalltalk has achieved every success it deserves, but I suspect that would be a case of damning with faint praise. This all started in a response to "Why People Don't Get Smalltalk". So I'm giving my answer -- and unlike other people's, my answer isn't "because everyone is too misguided and uninformed".
You used Squeak - Squeak has a vibrant Free Software kind of community! It does. It seems to be the only such community. Maybe I'm wrong, I'm not intimately aware of the current state of the Smalltalk community. Squeak is a good hobbiest project, and it's a good academic/experimental project, but I haven't seen it work outside of that.
What do you mean specifically by "the dominant syntax"? I mean function(args...) or object.function(args...). Mapping, say, Objective C into another syntax looks funny, you get stuff like obj.setX_y_(x, y) or much worse (usually much worse). Mapping the other way turns into object methodWith: arg1 with: arg2 with: arg3. I think other languages have been successful when they've been able to adopt foreign interfaces and APIs -- it allows them to quickly leverage other work (either porting code or using external code directly), and leverage not just the code but the documentation and skills around that interface. Smalltalk's syntax hinders that.
Maybe you mean: OOP devalues the idea of a "program"? Yes! That's exactly what I mean. I don't think the world is ready for that.
Why would we use an OO programming language to do simple imperative programming? Because it's simple? A lot of problems are simple. Easy problems should be easy to solve. I think imperative, non-component programming is simpler. It's not always appropriate -- but when it is, it's really nice to have it available. This is what I think of when I distinguish between frameworks and libraries -- with libraries the control stays with the caller, and the programmer defines the basic flow of code. A framework, in contrast, takes over control from the programmer, and the programmer customizes the framework, they can't simply use the framework.