I found this article on the popularity of programming languages
interesting.
http://www.paulgraham.com/popular.htmlIt 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