
The Future Programming Manifesto - jashkenas
http://alarmingdevelopment.org/?p=893
======
mythz
Nice to see another post addressing the biggest issue in Software Engineering
head-on.

This of course is nothing new - it's something Alan Kay has been telling us
for more than 3 decades [1], who also has an enlightening talk addressing the
biggest problem facing software engineering [2].

Before vanishing from the Internet node's Ryan Dahl left a poetic piece on how
"utterly fucked the whole thing is" [3].

Steve Yegge also has dedicated one of his epic blog posts to "Code's worst
enemy" [4].

More recently Clojure's Rich Hickey has taken the helm on the issue producing
his quintessential "Simple Made Easy" [5] presentation, explaining the key
differences between something that is "Easy", to something that is truly
"Simple".

[1]
[http://mythz.servicestack.net/#engineering](http://mythz.servicestack.net/#engineering)

[2] [http://www.tele-task.de/player/embed/5819/0/?iframe](http://www.tele-
task.de/player/embed/5819/0/?iframe)

[3]
[https://gist.github.com/cookrn/4015437](https://gist.github.com/cookrn/4015437)

[4] [http://steve-yegge.blogspot.com/2007/12/codes-worst-
enemy.ht...](http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html)

[5] [http://www.infoq.com/presentations/Simple-Made-
Easy](http://www.infoq.com/presentations/Simple-Made-Easy)

------
jamii
Some demonstrations of how simplicity can be pursued:

The Viewpoint Research Institute is trying to build an entire computing stack
in 20kloc -
[http://www.vpri.org/pdf/tr2010004_steps10.pdf](http://www.vpri.org/pdf/tr2010004_steps10.pdf)

The Berkeley Order-Of-Magnitude group reimplemented Hadoop and HDFS in a few
thousand loc whilst remaining api compatible and having similar performance -
[http://db.cs.berkeley.edu/papers/eurosys10-boom.pdf](http://db.cs.berkeley.edu/papers/eurosys10-boom.pdf)

Both efforts required questioning the assumption that the complexity of modern
systems reflects inherent complexity in the problem. That is the point of this
manifesto - to get such drastic improvements we have to step back and rethink
our entire approach to build software systems.

I suspect that a large part of the problem is the different response curves
for features and complexity. Adding a new feature for a little complexity
seems like a good trade. Thousands of people make that decision in their own
individual areas and suddenly the cumulative complexity falls off a cliff and
we can't handle it anymore. To get simplicity back we have to take a very
high-level view of the tradeoffs and demand much more power in return for each
unit of complexity we add.

EDIT "Programmers tend to overlook the fact that spring cleaning works best
when you're willing to throw away stuff you don't need." \- [http://steve-
yegge.blogspot.com/2007/12/codes-worst-enemy.ht...](http://steve-
yegge.blogspot.com/2007/12/codes-worst-enemy.html)

~~~
the_af
The example from the BOOM group is interesting! However, it's not clear they
are arguing for the same kind of "simplicity" than Jonathan Edwards.

The BOOM group seem to be using a Prolog variant, and their conclusions argue
for declarative, high-level programming languages (I didn't read the paper in
full; please correct me if I'm wrong!). But if you take a look at declarative
programming languages such as Prolog, or functional languages like Haskell or
OCaml (all languages which aim to make complex problems more tractable), this
is precisely what many programmers reject as "too complex". It doesn't help
that very often, "complex" is used as a synonym for "unfamiliar".

Here is another piece of the puzzle: in another post by John Edwards, he
claims simplicity led him to reject higher-order functions for the "simple"
language he is designing. But higher-order functions are a tool (not
necesarily a _simple_ tool) useful to reduce the complexity of code! It just
happens that a programmer unused to them must first learn about them before
becoming proficient with them.

So the trade-off between complexity and simplicity isn't so easy to define.

~~~
seanmcdirmid
> he claims simplicity led him to reject higher-order functions for the
> "simple" language he is designing. But higher-order functions are a tool
> useful to reduce the complexity of code! It just happens that a programmer
> unused to them must first learn about them before becoming proficient with
> them.

Higher-order functions, or higher-order anything (e.g. predicates) are not
complicated because they are unfamiliar, but are complicated necessarily:
HOFs, for example, indirect control and data flow, and now you have to think
2nd or 3rd order (hopefully not more) about what your code is doing!

Complexity is really just in the definition of "higher-order." It even shows
up directly in our tools for automatically reasoning about program behavior
(1st order is easier to deal with than 2nd or N-order). There is a reason 1st
order logic is so popular, not because people don't get higher-order logic,
but 1st order logic is easier to deal with. The problem is, of course,
expressiveness (you can't do much with a functional language that doesn't
admit HOFs).

~~~
the_af
I disagree that higher-order functions are "complicated necessarily". I
believe this is actually a side effect of people usually learning to program
using languages that don't support them. Weren't there success stories posted
here on HN about novices learning to program with functional languages without
difficulty?

It's not surprising you can do a lot with a programming language that doesn't
support HOFs (though, of course, there wouldn't be much point in calling it
functional) -- you can in fact do everything without them. The key issue here
is whether HOFs are a useful tool that, once learned, will help make the
complexity of the problem you're attempting to solve more manageable. I
believe they are, by helping with modularity and composability.

Even if learning to use more powerful tools is more "complex" (that is, it's
"easier" or "takes less time to get used to"), _once_ you master them,
presumably you're equipped to deal with the tasks you want to accomplish.

Maybe some power tools can be made easier to handle. This is a valuable goal.
But if your goal is to never make a tool that requires the user to be trained,
you're severely limiting yourself.

~~~
jamii
I think he is arguing that higher-order functions are more difficult to
learn/use than first-order functions because they require higher-order
reasoning. That's not to say that they aren't useful or that beginners can't
learn them, but just that they impose an overhead and it's worth exploring
alternative methods of reducing complexity that may end up having a lower
overhead.

> ...once you master them...

Arguments of this sort tend to assume that a) the learning time can always be
written off and b) that once you master a tool there are no more overheads. a)
is false in the case where the learning time is too long or simply not
available eg Joe Accountant may benefit from learning to program but he
doesn't have the time to spend years learning. b) is false in the case where
the abstraction is harder to reason about or makes debugging harder.

There is certainly an economic decision to be made here but it must consider
opportunity cost, cognitive overhead and maintenance overhead as well. That
decision doesn't always favour the slow-to-master tool.

It's like extolling the virtues of investing in an industrial nailgun to
someone who is just trying to hang a photo. Sure, the nailgun will make
driving in nails faster but the investment won't pay off for them.

------
mercurial
I'm all for simplicity, but often, programmers follow the same cycle:

1\. X is bloated, let's reimplement it under the name Y with all the fat
trimmed!

2\. Notice that the problem may be a little bit harder than originally
envisioned, start to add more and more features

3\. Y is impossible to distinguish from X

Not to say that sometimes you shouldn't cast down existing systems, but it's
often because the times have moved on (eg, Wayland vs X11).

I'll note that 1. is (involuntarily) in the same category as the discourse of
populist politicians who promise simple solutions to complex problems. I am
wary of both.

~~~
mwcampbell
Case in point: Notice that the web technology stack is really complex. So are
the native GUI toolkits on all mature platforms. And something like wxWidgets
that wraps all those toolkits is its own kind of complexity. "I know, I'll
implement my own beautifully simple UI toolkit and bind it to the core
graphics and input APIs on each platform." Congratulations; your beautifully
simple solution is going to be off limits to some users, because you haven't
handled accessibility, internationalization, etc. So some of that complexity
you wanted to avoid was necessary after all. But maybe we can still
categorically reject the web stack for applications that don't actually run in
a browser.

~~~
vbit
I think you are not stepping back far enough to look at the problem. Are you
actually suggesting the entire complexity of the current web-stack (html, css,
js and server side code) is essential to make web-apps?

~~~
mwcampbell
I wasn't clear. I know there's a lot of incidental complexity in the web
stack. But I'm afraid that some developers, in response to a stirring call to
simplicity such as this manifesto, will go too far, blissfully unaware that
some of the complexity of mature UI toolkits (not just the web stack, but also
the native toolkits of mature platforms) is actually necessary.

------
SomeCallMeTim
A Manifesto for Mediocrity.

Every few years someone comes up with the idea of making programming so simple
that anyone can do it. This is not new; the concept has been around at least
since the '60s. Look at some COBOL history:

"They agreed unanimously that more people should be able to program and that
the new language should not be restricted by the limitations of contemporary
technology. A majority agreed that the language should make maximum use of
English, be capable of change, be machine-independent and be easy to use, even
at the expense of power." [1]

Many attempts have been made to achieve this Silver Bullet. The examples that
get closest are things like GameMaker:Studio [2] or Unity 3d [3], which are
extremely domain-specific (for certain classes of 2d and 3d games,
respectively).

So you CAN create a _domain-specific_ language that anyone can use. But every
attempt to create a completely general purpose language that anyone can use to
do anything has failed -- or has ultimately (accidentally?) produced a domain-
specific language that solves the specific problems that the authors are most
familiar with.

[1] [http://en.wikipedia.org/wiki/COBOL](http://en.wikipedia.org/wiki/COBOL)

[2]
[http://en.wikipedia.org/wiki/Game_Maker:_Studio](http://en.wikipedia.org/wiki/Game_Maker:_Studio)

[3]
[http://en.wikipedia.org/wiki/Unity_%28game_engine%29](http://en.wikipedia.org/wiki/Unity_%28game_engine%29)

~~~
jamii
> But every attempt to create a completely general purpose language that
> anyone can use to do anything has failed

Excel is used by millions of people and powers large swathes of the worlds
economy. VB6 is still in use today and powers multi-million dollar companies
([http://msdn.microsoft.com/en-
us/magazine/jj133828.aspx](http://msdn.microsoft.com/en-
us/magazine/jj133828.aspx)). COBOL still lurks in the heart of many banks.

These systems have problems that cause untold economic damage. Instead of
improving the tools to help people avoid these problems we sit around being
smug about our uber-programming skills and declaring that programming is too
complex for those people anyway. What many people here don't seem to realise
is that the choice is not between the crappy VB6 app and a nicely architected
system built by a 'real' programmer, the choice is between the crappy VB6 app
and the same people doing the job manually.

Empirically speaking, given tools with an approachable learning curve many
people are capable of producing simple programs that make them more effective
at their jobs. Rather than lamenting that these people produce bad code we
should be improving the tools to lead them down the correct path.

~~~
the_af
I agree with some of what you say about the damage these tools have done (but
please note Excel is _not_ a general purpose language, which the parent post
was talking about, though it can be used to make pretty cool and surprising
things).

However, I don't think anyone is arguing that _nothing_ should be done about
it. Some of us would argue that something _must_ be done, but that the answer
is not necessarily simplification, especially simplification of the "make it
easy" kind.

Especially since, for many programmers, "simple" & "easy to learn" are
actually synonyms for "similar to something I'm already familiar with".

~~~
jamii
What most people seem to be arguing is either that the people currently using
Excel and VB6 should suck it up and learn a real language or that they
shouldn't be programming at all (I'm not saying you are, but this is the
general sentiment I encounter in eg
[http://developers.slashdot.org/story/14/07/09/131243/normal-...](http://developers.slashdot.org/story/14/07/09/131243/normal-
humans-effectively-excluded-from-developing-software)). There are number of
different spheres of programming with different requirements. For the sphere
of end-user programming (which Jonathan Edwards explicitly calls out in this
post) there are a huge number of people who have to choose between simple
tools which don't work well or complex tools that they don't have the time to
learn. This sphere has seen little change since the start of the millennium
(Excel is still the best option by far, for all its limitations). The OP is
arguing for efforts to close the gap and produce simple tools for their simple
needs.

~~~
sheepmullet
"What most people seem to be arguing is either that the people currently using
Excel and VB6 should suck it up and learn a real language or that they
shouldn't be programming at all"

And why is that such a problem? If you can handle excel and vba you can learn
to program. A lot of existing languages are easier to learn than excel+vba.

Excel is not easy to use if you want to do anything moderately complex. Even
after years of training all through school and in the workplace the average
user can't do much programmatically with it.

Excel solved the input/output problem, the availability problem, and the
business acceptability problem.

By that I mean business users were doing a massive amount of data entry and
data manipulation mainly in order to do simple calculations and view data
logically in tables. They did this without thought to automate but it made
automation 10x easier.

As a business grunt I can't just install python and start cutting code. If I
said "Hey boss I can automate this with python. It will only take me 2 weeks"
I've got no hope. For starters corporate IT wouldn't even let me install
python. But I can spend a month fiddling around in a spreadsheet to automate
the same task and my manager will be happy.

~~~
the_af
@jamii

> It's not just programming that is hard, it's editing, debugging, compiling,
> version control, packaging, deploying, upgrading etc. Existing tools give
> you a huge amount of flexibility and power (that most end-user tasks don't
> need) at the expense of a brutal learning curve.

Sure, I agree all of those steps are painful, and I think everyone here agrees
that anything that can improve them is welcome! At the same time, some of them
only exist in specific contexts. For example, is the guy writing an Excel
macro not bothered about version control because Excel is an easy-to-learn
tool that achieves simplicity, or because he isn't building something
collaboratively with a team of 5 other people, all working on the same task?

By the way, I read your article. I fully agree with this:

 _" Finally, environments can't be black boxes. Beginners need a simple
experience but if they are to become experts they need to be able to shed the
training wheels and open the hood. Many attempts at end-user programming
failed because they assumed the user was stupid and so wrapped everything in
cotton wool. Whenever we provide a simplified experience, there should be an
easy way to crack it open and see how it works."_

I'd add that they also need to be able to reach for the complex tools once
they've mastered the simpler ones.

~~~
jamii
I think you misunderstood my point somewhat. I'm not saying that Excel solved
the version control problem - far from it. Manual version control by emailing
copies of spreadsheets was identified as a major cause of errors in various
studies.

My point is that for end-user programming to work we need version control,
deployment, packaging etc to scale down as well as up. The software industry
has a tendency to fetishize scaling up and ignore scaling down.

Experienced professional programmers still struggle with git in their day-to-
day workflow ([http://www.sussex.ac.uk/Users/bend/ppig2014/13Church-
Soderbe...](http://www.sussex.ac.uk/Users/bend/ppig2014/13Church-Soderberg-
Elango-PPIG2014.pdf)). The average end-user has no chance. Even if the
underlying data model is something like git, the experience for the user needs
to be more like undo-tree or etherpad.

Excel smooths the learning curve for calculation/simulation - you can get
started by just putting in some numbers and learning a few basic functions. If
that's all you need, that's all you have to learn. I want to see the same pay-
as-you-go approach for all our tools.

------
haberman
> Build compelling simplicity and performance will come.

Python and Ruby are notable counter-examples to this.

Both Python and Ruby were designed primarily for human-friendliness, as this
essay advocates. Guido has described Python as "executable pseudo code". Matz
has said that the primary purpose of Ruby is to make programmers productive
and happy, and to design more for humans than for the machines.

People have tried to make the performance come. Python is well-loved which has
led to numerous attempts to accelerate it (Psyco, Unladen Swallow, PyPy). Many
of these efforts have made notable progress, but none have met the bar of
compatibility and performance necessary to displace the relatively slow
cPython. Ruby is getting faster, but it's still among the slowest compared
with its peers.

There are other languages where the performance _did_ come (JavaScript, Lua).
But this is in no way a given.

~~~
perfunctory
> Python and Ruby are notable counter-examples to this.

I beg to differ. You seem to imply that Python is a simple language. Quite the
contrary. Attempts to accelerate Python failed exactly because it's an
extremely complicated language. Same goes for Ruby and JavaScript.

~~~
perfunctory
> Python have a simple syntax

Python has a rather simple syntax indeed, but it has very complicated
semantics. `foo.bar` - syntactically very simple expression of the attribute
access has a mountain of semantics behind it.

> Given that Python and Ruby are both simple to learn and use (as users, not
> implementors), they are both simple by the definition given in this article.

Good remark. I still tend to disagree though. It's easy to learn and use a
very small _subset_ of the language. Not the whole language. Even then, it's
practically impossible to limit yourself to a certain subset. Not if you want
to use any python libraries.

------
electronvolt
I feel like this is a kind of naive approach that might work for some end user
programs, but isn't a good principle in general. Large/monolithic programs
like databases, operating systems, compilers, etc. all can benefit from added
overall complexity. (new data structures for storing data on disk, better
memory management and program separation, better/more aggressive
optimization+static analysis+etc.) You can argue that monolithic programs like
those should be broken down into smaller parts (they already are, though), but
in the end adding an R*-tree to a database allows you to do more types of
lookups efficiently and makes your program /better/.

The thing that no developer really benefits from is added state complexity.
But we've spent the last 30+ years coming up with ways to hide that kind of
complexity from a programmer. That's /why/ we have our programs and processes
divided into boxes (PL, OS, etc.) and /why/ we use things like higher level
languages instead of assembly, object oriented programming, and general data
hiding. On the other hand, it sounds much less sexy to say "People should do a
better job of following best practices, and a lot of the problems in our
industry are because people prefer to glue things onto existing code instead
of being willing to do a higher level restructuring of a code base when a new
need is established."

I'd agree that a lot of programming is not science. We shouldn't be treating
it as such. The harder parts of programming are an application of theoretical
mathematics (Dijkstra pointed this out years ago, and it's still true), but
very little of CS is 'science' the way something like physics or chemistry is
'science'.

~~~
jamii
> That's /why/ we have our programs and processes divided into boxes

[http://db.cs.berkeley.edu/papers/cidr11-bloom.pdf](http://db.cs.berkeley.edu/papers/cidr11-bloom.pdf)
\- by unboxing distributed systems we can statically predict whether a given
program is eventually consistent
([http://arxiv.org/abs/1309.3324](http://arxiv.org/abs/1309.3324) \- and
automatically add coordination protocols where necessary)

[http://db.cs.berkeley.edu/papers/dbtest12-bloom.pdf](http://db.cs.berkeley.edu/papers/dbtest12-bloom.pdf)
\- by unboxing distributed systems we can use static analysis to more
efficiently explore the space of message interleavings in unit tests

[https://infosys.uni-saarland.de/projects/octopusdb.php](https://infosys.uni-
saarland.de/projects/octopusdb.php) \- by unboxing storage, databases and
application-side queries we can treat the entire pipeline as a single
optimisation problem

[http://www.openmirage.org/](http://www.openmirage.org/) \- by merging the OS
box and the PL box we can improve performance and security for server
applications

I don't disagree with you exactly, but I would point out that a) boxes are a
mean of dealing with complexity - less complexity means we can have bigger
boxes and more opportunities for cross-layer optimisation b) the places we
have drawn those boxes are largely arbitrary and shift over time - the
existence of the boxes does not imply that we can't benefit by moving the
lines around or by merging some of them.

~~~
electronvolt
Interesting papers! I appreciate the links.

>a) boxes are a mean of dealing with complexity - less complexity means we can
have bigger boxes and more opportunities for cross-layer optimisation b) the
places we have drawn those boxes are largely arbitrary and shift over time -
the existence of the boxes does not imply that we can't benefit by moving the
lines around or by merging some of them.

I agree completely. However, the manifesto seems (to me) to advocate all-over
unification as the end goal, which I think is naive. I read it as "if a
program needs to be divided into separate boxes, perhaps you need to make it
simpler", which to me seems like the wrong way to go about things.

~~~
jamii
Oh, I read it in context with:

> We should concentrate on their modest but ubiquitous needs rather than the
> high-end specialized problems addressed by most R&D

A lot of the things we do in programming give us power and flexibility at the
expense of increasing the learning curve: eg separate tools for version
control, compiling, editing, debugging, deployment, data storage etc. IDEs can
show all those tools in one panel but it can't change the fact that they were
designed to be agnostic to each other and that limits how well they can
interface.

My current day job is working on an end-user programming tool that aims to
take the good parts of excel and fix the weaknesses. We unify data storage,
reaction to change and computation (as a database with incrementally-updated
views). The language editor is live so there is no save/compile step - data is
shown flowing through your views as you build them. We plan to build version
control into the editor so that every change to the code is stored safely and
commits can be created ad-hoc after the fact (something like
[http://www.emacswiki.org/emacs/UndoTree](http://www.emacswiki.org/emacs/UndoTree)).
Debugging is just a matter of following data through the various views and can
also be automated by yet more views (eg show me all the input events and all
the changes to this table, ordered by time and grouped by user). We have some
ideas about simplifying networking, packaging/versioning and deployment too
but that's off in the future for now.

Merging all these things together reduces power and flexibility in some areas
but allows us to make drastic improvements to the user experience and reduce
cognitive load. It's really a matter of where you want to spend your
complexity budget and how much value you get out of it. We think that the
amount spent on the development environment is not paying for itself right
now.

------
itazula
As an experiment, I took a few paragraphs and replaced the words "software",
"software and programming", "programming" with the word "mathematics" and
replaced the word "programmers" with "mathematicians":

Most of the problems of mathematics arise because it is too complicated for
humans to handle. We believe that much of this complexity is unnecessary and
indeed self-inflicted. We seek to radically simplify mathematics.

and

Much complexity arises from how we have partitioned mathematics into boxes:
<put various branches of mathematics here>; and likewise how we have
partitioned mathematics development: <put various phases here, from "Eureka"
moment to copy-editing of proof>. We should go back to the beginning and
rethink everything in order to unify and simplify. To do this we must unlearn
how to do mathematics, a very hard thing to do. (I paraphrased by replacing
the original "to" with "how to do".)

and

Revolutions start in the slums. Most new mathematics platforms were initially
dismissed by the experts as toys. We should work for end-users disenfranchised
by lack of mathematics expertise. We should concentrate on their modest but
ubiquitous needs rather than the high-end specialized problems addressed by
most R&D. We should take inspiration from end-user tools like <replace with
your favorite tools, like pen-and-paper, whiteboard, abacus>. We should avoid
the trap of designing for ourselves. We believe that in the long run expert
mathematicians also stand to greatly benefit from radical simplification, but
to get there we must start small.

------
ilaksh
If you've seen some of Edwards' work and listen to what he is saying about
aiming for non-programmers you may get an idea of how different his idea of
programming is from what most programmers do (I admit I am a traditional
programmer).

I think the problem is that the basic definition of programming relies on
editing textual and mainly static source code that describes processes at a
low level. As soon as you start to get away from that your tool by definition
is not a programming tool and therefore programmers don't want to be
associated with it.

Its a problem of a failure of imagination and worldview and a psychological
issue of insecurity. Programmers are like traditional wood workers who look
upon automated manufacturing with disdain.

Ultimately superior artificial general intelligence will arrive and put those
mainstream programmers with their overly complex outdated manual tools out of
work.

But programmers will hang on to their outdated paradigm until the end of the
human age. Which by the way is coming within just a few decades.

~~~
NateDad
I think you have a mistake in your analogy. We're more like mechanical
engineers drawing complicated CAD diagrams. It's just that we don't need a
whole factory to produce our product, because it's not physical. All we need
is a compiler and copy the bytes of the output.

There are 100 decisions every minute that need very complicated thought
processes to solve, this is as true in manufacturing as it is in software
development. Do you make this button out of plastic or metal? What _kind_ of
metal or plastic? How big should it be? Should it click or not? Does it have
multiple functions based on the state of the vehicle? Does it have a label?
Where does the label go? What does it say?

You could write this all into a spec, but the spec would end up being the same
as the CAD drawing / program. So you end up relying on the experience of the
engineer to make all the decisions without it all being 100% specced out.
Maybe it's a button on a top end Mercedes that gets pushed a lot, so it should
be metal to complete the feeling of luxury. Maybe it's a button on a mid-end
Nissan that gets pushed a moderate amount - make it a decent plastic, etc.

~~~
ilaksh
But we arent using CAD programs to develop software are we. Look at the tools
used to develop software and compare them to CAD programs.

------
tikhonj
This "manifesto", for lack of a better word, neatly exhibits the main problem
I have with so many efforts to "improve programming" of this style: they focus
on ease of learning as the be-all and end-all of usability. Coupled with the
unfortunate rhetoric¹, it left me with a negative impression even though I
probably agree with _most_ of their principles!

Probably the largest disconnect is that while I heartily endorse simplicity
and fighting complexity—even if it increases costs elsewhere in the system—I
worry that we do not have the same _definition_ of "simplicity". Rich Hickey's
"Simple Made Easy"² talk lays out a great framework for thinking about this. I
fear that they really mean "easy" and not "simple" and, for all that I agree
with their goals, that is not the way we should accomplish them.

How "easy" something is—and how easy it is to learn—is a relative measure. It
depends on the person, their way of thinking, their background... Simplicity,
on the other hand, is a property of the system itself. The two are not always
the same: it's quite possible for something simple to still be difficult to
learn.

The problem is that (greatly simplifying) you learn something _once_ , but you
_use_ it continuously. It's important for a tool to be simple and expressive
even if that makes it _harder_ to learn at first, since it will mostly be used
by people who have already learned it! We should not cripple tools, or make
them _more_ complex, in an effort to make them easier to learn, but that's
exactly what many people seem to advocate! (Not in those words, of course.)

So yes, incidental complexity is a problem. It needs addressing. But it's all
too easy to mistake "different" for "difficult" and "difficult" for "complex".
In trying to eliminate incidental complexity, we have to be careful to
maintain actual simplicity and not introduce complexity in other places just
to make life easier for beginners.

At the same time, we have to remember that while incidental complexity is _a_
problem, it isn't "the" problem. (Is there every really _one_ problem?)
Expressiveness, flexibility and power are all important... even if they make
things harder to learn. Even performance still matters, although I agree it's
over-prioritized 99% of the time.

Focusing solely on making things "easy" is _not_ the way forward.

¹ Perhaps it's supposed to be amusingly over the top, but for me it just sets
off my internal salesman alarm. It feels like they're trying to _guilt_ me
into something instead of presenting a logical case. Politics rather than
reason.

² [http://www.infoq.com/presentations/Simple-Made-
Easy](http://www.infoq.com/presentations/Simple-Made-Easy)

~~~
jonathanedwards
I've observed a definite correlation that people who like Hicky's simple/easy
framework don't agree with mine. Personally I don't find it useful because it
tries to separate knowing from doing.

I also seem to disagree with people who emphasize "expressiveness,
flexibility, and power". I think they are mostly a selection effect: talented
programmers tend to be attracted to those features, especially when they are
young and haven't yet been burned by them too often.

With such fundamental differences we can probably only agree to disagree.

~~~
swannodette
I don't think this manifesto and the simple/easy framework are even really
talking about the same things beyond the basic point around avoidance of
incidental complexity. I think both viewpoints outline worthy goals with
staggeringly different levels of scope. In the case of the manifesto there's
hardly anything actionable beyond doing lots of mostly messy research. I think
people find this frustrating, but so what? Lofty goals often arise out of the
conviction theres far too much momentum in the wrong direction. In contrast I
think the simple/easy framework is something a working programming can apply
to everyday tasks and while unlikely to result in a radical shift it may
perhaps bring some of us closer to seeing that even larger goals may be
possible.

------
DanielBMarkham
<brain dump> Complexity really is the enemy. A couple of thoughts:

\- In programming, our job is to move over the "complexity hump." We hear a
problem, we analyze it, we code it, then we simplify. Most really bad code
comes from programmers never pushing past the hump. They just slash away at
whatever problem is in front of them.

\- When we move past the hump, we push complexity off. Sometimes this is done
by abstraction, sometimes by a reduction in terms. In either case, our job is
to make the complexity go away. If we're still dealing with arcane issues a
month from now? We're not past the hump.

\- Many times we believe we've simplified a problem, only to have the
complexities jump out and bite us again later. That's why it's best to
"exercise your code" to make sure that your abstractions or re-organizations
will hold up in the real world. Use it in different contexts. When we don't
exercise our code enough, we get complexity debt. The old "works on my
machine" is now "works in these 12 cases I tried"

\- Every tool we pick up has some degree of complexity debt depending on how
much it has been exercised in various contexts. Stuff like *nix command line
programs? They rock. The reason they rock is because they have a billion
different scenarios in which they've been proven.

\- Most modern programming environments involve programmers plugging into x
number of tools, all of which have varying degrees of complexity debt. Many a
time I've watched a programmer walk down the "happy path" of using a tool or
suite. What a happy look! Then they realize they need something that's off the
happy path. So they've got to pull the source code, inspect the deployed
javascript, take a look at the IL, get a new patch, spend an hour on Google.
It's at this point that the tool/framework stops being a help and becomes a
liability.

\- For this reason, most tools and frameworks are actually liabilities instead
of assets. I think there are a lot of programmers that would be amazed at what
you can do in C, JSON, simple HTML, and Javascript.

</brain dump>

------
ekidd
This part seems really difficult to do well:

 _We should work for end-users disenfranchised by lack of programming
expertise. We should concentrate on their modest but ubiquitous needs rather
than the high-end specialized problems addressed by most R &D._

The single biggest win for end-users "disenfranchised by lack of programming
expertise" in the past 20 years was probably PHP, because all you really
needed to know was HTML plus a tiny smidgen of CSS, PHP and SQL. Anything else
could be cobbled together with help from StackOverflow. The results were a
mixed blessing: A lot of people built sites to suit their needs, but a lot of
those sites degenerated into pretty ugly hairballs. Before that, the biggest
win was probably Excel: The world runs on useful (but often buggy)
spreadsheets. I have nothing against these tools. They're important and they
fill a critical need.

Now compare a tool like Python: it's simple and it scales from novices to
experts. But it's mostly limited to programmers and scientists, and unlike
PHP, you actually need to learn some basic programming to use it in most
cases.

I like using tools designed for professional programmers. It's great if they
also work well for novices who are willing to learn a bit of programming. But
the stuff I build is a lot bigger than the typical amateur PHP website, and I
need tools for managing large amounts of complexity in my problem domain, and
for managing requirements that will change significantly over the course of
years.

------
franciscop
Highly recommended: Code Complete by Steve McConnell. A big part of the book
talks about how to reduce complexity, in the literal sense and by using
abstractions.

------
bitwize
A.k.a. the Suckless philosophy a.k.a. back in the day, the Unix/Plan 9
philosophy.

Unfortunately the market has shown that people vastly prefer ready-made,
comprehensive, integrated solutions to a loose kitbag of nice, simple,
composable parts out of which one might _build_ a solution. See: Outlook
(mail, contacts, and calendaring in one!) vs. Unix mail programs, many of
which didn't even have an editor built in but punted that to your $EDITOR. See
also, Apple's domination of everything. So you are going to see less and less
of the KISS priciple apply as the market demands more complexity for the sake
of making their lives easier. And this applies to open source too. Systemd is
evolving into a tightly-coupled mass that monitors and controls everything you
might monitor or control on a Linux system; and soon it will be everywhere.
There's also a whole generation of young programmers who do not understand
Unix and so reimplement it poorly in JavaScript.

~~~
jamii
The key quote from the OP is "Complexity is cumulative cognitive load".

From the point of view of an end-user, using Outlook is vastly simpler than
learning to program in order to cobble together their own solution out of
command-line tools with harsh learning curves. Even for a professional
programmer the tradeoff is pretty clear.

People only have so much cognitive capacity and so much time to live. Every
hour spent messing with configuration or customising behaviour has to be
weighed against the lifetime gain of that improvement (let alone the lifetime
cost of maintaining the custom solution as the environment changes).

That's not to say that I don't want software to be configurable and
composable, just that the cost of doing so with our current tools is too high
for most users.

~~~
mwcampbell
I think a crucial clarification here is the distinction between simplicity of
interface and simplicity of implementation, as pointed out in "The Rise of
Worse is Better". The components of a Unix system may individually have simple
implementations, but it adds up to a complex interface for the user.

~~~
jamii
Well said. That's the distinction that causes so much tension between
programmers and users - it's why we have this rift between unixy software
which is wonderfully composable but infuriating to use and windows/mac
software which is easy to use on the common path but refuses to talk to
anything else.

------
robotresearcher
The article seems to be cross with Computer Science in some way, while all the
points it makes are about software engineering. The last paragraph in
particular seems to be railing against something or other.

The manifesto declares boldly "we are not doing science". Right. This is
completely and trivially correct. No one thinks you are.

------
bowlofpetunias
> "Perhaps we can learn from the methodologies of other fields like
> Architecture and Industrial Design. This is a meta-problem we must address."

Something about history and being doomed to repeat it springs to mind.

~~~
SomeCallMeTim
The _entire concept_ of Design Patterns stems from a (largely failed) attempt
to create design patterns in architecture. [1]

So, yes.

[1]
[https://en.wikipedia.org/wiki/Pattern_%28architecture%29](https://en.wikipedia.org/wiki/Pattern_%28architecture%29)

------
gtirloni
It seems everybody is talking at a different level of abstraction. Reality is
complex so the closest you're to it, the more complex your code will be (e.g.
kernel supporting a zillion different hardware devices).

If the idea is to abstract even more in a simple and powerful way that more
people can create more/better software, go for it. But don't dream that all
that has been done until this day is complex because nobody cared about
simplicity at all. I'm not saying the complexity is completely unavoidable but
it takes a lot of work.

------
theonewolf
I would not say that we are not doing science.

I would rather say we are doing science of the artificial---which looks a lot
like design.

See the Sciences of the Artificial by Herb Simon (a true legend):

[http://www.amazon.com/The-Sciences-Artificial-3rd-
Edition/dp...](http://www.amazon.com/The-Sciences-Artificial-3rd-
Edition/dp/0262691914)

------
yalooze
What does the acronym 'PL' stand for in the sentence: "...partitioned software
into boxes: OS, PL, DB, UI, networking..."?

OS = Operating Sytem, DB = DataBase, UI = User Interface, PL = I can't work it
out but I'm sure it will be stupidly obvious once it's pointed out...

~~~
joshuacc
Programming language?

~~~
yalooze
Haha! Stupidly obvious indeed. Thank you both.

------
api
There's another thing that encourages complexity: vested interests. Once a
complex paradigm is established you'll have vendors with an interest in
maintaining or even increasing that complexity.

The corporate IT ecosystem is rife with this around areas like security and
network administration.

------
joshdance
Is Hypercard always mentioned in 'make programming easier' manifestos because
it was really easy or because we remember it nostalgically? I used it a few
times in school but can't remember much about it. Never really got into
programming in it much.

~~~
claystu
I used Hypercard for a solid year in high school. It was black-and-white and
ran on Macs that were old even for 1994, but you could do stuff that was just
awesome.

That was 1994--20 years ago--and my anatomy teachersomehow had a lab for
Hypercard computers. He had the entire class design animated anatomy
presentations that you still couldn't match today using 2014 mainstream
presentation software.

There's a lot of nostalgia in programming, but Hypercard was the real deal.

~~~
sirmarksalot
I think part of what made Hypercard so useful was that it made it really easy
to make one specific kind of application, which at the time was 90% of what
any single person could be expected to do by themselves. Most of the
"multimedia experiences" people were making and buying were basically
interactive slideshows, roughly as complex as a DVD menu. Hypercard made this
easy, and you knew before you started whether or not it would be a good fit
for your project. Under the covers, it was a Turning-complete language, but
I'd imagine trying to make anything more complicated than Myst would be really
painful. I suspect the developers of Myst probably ran into its limitations
before they were done.

I think the main obstacle nowadays is deployment. Back in the day, you'd have
Hypercard export a native application, and then copy it onto a disk that you
passed around. Nowadays, the expectation is that people can run it in a
browser, or download it from an app store. Web-based deployment means you have
to embed it in a website using Javascript, while app stores require setting up
a developer account, and building with complicated toolchains.

This isn't to say it definitively can't be done, just an explanation of why it
hasn't yet.

------
islon
"Inessential complexity is the root of all evil" this should be the wallpaper
of every programmer.

------
adamnemecek
Of course, why hasn't anyone thought about that?!

/s

------
josephschmoe
Natural language programming.

