I found this article on the popularity of programming languages interesting. http://www.paulgraham.com/popular.html It mostly references Lisp, but I think a lot of the same applies to Pharo. It is quite long so I picked a few points that stood out to me: Some non-technical points... * Nothing could be better, for a new technology, than a few years of being used only by a small number of early adopters. Early adopters are sophisticated and demanding, and quickly flush out whatever flaws remain in your technology. When you only have a few users you can be in close contact with all of them. And early adopters are forgiving when you improve your system, even if this causes some breakage. * Users are a double-edged sword. They can help you improve your language, but they can also deter you from improving it. So choose your users carefully, and be slow to grow their number. Having users is like optimization: the wise course is to delay it. * There are two ways new technology gets introduced: the organic growth method, and the big bang method. ... Organic growth seems to yield better technology and richer founders than the big bang method. If you look at the dominant technologies today, you'll find that most of them grew organically. * Hackers have to know about a language before they can use it. How are they to hear? From other hackers. But there has to be some initial group of hackers using the language for others even to hear about it. I wonder how large this group has to be; how many users make a critical mass? Off the top of my head, I'd say twenty. Some technical points... * There is one thing more important than brevity to a hacker: being able to do what you want. In the history of programming languages a surprising amount of effort has gone into preventing programmers from doing things considered to be improper. This is a dangerously presumptuous plan ... The bumbler will shoot himself in the foot anyway ... Good programmers often want to do dangerous and unsavoury things ... give the programmer access to as much internal stuff as you can without endangering runtime systems like the garbage collector. * It might be a good idea to have an active profiler -- to push performance data to the programmer instead of waiting for him to come asking for it. For example, the editor could display bottlenecks in red when the programmer edits the source code. * It might be a good idea to make the byte code an official part of the language, and to allow programmers to use inline byte code in bottlenecks. * The most important part of design is redesign. Programming languages, especially, don't get redesigned enough. cheers -ben