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/
