51 ms·

The Future Programming Manifesto

101 points by jashkenas 12y ago

mercurial 12y ago
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 12y ago
  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.
  - innguest 12y ago
    It looks like you're making a point that these things are all inherently complex. Isn't it more probable that the tools we have today are just inadequate to deal with those problems? And maybe they are still inadequate after all these years because our industry is very stubborn and doesn't learn from its mistakes? I see nothing complex about drawing interactive elements on the screen. Smalltalk with its Morphic interface offers a much richer and flexible GUI toolkit and that was out when, in the 60s? How many GUI toolkits have learned from those lessons? And Morphic/Smalltalk was cross-platform before Java, in ways Java isn't to this day. It seems to me what hampers evolution is the technology we choose (Java, C) and not the problem itself (drawing interactive elements on the screen). For anyone interested in this discussion I recommend Alan Kay's "The Computer Revolution hasn't happened yet": www.youtube.com/watch?v=oKg1hTOQXoY
    - mwcampbell 12y ago
      My point is that the inherent complexity of a UI toolkit is greater than many programmers realize. It's quite easy to implement your own UI that directly draws its controls on the screen and handles mouse clicks. Now, how are you going to make that accessible to blind users? Users with mobility impairments who can't use a mouse? How about right-to-left languages and non-Latin input methods? And there's probably more that I'm not aware of.
      - jamii 12y ago
        Thats true, but there is still plenty of incidental complexity. Poor layout languages with no composition, stateful manipulation of the ui, no way to express components. Tools like React.js and Apple's Auto Layout show that much of this complexity is not actually needed.
        mwcampbell 12y ago
        Agreed. I like the ideas behind React.js in particular.
  - vbit 12y ago
    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 12y ago
      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.
- bowlofpetunias 12y ago
  In which Y is usually prefaced with "micro"...
- sp332 12y ago
  This manifesto pushes back hard against step 2. If the software is getting complex, it's worthwhile to reconsider your approach. And if the problem really requires complex software, it's worth changing the environment to simplify the problem instead of writing complex software!
  - mercurial 12y ago
    > it's worth changing the environment to simplify the problem instead of writing complex software! No doubt there is a fair amount of architecture astronautics out there, but thinking you're going to turn complex problems into simple problems by "changing the environment" is most of the time extremely naive. You can push against reality all you want, but reality tends to push back.
    - sp332 12y ago
      "Reality is going to push back." It's a tradeoff, but experience has shown that fixing the problem without software will cause fewer headaches in the long run than fixing it with complex software.
      - mwcampbell 12y ago
        At the risk of belaboring the point from my other sub-thread... Suppose you've developed an application that has a graphical user interface. For the sake of simplicity, you rejected all of the overly complex GUI toolkits out there and rolled your own, with the assumption that all of your users can see what you're drawing on the screen. So you didn't implement your host platform's accessibility API (assuming you're running on a host platform with an accessibility API.) Now, a blind person needs to use your software. How do you fix that problem without software? Beyond that specific example, the point is that, as the GP said, trying to change the environment to eliminate inherent complexity is often not feasible.
        tree_of_item 12y ago
        Most of the complexity in these GUI toolkits is unrelated to accessibility or other "essential but non-obvious" features, so I don't think this is a good point.
- mattdeboard 12y ago
  I learned a great phrase over the weekend that perfectly applies to #2, "Chesterton's fence"[1]: "[the] intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it." In other words, that feeling when you realize that a thing you've rebuilt because you didn't like it was built that way for a reason. [1] http://www.chesterton.org/taking-a-fence-down/ http://www.chesterton.org/taking-a-fence-down/
franciscop 12y ago
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.
bowlofpetunias 12y ago
> "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 12y ago
  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
theonewolf 12y ago
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/0262691914 http://www.amazon.com/The-Sciences-Artificial-3rd-Edition/dp...
adamnemecek 12y ago
Of course, why hasn't anyone thought about that?! /s
joshdance 12y ago
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 12y ago
  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 12y ago
    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.
yalooze 12y ago
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...
- jamii 12y ago
  Programming Languages
- joshuacc 12y ago
  Programming language?
  - yalooze 12y ago
    Haha! Stupidly obvious indeed. Thank you both.
jamii 12y ago
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.html http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.ht...
- the_af 12y ago
  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.
mythz 12y ago
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.html http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.ht... [5] http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy
SomeCallMeTim 12y ago
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
- swannodette 12y ago
  Really now? Smalltalk the precursor to much of modern Object Oriented programming languages and development environments started off as a language project for children http://www.atariarchives.org/bcc1/showpage.php?page=61 http://www.atariarchives.org/bcc1/showpage.php?page=61. If that's the end result of mediocrity, our programming culture could use a whole lot more of that please.
- teamonkey 12y ago
  Game Maker and Unity are trying to make the full stack as easy and accessible as possible. The programming languages they use are part of that, but their chose of language is mostly a pragmatic balance between speed, power, familiarity for existing programmers and learning curve for newbies. I mean, Unity3D uses C# on top of .Net, which isn't at all what is described in the OP.
  - 12y ago
DanielBMarkham 12y ago
<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>
ilaksh 12y ago
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.
- cheery 12y ago
  You make it all sound so simple.
- NateDad 12y ago
  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.
electronvolt 12y ago
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 12y ago
  > 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.
tikhonj 12y ago
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
- ilaksh 12y ago
  You think that Edwards doesn't know the difference between simple and easy to learn/use? > 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! Why is that important? Why can't a tool be simple, expressive, easy to learn and easy to use? What studies do you site for your viewpoint? There has been a lot of research in this area. Please reference the research that supports your claim. Reason has been tried by Edwards and many other for decades. It hasn't worked.
ekidd 12y ago
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.
gtirloni 12y ago
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.
haberman 12y ago
> 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.
- AlexanderDhoore 12y ago
  In the case of Javascript, the performance came at great cost. Javascript engines are monstrously complex. The language might be "simple", but the implementation is not. Lua on the other hand is probably fast because it is simple. There aren't many other programming languages like that. (C and Scheme maybe?)
  - haberman 12y ago
    The Lua interpreter is among the fastest of languages in its class, but LuaJIT is also among the fastest JITs. I agree that a lot of this has to do with Lua being a simple language.
  - jamii 12y ago
    The lesson from both of these is that performance doesn't magically come from simplicity but it is enabled by simplicity. A complex system is always hard to optimise. A simple system may be easy to optimise. Building simple systems whilst keeping performance in mind is a delicate balancing act. Local optimisations tend to add complexity that may prevent later optimisations. Sweeping generalisations that reduce implementation complexity often inhibit later optimisation due to lack of information (eg http://lucumr.pocoo.org/2014/8/16/the-python-i-would-like-to-see/ http://lucumr.pocoo.org/2014/8/16/the-python-i-would-like-to...).
josephschmoe 12y ago
Natural language programming.
api 12y ago
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.
robotresearcher 12y ago
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.
bitwize 12y ago
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 12y ago
  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 12y ago
    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 12y ago
itazula 12y ago
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.
islon 12y ago
"Inessential complexity is the root of all evil" this should be the wallpaper of every programmer.

101 points by jashkenas 12y ago

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 12y ago
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.
- innguest 12y ago
  It looks like you're making a point that these things are all inherently complex. Isn't it more probable that the tools we have today are just inadequate to deal with those problems? And maybe they are still inadequate after all these years because our industry is very stubborn and doesn't learn from its mistakes? I see nothing complex about drawing interactive elements on the screen. Smalltalk with its Morphic interface offers a much richer and flexible GUI toolkit and that was out when, in the 60s? How many GUI toolkits have learned from those lessons? And Morphic/Smalltalk was cross-platform before Java, in ways Java isn't to this day. It seems to me what hampers evolution is the technology we choose (Java, C) and not the problem itself (drawing interactive elements on the screen). For anyone interested in this discussion I recommend Alan Kay's "The Computer Revolution hasn't happened yet": www.youtube.com/watch?v=oKg1hTOQXoY
  - mwcampbell 12y ago
    My point is that the inherent complexity of a UI toolkit is greater than many programmers realize. It's quite easy to implement your own UI that directly draws its controls on the screen and handles mouse clicks. Now, how are you going to make that accessible to blind users? Users with mobility impairments who can't use a mouse? How about right-to-left languages and non-Latin input methods? And there's probably more that I'm not aware of.
    - jamii 12y ago
      Thats true, but there is still plenty of incidental complexity. Poor layout languages with no composition, stateful manipulation of the ui, no way to express components. Tools like React.js and Apple's Auto Layout show that much of this complexity is not actually needed.
      - mwcampbell 12y ago
        Agreed. I like the ideas behind React.js in particular.
- vbit 12y ago
  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 12y ago
    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.
bowlofpetunias 12y ago
In which Y is usually prefaced with "micro"...
sp332 12y ago
This manifesto pushes back hard against step 2. If the software is getting complex, it's worthwhile to reconsider your approach. And if the problem really requires complex software, it's worth changing the environment to simplify the problem instead of writing complex software!
- mercurial 12y ago
  > it's worth changing the environment to simplify the problem instead of writing complex software! No doubt there is a fair amount of architecture astronautics out there, but thinking you're going to turn complex problems into simple problems by "changing the environment" is most of the time extremely naive. You can push against reality all you want, but reality tends to push back.
  - sp332 12y ago
    "Reality is going to push back." It's a tradeoff, but experience has shown that fixing the problem without software will cause fewer headaches in the long run than fixing it with complex software.
    - mwcampbell 12y ago
      At the risk of belaboring the point from my other sub-thread... Suppose you've developed an application that has a graphical user interface. For the sake of simplicity, you rejected all of the overly complex GUI toolkits out there and rolled your own, with the assumption that all of your users can see what you're drawing on the screen. So you didn't implement your host platform's accessibility API (assuming you're running on a host platform with an accessibility API.) Now, a blind person needs to use your software. How do you fix that problem without software? Beyond that specific example, the point is that, as the GP said, trying to change the environment to eliminate inherent complexity is often not feasible.
      - tree_of_item 12y ago
        Most of the complexity in these GUI toolkits is unrelated to accessibility or other "essential but non-obvious" features, so I don't think this is a good point.
mattdeboard 12y ago
I learned a great phrase over the weekend that perfectly applies to #2, "Chesterton's fence"[1]: "[the] intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it." In other words, that feeling when you realize that a thing you've rebuilt because you didn't like it was built that way for a reason. [1] http://www.chesterton.org/taking-a-fence-down/ http://www.chesterton.org/taking-a-fence-down/

franciscop 12y ago

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.

bowlofpetunias 12y ago

> "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 12y ago
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

theonewolf 12y ago

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/0262691914 http://www.amazon.com/The-Sciences-Artificial-3rd-Edition/dp...

adamnemecek 12y ago

Of course, why hasn't anyone thought about that?! /s

joshdance 12y ago

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 12y ago
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 12y ago
  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.

yalooze 12y ago

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

jamii 12y ago
Programming Languages
joshuacc 12y ago
Programming language?
- yalooze 12y ago
  Haha! Stupidly obvious indeed. Thank you both.

jamii 12y ago

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.html http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.ht...

the_af 12y ago
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.

mythz 12y ago

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.html http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.ht... [5] http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy

SomeCallMeTim 12y ago

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

swannodette 12y ago
Really now? Smalltalk the precursor to much of modern Object Oriented programming languages and development environments started off as a language project for children http://www.atariarchives.org/bcc1/showpage.php?page=61 http://www.atariarchives.org/bcc1/showpage.php?page=61. If that's the end result of mediocrity, our programming culture could use a whole lot more of that please.
teamonkey 12y ago
Game Maker and Unity are trying to make the full stack as easy and accessible as possible. The programming languages they use are part of that, but their chose of language is mostly a pragmatic balance between speed, power, familiarity for existing programmers and learning curve for newbies. I mean, Unity3D uses C# on top of .Net, which isn't at all what is described in the OP.
- 12y ago

DanielBMarkham 12y ago

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

ilaksh 12y ago

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.

cheery 12y ago
You make it all sound so simple.
NateDad 12y ago
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.

electronvolt 12y ago

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 12y ago
> 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.

tikhonj 12y ago

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

ilaksh 12y ago
You think that Edwards doesn't know the difference between simple and easy to learn/use? > 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! Why is that important? Why can't a tool be simple, expressive, easy to learn and easy to use? What studies do you site for your viewpoint? There has been a lot of research in this area. Please reference the research that supports your claim. Reason has been tried by Edwards and many other for decades. It hasn't worked.

ekidd 12y ago

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.

gtirloni 12y ago

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.

haberman 12y ago

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

AlexanderDhoore 12y ago
In the case of Javascript, the performance came at great cost. Javascript engines are monstrously complex. The language might be "simple", but the implementation is not. Lua on the other hand is probably fast because it is simple. There aren't many other programming languages like that. (C and Scheme maybe?)
- haberman 12y ago
  The Lua interpreter is among the fastest of languages in its class, but LuaJIT is also among the fastest JITs. I agree that a lot of this has to do with Lua being a simple language.
- jamii 12y ago
  The lesson from both of these is that performance doesn't magically come from simplicity but it is enabled by simplicity. A complex system is always hard to optimise. A simple system may be easy to optimise. Building simple systems whilst keeping performance in mind is a delicate balancing act. Local optimisations tend to add complexity that may prevent later optimisations. Sweeping generalisations that reduce implementation complexity often inhibit later optimisation due to lack of information (eg http://lucumr.pocoo.org/2014/8/16/the-python-i-would-like-to-see/ http://lucumr.pocoo.org/2014/8/16/the-python-i-would-like-to...).

josephschmoe 12y ago

Natural language programming.

api 12y ago

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.

robotresearcher 12y ago

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.

bitwize 12y ago

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 12y ago
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 12y ago
  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 12y ago

itazula 12y ago

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.

islon 12y ago

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