J J wrote:
One doesn't have to look far for this. C became popular for no other reason then it was "close enough" and we could use it "right now" to build systems. The more advanced languages used resources when there were no resources to use.
Paul Graham has an essay on why languages become popular: http://www.paulgraham.com/popular.html In the case of both C and C++, one should not discount the wight of AT&T, one of the largest and most widespread and visible companies of the time (as it ran a telephone monopoly). Similarly, without the backing of both Sun and IBM, Java might well never have taken off. Clearly Smalltalk was much better than Java in many ways when it was released: http://www.oreillynet.com/ruby/blog/2006/01/bambi_meets_godzilla.html And, before Java,. people were actively converting too it as a "COBOL for the 1990s"; and either C++ or Smalltalk were both so different from COBOL, that there was no huge difference in ease of understanding either syntax for COBOL programmers; in fact, Smalltalk was closer to COBOL's use of complete words without arbitrary abbreviations if anything.
"The rise of worse is better" largely misses the point here. The point is: getting 80% today is infinitely better then 100% "some day". And all the rest is just the incredible weight of "backward compatibility".
And the concept of backward compatibility isn't just software and hardware. It extends to workers as well. The average programmer is just not very good (and I don't speak about the worth of the people as human beings. There are just so many in the field with no interest in it other then money, which is totally ok. It just doesn't make for good programmers). The cost of moving people who are barely keeping up from C++ to Java isn't so bad. It actually makes things simpler: just the same syntax again with much of what they didn't understand taken out. But moving these folks away from a C based syntax is out of the question. And getting rid of them in favor of more talented programmers would be just as out of the question.
Well, it is also true one big issue is that an Algol-like syntax with operator precedence (times over plus) is taught in K-12 school. That is a big advantage for a computer language to build on that, even as that precedence is arbitrary and Smalltalk is more consistent. And you are right on how Java seemed an easy move for C++ programmers. Of course, now Ruby seems an easy move for Java programmers (and much of Ruby is based on Smalltalk ideas), so in a matter of time, we may see Ruby developers making the leap to a more self-documenting and flexible syntax. :-)
Still, Smalltalk syntax was supposedly designed to be easy for kids to learn. It is not that hard to learn the syntax. I've helped people in business learn it. It takes at most week to become proficient in it (and often just a day). What is hard is to learn all the libraries. But, with more and more programmers learning things like Java or Python or Ruby, all systems with rich libraries, Ruby's being almost exactly Smalltalk's in many ways, making the leap to a new syntax would be a minor investment (and one worth taking because Smalltalk syntax is more extensible and self-documenting than any of those other languages').
People are changing languages all the time. People have moved to Python; people are moving to Ruby; people have even moved to languages like Perl, which have much more tortured syntaxes or PHP which have much more limited libraries. People learned HTML out of the blue because they wanted to do web sites, and HTML is a much harder syntax to work in than Smalltalk's in many ways (though you can edit in vi and then see immediate results in your local web browser). So, why not people moving to Smalltalk (Squeak especially)? People in Python or Perl or PHP or Ruby camps are not bemoaning "backward compatibility" as the reason for limited success and adoption. While everything you say it true, it is not true enough IMHO to be the main reason. What are the others and how can they be addressed to produce a popular free Smalltalk?
Again, to contrast with Python, Squeak wants to run the show, but Python plays nice with all the other free tools of the GNU/Linux ecosystem.
I keep on seeing this, but it appears largely overstated. Java has it's own VM, threads etc. as well. And it is easier to connect to the outside world in Squeak then Java, because in java you are in "your on your own!" land. In Squeak you always were so there is no need to be afraid of this step if you need it. In at least Squeak and Dolphin smalltalk you can call "extern C" style functions directly from smalltalk (thought in squeak you need to load FFI first). That is at least as good as any of the other languages.
True. Though there can still be a difference in "culture" of the communities surrounding a language. Clearly Smalltalk's (or Squeak's) culture is very different than Python's. I wrote something on that here, in terms of how the cultures of the communities relate to their histories: http://mail.python.org/pipermail/edu-sig/2006-December/007476.html
And if you mean more to address the tools, well yes you *can* edit Java code in vi if you really want to. But no one really wants to. And if your interface to the language is through some program anyway, then the "barrier" of the code not being on the file system disappears.
Well, there is a bigger difference here between Python (which I mentioned) and Java (which you mentioned). Python plays nicer with UNIX-y systems than Java in many ways, mostly because Python is smaller, historically had a faster startup time, and earlier had more comprehensive libraries for interfacing with UNIX-y libraries. My point was more for Python, which is being billed as a "glue" languages -- something to glue together your C libraries.
Java is different, as you point out. However, Java is so different, and received so much attention, and incorporated so many Smalltalk-pioneered ideas in the JVM design and class libraries (Swing) that ten years after it has been introduced, it finally mostly works right as a self-contained environment. Not quite VisualWorks, but darn close in many ways by now, and it is free as in beer and is becoming free as in freedom (GPL). :-)
But for both Java and Python, being able to be easily edited in vi (or emacs) or being able to use a conventional text oriented version control system were indeed big wins, as they reduced the learning curve and initial commitment to new ideas. Being able to use the familiar file manager to look at code was also of value. And going beyond vi, the fact that Java IDEs started to look like C++ IDEs was another big win on familiarity. And seeing each class in a separate file in the good old reliable file system was also comforting -- at least you knew where your source is, and could use grep or other tools to search and manipulate it and back it up in a familiar fashion. Talks2 shows this is possible -- having a directory of Smalltalk class files. It is possible to generate text files from an image -- any Smalltalk can typically export such classes. And it isn't that hard to export instances as text either (I made something in Python that does it for instances in that language; any Smalltalk could do much the same) which gives you an image defined by textual program code to rebuild a world of objects.
Forcing everyone to work in Smalltalk using Smalltalk tools, as good as they are, means that other innovations developed in other languages with other tools, for example, Java, are lost to the Squeak community.
Um... What innovations in Java?
Extensive tested and debugged libraries on a variety of topics.
Many humans become fluent in multiple human languages and their accompanying cultures, which is typically a harder thing than learning new computer languages. If one needs to switch mental gears conceptually to work on the VM, then is it *really* so bad if the VM is written directly in C like GNU Smalltalk does?
Typically? It is harder in every case, no matter how badly designed the programming language.
Well, Spanish to Portuguese might be easier than COBOL to OCaml? But COBOL to OCaml is hard for different reasons than syntax. :-)
And what do you want to gain here? If the squeak community came out today and said "Ok! You can write the squeak VM in anything you want, we don't care", they wouldn't suddenly get volunteers knocking the doors down to work on squeak. They would only lose people who can work on the VM today (not because these people *can't* do it, but because they wouldn't want to anymore).
While I agree that squeak is not required to be written in a subset of smalltalk, it *is* and changing it wont gain anything. Getting squeak to run on strong talk might, but I haven't seen anyone forbidding that.
My point here wasn't that Squeak should change; it was just an example of how being different and staying entirely in Smalltalk might not have been a big win, compared to just having a VM written in, say, C. There remains the "conceptual" barrier of the VM domain, even as the "technical" one of syntax is removed.
I am not against translating a VM from an abstract representation, in, say Smalltalk. I think it is a clever idea, especially since it already has been done. And with some more work, it might even gain the elegance of say ANTLR's plugin for Eclipse, or ANTLRWorks, where you can step through the abstraction in an IDE without seeing the underlying code (Java in ANTLR's case). (Maybe Squeak can already do this by now?)
Still, having said that, a Smalltalk VM is so simple, consider this 47K Public Domain one that does most of the work (from the Java version of A Little Smalltalk, now called SmallWorld): http://budd.eecs.oregonstate.edu/~budd/SmallWorld/Source/SmallObject.java so how hard is that to maintain a Smalltalk VM the original Java?
Translating primitives into C or Java, like for sound manipulation, seems like a bigger win. But even then, you have to be writing that code (or rewriting that code) in such a non-Smalltalk way semantically that it is still not clear to me if there is a lot of value in it. Especially when the alternative might be to just call an existing sound synthesis library written in Java or C. We now have Java for a good cross-platform language with equivalent to C++ performance, so it would have been a harder choice ten years previously as to what cross-platform language to use if not C with all its quirks (Free Pascal?).
Right now, I think Squeak on the JVM, like Talks2 is a step towards, could be a really big win for the Squeak community, and translating the VM from an abstract representation (in Smalltalk) to a specific language is a big win there. Still, the VM could have been in any translatable abstraction (XML, Lisp, ANTLR parse tree from a VM-specific language, Parrot, etc.) and generating Java would still be easily doable (though of course Smalltalk encoding is preferable for Smalltalkers).
Java isn't the end-all/be-all here. Microsoft is moving to a more dynamic VM already, and because of this Java will be forced to as well. Java has always been behind pre-existing technologies and this area is no different. If you want to move into the future it is best not to follow a group that is always behind.
The value of Squeak on Java is a separate issue. The value is mostly to be able to reduce deployment overhead, especially for systems that mix Smalltalk and faster native-y code written in Java or another JVM language; Talks2 already did a lot of this work.
But here again is an issue of culture. Who cares if Sun is "behind"; or if Squeak runs 30% slower without some extra dynamic dispatch opcode in the JVM? Speed is not Squeak's main problem. Being able to leverage Sun's JVM and the fact that you can call AWT classes in the same way for any platform Java runs on is a big win for Squeak IMHO, as it would reduce the maintenance burden of it in terms of complexity of the common code base, and would also make it easy to install one common package for any platform Java runs on. Ten years ago, or even five, I myself would have laughed at the value of this idea (as Java was so buggy and unstable and slow). But most of the bugs have been fixed, the 1.5 JVM shares memory across JVMs and does dynamic translation for speed, so Java finally, now that it is going free under the GPL, has the potential to be a great cross-platform tool where you get both a common base GUI window system as well as the ability to deliver fast primitives written in Java, as well as access to a lot of libraries someone else has already written and debugged for you.
The Squeak community could admit that it would be a big win to leverage that "pink plane" success, even if it is "behind" and decide to move forward on top of it, but in other "blue plane" directions. Or it can continue to spend a lot of time dealing with time consuming basic issues relating to packaging and testing C code for lots of platforms (which essentially just duplicates the work the Java community is doing, but not as well because of more limited people power).
dot net is a non-starter because it is proprietary (and may be covered by patents). And I would not make this suggestion without basing it on Sun's move to the GPL for Java. There are several JVM Smalltalk already of course. http://www.robert-tolksdorf.de/vmlanguages.html But none have the power of Squeak. And, building on Squeak's strengths, it could be an opportune time to also shake off licensing problems, say by carefully comparing with and using GNU Smalltalk code when possible, or by using an approach like Bistro to leverage Java libraries temporarily until replacement versions in Smalltalk could be written in a true "clean room" fashion.
But the bigger point, along the lines of this main "revisited" thread, is that building on others work in a comprehensive way, like having a Squeak on top of Java, even though it has been done somewhat with the excellent Talks2, is something that goes against the grain of the community (and quite possibly to its disadvantage).
Python, by contrast, runs on the JVM, using Jython, and has great integration with Java. It has issues, and lags the main release, but overall it is production quality (at least in earlier releases); and since Java is such a difficult language to develop in because it is so verbose with braces and passing through exceptions and types and such, Jython may well be the big thing that makes Java continue to succeed. :-) From: http://www.jython.org/Project/index.html " Jython, lest you do not know of it, is the most compelling weapon the Java platform has for its survival into the 21st century:-) —Sean McGrath, CTO, Propylon"
Why not have Squeak in that role too? But the deeper question is, why is it not there already, and why has, say, Talks2 not gotten more effort behind it? And I think that issue has to do with community issues and also licensing issues than technology issues. (I myself would build on Talks2, right now except it is stuck in the same licensing ambiguity Squeak is; I'm hoping when Squeak gets that cleared up for itself, that Talks2 might follow).
== objects are an illusions, but useful ones ===
[snip]
To me this was the most insightful point in the whole essay. Though, honestly I thought this was pretty well understood. Object Orientation is simply a way of organizing code in a way that makes sense from the perspective of the problem domain it is related to. But since programming is a task of managing complexity, correct organization is a critical piece of the puzzle.
When one thinks deeply about this, perhaps your point about organization is the big missing piece of the puzzle. Yes, you are right, people build models of systems with objects, and should admit those models are imperfect. But there is no formal support for this process in the environment, or between people, other than using basic Smalltalk tools (Browser, Debugger, maybe Refactoring tools). Well, I guess you could use one of the formal OO modelling approaches, like CRC cards, but even that is oriented to getting one model -- not to managing a variety of possible representations to be used simultaneously as appropriate. Perhaps a next generation of OO systems needs to explicitly support this process somehow. How, I do not know. I just have the question here, not the solution. I do think having objects point to a context or world is perhaps a start, and I did that in a couple frameworks I have made in either Python or Smalltalk.
But this observation is the reason OO databases haven't really taken off: An OO database will tend to model things how *your* application wants to see them. A traditional relational DBA will model things in the most generic way he can so that *all* the applications can build the view they need easily. Relational DBA's tend to be of the view point: The data will exist for the life of the company, while the applications that access it come and go like the tide. And one only needs to look at the huge Java rewrites going on to know they are right.
Good point.
Consider Dan's statement of "A computer language should support the concept of "object" and provide a uniform means for referring to the objects in its universe." That appears to me to have made a classical mistake of thinking the universe has only one parsing into one object hierarchy and that the objects exist in some sort of Platonic ideal.
Actually I think this applies more to C++ derived OO languages (e.g. Java). It is those languages that have huge hierarchies of things that are not that related due to the brain-dead typing systems. In smalltalk the only hierarchy that has to be is inheriting from Object. And you don't even have to do that.
But I think this works just fine: We are choosing to code something, so we have to model it in the point of view appropriate to how we are going to solve the problem. And this implies some organization technique. And among organization techniques, (correct) OO has had the most success in my opinion.
All true, but if you look at how people teach OO, and how people talk about it, especially n Smalltalk circles, I think the community and its culture is somehow at odds with a greater flexibility. It's hard for me to detail this precisely; it more has to do with tone. Certainly I like the Smalltalk approach; it is just not enough.
<chair part snipped> There is no neat "class" to put it in.
I wouldn't expect it to be in a class. I would expect classes to know how to stick to each other. :)
Clearly you, the reader, can think about this entity so the human brain supports this fluidity in changing our definitions of objects and not requiring a one-to-one mapping to ideal classes to think about them, but a computer language like Smalltalk would have many problems representing this. William Kent, in the book _Data & Reality_ discusses these sorts of problems at length.
I disagree with where the focus is placed here. An entity typically does have just one name and would make sense to be called one thing in the system. What you are describing sounds more like interface protocols. This might be an area that could use more research, but honestly I would want to know what is bought by formalizing this existing practice more (e.g. making protocols first class objects themselves or something).
For an example of what I mean, in case it isn't that clear, we could think about Lists. They have a collection protocol: a series of messages that conform to what other collections can do. But they could also have a "stack" protocol: a series of messages for treating the list as though it were a stack.
This could be seen as what we do in real life. Due to necessity I may find myself driving a nail into a piece of wood with a screw driver. But I would never call what is in my hand a hammer. I would simply be using it's "blunt object" interface momentarily.
That is one of the reasons I have been attracted to Prototypes, which attempt to address issues like: http://en.wikipedia.org/wiki/Self_programming_language "Experience with early OO languages like Smalltalk showed that this sort of issue came up again and again. Systems would tend to grow to a point and then become very rigid, as the basic classes deep below the programmer's code grew to be simply "wrong". Without some way to easily change the original class, serious problems could arise"
But prototypes have other problems, the biggest being difficulty being self-documenting the way classes are. As someone put it to me, "if you want to share something, you probably have to name it".
Formalizing protocols is one possible idea. Dan mentions it in his paper.
I thin the solutions to this issue lie in deeper directions. Classes or instances or prototypes could be building blocks, perhaps, but we could use other abstractions and better tools somehow. What these are, I do not know for sure. Still, like Bill Kent, I think these may lie in the direction of being able to model "relations" somehow.
--Paul Fernhout