Devnology presentation slides
Yesterday, Diego and I presented Pharo at the Devnology meeting in Arnhem. http://www.slideshare.net/StephanEggermont/pharo-devnology20150401 Stephan
Nice. Thanks, Doru On Thu, Apr 2, 2015 at 11:18 PM, Stephan Eggermont <stephan@stack.nl> wrote:
Yesterday,
Diego and I presented Pharo at the Devnology meeting in Arnhem.
http://www.slideshare.net/StephanEggermont/pharo-devnology20150401
Stephan
-- www.tudorgirba.com "Every thing has its own flow"
Hi stefan what were the reactions of the audience? Stef Le 2/4/15 23:18, Stephan Eggermont a écrit :
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
Thanks Stephan and Diego, Added to my zotero subcollection on Smalltalk/Pharo: https://www.zotero.org/groups/diseo_y_creacion_phd_msc_universidad_de_caldas... Cheers, Offray El 03/04/15 a las 16:35, Stephan Eggermont escribió:
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/
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/
On 07/04/15 18:52, Thierry Goubier wrote:
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.
That's a good addition, thank you Stephan
superb Le 7/4/15 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/
participants (7)
-
Offray Vladimir Luna Cárdenas -
phil＠highoctane.be -
Stephan Eggermont -
stepharo -
Sven Van Caekenberghe -
Thierry Goubier -
Tudor Girba