January 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Pillar A4 :)

by stepharo

Bloc :)

Jan. 22, 2015

Re: [Pharo-users] Popular

by horrido

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.

Jan. 22, 2015

Re: [Pharo-users] Pillar A4 :)

by Offray Vladimir Luna CÃ¡rdenas

Hi Stef, Do you have the Pillar file for this one? I would like to see how do you deal with image positioning. Cheers, Offray El 22/01/15 a las 15:36, stepharo escribiÃ³: > One on Voyage :)

Jan. 22, 2015

Re: [Pharo-users] Mea Culpa

by Offray Vladimir Luna CÃ¡rdenas

Hi, I don't care about popularity, jvm or javascript now. I'm a newbie, but I was not drawn to Pharo/Smalltalk because of that. If that were the case I would choose an already popular language with javascript and/or jvm support. It's not about fear of the unpopular but doesn't caring about it (for the narrative in anglo tv series, seems that there is a big deal about being popular for North American people, specially in adolescence, but I digress). I share the attraction for the Dynabook idea and how a system could be understood by a single person.I have my own ideas about what a computer mediated experience could be, some related with the dynabook, some others don't and Smalltalk lets me explore/express some of that ideas more fluidly. What I would like from Smalltalk is to have is a better support for integration with the "external" world of computing, starting with documentation pandoc/TeX/luatex, fossil dvcs, then (I)Python, mind mapping and so on. I think that SRP has a "flaw" of showing itself as some kind of way to save Smalltalk of its unpopular destiny, not being on top 10 of TIOBE or being a niche platform, but for me that's not a cruel destiny and if it were that's not the best way to fight against it, but by building stuff that more people can use. Talking by making instead of talking by talking. We can start with some small community and spread from there (interactive documentation is my approach). So may be the best way of SRP to serve Smalltalk could be to not be so "self-serving" about its own goals (popularity, jvm, javascript, enterprise, TIOBE) and show the diversity of views and concerns of the Smalltalk community. To be a place for diversity in Smalltalk (may be a curator of dispersed experiences elsewhere). I hope it helps, Offray El 22/01/15 a las 13:03, horrido escribiÃ³: > Any language that has a significant user base, ie, a large number of > applications, will experience resistance to change. The only way to avoid > this is for people NOT to use the language. > > The fear of popularization will condemn a language to permanent niche > status. That's fine, if that's what the user community wants. The language > will forever be a "hobbyist" tool. > > > Sean P. DeNigris wrote >> >> hernanmd wrote >>> I am not that convinced Smalltalk should be popular >> For me, the goal is "critical mass" - big enough where issues and new >> projects move forward with ease. And this is probably just a few hundred >> percent. Mass popularity brings in people disconnected from the vision. >> Smalltalk for me is prototype Dynabook software. If it was just "a better >> programming environment", I'd still use it, but I doubt there would still >> be a passionate dream for the future of humanity attached to it... > > > > > > -- > View this message in context: http://forum.world.st/Mea-Culpa-tp4800840p4801047.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Jan. 22, 2015

Re: [Pharo-users] Pillar A4 :)

by Sven Van Caekenberghe

Thanks you: checked in ! > On 22 Jan 2015, at 21:16, stepharo <stepharo(a)free.fr> wrote: > > Hi sven > > here is one of several that I will send :) > > Stef > <PillarA4.pdf>

Jan. 22, 2015

Re: [Pharo-users] Pillar A4 :)

by stepharo

One on Voyage :)

Jan. 22, 2015

Re: [Pharo-users] Pillar A4 :)

by stepharo

Here is one on Citezen

Jan. 22, 2015

Pillar A4 :)

by stepharo

Hi sven here is one of several that I will send :) Stef

Jan. 22, 2015

Popular

by Ben Coman

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

Jan. 22, 2015

Re: [Pharo-users] Mea Culpa

by blake

>>Without the ability to address the largest number of Smalltalkers, the SRP cannot make any progress.<< Did you do any research on this before embarking? You may not be the first person who has attempted what you're trying. â Often when I'm trying to accomplish something that hasn't previously been attempted or, if attempted, not attained, I find that I've misunderstood where the difficulty lies. In very few cases is it merely a matter of determination. Looking at others' failures can be instructive.

Jan. 22, 2015