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
So let me see if I understand this... Pharo is not ready for prime time because it's still gestating? At what point will Pharo be ready for everyone in the world to use? Five years from now? Ten years? And when it is ready for the world to use, can we be sure that the world will use it? "If you build it, they will come." Really?? Have we not learned that grassroots guarantee nothing? The language landscape is littered with dead or dying languages that failed to rise above grassroots. At some point, people will begin to use your language (you hope). And when that time comes (sooner than 5 years?), organic growth will be a lot tougher. You don't get to choose your users; the users choose your language. Of course, you can always screw them by pulling the rug from underneath them. Not nice, but who said you have to be nice? The idea that hackers know, or can determine, what is a "good" language strikes me as rather presumptuous and incorrect. And whose definition of "good" are we using anyway? Ben Coman wrote
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
-- View this message in context: http://forum.world.st/Popular-tp4801049p4801103.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Richard, My post was somewhat in response to your campaign, but not trying to discourage you. Its just providing some counterpoint to consider in the big picture. Maybe I should not of posted another opinion piece so soon on top of the other threads, so probably even though you can pick holes in my answers to your questions, some advance notice I'm going to _try_ limiting further followups to let things settle down a bit. On Fri, Jan 23, 2015 at 5:08 AM, horrido <horrido.hobbies@gmail.com> wrote:
So let me see if I understand this...
Pharo is not ready for prime time because it's still gestating?
For some (the early adopters) Pharo is already ready for prime time. People are doing successful business with Pharo now! Successful enough to want to be paying members of the Pharo Consortium.
At what point will Pharo be ready for everyone in the world to use?
Five years from now? Ten years?
I agree with your implication. It is not beneficial to treat Pharo as unready-for-the-masses for an extended period. Now PG says you need: 1) a free implementation - Got it! Pharo's MIT license. 2) something to hack - Got it! There is the IDE itself, the PBE develops a game, and there is a broad base of open source applications and libraries. 3) a book - Currently we have only half of this. We have a very good book in PBE, but it is outdated several years. Early adopters and existing Pharo users can work around this, but for potential incoming masses, an up to date book is a critical aspect. There is current activity to update PBE for Pharo 4 (and now I realise I should help with it more, Thanks for clarifying my thinking on this.) To bring in the masses before this update is ready I believe could do more harm than good. It would be embarrassing and a great disappointed to push a campaign generating an influx of users that end up criticizing this aspect, and missing the chance for them to experience the value of Pharo - and you might only get one chance to create a good impression. So for me, right now PBE for Pharo 4 is the critical dependency before pushing a big advertising agenda, with a plan to align such with the Pharo 4 release. In addition, I consider running on pure 64-bit OS to be critical to gain credibility in the wider community. In my conservative view, for outside consumption I don't think its critical this be completed for Pharo 4, but aligning the release of a technology preview would be very nice.
And when it is ready for the world to use, can we be sure that the world will use it? "If you build it, they will come." Really??
That is a null point. That would be the same in ten years, five years and today. Besides, we are also building Pharo for ourselves. Indeed, "Every good work of software starts by scratching a developer's personal itch. [1] " Of course we want Pharo to grow because that will help fund its improvement and sustainability. But I don't think we need the whole world (yet). That brings other complications, like maybe design by committee. PG says "Everyone knows that it's not a good idea to have a language designed by a committee. Committees yield bad design. But I think the worst danger of committees is that they interfere with redesign" and that last point is important to consider for Pharo's vision [2]. [1] http://www.catb.org/esr/writings/homesteading/cathedral-bazaar/ar01s02.html [2] https://gforge.inria.fr/frs/download.php/30434/PharoVision.pdf (I think an update is in progress)
Have we not learned that grassroots guarantee nothing? The language landscape is littered with dead or dying languages that failed to rise above grassroots.
Nothing is guaranteed. But Pharo's steady organic growth makes me optimistic. My point is, Pharo has not had a BIG advertising campaign before. Growing organically has perhaps allowed us to get by with a few loose ends (like documentation) with the subsequent volume of newcomer questions arising from this being manageable. At least newcomers get a positive impression from fast response to their queries. A big influx a novice queries might result in either: * Pharo improvements delayed as the experts spend all delayed in improving Pharo; or * newcomers being frustrated with questions going unanswered. The advantage of organic growth is that you have a steady progression of people from novice to journeyman to master. "Ideally" the pool of journeyman available to answer novice questions grows at the same rate as the pool of newcomers grows. I consider my own journey. I lurked for a long while. Then I started contributing to the discussion. Of course, the easiest thing to contribute is "an opinion" -- and there is some value in that, but it doesn't actually create code. Actually it drags other coders away from their coding, so productivity goes down (so maybe sorry also for this thread). But its an investment in the future that hopefully the newcomer grows into a code contributor. At this stage I was probably a net drain (not that I noticed at the time). Then December 2013 there was a call for help whittling down the Issue List, so I dove in. The effect was I really learnt A LOT reviewing how others fixed code and getting my code fixes reviewed (and I recommend others do the same). So now I feel I can add more value.
The idea that hackers know, or can determine, what is a "good" language strikes me as rather presumptuous and incorrect. And whose definition of "good" are we using anyway?
PG says... "It may be that the majority of programmers can't tell a good language from a bad one. But that's no different with any other tool. It doesn't mean that it's a waste of time to try designing a good language. Expert hackers can tell a good language when they see one, and they'll use it. Expert hackers are a tiny minority, admittedly, but that tiny minority write all the good software, and their influence is such that the rest of the programmers will tend to use whatever language they use." And I guess if anyone would know, it is the founder of Y-Combinator [2] (DropBox, AirBnB, Heroku and others). [2] http://techcrunch.com/2013/05/26/paul-graham-37-y-combinator-companies-have-... So how do we target experts? * Experts are probably more suspicious of hyperbole and cheer leading. * Experts are in demand and busy - so short targeted concrete examples would be good. * Maybe quickstart tutorials demonstrating foundations for different application areas * Web (e.g. http://zn.stfx.eu/zn/build-and-deploy-1st-webapp/) * Games * Business GUI * Business RDMS App * Demonstrating Pharo's tight debug/compile/resume workflow * Acknowledging past criticisms and how they have been addressed, or how times have changed (Richard I see you trying to do this, but its a hard task) cheers -ben
Excerpts from Ben Coman's message of 2015-01-23 08:56:58 +0100:
In addition, I consider running on pure 64-bit OS to be critical to gain credibility in the wider community.
yes, i was quite surprised to find that 64bit is not supported yet. in my case i had to pick all the 32bit dependencies by hand to make it work which was quite an effort.
So how do we target experts? * Experts are probably more suspicious of hyperbole and cheer leading. * Experts are in demand and busy - so short targeted concrete examples would be good. * Maybe quickstart tutorials demonstrating foundations for different application areas * Web (e.g. http://zn.stfx.eu/zn/build-and-deploy-1st-webapp/)
definitely! for me this is the tutorial that had me hooked into hacking on pharo.
* Games * Business GUI * Business RDMS App * Demonstrating Pharo's tight debug/compile/resume workflow
oh yes! greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin Bähr working in china http://societyserver.org/mbaehr/
On Fri, Jan 23, 2015 at 09:21:52AM +0100, Martin Bähr wrote:
yes, i was quite surprised to find that 64bit is not supported yet. in my case i had to pick all the 32bit dependencies by hand to make it work which was quite an effort.
On Debian/Ubuntu, installing ia32-libs used to meet all the dependencies. But then the OS builders/packagers decided that ia32-libs was a hack and "improved" upon it...
Ben Coman writes:
3) a book - Currently we have only half of this. We have a very good book in PBE, but it is outdated several years. Early adopters and existing Pharo users can work around this, but for potential incoming masses, an up to date book is a critical aspect. There is current activity to update PBE for Pharo 4 (and now I realise I should help with it more, Thanks for clarifying my thinking on this.)
I'm happy to offer my services as an editor, proof-reader and writer. It's a lot easier to get English text out of me than code. :) If anybody needs or wants me to fix their text, just point me to it. -- Daniel Lyons
On 23 January 2015 at 16:23, Daniel Lyons <fusion@storytotell.org> wrote:
Ben Coman writes:
3) a book - Currently we have only half of this. We have a very good book in PBE, but it is outdated several years. Early adopters and
existing
Pharo users can work around this, but for potential incoming masses, an up to date book is a critical aspect. There is current activity to update PBE for Pharo 4 (and now I realise I should help with it more, Thanks for clarifying my thinking on this.)
I'm happy to offer my services as an editor, proof-reader and writer. It's a lot easier to get English text out of me than code. :)
If anybody needs or wants me to fix their text, just point me to it.
-- Daniel Lyons
It would help if the Pharo By Example book was integrated into Pharo itself, so that both using it and updating it would be in the same environment. Is it like that already? -- Frank Church ======================= http://devblog.brahmancreations.com
Not currently, but it would be good - perhaps being able to add scripts into Pillar that run to generate pictures, etc. On Sat, Jan 24, 2015 at 2:22 PM, vfclists . <vfclists@gmail.com> wrote:
On 23 January 2015 at 16:23, Daniel Lyons <fusion@storytotell.org> wrote:
Ben Coman writes:
3) a book - Currently we have only half of this. We have a very good book in PBE, but it is outdated several years. Early adopters and
existing
Pharo users can work around this, but for potential incoming masses, an up to date book is a critical aspect. There is current activity to update PBE for Pharo 4 (and now I realise I should help with it more, Thanks for clarifying my thinking on this.)
I'm happy to offer my services as an editor, proof-reader and writer. It's a lot easier to get English text out of me than code. :)
If anybody needs or wants me to fix their text, just point me to it.
-- Daniel Lyons
It would help if the Pharo By Example book was integrated into Pharo itself, so that both using it and updating it would be in the same environment. Is it like that already?
-- Frank Church
======================= http://devblog.brahmancreations.com
Le 24/1/15 09:02, Ben Coman a écrit :
Not currently, but it would be good - perhaps being able to add scripts into Pillar that run to generate pictures, etc.
yes Stefan Eggermont started but someone should make it works for real. Stef
On Sat, Jan 24, 2015 at 2:22 PM, vfclists . <vfclists@gmail.com <mailto:vfclists@gmail.com>> wrote:
On 23 January 2015 at 16:23, Daniel Lyons <fusion@storytotell.org <mailto:fusion@storytotell.org>> wrote:
Ben Coman writes: > 3) a book - Currently we have only half of this. We have a very good > book in PBE, but it is outdated several years. Early adopters and existing > Pharo users can work around this, but for potential incoming masses, an up > to date book is a critical aspect. There is current activity to update PBE > for Pharo 4 (and now I realise I should help with it more, Thanks for > clarifying my thinking on this.)
I'm happy to offer my services as an editor, proof-reader and writer. It's a lot easier to get English text out of me than code. :)
If anybody needs or wants me to fix their text, just point me to it.
-- Daniel Lyons
It would help if the Pharo By Example book was integrated into Pharo itself, so that both using it and updating it would be in the same environment. Is it like that already?
-- Frank Church
======================= http://devblog.brahmancreations.com
It would help if the Pharo By Example book was integrated into Pharo itself, so that both using it and updating it would be in the same environment. Is it like that already?
Pharo by Example is not written in Pillar. We are porting it. What would be good is to help us supporting the automatic run of the code snippets as Oscar did in Pharo by Example. Stef
On Jan 24, 2015, at 4:22 AM, vfclists . <vfclists@gmail.com> wrote:
It would help if the Pharo By Example book was integrated into Pharo itself, so that both using it and updating it would be in the same environment. Is it like that already?
Offering an easy install in one shot would be really nice but if you do a compulsive preinstall youâll alienate the ones that use pharo as headless servers that want to stay lean.
Le 24/1/15 22:46, Sebastian Sastre a écrit :
On Jan 24, 2015, at 4:22 AM, vfclists . <vfclists@gmail.com <mailto:vfclists@gmail.com>> wrote:
It would help if the Pharo By Example book was integrated into Pharo itself, so that both using it and updating it would be in the same environment. Is it like that already?
Offering /an easy install in one shot/ would be really nice but if you do a compulsive preinstall youâll alienate the ones that use pharo as headless servers that want to stay lean.
oh yes :)
Hi daniel This would be a really really great service to the community.
I'm happy to offer my services as an editor, proof-reader and writer. It's a lot easier to get English text out of me than code. :)
If anybody needs or wants me to fix their text, just point me to it.
Oh I would really love that! We have the ready to review chapters of the next books https://github.com/SquareBracketAssociates/EnterprisePharo STON Artefact Fuel NativeBoostX11 Zinc-Encoding-Meta Zinc-HTTP Zinc-REST PillarChap are ready to edit and review https://github.com/SquareBracketAssociates/PharoReadyForReviews you can start with DSL NeoCSV NeoJSON Voyage WebSockets are ready to edit and review We are doing a pass to update PharoByExample... but we are not finished yet. Stef
participants (8)
-
Ben Coman -
Daniel Lyons -
horrido -
Martin Bähr -
Pierce Ng -
Sebastian Sastre -
stepharo -
vfclists .