- Pharo-users - lists.pharo.org

Re: [Pharo-users] Devnology presentation slides

by Thierry Goubier

Thanks Stephan, such narratives are important. > Pharo uses a very simple and orthogonal language, using a very small > set of constructs. I allways tend to complement with: > but this very small set of constructs contains all the needed > features for building highly complex, understandable and reusable > software architectures. Thierry Le 07/04/2015 18:39, Stephan Eggermont a Ã©crit : > On 02/04/15 23:18, Stephan Eggermont wrote: >> Diego and I presented Pharo at the Devnology meeting in Arnhem. >> >> http://www.slideshare.net/StephanEggermont/pharo-devnology20150401 > > And a narrative: > > Pharo, the Immersive Programming Experience > > Why do we choose to use Pharo? We feel that Pharo provides the best > way to combat complexity in software development. > > As long as the number of software developers paid to make software > smaller and throw away code is a lot smaller than the number of > developers paid to add code, the software we deal with on a daily > basis will continue to grow. This inevitably leads to an increase in > the complexity of the systems we build. This complexity is > problematic because decision making in difficult situations is biased > (1), using first fit heuristics instead of best fit. > > An interesting observation (2) is that successful software tends to > have technical debt. If a software system is successfull, the market > pressure to deliver more and faster than technically advisable is > difficult to resist. When growing very fast, it can make sense to > make choices that enable short-term growth that will need refactoring > later. Additionally, an architecture that is optimal for a small > system is not ideal for a large system and vice-versa. > > So, what can we do? There are several interesting models dealing with > complex software systems. Let's check a few of them, and see what > Pharo has to offer there. > > The Cynefin framework (3) categorizes the problem space into 5 > domains: - Obvious, where the relationship between cause and effect > is obvious to all; - Complicated, where the relationship between > cause and effect requires analysis and/or the application of expert > knowledge; - Complex, where the relationship between cause and effect > can only be perceived in retrospect; - Chaotic, where there is no > relationship between cause and effect - Disorder, where the type of > causality is unknown. Each domain needs a different approach. In the > complex domain the approach is Probe, Sense, Response, or run > multiple safe-to-fail experiments simultaneously and see how the > system responds. > > Pharo is well-suited to doing experiments and prototyping. > > It offers fast feedback with instantaneous compilation of the > currently edited method, optionally running an autotest on the > changed code. > > The system contains all the source code of all the tools, and they > are designed to be quickly customizable by the individual developer. > A stated goal is to be able to build a custom tool in 10 minutes. > > Pharo immerses you in a sea of objects and provides you with lots of > different ways of looking at them. The late binding allows > manipulating these objects at runtime, even modifying the runtime > stack. > > Real Options (4) provides a decision model based on - Options have > Value - Options Expire - Never commit early unless you know why > > Pharo embraces this model. Code is compiled as late as possible, in > the running system. This makes it possible to use information > available only then to customize behaviour > > Behaviour is triggered only by message passing, and the receiving > object decides what to do with a message. Sending an object a message > it does not understands is caught at runtime and can be dealt with in > several ways. It makes it easy to create proxies and can be used to > learn objects new behaviour. > > Debugger-Driven-Design is an approach unique to smalltalk systems. It > makes it possible to design the way objects communicate while > implementing it. It supports a superior way of doing test driven > development. > > Small is Beautiful (5) is something that is very much applicable to > software. Software systems suffer from diseconomies of scale. > > Pharo uses a very simple and orthogonal language, using a very small > set of constructs. This reduces the cost of building custom tools > and makes it possible to cost-effectively provide such an advanced > environment. The systematic refactoring applied over many years pays > off in a very "dense" library that makes it possible to solve > problems writing a very low number of lines of code. > > The state of the art in mainstream software development to battle > complexity is reuse at the application level, building systems out of > large-grained components (database, web server). > > Pharo supports reuse at a much lower granularity. It has lots of > small domain specific languages to deal with specific problems. > Because smalltalk has so little syntax and supports fluent > interfaces, these languages support describing problems and their > solutions in a language near to that of the domain expert. > > All software development environments support programming yourself > into a corner. Making decisions that turn out to be bad is > inevitable when building complex systems. Being able to program > yourself out of that corner again makes it possible to approach a > problem without fear. > > Pharo offers easy meta programming and a code rewriting engine to > help undoing bad design decisions and and cleaning up large amounts > of code in a controlled way. > > The choices made by the Pharo project put it on the left hand side on > the value chain map (6). suitable for innovation, focusing on > effectiveness instead of efficiency. > > Pharo is an open source project, supported by the Pharo Consortium. > It is both a research vehicle and a platform for commercial software. > We use continuous integration to make sure that the innovations from > research don't destabilize commercial developments. Next week we hope > to release Pharo 4, and in a few months the much faster new "Spur" vm > with support for 64 bits. > > This was an introduction presentation for the Devnology workshop of > April 1. 2015. Devnology is a Dutch group of people interested in > improving software development, organizing a monthly meetup. > > (1) Gary Klein (1999) Sources of Power: How People Make Decisions. > > (2) @meekrosoft, Mike Long (Long Life Software), 2013, Cleaning Code > - Tools and Techniques for legacy restoration projects > > (3) Dave Snowden http://cognitive-edge.com/ > > (4) Chris Matts and Olav Maassen, Committment, the Book. Expands on > the ideas articulated by Kent Beck in "Extreme Programming Explained, > Embrace Change" http://commitment-thebook.com/ > > (5) E.F. Schumacher, (1973) Small is beautiful: A Study of Economics > As if People Mattered. > > (6) Simon Wardley, http://blog.gardeviance.org/ > > >

April 7, 2015

Re: [Pharo-users] pillar internal link

by Dmitri Zagidulin

Thanks, Cyril! We bumped into the internal link (with label) limitation, too, in Updated Pharo by Example ( https://github.com/SquareBracketAssociates/UpdatedPharoByExample/issues/10#… ). So, +1 interest to that feature, here :) On Tue, Apr 7, 2015 at 11:03 AM, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > Hi ! > Inter-File link are on the TODO list of pillar. Currently you can't. > I'm working on Pillar now, if i add inter-file link i'll say it to you ! > > On 7 April 2015 at 16:45, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> Hi, >> >> how does one add an internal link? >> I have chapter 'Framework' (and file 'Framework/Framework.pillar') and >> 'Palette' (and file 'Palette/Palette.pillar') >> >> Can I in Framework.pillar write something like *Palette/Palette* to >> create a link? >> Currently it fails at >> >> *** Warning: PRReferenceNotFound: Can't find anchor named >> 'Palette/Palette' >> >> Thanks, >> Peter >> >> > > -- > Cheers > Cyril Ferlicot >

April 7, 2015

Re: [Pharo-users] Devnology presentation slides

by Stephan Eggermont

On 02/04/15 23:18, Stephan Eggermont wrote: > Diego and I presented Pharo at the Devnology meeting in Arnhem. > > http://www.slideshare.net/StephanEggermont/pharo-devnology20150401 And a narrative: Pharo, the Immersive Programming Experience Why do we choose to use Pharo? We feel that Pharo provides the best way to combat complexity in software development. As long as the number of software developers paid to make software smaller and throw away code is a lot smaller than the number of developers paid to add code, the software we deal with on a daily basis will continue to grow. This inevitably leads to an increase in the complexity of the systems we build. This complexity is problematic because decision making in difficult situations is biased (1), using first fit heuristics instead of best fit. An interesting observation (2) is that successful software tends to have technical debt. If a software system is successfull, the market pressure to deliver more and faster than technically advisable is difficult to resist. When growing very fast, it can make sense to make choices that enable short-term growth that will need refactoring later. Additionally, an architecture that is optimal for a small system is not ideal for a large system and vice-versa. So, what can we do? There are several interesting models dealing with complex software systems. Let's check a few of them, and see what Pharo has to offer there. The Cynefin framework (3) categorizes the problem space into 5 domains: - Obvious, where the relationship between cause and effect is obvious to all; - Complicated, where the relationship between cause and effect requires analysis and/or the application of expert knowledge; - Complex, where the relationship between cause and effect can only be perceived in retrospect; - Chaotic, where there is no relationship between cause and effect - Disorder, where the type of causality is unknown. Each domain needs a different approach. In the complex domain the approach is Probe, Sense, Response, or run multiple safe-to-fail experiments simultaneously and see how the system responds. Pharo is well-suited to doing experiments and prototyping. It offers fast feedback with instantaneous compilation of the currently edited method, optionally running an autotest on the changed code. The system contains all the source code of all the tools, and they are designed to be quickly customizable by the individual developer. A stated goal is to be able to build a custom tool in 10 minutes. Pharo immerses you in a sea of objects and provides you with lots of different ways of looking at them. The late binding allows manipulating these objects at runtime, even modifying the runtime stack. Real Options (4) provides a decision model based on - Options have Value - Options Expire - Never commit early unless you know why Pharo embraces this model. Code is compiled as late as possible, in the running system. This makes it possible to use information available only then to customize behaviour Behaviour is triggered only by message passing, and the receiving object decides what to do with a message. Sending an object a message it does not understands is caught at runtime and can be dealt with in several ways. It makes it easy to create proxies and can be used to learn objects new behaviour. Debugger-Driven-Design is an approach unique to smalltalk systems. It makes it possible to design the way objects communicate while implementing it. It supports a superior way of doing test driven development. Small is Beautiful (5) is something that is very much applicable to software. Software systems suffer from diseconomies of scale. Pharo uses a very simple and orthogonal language, using a very small set of constructs. This reduces the cost of building custom tools and makes it possible to cost-effectively provide such an advanced environment. The systematic refactoring applied over many years pays off in a very "dense" library that makes it possible to solve problems writing a very low number of lines of code. The state of the art in mainstream software development to battle complexity is reuse at the application level, building systems out of large-grained components (database, web server). Pharo supports reuse at a much lower granularity. It has lots of small domain specific languages to deal with specific problems. Because smalltalk has so little syntax and supports fluent interfaces, these languages support describing problems and their solutions in a language near to that of the domain expert. All software development environments support programming yourself into a corner. Making decisions that turn out to be bad is inevitable when building complex systems. Being able to program yourself out of that corner again makes it possible to approach a problem without fear. Pharo offers easy meta programming and a code rewriting engine to help undoing bad design decisions and and cleaning up large amounts of code in a controlled way. The choices made by the Pharo project put it on the left hand side on the value chain map (6). suitable for innovation, focusing on effectiveness instead of efficiency. Pharo is an open source project, supported by the Pharo Consortium. It is both a research vehicle and a platform for commercial software. We use continuous integration to make sure that the innovations from research don't destabilize commercial developments. Next week we hope to release Pharo 4, and in a few months the much faster new "Spur" vm with support for 64 bits. This was an introduction presentation for the Devnology workshop of April 1. 2015. Devnology is a Dutch group of people interested in improving software development, organizing a monthly meetup. (1) Gary Klein (1999) Sources of Power: How People Make Decisions. (2) @meekrosoft, Mike Long (Long Life Software), 2013, Cleaning Code - Tools and Techniques for legacy restoration projects (3) Dave Snowden http://cognitive-edge.com/ (4) Chris Matts and Olav Maassen, Committment, the Book. Expands on the ideas articulated by Kent Beck in "Extreme Programming Explained, Embrace Change" http://commitment-thebook.com/ (5) E.F. Schumacher, (1973) Small is beautiful: A Study of Economics As if People Mattered. (6) Simon Wardley, http://blog.gardeviance.org/

April 7, 2015

Re: [Pharo-users] Eating your own dog food (Site/Blog)

by garduino

philippeback wrote > On Tue, Apr 7, 2015 at 9:28 AM, Yuriy Tymchuk < > yuriy.tymchuk@ > > wrote: > > I think http://www.samadhiweb.com/blog/ is using a Smalltalk engine. But I > do not know if it is public. > > Phil > >> Uko >> Good catch! >From the about page: This blog began life as a set of static pages, generated by a home-grown content management system written in Smalltalk, imaginatively called SmallCMS1. Since April 2012, SmallCMS1 has evolved into serving content dynamically, to support tag linking like this: sqlite. Is SmallCMS1 published somewhere? -- View this message in context: http://forum.world.st/Eating-your-own-dog-food-Site-Blog-tp4817960p4818131.… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 7, 2015

Re: [Pharo-users] Eating your own dog food (Site/Blog)

by Stephan Eggermont

On 07/04/15 10:28, Yuriy Tymchuk wrote: > if I want to create a site/blog in pharoâ¦ What do I use? I know that there is Pier, >but when you check its webpage, the last update is in 2011. >Pharo website is built with Marina, but when I check the repo, >the last commit was done by me and it was 2 month ago. >Will Marina continue to evolve? And is anyone else using Marina? Pier is on CI, and just works. Once in a while something breaks and then we fix it. The PierAddons are also on ci, but are less used. Diego published how to use Bootstrap with Pier on the mailing list. That post might be hard to understand, Pier is very elegant but complex. Stephan

April 7, 2015

Re: [Pharo-users] Updating ZeroConf! Please do not use it until new advice!

by Sven Van Caekenberghe

Good work, thanks. > On 07 Apr 2015, at 17:24, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > okâ¦ success :) > now, this is the change: > > from now, each version is married with one vm. > > so, if you download /30+vm it will download the Pharo30 image with its corresponding "vm30" > > which means some links do not have sense anymore: > > /vm > /vmLatest > > but you have > > /vm12 > ... > /vm20 > /vm30 > /vm40 > /vmLatest40 > > the concept of âlatest vmâ is also now married to development imageâ¦ while an image is being developed (40 now, 50 next week), it will have a âlatestâ vmâ¦ but once releases, release will come with a âblessedâ vmâ¦ the one is good for you to use. > > of course, that does not means vmâs are not exchangeable, as usualâ¦ it means we are blessing one version of the vm to be used with one version of the image. > > Now, the vm will download just ONE source version (vm30 will download PharoV3.sources)â¦ so we can keep many version without bloating our downloads. > > Also, this prepares us to future non compatible VM versions (like Spur), so is a good change. > > I hope it is clear for you :) > > cheers, > Esteban > > > >> On 07 Apr 2015, at 16:56, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> Ok, retrying. DO NOT USE THEM! >> >> Esteban >> >>> On 07 Apr 2015, at 16:20, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> ok, you can use it now. Update failed and I need to leave for half na hourâ¦. I will retry later. >>> >>> cheers, >>> Esteban >>> >>>> On 07 Apr 2015, at 16:03, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> >>>> thatâ¦ we need to change it :P >>> >> > >

April 7, 2015

Re: [Pharo-users] Metacello GIT methodProperties.json

by Thierry Goubier

Hi Peter, Le 07/04/2015 17:39, Peter UhnÃ¡k a Ã©crit : > Hi, > > are "methodProperties.json" files needed? No. > Every time someone makes even small changes it is accompanied by ten > times more json file changes which is a mess. Yes, it creates quite some noise on the git logs and diffs. > So is it needed with git? Cannot the information be retrieved from git > commits? It is not needed for git. GitFileTree retrieves the information via the git logs. But, if we remove it entirely, then the repository won't be usable by filetree. So GitFileTree keeps writing that metadata to stay compatible. Thierry

April 7, 2015

Metacello GIT methodProperties.json

by Peter UhnÃ¡k

Hi, are "methodProperties.json" files needed? Every time someone makes even small changes it is accompanied by ten times more json file changes which is a mess. So is it needed with git? Cannot the information be retrieved from git commits? Thanks, Peter

April 7, 2015

Re: [Pharo-users] Eating your own dog food (Site/Blog)

by Dmitri Zagidulin

You may also want to take a look at PillarHub ( http://smalltalkhub.com/#!/~mikefilonov/PillarHub ) CMS. On Tue, Apr 7, 2015 at 5:05 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > On Tue, Apr 7, 2015 at 9:28 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > wrote: > >> Hi, >> >> if I want to create a site/blog in pharoâ¦ What do I use? I know that >> there is Pier, but when you check its webpage, the last update is in 2011. >> Pharo website is built with Marina, but when I check the repo, the last >> commit was done by me and it was 2 month ago. Will Marina continue to >> evolve? And is anyone else using Marina? >> >> I had a look, but there was too much unsupported tech in there. > > I think http://www.samadhiweb.com/blog/ is using a Smalltalk engine. But > I do not know if it is public. > > Phil > >> Uko >> >

April 7, 2015

Re: [Pharo-users] Updating ZeroConf! Please do not use it until new advice!

by Esteban Lorenzano

okâ¦ success :) now, this is the change: from now, each version is married with one vm. so, if you download /30+vm it will download the Pharo30 image with its corresponding "vm30" which means some links do not have sense anymore: /vm /vmLatest but you have /vm12 ... /vm20 /vm30 /vm40 /vmLatest40 the concept of âlatest vmâ is also now married to development imageâ¦ while an image is being developed (40 now, 50 next week), it will have a âlatestâ vmâ¦ but once releases, release will come with a âblessedâ vmâ¦ the one is good for you to use. of course, that does not means vmâs are not exchangeable, as usualâ¦ it means we are blessing one version of the vm to be used with one version of the image. Now, the vm will download just ONE source version (vm30 will download PharoV3.sources)â¦ so we can keep many version without bloating our downloads. Also, this prepares us to future non compatible VM versions (like Spur), so is a good change. I hope it is clear for you :) cheers, Esteban > On 07 Apr 2015, at 16:56, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Ok, retrying. DO NOT USE THEM! > > Esteban > >> On 07 Apr 2015, at 16:20, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> ok, you can use it now. Update failed and I need to leave for half na hourâ¦. I will retry later. >> >> cheers, >> Esteban >> >>> On 07 Apr 2015, at 16:03, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> thatâ¦ we need to change it :P >> >

April 7, 2015