16 ms·

Malleable Systems: Software must be as easy to change as it is to use it

• MaxBarraclough 7y ago
  This is just silly. No, a C++ compiler cannot be as easy to change as it is to use. Come on now.
  • amicin 7y ago
    Solution: make the C++ compiler harder to use!
  • saagarjha 7y ago
    I wouldn't go as far as to say it's (or should be) "as easy to change", but making compilers that allow for modification is not novel or unusual: Clang lets you load optimizer plugins written in C++, for example; Rust lets you write macros in Rust itself that give you access to the token stream, and Lisps, of course, are homoiconic.
  • rubiquity 7y ago
    I leave this for you without comment: http://nibblestew.blogspot.com/2020/04/your-statement-is-100-correct-but.html http://nibblestew.blogspot.com/2020/04/your-statement-is-100...
    • saagarjha 7y ago
      FWIW, I consider posting a link that has a title matching the point you're trying to make, without further clarification or constructive feedback, fairly lazy.
      • rubiquity 7y ago
        My effort matches that of the person I was replying to. But yeah overall a bit out of character for me. Extremely polarizing examples to deter something could be progress is a pet peeve.
        • saagarjha 7y ago
          When possible, I think it's nice to aim for something better than that. While brusque, I don't think I the comment was in bad faith, so I think it deserved better.
  • xkapastel 7y ago
    Of course it can. You can do pretty much anything you like with software as long as you have the vision. A plugin/extension architecture can certainly make modifying a compiler easy. What makes you think it can't?
    • MaxBarraclough 7y ago
      Except it doesn't work like that. Sensible architecture doesn't make compiler engineering trivial. Compiler engineering is a highly technical area of software engineering. Think an average C++ programmer could take an old C++ compiler like OpenWatcom and make the necessary improvements to make it comply with the latest C++ language standard? Not a chance, that would be the work of a lifetime. They might have a shot at making small contributions to a compiler, but they'd have to set their sights quite low. Another example might be operating systems. The abstractions offered by modern operating systems are terribly easy to use, but there's a high skills barrier to doing meaningful work on the kernel. Similarly, the average web developer stands little chance of making a contribution to V8 or WebKit. This strikes me as analogous to discussing whether it should be harder to design and build a car, than to drive one. I don't like to be uncharitable but I stand by my earlier choice of words: this is silliness. Difficult engineering fields cannot be made easy. I see that another commenter, 'gm', has done a good job expressing similar points.
  • wtetzner 7y ago
    For compilers that are written in C++, changing the compiler is using it. ;)
• tmikaeld 7y ago
  Eric Elliot would probably jump on this, considering his books and series https://medium.com/javascript-scene/composable-datatypes-with-functions-aec72db3b093 https://medium.com/javascript-scene/composable-datatypes-wit...
• mwcampbell 7y ago
  Sometimes malleability can backfire. By coincidence, just yesterday a friend of mine sent me this Joel on Software classic: https://www.joelonsoftware.com/2000/04/12/choices/ https://www.joelonsoftware.com/2000/04/12/choices/ Particularly relevant here is the part about the user who made their taskbar take up half the screen, making their computer unusable.
  • fjallstrom 7y ago
    20 year old article? still fantastic content. wow.
  • saagarjha 7y ago
    I disagree with the point made in that article: > Every time you provide an option, you’re asking the user to make a decision. The best-of-both-worlds is when you give users an option, and then you pick a sensible default for it. Some of the best options are the ones that 90% of people don't even know about, but the 10% that do can find when they need it. I can't tell you how many hidden "defaults" commands I have run that are not even exposed to the UI but make my life much, much nicer.
  • vsareto 7y ago
    Hah, you can still do that on Win10. I wonder why they even bother letting it go to half-screen?
    • mellow2020 7y ago
      Why not? Maybe I have a lot of monitors and want to dedicate a small one to a taskbar where I see the full pathname of each editor that has a file open. People who just randomly click things without even realizing they're clicking may just as well delete random files or worse, the taskbar taking up half the screen is about the most harmless consequence I can think of. If it's really such a worry, add a dialog that asks the user "are you sure you want this?" for anything "weird", with a checkbox to "never ask again". If people "accidentally" click that, too, that is really their problem.
  • cptnapalm 7y ago
• save_ferris 7y ago
  I agree with this in theory, but doesn’t this go against YAGNI, agile, etc.? In most commercial applications I’ve worked on, supporting every type of interop or integration would never fly from an iterative development perspective. Or perhaps I’m misunderstanding the thesis here.
• saagarjha 7y ago
  I don't think this is a very popular opinion, but for those shipping software, consider having at least one programmatic way to "monkey patch" it. These are things like a plugin API, dynamically linking it, or using a language with an exposed runtime–things that allow programmatic injection of code, so that users who really care about tweaking the tool can do so. It doesn't even take much effort, either: my text editor has no plugin interface, but one of the reasons I stick with it is because I can hook its calls to libc to customize some of the things I don't like. My preferred mail client happens to lack a certain entitlement that most people don't even know about and that enables an entire cottage industry of software for it. Browsers let you specify some JavaScript to run on each page and suddenly the balance of power on the web tilts significantly towards the user. Even (or especially) if your tool is open source, consider supporting such an interface: it's much nicer to add on to piece of software than fork it.
  • bem94 7y ago
    I agree that people would and do find such interfaces very useful in many of their programs and tools. Those with nefarious purposes find them extremely useful too. It's a lot of work to secure those interfaces against abuse.
    • saagarjha 7y ago
      This is why I believe it to be an "unpopular opinion" these days as most computing platforms move towards being more locked down and less extensible; for security or complexity reasons these kinds of things seem to get little love or are even axed completely. Usually, the hard part is not security per se, but identifying user intent. You want to come up with a process that ensures that the user who enables potentially dangerous interfaces knows what they are doing. Preventing the user from doing this entirely is an easy but fairly disappointing "solution" to this problem.
      • bem94 7y ago
        > Preventing the user from doing this entirely is an easy but fairly disappointing "solution" to this problem. For sure. And if individuals are happy with trading some security for some functionality/flexibility in their software, I'll support their right to make that choice. It gets more complex when the people affected by that choice aren't the people making the choice. Which is more likely in the case of network programs. > Usually, the hard part is not security per se, but identifying user intent. You want to come up with a process that ensures that the user who enables potentially dangerous interfaces knows what they are doing. Indeed. I'd add identifying developer intent to that as well. What functionality am I trying to enable v.s. what else am I actually enabling? Coming up with that process is the herculean task there.
• pjc50 7y ago
  Interesting to put this on the front page next to the "immutable infrastructure for mutable systems" one. The thing is, these drives pull in opposite directions. If it's easy to change it's easy to break, and changes drive entropically downwards as it's always easiest to make the quick and dirty change. Malleable systems are great for expert users, but can easily be turned into a ball of mud by a non-expert. Hence the popularity of Chromebooks. Security also enters into consideration. Anything that can be programmed can be attacked. Any program that reads external data is an attack surface. Look at the history of e.g. web browser extensions, and how they have become more and more locked down to prevent abuse by bad actors.
  • AnIdiotOnTheNet 7y ago
    On the other hand, malleable systems are responsible for enormous increases in the productivity of computer users. We may all hate kludgy excel spreadhseets with a nightmare of tangled hacky VBA code, but you see that sort of thing in a lot of businesses' critical workflow because that kinda of malleability by "untrained" users was invaluable in the earlier life of the business.
    • Jtsummers 7y ago
      It's still invaluable in highly locked-down office environments. It lets users automate things that they wouldn't be allowed to automate otherwise (needing a full development environment or the ability to run arbitrary executables or access to Powershell).
  • ereyes01 7y ago
    I can see immutable infrastructure and this concept working in a copy-on-write model. For instance, if a service is up and running, a modification can consist of duplicating the infrastructure so you have your own copy and then making the modifications. It localizes the change, and in theory keeps the original unmutated. I have no idea how this would work in practice. This manifesto seems to go against the grain in other ways, as I'm not sure how it can coexist the economic model of SaaS that has emerged. Also, as others have said, the security and UX implications are big concerns that threaten the feasibility of this idea.
• lerpapoo 7y ago
  open ended thinking on a framework level is basically R&D, many companies don't have money for R&D, they just need something to sell and get paid so you can get your next paycheck, but u can try and find a sugar daddy or live off of foodstamps for a few years and really put some thought into it lol.
• thesuperbigfrog 7y ago
  The Malleable software principles seem to be more of a "No Code" / "Low Code" wish list with some similarities to the Four Freedoms of the Free Software Foundation. >> "Software must be as easy to change as it is to use it" Easy is relative. I find command-line interfaces remarkably clear and easy to work with, but others might not agree with my opinions or preferences. How easy is "easy"? How do you know if software is easy enough? How can we fundamentally simplify the essential complexities of software development so that it is approachable by "the man or woman on the street"? What incentives do we have to do so? >> "All layers, from the user interface through functionality to the data within, must support arbitrary recombination and reuse in new environments" >> "If I want to grab a UI control from one application, some processing logic from another, and run it all against a data source from somewhere else again, it should be possible to do so." source: https://malleable.systems/mission/#2-arbitrary-recombination-and-reuse https://malleable.systems/mission/#2-arbitrary-recombination... If you have the software source code then this might be technically possible, but licensing restrictions may come into play. Short of the source code, the "no code" / "low code" software development pipe dream needs to become a reality and then become standardized to allow for component interoperability. It might be possible, but the question of incentives comes up again. If I were a company selling a production-quality "no code" / "low code" system, why would I make it interoperable unless I was trying to undercut a competitor? Compare to the FSF Freedom 1: "The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this." >> "Tools should strive to be easy to begin working with but still have lots of open-ended potential" How do you define or measure "open-ended potential" from the user standpoint? >> "People of all experience levels must be able to retain ownership and control" Does this imply some kind of built-in DRM or is it merely copyright and licensing? How would ownership and control be enforced? >> "Recombined workflows and experiences must be freely sharable with others" This nests pretty closely with the FSF Freedoms 2 and 3: "The freedom to redistribute copies so you can help others (freedom 2)." "The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this." How does this principle combine with the previous principle about retaining ownership and control? How is it different from copyright and licensing that is currently used? >> "Modifying a system should happen in the context of use, rather than through some separate development toolchain and skill set" Using software and building software are different activities that REQUIRE different knowledge and skill sets. This is roughly the equivalent of wanting to modify your car without understanding how the drive train or transmission work. If you do not understand the underlying natural laws that govern how something works then how can you expect to make changes that do what you want? Lack of understanding leads to cargo cult reasoning and magical thinking. >> "Computing should be a thoughtfully crafted, fun, and empowering experience" It depends on the person, but actually learning how computers work and how to program computers can be a fun and empowering experience.
• rwmj 7y ago
  This is describing Smalltalk and Lisp Machines?
• dustingetz 7y ago
  “Mission... reset the balance of power” Does any of the real economic activity want to reduce its power and influence? that’s the opposite of a startup
  • rektide 7y ago
    My guess is there's a lot of companies that would do very very well, if we opened up software & made it flexible. The entire era we live in/just left, the PC era, happened because of Adversarial Interoperability. Massive economic activity was created because "real economic activity" had "reduce[d] its power and influence", as PC-compatible systems emerged & created a robust, fast growing, competitive market place. Did IBM want to? No. But enough legal space was still there to allow companies to create. While IBM could patent inventions, they could not own the idea of an addition ops code to add two numbers. I'd content that the lack of Adversarial Interoperability, this low standard we've sunk to in software world, is holding back vast seas of economic activity. We cannot effectively build new better more interesting, systems, when each piece of software is a closed, inflexible box. We've got to open up to possibility again, just as PC-Compatible opened the doors of possibility that brought Very Large Scale Integrated circuits & systems to us all. Support Adversarial Interoparability. Support Malleable Systems. Support an open future where people can have meaningful interactions with machines & build meaningfully better ones. https://www.eff.org/deeplinks/2019/10/adversarial-interoperability https://www.eff.org/deeplinks/2019/10/adversarial-interopera...
• ddevault 7y ago
  This is something I like about Plan 9 (and I like basically everything about Plan 9). The entire OS's source code (the kernel, userspace, everything) is available at /usr/src and can be compiled and installed with these commands: cd / . /sys/lib/rootstub cd /sys/src mk install It takes about 5 minutes. Want to cross-compile for another architecture? cd / . /sys/lib/rootstub cd /sys/src objtype=arm64 mk install If you haven't tried Plan 9, you really ought to spend your next spare weekend messing around with 9front. http://9front.org/ http://9front.org/ No other technology you could spend your weekend with will have a larger impact on your way of thinking about computers than Plan 9 might.
  • qqii 7y ago
    Unfortunately I think plan9 only remains this way by keeping the people who use it small, being elitist and somewhat unwelcoming[0]. That's not to say I wouldn't also recommend spending a weekend messing around. I was recently having a conversation about the unix philosophy on reddit[1]. As nix and software built for nix became more and more mainstream it becomes harder and harder to keep with the unix philosophy and the philosophy of this post. [0]: http://fqa.9front.org/ http://fqa.9front.org/ [1]: https://youtu.be/XvDZLjaCJuw https://youtu.be/XvDZLjaCJuw
    • ddevault 7y ago
      The reading material is "unwelcoming" to discourage coming into it with any preconceptions. If you go into it trying to make it do $x, you'll have a bad time and send lots of annoying emails to the maintainers. If you come into it wanting to learn about it and derive an $x from your experience, you'll have a better time.
      • saagarjha 7y ago
        To be fair, a cat flipping me off and telling me to “go away” in the FAQ may lead to misunderstandings.
  • PaulDavisThe1st 7y ago
• aey 7y ago
  The unfortunate outcome is more yaml and less lisp or small talk :(
• duxup 7y ago
  I feel like I could spend infinite amounts of time coding and recoding to make things easy to change ... and not get anywhere / add a lot of unneeded abstraction. I've certainly run into plenty of hard coded narrow code that is brutal to change, but the changes I make are were probabbly not obvious to the guy who wrote the code in the first place.
• ChrisMarshallNY 7y ago
  I tend to design software in what I call a "layer cake" fashion. Lots of layers, with clearly defined domains, strict APIs, and each with its own project lifecycle. I also tend to "design with SDKs." I treat each module asn an SDK, which means that I pretend I don't know exactly how it will be used, and I use my "S.Q.U.I.D." methodology on it. https://littlegreenviper.com/miscellany/bluetooth/itcb-04/#squid https://littlegreenviper.com/miscellany/bluetooth/itcb-04/#s...
• iopeak 7y ago
  When I read the concerns addressed here I cannot help but think of the end user (not a developer per say). There is an entire category of EUSE products that try to accommodate these concerns, however fall quite short. We need to rethink the entire paradigm of development, define sectors that need specialized product concerns (embedded vs games vs cloud) and build holistic ecosystems around them. There are startups doing this, yet how to categorize these types of tools is still not established; therefore hard to point at.
• 0xDEEPFAC 7y ago
  In my experience, this line of thinking tends to lead to inefficient and hard-to-manage large projects based on languages which are convenient on a small scale. Cough Electron Cough https://medium.com/commitlog/electron-is-cancer-b066108e6c32 https://medium.com/commitlog/electron-is-cancer-b066108e6c32 I mean, what percentage of users are adept enough to change a program they use and then what percentage of them would even want to go through the trouble of doing it. Moreover, why should we go through all the hoops needed to encourage novice/non-programmers to modify things they don't really understand anyway. This seems like a solution/problem in search of a problem.
  • saagarjha 7y ago
    Nobody said you need to bundle a Chromium engine to make a program extensible.
  • danShumway 7y ago
    If you want to talk about text editors in that post, Emacs is wildly, almost obscenely configurable (I'm currently using Emacs as my Linux WM[0]). Vim has its own scripting language that you can use to write custom bindings and configs, and they can get similarly complicated. Sublime has a pretty good Python API. Even Nano can have its syntax highlighting extended. The extensibility of those systems are why they've stuck around. The composability of Vim's keybindings are why people keep reimplementing Vim modes in different pieces of software. If you don't like Electron, fine, but what does that have to do with building malleable systems? Can you name me any popular native text editor that's used for serious work and that doesn't support plugins? > Moreover, why should we go through all the hoops needed to encourage novice/non-programmers to modify things they don't really understand anyway[?] This is like asking why a programming language should have power-user features in it. I mean, by that logic why would anyone add pointers to a language like C? Pointers are hard, and most programmers aren't very good with them. Why go through the hoops needed to encourage programmers to use a memory model that most novices don't understand very well? If you design a system or program only for beginners and no one else, then only beginners will use it. Once they've matured, they'll leave so that they can find something else that meets their evolving needs. Good software design considers the entire life-cycle of how a user will interact with a program as they develop and learn new features. Many users will never get to the point where they'll want to program extensions themselves, but even they will often benefit from having extensions written for them by the surrounding community. [0]: https://github.com/ch11ng/exwm https://github.com/ch11ng/exwm
• bri3d 7y ago
  Wasn't this the idea of the 4GL and 5GL craze in the 1980s and 1990s?
• jshap70 7y ago
  title makes it justifiable for systems to both be hard to modify and difficult to use
• gatvol 7y ago
  The two aims of the argument are often at odds in my experience. You can generally have one or the other, seldom if ever both
• AriaMinaei 7y ago
  Alan Kay: It was kind of like what we have today, but better. It was a completely integrated system that was not made up of applications, but "objects'' that you could mix and match anywhere. You've got a work area and you can bring every object in the system and you just start: You've got every tool, you've got every object, and you can make new objects. It was programmable by end user, and it had the famous GUI. Larry Tesler: It was the first one that was graphically based–overlapped windows, a mouse, stuff like that. Adele Goldberg: It was very much a GUI demo. Dan Ingalls: I was scrolling up some text and Steve said, "I really like this display." Alan Kay: At that time, when text scrolled, it did so discreetly: So jump, jump, jump–like that. Dan Ingalls: And Jobs said, "Would it be possible to scroll that up smoothly?" Alan Kay: "Can you do it continuously?" Steve liked to pull people's chains. Dan Ingalls: Because it did look a little bit jerky, you know? Alan Kay: So Dan or maybe Larry just opened up a Smalltalk window and– Bruce Horn: –changed a few lines of code in Smalltalk, and in the blink of an eye it could do a smooth scroll. Alan Kay: And so it was like, "Bingo!" And so Steve was impressed but he didn't know enough to be _really_ impressed. The other Apple people just shit in their pants when they saw this. It was just the best, best thing I've seen. Dan Ingalls: I think that sort of blew Steve's mind. Certainly, just about anybody who worked on development systems responded really well to that particular demonstration. It really showed how the Smalltalk system could be changed on the fly and be extremely malleable in terms of stuff you could try out in the user interface. Alan Kay: On Smalltalk you could change any part of the system in a quarter of a second. These days it's called live coding, but most of the stuff today–and virtually everything back then–used compiled code, so your programming and editing and stuff like that was a completely separate thing. You had to stop the system and rebuild. Dan Ingalls: So you had a regular sort of programming environment sitting there in front of you with windows and menus and the ability to look at code and stuff. But the neat thing about it was that if you edited the code, it would actually change the code that you were running at that very moment. The object-oriented architecture made it really, really quick to make changes. Bruce Horn: Even today if you wanted to change something at the level of the operating system in MacOS or Windows, it's simply impossible unless they have decided to give you that option to smooth-scroll or not. It's simply impossible to get to the source code to do that unless you're an employee–and even then it would probably take six months to get that feature in. Whereas within Smalltalk, you pop up the menus, accept the change, and it's working right now. You can't even do that today. (from Valley of Genius: The Uncensored History of Silicon Valley)
• GuiA 7y ago
  A worthy mission, but if the best examples of it are emacs, HyperCard, and a bunch of academic papers no one wants to read (I say this as a former HCI academic :), the road ahead is long and arduous indeed. It’d be nice to see the authors of this manifesto make a small program (image editor, chat client, etc) that embodies the values they have in mind.
• hypfer 7y ago
  "a community space for those interested in redefining our relationship with software by dismantling the boundaries of contemporary applications." "the collective’s mission to get an idea of the revolution we’re working towards" It's an art project, isn't it? This needs to stop.
• CapriciousCptl 7y ago
  I see this and then I think of all the success of strongly opinionated things like Rails. Having one way to do things forces you to focus on what’s most important, make choices and get things done. It keeps you away from premature optimization and analysis paralysis. Yes, you could split things into 100 different pure pluggable microservices but should that really be where you put your resources at the beginning? To me, engineering and for that matter everything you do isn’t any doing things the perfect way— it’s about doing them the best way you can and moving on to the next problem. Some things work well together in a functional pipeline— Linux commands that do one thing for instance. EMRs are famously malleable too, for better or worse. But could you imagine being IT managing 1000 PCs all with slightly different versions of word processors or something like that?
  • denster 7y ago
    Here's a counter argument: In college (17 years ago) a professor once told me that databases largely outlive the apps that use them. Imagine a world [1] where IT manages data centrally, but users are free to interact with it how they best see fit? Would this kind of a world be better? (provided of course you have the right permission model & audit trail for modification) -- [1] Founder of https://mintdata.com https://mintdata.com, so I'm biased -- malleable systems are near and dear to our heart [2] Professor Franklin at UC Berkeley, if you're reading this, I am very sorry for not being the most attentive student :)
    • acomjean 7y ago
      That's kind of how we design my web applications. We store all the data in the database and the applications query the data/ process and return. We actually have multiple applications in various languages accessing the data (php, java, perl...). Its genetic data so a lot of tables are shared across our applications. Gene symbol lookup for example). When I started in this field I worked with Lotus Notes. Its actually a shared nosql database which users can create applications that query it as they see fit. I was clunky, but it could be effective in making custom team tools.
    • philote 7y ago
• mtraven 7y ago
  Should include some mention of Richard Gabriel's "Habitability and Piecemeal Growth", a really good essay on this topic from almost 30 years ago... https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf
• awinter-py 7y ago
  > software must be as easy to modify as it is to use interesting metric, reallllllly bad target
• austincheney 7y ago
  Does this article literally mean easy as in hire somebody else to do it for you or does it mean simple as a one step change? By no means is that clear from reading the post. This subject of easy versus simple is frustrating, angrily so. I frequently see people asking for things to make various software tasks more easy. When I see anybody ask for easier the only appropriate question is: How easy does it need to be?. The question isn't rhetorical, because I doubt (from experience with this issue) that the person asking for easy has any idea about what the end state of what that easy should comprise. Here is a real life example: At work there is a software component that has jQuery 1.x embedded and this failed an internal security audit. To solve for the audit failure version 1 of jQuery must be removed from this application. My first thought is to simply remove jQuery all together. You don't need it, but jQuery is easy. I was denied from removing jQuery, so I have to upgrade it. I upgraded jQuery and it breaks the application. I tried 3 different versions of jQuery Migrate and multiple versions of jQuery 2 and 3 and no luck. The application is broken. This quest for easy is wasting an absurd about amount of time, so far a week, and its still ongoing. Knowing this is absurd I took the initiative to simply remove jQuery. I removed the jQuery library (about 12000 lines of code uncompressed and about another 100 lines for AJAX prep in our application). I then added about 20 lines of code for standard XMLHttpRquest handling. The application works perfectly, but fails a code review. We must use jQuery. I tried to explain this to nondevelopers and couldn't do it in a way that empathizes with the need for easy, because at face value it seems irrationally absurd. No matter how I tried it always sounded stupid. So, instead I have learned to explain like driving a car. Imagine you are a professional driver. You have been driving professionally for 10 years and have quite the validated resume. You have experience driving sedans, limousines, trucks, and so forth. You can drive safe and fast. You come to the current client highly recommended. A transport service dropped off an extremely expensive super sports car at an import broker and you are required to drive it to the client. You hop into that driver's seat and are shocked to discover there is this weird stick thing in the middle console between the seats and 3 foot pedals. Remaining confident you put the keys into the ignition but the car doesn't start. You sit there for 10 minutes completely lost. You have never seen a car with 3 pedals or a weird stick between the driver and passenger seats. Clearly, the car must be broken. Never mind that somebody just pulled the car up to you and never mind that its a standard transmission, which is the default in most super sports cars. Obviously the car is broken. The best recommendation is to investigate the car for mechanical defects, swap out the manual transmission with an automatic and after $18000 and 3 weeks it will be ready to go. Easy, now any qualified driver can drive the car. Simple, conversely, is just putting your foot on the clutch while engaging the ignition. The car starts without delay and allows for greater speed and precision at no extra effort. As a web developer most of the software I encounter is easy and extremely fragile, but its certainly not simple. This is especially true when you out grow your giant framework.
• gm 7y ago
  I think it's a pipe dream. Non-experts making changes to a system an expert wrote will yield either: 1) very few little changes, such as changing the color of an item, etc. Or 2) disasters where it's better to throw away the changes and start over doing it "the right way". Just look at automobiles: They are malleable indeed. We've all probably seen pics of modifications of all types, from the hillbilly type VM bug/truck combination to the amazing Cobra replica that few can tell from the real thing. In all cases, the craftsmanship level (and budget) of the person doing the modification directly affects the quality of the result. And how many cars are there whose modifications simply failed and the car never hit the road again? The same in software. Give Annie in accounting the ability to modify the inventory system and you will have a disaster in your hands, especially if she does not know much about the architecture of the system and/or she's not a matter expert on inventory methods and procedures. In that case I'd much rather trust my company to a hard-to-change system than one where everyone can mess with and break it beyond repair. I think the false premise here is that non-experts can build on the work done by experts. And I'm talking about both experts in programming who built the system in the first place (ie, add shitty architecture on top of good architecture), and experts in the domain the system is solving. If you get a smart your developer who is a solid coder to make changes to the aforemetioned inventory system, he will probably break the system (at least in the edge cases), albeit with beautiful, readable code. I just don't see how it's possible unless the ability to expand the system is severely limited (ie, not a "malleable system").
  • denster 7y ago
    Whoa! What do you have against hillbillies? :) Jokes aside, imagine if Annie in accounting has the ability to define her own malleable tools, on top of a solid/robust system for centrally managing data? (version, backup, secure via IAM, etc) Or will we really be stuck writing procedural code for the next 20, 30, 50 years? -- [1] Caveat: chief hillbilly of https://mintdata.com https://mintdata.com here, where we think you really can have your cake (create expressive tools) and eat it too (centrally control, manage, and version your data) .
    • derefr 7y ago
      Sure, but that's not "modifying the original system" any more. That's taking the original system (original abstraction) as a fixed/static foundation, and then expressing things in terms of it. Which, I mean, if the tooling you've made is Turing-complete (Excel, Unix) then you can certainly say that the person working on top of your system is "programming"; but they're not programming your system. They're not writing plugins that interface with it on the same terms that its components interface with one-another (as you would be if you e.g. wrote your own POSIX shell utilities in C); they're trapped "above" that abstraction, in a sandbox, one from which they can only access the narrow subset of the API surface that you explicitly chose to expose to them. Let me put it this way: you can get pretty far using e.g. Postgres as a custom data platform, by defining custom functions and types. But at some point, you'll need to write a Postgres extension. There's a big difference between a system that makes it easy for someone who's not a professional programmer to work on top of it (PG functions/types) and a system that makes it easy for someone who's not a professional programmer to extend it (PG extensions.) I've not yet seen a constructive proof that the latter is even possible.
• throw1234651234 7y ago
  Our software always starts out as super-clean, easy to change, human-readable, etc. Then requirements change 100s of times, on a deadline, and that it's no longer a pinnacle of those qualities.
• hugozap 7y ago
  Complexity has to go somewhere. Because systems are just piles of abstractions and conventions "easy to change" is very relative. A compromise will always be required. A simplification here means pushing complexity somewhere else. What I think is a practical way to see it is to have a good match between your audience mental models and the system conventions.
  • kccqzy 7y ago
    > A simplification here means pushing complexity somewhere else. And it is a good idea to concentrate complexity on a few small pieces of software that only experts are contributing to. Think your typical web applications and databases: your app doesn't need to think about how data is laid out on disk and how on-disk indices are implemented; all of those complexities are pushed into the database. It's a good compromise.
• mrfusion 7y ago
  I always liked the extension system in browsers.
• oliverx0 7y ago
  This is the vision that Seliom, the startup I am working on, has. We are still too early and don’t have documentation to share, but the idea is to give business owners the power to easily change digitized processes in minutes.
  • aryehof 7y ago
    My question is: are processes the wrong focus? Given a complex problem domain (for example a payroll system), isn't a physical model of the problem domain itself better than an implementation of processes which are hard to determine and subjective in nature? Perhaps another way to put is to question the degree to which which a payroll system might be built on the back of a series of state machines that are often associated with business "processes". Perhaps such a complex problem domain is a bad example and it is intended to expose processes in some other context?
    • oliverx0 7y ago
      This is a great question. Our approach here is that there are certain processes that can be easily modeled and digtized, and others that are not. For those that are not (a complex payroll system), we aim to provide a more "informal" way of managing them. That is, there are a series of steps that need to be made, but you can collaborate on top of these steps in a more informal manner (by commenting, tagging people, uploading documents, etc). We have found that even in complex processes, there are steps that need to be followed. For the uncertain aspects of that process, it is best to just describe it at a very high level and use the informal collaboration I just described.
• chrischen 7y ago
  Functional programming to the rescue!
• oblib 7y ago
  Ok... I am a self taught "app maker". Not CS grad. Not a "software engineer". I use tools that other's here create to make apps. What they do is way over my pay grade but I can use well written and documented APIs, especially when some example code is supplied. I think I'm closer to the target this applies to. Compared to the folks who create something like jQuery or PouchDB.js, I'm a laborer working in the fields with the tools (APIs) they create and provide. What I do is more akin to a craftsmen than a "software engineer". I'm sure some of what I've made is pretty crappy from an engineering viewpoint. I struggle sometimes to get stuff to work. But I also make software that some people love using. It's a pretty low bar to learn how to use HTML, CSS, and even tools like jQuery, Bootstrap, and PouchDB.js. What you can make with them can be very useful, and very specific. And it can be fast and easy to make too. I guess what I'm trying to say is the bar is now low enough that we can start teaching others how to make apps as a trade skill.
  • denster 7y ago
    (!) This! First, big props for shipping stuff that people use. Second, I've [1] often compared 90% of what we do in software development to being highly trained baristas. Granted, this buys me little love from engineers & even less from Starbucks. To the point -- I think it's time we rise up & start to use more powerful tooling. Tooling that: 1) Lowers the barrier for who can author software (really, web-based interfaces that help us get stuff done, the way we want to accomplish a task) 2) Doesn't introduce more chaos (disparate data spread across 10 SaaS products, death by 1,000 spreadsheets by email or in Google drive, no centralized/secure/managed storage, etc) 3) Emphasizes that a superb user experience is table stakes for such tooling. Thoughts? -- [1] founder of https://mintdata.com https://mintdata.com here, so just a tad biased, take the above with a few pounds/kilograms of salt. [2] oblib -- DM me, we're happy to give you free access if you'd like -- the above wording just warms our collective hearts.
    • taurath 7y ago
      > highly trained baristas And its sort of an insult to training, since there is very little actual formal training. Over 95% of the processes I use in developing software and systems are ones I've learned on the job, not learned while learning to be on the job. An apprentice system would work extremely well with software development.
• m0zg 7y ago
  Been in the industry for 20+ years and never once have I seen anything remotely resembling what this manifesto describes. I've seen several attempts to go in this approximate direction, though, each ending in a disaster because what's described there calls for a drastic, "be all end all" over-design that either doesn't do anything useful at all (example: "zero code"), or is so complicated that nobody can figure out how to use it (example: one of the distributed systems frameworks I worked on at Google - very general, reusable and modular, but you'd need a PhD to even understand it conceptually). This seems to be written by someone who doesn't really know what they're talking about, but would like to "help" by "writing". Reminds me of this scene from "The Fifth Element": https://www.youtube.com/watch?v=CYHO7FRsQAA https://www.youtube.com/watch?v=CYHO7FRsQAA It's akin to looking down into a shaft of a coal mine and suggesting that miners should breathe fresh air and stay above ground, because what they currently do is not good for their health.
  • goatlover 7y ago
    Smalltalk, Lisp, Cedar, Emacs, Hypercard and Lotus Notes come to mind.
    • cosmotic 7y ago
      I'm sorry, how is emacs easy to use (as per manifesto)?
      • goatlover 7y ago
        There is a bit of a learning curve. I guess Hypercard and Lotus Notes would have be the easiest to learn. Maybe throw Excel in also since it can be used (or abused) for a lot of things.
        • scroot 7y ago
          Emacs never really got the "popular test" that something like Hypercard did at a very important time in the adoption of personal computing, probably because most normal personal computer users didn't have access to it. But what we do see from the Hypercard days is a completely different -- even opposite -- relationship of average people to their computing media than we have today. It's both a compelling demonstration of what's possible and what's been lost
• twelvechairs 7y ago
  I have thought about this for a long time. For me the meaningful change means it needs to work at the OS/GUI level. What people miss in this thread is there 2 kinds of complexity we deal with - one that is fundamentally understanding the field and a second that is understanding the complex tooling required to do things. The latter has been getting much more complex lately (frequently multiple programming languages and multiple software packages) and a good set of fundamental tools that can operate in a loose environment is absolutely a big thing to aspire to
• PaulDavisThe1st 7y ago
  We had a moderately long thread on the question of scripting versus "change the code" over on the ardour.org forums, starting with a post from me ... https://discourse.ardour.org/t/is-open-source-a-diversion-from-what-users-really-want/102665 https://discourse.ardour.org/t/is-open-source-a-diversion-fr... TLDR: i still don't know if most of our users would prefer a more scriptable application even if it was closed source.
• souprock 7y ago
  I do this. Just yesterday, I changed a large piece of software. I didn't have any source code for it. I think it may have been written in C++, but that didn't matter. I had the *.exe file, which was all I needed. I used IDA Pro to study the software. You could use Ghidra, Binary Ninja, or Hopper Disassembler. They are pretty similar. I used xxd and joe to modify the software. You could use dd and echo, or a proper hex editor. I found the function that was annoying me, practically causing the software to be malware. I inserted the bytes 33 DB (a XOR opcode) near the end of a function, then removed the bytes CC CC (alignment padding) from right after the function. I seem to have hit most of the points in that article. The big miss was the unreasonable dream of "all experience levels". That just won't ever be reality. Mastery of a disassembler is not a beginner skill.
• searchableguy 7y ago
  I don't agree with it. A good deal of complex software is abstracting away on existing complex systems that you run on. without understanding the underlying system, you can make guesses about what something is doing but that wouldn't be ideal always. For example, package management. Your package manager might verify the files, check for existing configuration, setup permissions, directories, do dependency resolution, and lot more. In practice, it is just package manager install something. How will you modify the package manager without understanding what exactly is it abstracting away from you?
• mntmoss 7y ago
  The question to reconcile in my mind: Malleable systems with reproducable builds. It's very easy to get your hands dirty with the bytes and add various assumptions and dependencies. Most "hack solutions" go in that direction. But reproducing the modification in some larger context changes the assumption: What if the dependency isn't there? What tends to make the system stable over the long term is the thematic assumptions: Certain broad goals that never shift, even as the specification does. I think that's the factor missing from having malleability itself as a goal. You already have it, that's software.
• renewiltord 7y ago
  Web user agents do this the best. You can run code in the console, delete elements, make that persist with an extension. And there you see the best outcomes and the dangers ("This is a browser feature intended for developers. If someone told you to copy and paste something here to enable a Facebook feature or "hack" someone's account, it is a scam and will give them access to your Facebook account.").
• mikejulietbravo 7y ago
  This would make a lot of sense for designing things around Web 2.0 - it's as easy to create content as to consume it. For software in general? This is insane. The key reason? Domain knowledge.
• shalabhc 7y ago
  This isn't about building software similar to what we currently have and just making it more end user configurable. This is about rethinking software so that end user malleability makes sense. What does such software even look like? We want some kind of end user modifiable artifacts, still contained within some constrained substrate. Think Minecraft or Excel - I can give you a spreadsheet to calculate some taxes, but you can then dig in, change the formulae, remix with other sheets, and so on. Most software is not like this - typically you get some pre canned views and switches, not a canvas of composition.
  • jcelerier 7y ago
    plenty of people use software such as Max/MSP, PureData to do exactly that
    • denster 7y ago
      The issue is that FBP (flow based programming) scales to a certain point of complexity. After that, it stops being more effective than a textual representation or (gasp!) even old fashioned imperative programming. As a result, we need new approaches for more powerful tooling that scales better along the axis of complexity (for the idea / thing we want to create)
  • denster 7y ago
    This is exactly what we built at MintData. [1] A new way to construct software by using a spreadsheet to define application logic, instead of today’s spreadsheets which breed chaos. “A canvas of composition” - I really like that phrase to describe this approach of re-mixable software creation and usage. —- [1] I’d add a link here, but I think folks below might be sharpening their pitchforks by now :D
    • qnsi 7y ago
      Dude pls with the spamming
• fakedrake 7y ago
  I miss vimperator :(
• hootbootscoot 7y ago
  You are right, let's make defibrillator firmware magic numbers into dynamic variables you can set from a numerical input element on a publically accessible web page. That'll learn 'em. ...or perhaps consider limiting the scope* of such advice... disclosure: I know nothing about defibrillator firmware, but I'll wager that it has no malloc nor any embedded javascript engines... *perhaps software intended to be modified or customized or modular etc.
• carapace 7y ago
  ATLAST by John Walker (circa 1991) https://www.fourmilab.ch/atlast/ https://www.fourmilab.ch/atlast/ > Atlast is an attempt to make software component technology and open architecture applications commonplace in the mainstream software market. It is both a software component which can be readily integrated into existing applications, providing them a ready-made macro language and facilities for user extension and customisation and, at the same time, it is a foundation upon which new applications can be built in an open, component-oriented manner. > Atlast is based upon the FORTH-83 language, but has been extended in many ways and modified to better serve its mission as an embedded toolkit for open, programmable applications. Atlast is implemented in a single file, written in portable C Some discussion: https://news.ycombinator.com/item?id=20570902 https://news.ycombinator.com/item?id=20570902 - - - - I think you would want something like Oberon or Smalltalk (Squeak, Pharo) or Jef Raskin's Cat[1], or even Emacs. (Secretaries were extending Emacs using Lisp in the 70's.) The thought occurs to me that OLPC didn't fail due to Sugar[2], eh? [1] https://en.wikipedia.org/wiki/Canon_Cat https://en.wikipedia.org/wiki/Canon_Cat [2] http://wiki.laptop.org/go/Sugar http://wiki.laptop.org/go/Sugar
• harikb 7y ago
  What is left out of this entirely is that “composability”, sometimes, comes at the cost of efficiency or user experience. Companies like Google try to create each new product fit within Google infra and then end up with a less intuitive product. The reason many startups succeed in creating better solution is that they don’t have the baggage of making things malleable and composable.
• luckycharms810 7y ago
  You are possibly doing better than most engineering teams if you can achieve this within your team. This takes a lot of empathy And trust from the writers of the software and the users. The teams that move the fastest are those that can use each other’s work. The teams that move the slowest are like government - each one re-writing the progress made by another as years go by with things mostly unchanged on the whole.
• conradev 7y ago
  This is my favorite take on “why” by Jay Freeman (saurik): https://www.youtube.com/watch?v=ReKCp9K_Jqw https://www.youtube.com/watch?v=ReKCp9K_Jqw
• kazinator 7y ago
  We are better at making software that is easy to change, than at making software that is easy to use. Look at most FOSS. :) When programmers are left to control the requirements (no product managers anywhere in sight), the program structure will be still reasonably maintainable and thus easy to change, as a matter of pride before other programmers, but the thing will be hard to use for non-programmers. "Oh, just give it --help and you will get the expected input language in crystal-clear EBNF ..." Software is malleable. Who is attributed with that famous "software is infinitely malleable" quote, in fact? Fred Brooks? Of course, Brooks believed that a program was "incompletely delivered" without source: "The dependence upon others has a particular case that is especially painful for the system programmer. He depends upon other people's programs. These are often maldesigned, poorly implemented, incompletely delivered (no source code or test cases), and poorly documented. So he must spend hours studying and fixing things that in an ideal world would be complete, available, and usable." (From Mythical Man Month)
• hburd 7y ago
  Software engineering is about solving real problems. The only time you need to write malleable software is when the problem needs a malleable solution. Pushing for everyone to write malleable software sounds like telling people to forget about the particular problems that they are solving, and telling them to solve a general problem instead. Now you’re writing a complicated system for general use, rather than a simple solution for a well-defined problem. Your solution will now take longer to develop, be harder to understand and MUCH harder to test properly (way more use cases). Obviously some problems need general solutions. But if every problem needed a general solution nobody would get anything done.
  • saagarjha 7y ago
    > The only time you need to write malleable software is when the problem needs a malleable solution. The point is that it’s very difficult to account for this beforehand, especially as the author of the software. (“What do you mean we should make this an option? 5 works for me, and I’ll change it in the code if it doesn’t!”) When designing software, it’s always nice to give a thought to “if I were using this and I wanted to change it, how would I do so?” and seeing if there’s anything you can do to improve that.
• _alex_ 7y ago
  this is all just a long con to try to convince everyone to integrate Guile
• mbrodersen 7y ago
  I must admit I laughed out loud reading this. The real world is complex. The problems software solve in the real world are complex. Economics, sales, politics, personalities, random world events, competition etc. has always and will always be a force pushing software development in non-ideal directions. In my experience, software that is twice as malleable takes four times as long to write, making you dog food for the competition. A better choice (again from experience) is to think like an Engineer: find the least cost good enough solution to the problem. Then implement it.
  • torgian 7y ago
    Agreed. The only place where software that the OP wants to create can reside is in the hobbyist community or free, open source community. In the real world this isn’t cost effective or viable. Just takes too long.
    • Silhouette 7y ago
      The only place where software that the OP wants to create can reside is in the hobbyist community or free, open source community. That was my instinctive reaction as well. Existing commercial models would not support this model of building software. I'm not sure most existing FOSS models would either. Whether this is a problem is a different question. Maybe the kind of software that is interesting to a large enough group of people for this idea to be relevant should be created and developed by the community of its users, collaboratively, over a long period of time, without financial gain being their main incentive to contribute. I think what the community behind this site is looking for is probably a form of social change more than technological change. There are lots of people out there who have the skills to contribute to software, and there are lots more people who might learn those skills given sufficient accessibility of the knowledge and awareness of the possibilities. Right now, it's just too difficult for the potential contributors to make actual contributions. I can think of many factors that play a part on that, but none that seems to be inherently impossible to overcome.
      • torgian 7y ago
• mbrodersen 7y ago
  The history of software is full of failed projects trying to make users into programmers. It simply doesn't work. Thinking abstractly/systematically about automating processes is a skill that is hard to learn, and customers are busy enough taking care of just running their business.
• rukuu001 7y ago
  Hey, this isn't completely bananas everyone. I can think of some examples of software that's like this now. Like Excel, BI tools, workflow tools etc. They don't cover all the requirements outlined in the article (like the bit about it being fun & easy to use), but we're a long way from this being 'impractical' or a 'pipe dream'. (edited for grammar)
• iLemming 7y ago
  This comment probably will be downvoted since it doesn't represent popular opinion. I think everyone who has chosen a career of a software developer sooner or later needs to seriously evaluate Lisp and Lisp dialects - Racket, Clojure, CL, Emacs Lisp, Fennel, etc. Lisp has certain qualities that most other languages don't (perhaps except for Smalltalk). I have personally learned, tried, and implemented working software in numerous different programming languages. I'm not trying to brag about it, that's not the point. The point I'm trying to make is the following: I've seen many programs - systems, small, medium, and of significant size, and honestly, only systems written in Lisp can give you this genuine feeling like you are dealing with a garden. Even in systems where things get incredibly messy, you still can organically keep growing them and keep adding more and extend existing stuff. They usually do not crumble under their weight. Take, for example, Emacs. Arguably it is probably the most extensible piece of software that humanity has ever created. It is wildly malleable. Things you can do with Eisp are borderline insanity; you can change things on the fly without even having to restart Emacs - sometimes, it feels like some sorcery. Last time I checked - I pull something over 400 hundred different packages in my configuration. And somehow things just work. Yes, from time to time, "abstractions start leaking," and things would break, but never to the point that it becomes completely unusable. Check out GitHub stats. Github alone contains an incredible amount of Emacs lisp. A language with one sole purpose - configuration. Basically, it is a glorified YAML for Emacs. And the people who wrote that code - most of them never had met each other. They have never worked in the same org. They didn't have to follow strict guidelines or standards. It is a messy, wild, and lawless world. Emacs ecosystem defies any logic. If you think about it - it should not work at all, yet it does. And it's been working for over 40 years. Many people. Some brilliant individuals every once in a while would claim: "Well, Lisp is just old. Give language X a few more years, and it gets the same and even better features..." And that's been going on for over six decades now. Ironically, almost every single language that is on top of TIOBE and RedMonk today, has borrowed many ideas from Lisp, except the most fundamental one. The concept of homoiconicity. The benefits of homoiconicity are incredibly underrated. You may dislike or even hate Lisp, but trust me, years later, when Python is no longer sufficient for our needs; when Java becomes too expensive to maintain; and Javascript transforms into a drastically different language - Lisp still would be used, and systems written in it would be thriving. Learn Lisp. It will make you a better programmer. That is guaranteed. Don't take my word for it. See what the world known CS experts have to say about it. Not a single one has ever said: "Lisp is a waste of time."
• b0rsuk 7y ago
  If software must be as easy to change as to use, then surely that means it's pretty easy to modify it by accident? Do we really want that?
• MichaelMoser123 7y ago
  Good luck! Are there any examples of this idea in action? I didnt find any references on the page. I think this idea has potential: take the bash shell as an example - it is a terrible programming language with one redeeming feature, execution tracing (set -x). Whenever i have to work with an unknown bash script i can turn on that option and see what it is doing. I think such a level of transparency is a first step towards the ideal of malleable systems.
• satanspastaroll 7y ago
  Complexity can only ever be moved, never removed. This means complex problems are impossible to make easy, only a single part of a problem can be swayed with equal or worse cost to others. This is best seen in abstractions; they make certain functions much easier to do on a routine basis, but they are less flexible than the functions they represent, and thus you end up with creating more and more abstractions, cases for them and at the end, end up with the same or more chaos than you had in the beginning. This results in what I'd say futile work being done trying to fight it without even realising. You can't do something complex with less, or it wasn't that complex in the first place. To make a truly malleable system, is to make a fractal, which is by definition impossible to solve. A problem(fractal) always requires a problem-area and accuracy in order to solve it, in that accuracy. There is _always_ an equal or worse tradeoff.
  • Mikhail_Edoshin 7y ago
    Abstractions in software are just that: we write a piece of code to do what we want to do and then we only supply parameters. Once we want to change what we are doing, we either have to go back to basics and come back with a new piece of code or somehow piggyback the existing code to fit the new scenario. The problem is that after we've written the first piece of code, we consider the thing solved. The first piece + parameters becomes the way of doing things and we are very reluctant to go back to basics again. So we start to pile up abstractions. But we don't have to. We can totally go back to basics and reduce the number of abstractions. We cannot overcome the inherent complexity of the task (The Law of Requisite Variety) but it's not this complexity that bites us: it's the complexity of added abstractions.
• afpx 7y ago
  Dumb question. But, Why can't there be a universal language that all other languages could be transpiled to and from? Wouldn't that eliminate a lot of the re-work that goes in maintaining all of these libraries in different languages?
  • Mikhail_Edoshin 7y ago
    The idea of Algol was like that: a standard language to describe algorithms. Mostly for publishing, where it served in this role (for ACM) for about 30 years. I myself like the idea, but looking at how things develop in general I have doubts. Such a language must be austere, but who wants austere?
• jarvuschris 7y ago
  WordPress is an excellent example of a malleable system Proper software engineers will poo-poo all day on WordPress' bad architecture and the messes users make with it But also, it has empowered millions to create and by some estimates it powers ~30% of the internet These facts are not unrelated. Sometimes it's OK to let people make messes, sometimes "good engineering" isn't as important as creative liberty
• cgrealy 7y ago
  “Software” shouldn’t be anything. Software is so broad a generalisation as to be utterly meaningless. Should some software be easy to change? Of course. There is immense proven value in that approach especially in the “unix tools” philosophy. But you cannot reason about embedded medical device drivers the same way as you can about a desktop CAD application or a video game or a massive SAAS platform.