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/
