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.
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.
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.
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.
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?
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.
> 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.
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.
Knew a girl who complained that her computer was too slow. As it turns out, she had added every add-on toolbar to Internet Explorer she ever came across. Her usable window was about two inches tall. Yet, it was the speed she complained about, not the utterly unusable web browser window.
You know, there are plenty of drawbacks on the act of offering options to the user, but the article touches on none of them.
It has really the wrong focus. It talks about pop-ups and distracting messages; it talks about surprising interfaces; it talks about actions that are hard to undo. But it doesn't talk about any problem that options cause by themselves.
> It’s true that the first time they realized you could completely remap the keyboard in Word, they changed everything around to be more to their liking, but as soon as they upgraded to Windows 95 those settings got lost, and they weren’t the same at work, and eventually they just stopped reconfiguring things.
Who is "we"? That didn't describe me in 2000 and describes me even less today.
Being able to moving the taskbar is bad because his friend shot herself in the foot this one time, but "we all love Winamp skins" -- because the person whose winamp turned unusable because they double clicked the wrong file just didn't happen to be friends with Joel. Sure, don't make software for me, but don't try to rationalize it with such gymnastics.
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.
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.
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.
> 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.
Usually in the case of network programs you want users to have a way to control their view of the shared backend/database/whatever, which means providing things like REST APIs and hackable clients.
"Those with nefarious purposes find them extremely useful too"
Whilst I don't disagree with this point, it has all to often been used as an argument against open software, and ultimately leads to more closed and less secure software.
The problem is support. Even if you put big caution tape around it, if you break it or change it in a way that isn't backwards compatible users will complain loudly about it. And if you have users paying lots of $$$ relying on it, it might force your hand.
Building a plug-able system in a way that doesn't blow up in your face can be hard. Firefox got a lot of bad press for redesigning their plugin system.
This is a great point and something to consider when designing runtime programmable tools. It should mean moving slow, cautious with minimal surface area and opinions about the future is probably a way to go. Having strong isolation is probably good too. This is something that made me uneasy about highly programmable/hackable platforms. I like when the core maintainers understand _how_ a system wants to be extended and shaped and provides precise hooks for doing so.
It seems to me the key then would be to have that programmable interface be used to actually implement the features shipped as part of the project. It will be a lot easier to get the API right if the developers are using it themselves, plus that adds a lot more incentive to maintain backwards compatibility as well.
Arguably, it's not just about support: It's often just not a good idea, complicating the existing product, still only gives you pre-defined hooks.
Jenkins is one of my favorite examples for why plugin systems are evil. As users accumulate plugins, it all becomes a giant, unmaintanable monolith that ends up unable to perform even the most basic tasks due to some unrelated/uninteresting/forgotten plugin somewhere doing something weird.
Instead of stuffing everything into a monolith with plugins, split it out into individual composeable units with minimal features.
It's not about making each macro-service into 1000 micro-services. It's about making your macro-services smaller, instead of all-consuming monoliths.
The problem is that monoliths will never be hackable. A LEGO-kit is hackable. A monolith just have hooks and connectors, but the product itself will always be static.
You can get things shipped as pre-assembled LEGO kits (both metaphoric or not)?
> As users accumulate plugins, it all becomes a giant, unmaintanable monolith that ends up unable to perform even the most basic tasks
I agree that most of the time it's best to give users only one way of doing things, so that they don't get creative and go down a rabbit hole.
Nevertheless, if a product targets a specific type of user, which is expected to be knowledged about and follow certain best practices while using it, making the product more customizable can be a competitive advantage.
We can't always blame the product for being "too complex" if it's purposely designed that way so that well-read users can take the most out of it.
I just attached a desktop PC to mine... so now it’s more complicated and does everything I want. =P
Doesn’t require much complexity from the TV though.
Jokes aside, sometimes simplicity is judged on different criteria. Everyone’s favorite example is Craigslist (ugly, but actually quite simple once you grok it), but I can name a few others where the actual criteria for simplicity can be hard to define.
Bash, for example. It takes a while before you really realize what the scripting can actually do and what Unix pipes can do. Once you see it, it makes a ton of sense, but until you grok the abstractions, it's just a pile of syntactic mush you can't remember. It's simple for what it does, but the problem itself has a lot of complexity.
I believe the same thing about Vim. It requires training because while its modes become simple after you start to get it, it's an irritatingly arduous road to get there. So from the perspective of a lay user... not simple at all. From the perspective of an expert, it's effective to the point of religion.
True. SmartTV's may appear simple, but I am fairly certain that their simplicity crumbles for most users quickly.
Say, once a user just wants to play games on a console and has to wait for a TV to boot and prompt you to install updates, when a user wants to use AppleTV instead of Android TV, or when they want to upgrade the smarts.
I think the man reason people think this is simpler is that manufacturers force it down consumers' throats as this setup sells more units due to planned obsolescence.
Sure, I think that's a market to target. But it sounds like it's a slog to develop for and often a slog to use (or at least set up).
Often the opinions made when designing the software is part of what you're selling. Otherwise, I just ship you a box of 1s and 0s and you can put it together yourself =)
Here is a thought experiment for your preference of “individual units with minimal features”: How do you take an artist’s toolbox app (Photoshop, Illustrator,
Blender, Painter, Procreate, Clip Studio, etc) and decompose it into individual units that can still be interacted with via a stylus as the primary UI?
While I was primarily referring to things with a backend, trying to redesign these "everything but the kitchen sink" apps is actually an interesting task.
First of all, Photoshop isn't a toolbox. It's a tool, but with plugins. The real-world analogy would be a KitchenAid kitchen machine, where you can attach awkward tumors like a spaghetti machine or entire food processor to their power take off. The kind of accessories that, after purchase, make you look long and hard in the mirror, trying to figure out just when it happened that your life fell apart.
A toolbox, on the other hand, is just a vehicle for making tools easily available. That, and being a blunt weapon in emergencies.
If I were to imagine a universal image toolbox, I'd imagine it as system that can visualize a stack of buffers. Then, it would be able to launch other applications, providing access an API to access and manipulate the buffer stack. That's all.
These applications can provide your usual floating toolbox UI's just fine, and nothing should stop it from having the same UX as Photoshop, but plugin-less. Depending on things, these tools may use usable standalone, for bulk use, command-line use, from different toolboxes, whatever. You'd be able to swap out features that are otherwise Photoshop built-ins, as they're just another application here.
This distinction between plugins (i.e. extendable tool) vs. toolbox (isolated tools) is important: Instead of awkward tools designed entirely around their ability to attach awkwardly to a KitchenAid, you get a tool designed around doing its job right.
(That KitchenAid accessory metaphor works a lot better than I initially anticipated—the PTO is the annoyingly limited hooks you have to work around, and the results are as awkward as any plugin system.)
An interesting comparison to Jenkins in the same space is Buildbot. Which embraces being written in a scripting language, and is "configured" by writing code that describes the builds, using existing primitives and extending or replacing them where necessary.
Interesting you mention Firefox because, when you think about it, a web browser (just like an operating system) is a massive pluggable system. They changed the plugin system, but they haven't (as far as I know) broken web standards, so that 20 year old websites still work today.
The user should have the power. Also the interface should be as powerful as possible. One such browser that embraces this philosophy is Next https://github.com/atlas-engineer/next. Source: biased author
Very cool! I'll show this to our team [1]; we have a few keyboard ninjas & I think they'll absolutely love it.
--
[1] team of https://mintdata.com, where we've been known to appreciate a fine keyboard shortcut or 12.
[2] partly an inside joke to our team who reads HN, since we recently shipped keyboard shortcuts for our top menu (Google Sheets, we borrowed what we could to ease the pain :D )
Mintdata looks cool, what does the imperative layer that drives the declarative layer look like? It'd be nice if this was a platform where engineers could sell the imperative layers
We've been using our own "Visual SDK" to build large parts of MintData for the past few years.
It's 100% written in TypeScript/React, using decorators (cough: annotations!) and allows us to:
1) add new spreadsheet functions in TypeScript
2) wrap any React component
3) we get the auto-magic property panel UI "for free" & it instantly talks to/from the spreadsheet
For our cloud/backend imperative layer:
4) we use our own real-time stream processor (think: Apache Storm but minus the Clojure stacktraces)
5) the SDK lets us quickly write flow blocks in Java using annotations & connect to all sorts of enterprise-y systems (SQL/NoSQL stores, Queues, File Systems, etc)
@slifin -- in terms of engineers writing & selling those layers, we're open to it -- ping me if you have ideas & we can give you access to the docs & SDK.
--
[1] I'd put a link here, but the flamethrowers have come out on this thread :)
Looks pretty cool; IMHO it's a good idea. (I once participated as a consultant / dev on a project to convert a Byzantine set of Excel spreadsheets into a deployable application built on web technologies, and this might have been a saner approach.)
Before the others come with torches, I’ll point out we turned on public/free access recently, would be happy to hear your thoughts/feedback on the MintData approach.
Who actually likes DSLs and why? You introduce the complexity of a lexer and parser in the form of an abstraction on top of an API. What does that buy you?
In my experience, it just makes workflows more difficult since you now need to create custom editors, linters, formatters, testing frameworks, etc. You need a whole new ecosystem before you can truly become productive on top of learning an entirely new syntax.
It exists for software that considers itself a platform in the form plugins, themes and such. And it’s very different, much harder, software play for support and reputation management.
It’s challenging to do, but there is something to be said for having features you don’t advertise.
You don’t have to make them work for everyone. They don’t have to be safe in all possible scenarios. But they are there for Support to offer to users who are caught in a bind and need a solution.
The about: box is a bit like this. It’s there, if you really need it, but they aren’t going to flood their menus for all the 2% cases.
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.
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.
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).
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.
And in the intersection of mutability and immutability you have fantastic experiences like live editing and time travel. /Where/ the interface for mutability is located is essential.
There are strong engineering impetuses for control, for provability, for ahead-of-time decisions, for immutability. Engineers get woken up when things go wrong, they get blamed when things go wrong, & they want, they have to deal with other engineers code doing bad things with their code, & the software world has a wide variety of strategies, tools, & outlooks that all try to build safety, certainty, that restrict & constrain systems, to keep anything unexpected from happening.
I feel, though, that characterizing malleable systems as being for expert users alone is a great injury. At present this may match expectations, but I don't think it's fair to make an assessment of how or what computer-users want when, at the moment, they don't really have the options. There are too few malleable systems out there to judge. What general malleable systems we do have require advanced expertise to use- AppleScript, DCOP (Desktop COmmunication Protocol), DBus, WebExtensions all require at least some programming style skills to use. But I think this expertise is owing to a broad lack of investment in building malleable software. Most software strives to give the user a specified & specific experience, not be a malleable system folks can get the experience they want out of. I don't think we know how much latent pull users have, how strong the tension is to be released from engineer's certainty, because I don't think there are even many testbeds, much less a broader societal view of systems flexibility, systems adaptability, of softer software.
To me, I just think it's clear that, whatever valid concerns we do have, whatever justification we have for building endless arrays of rigid systems, it seems like it's not worth it anymore. We keep making more and more software, the profusion of software applications is a torrent of similar-but-different applications, focusing on shuffling this or that kind of data specifically, yet the generality, the inter-connectedness of the pieces seems so weak, and it seems like we've shut users out from having any creative capabilities & control of their own.
I think WebExtensions are a very interesting case. The killer aspect, to me, is that the extensions work invisibly. We can't rely on everyone becoming an expert extension operator, but I do think that some reporting mechanisms on what extensions do would radically reshape how the community review's & socialized the extensions they use. In many ways, it's that the extensions are a means of exercising the malleability of hypertext, but they themselves are rigid & unmalleable & opaque. A part of being malleable- a precondition- is making yourself visible, providing viewability into what is happening, such that folks can reshape & redefine & redirect those actions that you the software are enacting. So the circle needs to grow more, is what it seems to me- rather than lock down extensions, rather than rely on authoritarian centralized powers to moderate extensions, my plea would be to make extensions malleable too, to make their working visible too, and to try to let consciousness & human adaptability start to take hold in this realm.
You're absolutely correct that there are good reasons why software is so rigid & inflexible & opaque. Security has been nightmarishly cumbersome to the whole industry for the last decade. And I think malleability does indeed open up a lot more surfaces, endlessly opens surfaces. But at some point, we have to develop systems that have a co-relation with their operators, that respect the operators, that let them see what is happening & let them work their own systems. Continuing to try to push computers forwards entirely on the assumption that the user is worthless, does not know anything, and can not understand what is happening has cornered us, has cut off the chance to try & explore other options.
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.
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...
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.
>> "A fundamental problem of today’s software ecosystem is that we do not own or control the software that runs on our devices. In addition, much of the actual processing logic has been passed off to remote systems in the cloud, so only the inputs and outputs are observable."
>> "We must ensure that malleable software approaches allow the customisations and personal workflows you create to be owned and used as you see fit. If an approach relies on some amount of remote functionality (perhaps to assist with pulling apart an application or service), we must ensure there’s a clear path for anyone interested to keep those dependencies alive so that their workflows are not disturbed if the remote service were to shut down."
>> "This has many parallels with the ongoing movement towards data ownership, which is gaining popular awareness. Although the data ownership movement typically focuses on identity and social data, the programs and customisations that authors create are personal creative expressions. Authors must retain ownership of their data, programs, and customisations just as anyone would expect to have control over a book they wrote or art they created."
The first paragraph definitely matches up with your point that the user should be in control of their computing environment. However the third paragraph certainly seems like copyright and licensing are implied.
As you’ve surmised, the user / workflow author is meant to be the same person.
When it says “authors must retain ownership”, this was mostly meant as a reaction against platforms like IFTTT and marketplaces like browser extension galleries that may bring sharing restrictions, vendor lock-in, etc. So it’s trying to argue for more openness at least being available as an option to the hybrid user / workflow author.
For cases where the user / author wants to be restrictive and lock down who can use the work, the mission is mostly silent on this front.
Personally, I would hope most would see value in openness, and known approaches for enforcing restrictions (like DRM) are quite ... unpleasant.
I am hopeful better schemes can be created for those who want such things, but it seemed a bit beyond the core focus of the mission (which is already quite ambitious). Thanks for the feedback!
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.
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.
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.
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.
Plan 9 is lucky - by design it is self-contained and has no dependencies.
One of the hardest parts about building many complex open source projects (particularly on Windows and macOS) is getting their dependency stacks in order.
89 libraries is a lot. Even the most complex project I work on has just 20. The list you gave seems somewhat reasonable, but I'm willing to bet that the long tail of stuff you didn't mention includes a lot of more trivial dependencies. I don't know your project, but I imagine that you ought to redefine your scope to avoid introducing a need on complex dependencies. Simpler software is more robust, more maintainable, and often gets the job done better - but it's more difficult to make.
In any case, I'm mainly criticisng the typical JavaScript, Ruby, etc project, with their giant pile of node_modules or whatever the case may be. It can easily get out of hand with other projects, too, especially in languages which encourage over-engineering and over-abstracting like Rust or C++ (let me guess: yours is the latter?).
As a trivial example, I spent a couple of hours last night pruning stuff I didn't need from one of my text editor plugins (https://github.com/mhinz/vim-signify). I was able to take it down from 1400 lines to sub-300 lines. And in the process it became a lot clearer precisely what the algorithmic core of the library was. A valuable learning experience.
vim-signify was 800 lines large back in 2014 when I first started using it. How much of the stuff added since mattered to me? Almost nothing. These are the costs we all take on -- death by a thousand cuts -- when we blindly import dependencies.
C++ (with a tiny bit of assembler). Most of our dependencies arise from our choice to use GTK, but there's a fair number that do not.
I wouldn't call any of them trivial dependencies.
Edit: on the order of a dozen of the deps are actually requirements for the build system of libs we depend on (e.g. autotools nonsense), but from a practical perspective, they are dependencies that have to be satisfied if you want to build Ardour completely from scratch (by which we mean, alternately, a Linux system with only libc, libstdc++ and X, or a new macOS install).
Build deps aren't free, but have different constraints and effects.
Anyway, if this is your full dependency tree - with transitive dependencies included - this is fairly reasonable. I reckon Boost doesn't need to be there, and you're probably well past the point of diminishing returns with GTK+ and a UI like yours, but otherwise this seems reasonable to me. You should also consider moving on from autotools by now, I recommend Meson as a replacement.
These kinds of questions - is autotools still a good choice? Do we really need Boost? Is GTK+ doing us any favors? Answering these is the "careful keeping of your dependency graph small and conservative" that I am referring to.
I mentioned autotools as part of the build system of some of our dependencies. We abandoned it ourselves in disgust many years ago (in favor of waf; meson may be in our future).
Boost is critical for us because we aim for compatibility (and for macOS that means buildability) on systems only reaching C++98, meaning that boost fills in large parts of the then-missing std:: namespace (such as shared_ptr<>). We will move to C++11 after our 6.0 release, but boost still provides several other very useful bits of functionality.
GTK+ remains useful even as we slowly move away from it, and there remains the big four (text entry, file browsing, treeviews and menus) that will be a huge effort to reimplement. Our goal is to eventually depend only upon GDK (i.e. a thin window system wrapper), but I doubt that we will ever reach that goal.
1998 was 22 years ago. At some point we've gotta let it go. And I'm not going to argue about Boost, but it'll suffice to say that I passionately hate C++ and Boost is a big part of why. That Ardour is a C++ project has a lot to do with its sprawling complexity, these are often correlated (which is why I guessed C++ from your earlier description). Also, I would definitely recommend looking into Meson instead of waf, having used both.
Anyway, I think we have reached something resembling an understanding. Your dependencies are fairly reasonable, but there's room to and reason to cull them down a bit.
I'm not Drew DeVault, but I think there's value in taking responsibility for your dependencies. You don't need to understand all of it on day 1, but as you use it and run into issues you should be gradually understanding its internals better, gradually resolving features that you use vs features that you don't. That then gives you the option to rip out stuff you're sure you'll never need. Or to rip out stuff you may need in future, but is easy to put back (this is analogous to deleting code without fear because version control).
One "value" of of libraries is that it allows us programmers to spread out responsibility for breakage. What if we didn't do that? What if we exchanged software in units of working computing stacks, to take the idea to an extreme. It seems unquestionably useful to the world. So it seems worth exploring how close to that ideal we can feasibly get.
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.
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.
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.
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.
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.
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.
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)
It's interesting how the ideas of the Smalltalk and Lisp systems of the 70s and 80s get reintroduced over time, but they're never fully embraced, even though some of their features make it into the mainstream. Emacs would be an exception. Makes you wonder where Smalltalk-inspired systems would be today if they had the kind of support popular languages have received. Imagine Smalltalk receiving the kind of attention Java, Python or Javascript have the past 20 years.
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.
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?
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.
In this sort of world, how do you prevent users from making bad queries and hogging all the database resources or even crashing the database? How do you prevent users from wiping out data? (I get that you could back it up and restore it, but depending on the company, this could cause serious downtime and loss of revenue).
2) Competition in established industries is fierce (finance, real estate, education, construction, etc)
--
To the extent possible, I'd:
a) time out bad queries
b) add more hardware where feasible
--
For the "wiping out data" part, I think:
1) Mark things as "removed", delete when {GDPR,CCPA,etc} requires it
2) The UIs designed can/should have human processes in mind -- that is, things like multiple people involved (async) on what to do with a piece of data (flag it, mark it removed, send it for approval, etc) -- what a lot of companies are calling "workflows" and "workflow management platforms" these days.
3) Backup/restore should be used only as a last resort (DR and the like)
4) Versioning like Google Sheets of the UI is paramount and integration with CI/CD systems is crucial to having the cake (allowing people to create the tools they want) while also eating it too (making sure IT doesn't drive the above-mentioned dune buggy off a cliff in protest)
205 comments
[ 3.4 ms ] story [ 203 ms ] threadCompiler 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.
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.
> 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.
I wonder why they even bother letting it go to half-screen?
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.
It has really the wrong focus. It talks about pop-ups and distracting messages; it talks about surprising interfaces; it talks about actions that are hard to undo. But it doesn't talk about any problem that options cause by themselves.
Who is "we"? That didn't describe me in 2000 and describes me even less today.
Being able to moving the taskbar is bad because his friend shot herself in the foot this one time, but "we all love Winamp skins" -- because the person whose winamp turned unusable because they double clicked the wrong file just didn't happen to be friends with Joel. Sure, don't make software for me, but don't try to rationalize it with such gymnastics.
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.
Those with nefarious purposes find them extremely useful too. It's a lot of work to secure those interfaces against abuse.
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.
Whilst I don't disagree with this point, it has all to often been used as an argument against open software, and ultimately leads to more closed and less secure software.
Building a plug-able system in a way that doesn't blow up in your face can be hard. Firefox got a lot of bad press for redesigning their plugin system.
Jenkins is one of my favorite examples for why plugin systems are evil. As users accumulate plugins, it all becomes a giant, unmaintanable monolith that ends up unable to perform even the most basic tasks due to some unrelated/uninteresting/forgotten plugin somewhere doing something weird.
Instead of stuffing everything into a monolith with plugins, split it out into individual composeable units with minimal features.
This feels like microservices-for-everything as a product.
Then you've designed a platform, with a reference combination. Which carries its own set of challenges and over-complications.
There's something to be said for a clean, batteries-included product... with a way to hack the hell out of it.
It's not about making each macro-service into 1000 micro-services. It's about making your macro-services smaller, instead of all-consuming monoliths.
The problem is that monoliths will never be hackable. A LEGO-kit is hackable. A monolith just have hooks and connectors, but the product itself will always be static.
You can get things shipped as pre-assembled LEGO kits (both metaphoric or not)?
I agree that most of the time it's best to give users only one way of doing things, so that they don't get creative and go down a rabbit hole.
Nevertheless, if a product targets a specific type of user, which is expected to be knowledged about and follow certain best practices while using it, making the product more customizable can be a competitive advantage.
We can't always blame the product for being "too complex" if it's purposely designed that way so that well-read users can take the most out of it.
Doesn’t require much complexity from the TV though.
Jokes aside, sometimes simplicity is judged on different criteria. Everyone’s favorite example is Craigslist (ugly, but actually quite simple once you grok it), but I can name a few others where the actual criteria for simplicity can be hard to define.
Bash, for example. It takes a while before you really realize what the scripting can actually do and what Unix pipes can do. Once you see it, it makes a ton of sense, but until you grok the abstractions, it's just a pile of syntactic mush you can't remember. It's simple for what it does, but the problem itself has a lot of complexity.
I believe the same thing about Vim. It requires training because while its modes become simple after you start to get it, it's an irritatingly arduous road to get there. So from the perspective of a lay user... not simple at all. From the perspective of an expert, it's effective to the point of religion.
Say, once a user just wants to play games on a console and has to wait for a TV to boot and prompt you to install updates, when a user wants to use AppleTV instead of Android TV, or when they want to upgrade the smarts.
I think the man reason people think this is simpler is that manufacturers force it down consumers' throats as this setup sells more units due to planned obsolescence.
Often the opinions made when designing the software is part of what you're selling. Otherwise, I just ship you a box of 1s and 0s and you can put it together yourself =)
First of all, Photoshop isn't a toolbox. It's a tool, but with plugins. The real-world analogy would be a KitchenAid kitchen machine, where you can attach awkward tumors like a spaghetti machine or entire food processor to their power take off. The kind of accessories that, after purchase, make you look long and hard in the mirror, trying to figure out just when it happened that your life fell apart.
A toolbox, on the other hand, is just a vehicle for making tools easily available. That, and being a blunt weapon in emergencies.
If I were to imagine a universal image toolbox, I'd imagine it as system that can visualize a stack of buffers. Then, it would be able to launch other applications, providing access an API to access and manipulate the buffer stack. That's all.
These applications can provide your usual floating toolbox UI's just fine, and nothing should stop it from having the same UX as Photoshop, but plugin-less. Depending on things, these tools may use usable standalone, for bulk use, command-line use, from different toolboxes, whatever. You'd be able to swap out features that are otherwise Photoshop built-ins, as they're just another application here.
This distinction between plugins (i.e. extendable tool) vs. toolbox (isolated tools) is important: Instead of awkward tools designed entirely around their ability to attach awkwardly to a KitchenAid, you get a tool designed around doing its job right.
(That KitchenAid accessory metaphor works a lot better than I initially anticipated—the PTO is the annoyingly limited hooks you have to work around, and the results are as awkward as any plugin system.)
In that regard, browsers aren't that bad.
The user should have the power. Also the interface should be as powerful as possible. One such browser that embraces this philosophy is Next https://github.com/atlas-engineer/next. Source: biased author
--
[1] team of https://mintdata.com, where we've been known to appreciate a fine keyboard shortcut or 12.
[2] partly an inside joke to our team who reads HN, since we recently shipped keyboard shortcuts for our top menu (Google Sheets, we borrowed what we could to ease the pain :D )
Card carrying member of the disagree-club here (malleable clan), but I think it's a tall order to ask users to write procedural code.
Tools that are:
(1) declarative by nature (HTML, DSLs)
(2) based on direct manipulation (PSA: we're lucky to have Bret Viktor on this planet)
is what will win out in my opinion.
Or will we be writing procedural code 30, 50 years out? :)
--
[1] YMMV, founder of https://mintdata.com here, where we recently opened public access & are seeing the above come true.
We've been using our own "Visual SDK" to build large parts of MintData for the past few years.
It's 100% written in TypeScript/React, using decorators (cough: annotations!) and allows us to:
1) add new spreadsheet functions in TypeScript
2) wrap any React component
3) we get the auto-magic property panel UI "for free" & it instantly talks to/from the spreadsheet
For our cloud/backend imperative layer:
4) we use our own real-time stream processor (think: Apache Storm but minus the Clojure stacktraces)
5) the SDK lets us quickly write flow blocks in Java using annotations & connect to all sorts of enterprise-y systems (SQL/NoSQL stores, Queues, File Systems, etc)
@slifin -- in terms of engineers writing & selling those layers, we're open to it -- ping me if you have ideas & we can give you access to the docs & SDK.
--
[1] I'd put a link here, but the flamethrowers have come out on this thread :)
Before the others come with torches, I’ll point out we turned on public/free access recently, would be happy to hear your thoughts/feedback on the MintData approach.
In my experience, it just makes workflows more difficult since you now need to create custom editors, linters, formatters, testing frameworks, etc. You need a whole new ecosystem before you can truly become productive on top of learning an entirely new syntax.
You don’t have to make them work for everyone. They don’t have to be safe in all possible scenarios. But they are there for Support to offer to users who are caught in a bind and need a solution.
The about: box is a bit like this. It’s there, if you really need it, but they aren’t going to flood their menus for all the 2% cases.
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.
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.
There are strong engineering impetuses for control, for provability, for ahead-of-time decisions, for immutability. Engineers get woken up when things go wrong, they get blamed when things go wrong, & they want, they have to deal with other engineers code doing bad things with their code, & the software world has a wide variety of strategies, tools, & outlooks that all try to build safety, certainty, that restrict & constrain systems, to keep anything unexpected from happening.
I feel, though, that characterizing malleable systems as being for expert users alone is a great injury. At present this may match expectations, but I don't think it's fair to make an assessment of how or what computer-users want when, at the moment, they don't really have the options. There are too few malleable systems out there to judge. What general malleable systems we do have require advanced expertise to use- AppleScript, DCOP (Desktop COmmunication Protocol), DBus, WebExtensions all require at least some programming style skills to use. But I think this expertise is owing to a broad lack of investment in building malleable software. Most software strives to give the user a specified & specific experience, not be a malleable system folks can get the experience they want out of. I don't think we know how much latent pull users have, how strong the tension is to be released from engineer's certainty, because I don't think there are even many testbeds, much less a broader societal view of systems flexibility, systems adaptability, of softer software.
To me, I just think it's clear that, whatever valid concerns we do have, whatever justification we have for building endless arrays of rigid systems, it seems like it's not worth it anymore. We keep making more and more software, the profusion of software applications is a torrent of similar-but-different applications, focusing on shuffling this or that kind of data specifically, yet the generality, the inter-connectedness of the pieces seems so weak, and it seems like we've shut users out from having any creative capabilities & control of their own.
I think WebExtensions are a very interesting case. The killer aspect, to me, is that the extensions work invisibly. We can't rely on everyone becoming an expert extension operator, but I do think that some reporting mechanisms on what extensions do would radically reshape how the community review's & socialized the extensions they use. In many ways, it's that the extensions are a means of exercising the malleability of hypertext, but they themselves are rigid & unmalleable & opaque. A part of being malleable- a precondition- is making yourself visible, providing viewability into what is happening, such that folks can reshape & redefine & redirect those actions that you the software are enacting. So the circle needs to grow more, is what it seems to me- rather than lock down extensions, rather than rely on authoritarian centralized powers to moderate extensions, my plea would be to make extensions malleable too, to make their working visible too, and to try to let consciousness & human adaptability start to take hold in this realm.
You're absolutely correct that there are good reasons why software is so rigid & inflexible & opaque. Security has been nightmarishly cumbersome to the whole industry for the last decade. And I think malleability does indeed open up a lot more surfaces, endlessly opens surfaces. But at some point, we have to develop systems that have a co-relation with their operators, that respect the operators, that let them see what is happening & let them work their own systems. Continuing to try to push computers forwards entirely on the assumption that the user is worthless, does not know anything, and can not understand what is happening has cornered us, has cut off the chance to try & explore other options.
>> "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...
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.
I think this refers to the user being in control (as opposed to the developer) and having ownership of their computing environment.
The links in the principles give more details: https://malleable.systems/mission/#4-retain-ownership-and-co...
For this principle, it says:
>> "A fundamental problem of today’s software ecosystem is that we do not own or control the software that runs on our devices. In addition, much of the actual processing logic has been passed off to remote systems in the cloud, so only the inputs and outputs are observable."
>> "We must ensure that malleable software approaches allow the customisations and personal workflows you create to be owned and used as you see fit. If an approach relies on some amount of remote functionality (perhaps to assist with pulling apart an application or service), we must ensure there’s a clear path for anyone interested to keep those dependencies alive so that their workflows are not disturbed if the remote service were to shut down."
>> "This has many parallels with the ongoing movement towards data ownership, which is gaining popular awareness. Although the data ownership movement typically focuses on identity and social data, the programs and customisations that authors create are personal creative expressions. Authors must retain ownership of their data, programs, and customisations just as anyone would expect to have control over a book they wrote or art they created."
The first paragraph definitely matches up with your point that the user should be in control of their computing environment. However the third paragraph certainly seems like copyright and licensing are implied.
When it says “authors must retain ownership”, this was mostly meant as a reaction against platforms like IFTTT and marketplaces like browser extension galleries that may bring sharing restrictions, vendor lock-in, etc. So it’s trying to argue for more openness at least being available as an option to the hybrid user / workflow author.
For cases where the user / author wants to be restrictive and lock down who can use the work, the mission is mostly silent on this front.
Personally, I would hope most would see value in openness, and known approaches for enforcing restrictions (like DRM) are quite ... unpleasant.
I am hopeful better schemes can be created for those who want such things, but it seemed a bit beyond the core focus of the mission (which is already quite ambitious). Thanks for the feedback!
Does any of the real economic activity want to reduce its power and influence? that’s the opposite of a startup
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-interopera...
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.
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/ [1]: https://youtu.be/XvDZLjaCJuw
One of the hardest parts about building many complex open source projects (particularly on Windows and macOS) is getting their dependency stacks in order.
Surely you can't be serious. Unless you just don't believe in "big, complex software" ?
In any case, I'm mainly criticisng the typical JavaScript, Ruby, etc project, with their giant pile of node_modules or whatever the case may be. It can easily get out of hand with other projects, too, especially in languages which encourage over-engineering and over-abstracting like Rust or C++ (let me guess: yours is the latter?).
vim-signify was 800 lines large back in 2014 when I first started using it. How much of the stuff added since mattered to me? Almost nothing. These are the costs we all take on -- death by a thousand cuts -- when we blindly import dependencies.
C++ (with a tiny bit of assembler). Most of our dependencies arise from our choice to use GTK, but there's a fair number that do not.
I wouldn't call any of them trivial dependencies.
Edit: on the order of a dozen of the deps are actually requirements for the build system of libs we depend on (e.g. autotools nonsense), but from a practical perspective, they are dependencies that have to be satisfied if you want to build Ardour completely from scratch (by which we mean, alternately, a Linux system with only libc, libstdc++ and X, or a new macOS install).
Anyway, if this is your full dependency tree - with transitive dependencies included - this is fairly reasonable. I reckon Boost doesn't need to be there, and you're probably well past the point of diminishing returns with GTK+ and a UI like yours, but otherwise this seems reasonable to me. You should also consider moving on from autotools by now, I recommend Meson as a replacement.
These kinds of questions - is autotools still a good choice? Do we really need Boost? Is GTK+ doing us any favors? Answering these is the "careful keeping of your dependency graph small and conservative" that I am referring to.
I mentioned autotools as part of the build system of some of our dependencies. We abandoned it ourselves in disgust many years ago (in favor of waf; meson may be in our future).
Boost is critical for us because we aim for compatibility (and for macOS that means buildability) on systems only reaching C++98, meaning that boost fills in large parts of the then-missing std:: namespace (such as shared_ptr<>). We will move to C++11 after our 6.0 release, but boost still provides several other very useful bits of functionality.
GTK+ remains useful even as we slowly move away from it, and there remains the big four (text entry, file browsing, treeviews and menus) that will be a huge effort to reimplement. Our goal is to eventually depend only upon GDK (i.e. a thin window system wrapper), but I doubt that we will ever reach that goal.
Anyway, I think we have reached something resembling an understanding. Your dependencies are fairly reasonable, but there's room to and reason to cull them down a bit.
One "value" of of libraries is that it allows us programmers to spread out responsibility for breakage. What if we didn't do that? What if we exchanged software in units of working computing stacks, to take the idea to an extreme. It seems unquestionably useful to the world. So it seems worth exploring how close to that ideal we can feasibly get.
(Part of this comment was reworked from https://news.ycombinator.com/item?id=16882140#16882555 back in 2018.)
(I research ways to distribute software as complete stacks: http://akkartik.name/akkartik-convivial-20200315.pdf)
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.
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/#s...
Cough Electron Cough 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.
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
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)
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.
"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.
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?
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, 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 :)
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.
1) Computing is cheap, human time is not.
2) Competition in established industries is fierce (finance, real estate, education, construction, etc)
-- To the extent possible, I'd:
a) time out bad queries
b) add more hardware where feasible
-- For the "wiping out data" part, I think:
1) Mark things as "removed", delete when {GDPR,CCPA,etc} requires it
2) The UIs designed can/should have human processes in mind -- that is, things like multiple people involved (async) on what to do with a piece of data (flag it, mark it removed, send it for approval, etc) -- what a lot of companies are calling "workflows" and "workflow management platforms" these days.
3) Backup/restore should be used only as a last resort (DR and the like)
4) Versioning like Google Sheets of the UI is paramount and integration with CI/CD systems is crucial to having the cake (allowing people to create the tools they want) while also eating it too (making sure IT doesn't drive the above-mentioned dune buggy off a cliff in protest)
interesting metric, reallllllly bad target