- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] a Pharo talk from a ruby conference

by kilon alios

The problem is that sometimes we overestimate how important "play well with others" is. In python we have the cpython vs jython / ironpython . Cpython is the popular choice which is python implemented in C. Ironpython is a compiler of python for .NET and jython a compiler for Java. The advantage of using .NET and especially Java libraries out of the box is obvious. Yet Jython and Ironpython are hardly popular , definitely less popular than Pharo. It seems that coders suffer on what I call "code narcissism syndrome" , it goes like this Jython : well I am python written in Java and I can use any Java library you want out of the box and even C libraries like Cpython coder : Wow cool Cpython : yes but all my libraries are written in python do you really want to mess with Java libraries ? coder: hmm, eh, no not really So my experience is that if you have something you really enjoy even though it may lack features you would find on a bigger system, you will still prefer to use that. Because there is a reason why you checked it out in the first place, you were really unhappy with the big system. So I am full supporter of the idea that pharo should make git integration, as well CLI , and other tools easier for those that want to use such external tools. But we should not worry too much about it. Afterall people change or try new languages because they are not satisfied with what they have already in their system. They want a fresh new approach to things. I was interested in pharo because python lacks a real python IDE. Most IDEs that Python uses are IDEs that follow "work well with others" concept but that concept sacrifices the advantages of having a closely integrated system like Pharo has. On Tue, Apr 29, 2014 at 10:42 AM, Frank Shearar <frank.shearar(a)gmail.com>wrote: > On 29 April 2014 03:48, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Esteban A. Maringolo wrote > >> Plays well with "choose your favorite text editor" (Sublime, Vim, > >> etc.) and IDEs (RubyMine, etc.), with source control systems (any file > >> based system), with unix in general (several cli commands), has > >> binding for any major/mainstream library* (databases, network, etc.). > > > > But again these boil down to community size/interest > > - To use "your favorite text editor", Craig Latta serves Smalltalk via > > WebDav [1], but who has jumped at this opportunity? > > - source control - now that there is community interest, progress on git > > support has been moving ahead rapidly with minimal resources > > - unix in general - with FFI and OSProcess, what can't you do? Are we > > talking about the lack of cool Ruby backtick syntax? While definitely > cool, > > that special-purpose syntax is the kind of cognitive load Smalltalk > > overcomes. All those little syntactical twists and turns to remember lead > > away from "syntax on a T-shirt" to manuals with hundreds of pages > > - bindings - again, obviously just a question of community size and > interest > > Backtick syntax is largely bogus anyway. It's a minor string > interpolation trick with a special evaluation strategy. And I entirely > agree that Ruby has (way, WAY) too much syntax. > > > So the "play well with others" is a self-fulfilling prophecy. There are > no > > bindings because there are no people to write them because there are no > > bindings... At inception, Ruby (and every other language) didn't have > those > > bindings either. > > That's largely true, in the sense that someone needs to grab a shovel > to dig that trench. > > But if you start out with an external text editor, with an external > version control system, with (only) stdout/stderr/stdin, you end up > building a different system than if you're already in an insular > environment and want/need to learn to "play well with others". Ruby > plays well with other - interfaces well with external systems - > precisely because it didn't have that integrated environment. Now > sure, back in 1976 Smalltalk didn't either, but we're here in 2014, 18 > years after Squeak budded off Apple Smalltalk: a tightly integrated > environment is what we started from. > > frank > > > [1] > > > http://thiscontext.com/2011/06/09/my-favorite-text-editor-editing-a-spoon-w… > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/a-Pharo-talk-from-a-ruby-conference-tp4756805p4756900… > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > >

April 29, 2014

Re: [Pharo-dev] Amber-Pharo based coding dojo in a coworking space

by Markus Fritsche

On 2014-04-28 17:17, Ben Coman wrote: > 1. The most kick ass thing I can think of would go something like this... The most "kick ass thing" I can think of is... - Have a Pharo World being interfaced to an amber frontend, so you can use your image through your browser. ... on second thought... that might be cool but after five minutes it'll make me think "and now?" ;-)

April 29, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] 0937b8: 30839

by Marcus Denker

On 29 Apr 2014, at 10:23, GitHub <noreply(a)github.com> wrote: > Branch: refs/heads/3.0 > Home: https://github.com/pharo-project/pharo-core > Commit: 0937b85d745a2c5b064e784ac5535e6dea7fdc2f > https://github.com/pharo-project/pharo-core/commit/0937b85d745a2c5b064e784a… > Author: Jenkins Build Server <board(a)pharo-project.org> > Date: 2014-04-29 (Tue, 29 Apr 2014) > > Changed paths: > M Athens-Cairo.package/TCairoLibrary.class/class/library path/nbLibraryNameOrHandle.st > M Files.package/PharoChangesCondenser.class/instance/private - 1 writing/writeClassComment_.st > M Files.package/PharoChangesCondenser.class/instance/private - 1 writing/writeMethodSource_.st > M Files.package/PharoChangesCondenser.class/instance/private/condenseClassOrTrait_.st > M ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script100.st > A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script101.st > M ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30838.st > A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30839.st > M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st > M Slot.package/ClassModification.class/instance/testing/modifiesSharedVariables.st > A SlotTests.package/SlotIntegrationTest.class/instance/tests/testSlotScopeParallelism.st > M SlotTests.package/TOne.class/class/testing/classOne.st > M Traits.package/TClass.class/class/fileIn%2FOut/allSuperclassesFor_cache_.st > M Traits.package/TClass.class/class/fileIn%2FOut/doesNotIncludeInstanceOrSuperclassesFor_in_cache_.st > M Traits.package/TClass.class/class/fileIn%2FOut/fileOutPool_.st > M Traits.package/TClass.class/class/fileIn%2FOut/hasNoDependenciesForMetaclass_in_cache_.st > M Traits.package/TClass.class/class/fileIn%2FOut/hasNoSuperclassesOf_in_cache_.st > M Traits.package/TClass.class/class/fileIn%2FOut/superclassOrder_.st > M Traits.package/TClass.class/class/inquiries/rootsOfTheWorld.st > M Traits.package/TClass.class/class/instance creation/templateForSubclassOf_category_.st > M Traits.package/TClass.class/class/instance creation/template_.st > M Traits.package/TClass.class/class/private/hasNoDependenciesFor_in_cache_.st > M Zinc-System-Support.package/extension/SmalltalkImage/instance/downloadSources.st > M Zinc-Tests.package/ZnClientTests.class/instance/testing/testProgress.st > The changes recorded here are actually side=effects from git having stored the reverted changesâ¦ not nice but should not be a problemâ¦ Marcus

April 29, 2014

[pharo-project/pharo-core] 0937b8: 30839

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 0937b85d745a2c5b064e784ac5535e6dea7fdc2f https://github.com/pharo-project/pharo-core/commit/0937b85d745a2c5b064e784a… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-04-29 (Tue, 29 Apr 2014) Changed paths: M Athens-Cairo.package/TCairoLibrary.class/class/library path/nbLibraryNameOrHandle.st M Files.package/PharoChangesCondenser.class/instance/private - 1 writing/writeClassComment_.st M Files.package/PharoChangesCondenser.class/instance/private - 1 writing/writeMethodSource_.st M Files.package/PharoChangesCondenser.class/instance/private/condenseClassOrTrait_.st M ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script100.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script101.st M ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30838.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30839.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot.package/ClassModification.class/instance/testing/modifiesSharedVariables.st A SlotTests.package/SlotIntegrationTest.class/instance/tests/testSlotScopeParallelism.st M SlotTests.package/TOne.class/class/testing/classOne.st M Traits.package/TClass.class/class/fileIn%2FOut/allSuperclassesFor_cache_.st M Traits.package/TClass.class/class/fileIn%2FOut/doesNotIncludeInstanceOrSuperclassesFor_in_cache_.st M Traits.package/TClass.class/class/fileIn%2FOut/fileOutPool_.st M Traits.package/TClass.class/class/fileIn%2FOut/hasNoDependenciesForMetaclass_in_cache_.st M Traits.package/TClass.class/class/fileIn%2FOut/hasNoSuperclassesOf_in_cache_.st M Traits.package/TClass.class/class/fileIn%2FOut/superclassOrder_.st M Traits.package/TClass.class/class/inquiries/rootsOfTheWorld.st M Traits.package/TClass.class/class/instance creation/templateForSubclassOf_category_.st M Traits.package/TClass.class/class/instance creation/template_.st M Traits.package/TClass.class/class/private/hasNoDependenciesFor_in_cache_.st M Zinc-System-Support.package/extension/SmalltalkImage/instance/downloadSources.st M Zinc-Tests.package/ZnClientTests.class/instance/testing/testProgress.st Log Message: ----------- 30839 Error when loading a MC version that removes a class-side variable https://pharo.fogbugz.com/f/cases/13231 http://files.pharo.org/image/30/30839.zip

April 29, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30839 Home: https://github.com/pharo-project/pharo-core

April 29, 2014

Re: [Pharo-dev] a Pharo talk from a ruby conference

by Frank Shearar

On 29 April 2014 03:48, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Esteban A. Maringolo wrote >> Plays well with "choose your favorite text editor" (Sublime, Vim, >> etc.) and IDEs (RubyMine, etc.), with source control systems (any file >> based system), with unix in general (several cli commands), has >> binding for any major/mainstream library* (databases, network, etc.). > > But again these boil down to community size/interest > - To use "your favorite text editor", Craig Latta serves Smalltalk via > WebDav [1], but who has jumped at this opportunity? > - source control - now that there is community interest, progress on git > support has been moving ahead rapidly with minimal resources > - unix in general - with FFI and OSProcess, what can't you do? Are we > talking about the lack of cool Ruby backtick syntax? While definitely cool, > that special-purpose syntax is the kind of cognitive load Smalltalk > overcomes. All those little syntactical twists and turns to remember lead > away from "syntax on a T-shirt" to manuals with hundreds of pages > - bindings - again, obviously just a question of community size and interest Backtick syntax is largely bogus anyway. It's a minor string interpolation trick with a special evaluation strategy. And I entirely agree that Ruby has (way, WAY) too much syntax. > So the "play well with others" is a self-fulfilling prophecy. There are no > bindings because there are no people to write them because there are no > bindings... At inception, Ruby (and every other language) didn't have those > bindings either. That's largely true, in the sense that someone needs to grab a shovel to dig that trench. But if you start out with an external text editor, with an external version control system, with (only) stdout/stderr/stdin, you end up building a different system than if you're already in an insular environment and want/need to learn to "play well with others". Ruby plays well with other - interfaces well with external systems - precisely because it didn't have that integrated environment. Now sure, back in 1976 Smalltalk didn't either, but we're here in 2014, 18 years after Squeak budded off Apple Smalltalk: a tightly integrated environment is what we started from. frank > [1] > http://thiscontext.com/2011/06/09/my-favorite-text-editor-editing-a-spoon-w… > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/a-Pharo-talk-from-a-ruby-conference-tp4756805p4756900… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

April 29, 2014

Re: [Pharo-dev] a Pharo talk from a ruby conference

by Esteban Lorenzano

On 29 Apr 2014, at 02:24, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Tudor Girba-2 wrote >> There is a point of view from which one could say that >> Pharo is Smalltalk by seeing Smalltalk as a movement, rather than specific >> implementation. Unfortunately, everyone else thinks of Smalltalk as a >> specific language, or set of languages with specific environments that >> typically look old enough to not be relevant anymore. > > Yes! This is a tower of babel argument. > For almost every programmer alive, Smaltalk = Smalltalk 80 -> Pharo is > Smalltalk-inspired > For us, Smaltalk = "experimental Dynabook software that bootstraps itself > (ideally every 4 years)" -> Pharo is Smalltalk 109. > > So it's a question of who you're marketing to. Since we're marketing to > non-Smalltalkers (quite wise since 16% market penetration is the tipping > point [1], and we're not there yet), clearly "Pharo is Smalltalk-inspired" > is the thing to say. It's not any more or less true than the latter, just > more useful in its context. > > [1] http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action +100 is not about âwhat is or what is not pharoâ, is about how we spread it. all of us know that pharo is a smalltalk, but âusâ is the 600 people of this list. there is a world outside. And I even would say: a brave world (yet not so new). So the question is how we reach them (or at least more of them). You are losing time arguing something that does not have any sense because is clear (for us) what pharo is. Thatâs not the discussion. Not at all. This is a true story: (eve-online chat, the more nerd of the games around, aprox. 25% of their players are programmers or systems-related) X>So, what do you do? me>Iâm a programmer X>yes, me tooâ¦ but what do you do? me>Pharo, a kind of Smalltalk X>What? me>a Smalltalk X>Is not that an old long time dead language? how is possible to work on it? me> [LONG EXPLANATION] X>I never knew anyone who programs in that. I do games, so I program in C++â¦ me>but you know that *this* game is made in Python, isnât? X>yes, but Python is modern, even if not as powerful as C++ me>plop And like that, it happened several times. Soâ¦ until someone demonstrate that the majority of the programming community in the world does not have a pre-concept around Smalltalk, I sustain that we need to present our supergreat environment in better ways that just step there saying âlook the magnificent smalltalkâ! Btwâ¦ Gilad did same thing with newspeak: He said âis in the tradition ofâ with is just another way of saying âis smalltalk/self-inspiredâ. And another btw: I do agree with Gilad: Newspeak is not Smalltalk (same as Self is not)â¦ They share a tradition, but if we can say that Newspeak and Self are âSmalltalksâ we need to say that Java and C# are âC plus plusesâ. cheers, Esteban > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/a-Pharo-talk-from-a-ruby-conference-tp4756805p4756891… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

April 29, 2014

Re: [Pharo-dev] a Pharo talk from a ruby conference

by S Krish

"So it's a question of who you're marketing to. Since we're marketing to non-Smalltalkers (quite wise since 16% market penetration is the tipping point [1], and we're not there yet)" If you can get Pharo Smalltalk to be what makes people feel great about using it and creating great applications with, it will succeed far more than Ruby has in 5 years ahead. We need not push our efforts and energy in labelling ( falsely ), that will give no impact / or add any value to the perception of people. Java succeeded because it enabled many to move on to the web enabled world.. massively.. Rails succeeded because developers found it easier and simpler to bring up a complete website and maintain it than its alternatives. JRuby helped in as much Heroku did in its growth. Many developers made their fortune out of Rails.. iPad, iPhone, iPod, now android phones / tablets succeed well and truly because they enable the people to do what they want with it, make them feel great about using them too and bigger bet was developing for the Appstore and Android Market place that enabled many more to make money. Can we move on to have a Pharo Appstore with a demand for the apps in the store ... you will see more than 16% share you will need to make Pharo big. http://skrishnamachari.wordpress.com/2014/04/29/pharo-is-a-smalltalk-dialec… On Tue, Apr 29, 2014 at 5:54 AM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > Tudor Girba-2 wrote > > There is a point of view from which one could say that > > Pharo is Smalltalk by seeing Smalltalk as a movement, rather than > specific > > implementation. Unfortunately, everyone else thinks of Smalltalk as a > > specific language, or set of languages with specific environments that > > typically look old enough to not be relevant anymore. > > Yes! This is a tower of babel argument. > For almost every programmer alive, Smaltalk = Smalltalk 80 -> Pharo is > Smalltalk-inspired > For us, Smaltalk = "experimental Dynabook software that bootstraps itself > (ideally every 4 years)" -> Pharo is Smalltalk 109. > > So it's a question of who you're marketing to. Since we're marketing to > non-Smalltalkers (quite wise since 16% market penetration is the tipping > point [1], and we're not there yet), clearly "Pharo is Smalltalk-inspired" > is the thing to say. It's not any more or less true than the latter, just > more useful in its context. > > [1] http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/a-Pharo-talk-from-a-ruby-conference-tp4756805p4756891… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

April 29, 2014

Re: [Pharo-dev] a Pharo talk from a ruby conference

by Sean P. DeNigris

Esteban A. Maringolo wrote > Plays well with "choose your favorite text editor" (Sublime, Vim, > etc.) and IDEs (RubyMine, etc.), with source control systems (any file > based system), with unix in general (several cli commands), has > binding for any major/mainstream library* (databases, network, etc.). But again these boil down to community size/interest - To use "your favorite text editor", Craig Latta serves Smalltalk via WebDav [1], but who has jumped at this opportunity? - source control - now that there is community interest, progress on git support has been moving ahead rapidly with minimal resources - unix in general - with FFI and OSProcess, what can't you do? Are we talking about the lack of cool Ruby backtick syntax? While definitely cool, that special-purpose syntax is the kind of cognitive load Smalltalk overcomes. All those little syntactical twists and turns to remember lead away from "syntax on a T-shirt" to manuals with hundreds of pages - bindings - again, obviously just a question of community size and interest So the "play well with others" is a self-fulfilling prophecy. There are no bindings because there are no people to write them because there are no bindings... At inception, Ruby (and every other language) didn't have those bindings either. [1] http://thiscontext.com/2011/06/09/my-favorite-text-editor-editing-a-spoon-w… ----- Cheers, Sean -- View this message in context: http://forum.world.st/a-Pharo-talk-from-a-ruby-conference-tp4756805p4756900… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 29, 2014

Re: [Pharo-dev] a Pharo talk from a ruby conference

by Esteban A. Maringolo

2014-04-28 21:42 GMT-03:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Yes, it was very fair and a nice bridge between the Ruby and Smalltalk > communities i.e. not too elitist. +1 > kilon alios wrote >> I also completely agree with his criticism on smalltalk of... not playing >> well with >> others > I think this has always been a red herring. How exactly does Ruby "play well > with others"? Wth does that mean? Plays well with "choose your favorite text editor" (Sublime, Vim, etc.) and IDEs (RubyMine, etc.), with source control systems (any file based system), with unix in general (several cli commands), has binding for any major/mainstream library* (databases, network, etc.). And even has a VM that runs on top of a Smalltalk one :) Of course some of the "play well with others" decisions can restrict what you can do (as it certainly did with ruby), but they certainly play better. IMHO. > If we're talking about e.g. native windows, Ruby has bindings to GUI > libraries because it has a community big enough that is interested-in-that > enough to write them. In fact IIRC, someone wrote GTK bindings for > Squeak/Pharo, but there was little user interest and they took their code > elsewhere. There's no difference in that regard. When it comes to GUIs, any binding in langs is more a proof of concept than anything else, there are no "killer apps" written in Ruby that uses native GUIs (by means of Gtk, Qt, etc.). And I'd bet my balls (the golf ones ;-) that no single person comes to Ruby world to develop with Gtk bindings or similar. And a few years ago I'd say that no one came to ruby for other thing than Rails. Same goes for PHP, and other web based software. Maybe I'm totally mistaken, but today demand is web UI or an API. Considering the jobs request, no one is developing with native GUI any longer, except for those doing mobile development (Android/iOS); and that's because HTML5/JS is still slow/immature to replace the native alternatives. Regards, Esteban A. Maringolo

April 29, 2014