Devnology presentation slides

> Yesterday,
>
> Diego and I presented Pharo at the Devnology meeting in Arnhem.
>
> http://www.slideshare.net/StephanEggermont/pharo-devnology20150401
>
> Stephan
>
>
>
>

> On 03/04/15 19:30, stepharo wrote:
>> Hi stefan
>>
>> what were the reactions of the audience?
>
> We managed to make them think.
>
> We had a very small, and very knowledgable group,
> so we had lots of difficult and interesting questions
> and discussions.
>
> The thing that impressed them the most was the incredibly
> short feedback loop when doing debugger driven design,
> and the way you talk to your objects.
>
> We pretty much followed the slides with the exercises,
> having a short sample of each of the complexity reducing
> things we do in Pharo.
>
> Stephan
>
>
>

> 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/
>
>
>

> 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.

> 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/
>
>
>