
Malleable Systems: Software must be as easy to change as it is to use it - pcr910303
https://malleable.systems/
======
saagarjha
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.

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

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

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

~~~
arghwhat
Complex ≠ useful. A TV and a set top of your choice box is simple useful. A
smart TV does the same thing, but is complex and inflexible.

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

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

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

~~~
denster
I'll give you an example that mid-way [1] disproves the above.

Think of a typical "product tour" in a SaaS product. We're building the
MintData product tour, in MintData itself. We then "publish" this "product
tour application", and include it with the original blank design that a user
gets when they first enter MintData.

So, in a way, our MintData onboarding is built in/on MintData itself, a bit
like how you can have a bootstrapping compiler (one that compiles itself).

So, is the above us "modifying the original system"?

I think to some extent yes, although we have special spreadsheet functions
that help jump the gap between Onboarding Application and Blank User Design
(akin to the Postgres extensions [2] above).

So I think it _is_ possible to build a system that allows you to then
customize the system's own behavior (earlier versions of MintData could not
build the onboarding experience, similarly to how the first compiler has to be
built in a lower level language).

Genuinely curious -- derefr, do you agree or disagree with the above?

\--

[1] Chief abstraction wrangler at
[https://mintdata.com](https://mintdata.com), so YMMV on the above.

[2] As a person who was held at Grade-point and forced to write PostgreSQL C
code to "modify the original [Postgres] system", I can only say it's an
acquired taste :) Even Prof Franklin at UC Berkeley I think would back me up
on this :D :D

~~~
GuiA
Seeing your product shilled so blatantly repeatedly as one goes down the
comments in this thread is pretty off putting.

~~~
denster
Ouch! That hurts!

My only response is this:
[https://youtu.be/Mm4epcGApnY?t=14](https://youtu.be/Mm4epcGApnY?t=14)

------
mbrodersen
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
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
_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
I largely agree with you here, and this entire thread has been an interesting
read for me.

I’m actually writing what is turning out to be a research paper ( it started
as a blog post ) about software development today.

What the OP is looking for _is_ a change, but it’s not just a change in
society. It’s also how software development is viewed as a discipline and a
career.

Very roughly put: software engineering is not a respected discipline, not to
the level of other engineering disciplines. To create what the OP is looking
for, The idea and viewpoint of software engineering needs to be changed as a
whole.

To go into it more would be too much in a single post, and it’s part of the
reason why I’m going down the rabbit hole with my paper.

~~~
Silhouette
I encourage you to share your paper when it's finished. This is an interesting
discussion that I'd like to see more people joining.

For what it's worth, I don't think "software engineering" _should_ be accorded
the same respect as true engineering disciplines. What we do has little
resemblance to real engineering in terms of either the systematic, tried and
tested approach or the ethical foundation. It is something I think we should
aspire to, but we are a long way from reaching that standard today.

That said, I don't think everyone needs to become a full-fledged software
engineer to reach the goals set out in the linked piece. If we do ever achieve
something like that, I think it will be because the core of the systems is
carefully constructed by experts, and because it provides methods for
"malleability" also carefully constructed by experts so that non-experts can
use them. That recipe has proved successful in the past, in a wide range of
applications from game mods to Excel macros, and I see no reason in principle
that it couldn't be used much more widely for other types of software _if_
there is some incentive for the experts to build the core and the
extensibility framework around it.

------
oblib
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
(!) 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.

~~~
throwaway_pdp09
I'm going to disagree here, though sort of understand what you and the
original poster are saying.

In short I've seen the mess that 'unsilled' people make using complex tools.
Tools such as databases (my area) are presented as being easy to use by
microsoft, who make a lot of effort to make it easy to use. Too easy. Not
because I want to keep people out, far from it, but because if they don't know
what they are doing they get only so far, then things go bad and they've no
idea why. Drag/drop, point/click only goes so far.

I guess no complex tool can be (or should be?) used with concomitant levels of
training. It's not an argument for code gurus to make themselves a comfortable
walled garden to preside over and keep others out, it's an argument that tools
should come with training, always.

The problem these days is the hirers just want everything (blah blah full
stack blah) and don't understand the cost of getting it wrong because it works
- up to a point. MSSQL, Spark, Kafka, down to failure to understand how CPUs
work. They all get treated as black boxes, and that's fine up to a point. Then
things break or don't scale. Out of my sphere I see so many websites that have
no basic understanding of usability, or standards, or accessibility, security
and by web devs that barely understand HTTP.

If it's plain line of business, unimaginative gruntwork that keeps a business
alive with spreadsheets etc, then that's what's needed and basic understanding
is sufficient. I've done plenty of jobs like that, they keep the economy
going, but if you want heftier dev work, I don't think that will suffice.

I guess that makes me sound a snob. Not intended that way, just saying complex
tools may not be usable to their full capacity without understanding them. I
may be wrong too.

~~~
slifin
I don't know, if a system exposed a EAVT database like Datomic where you don't
need to normalise tables and you don't have to index manually and the n query
problem isn't an issue then I think a non expert could get a lot further with
the right UI then someone given a traditional SQL/NoSQL database

It's easy to make things complex and its hard to make things simple but if we
can simplify to a data model then we can do declarative programming and make
systems more tenable

Thinking in declarative data models is hard if you're not used to doing it,
I'd recommend looking at the following libraries in Clojure: Garden, Hiccup,
HoneySQL or Drupal's form management, or kind of ReactJS if you stretch your
idea is what data is, they can all handle complex but focused tasks

~~~
throwaway_pdp09
I have to be sceptical about what you say, so understand that comes from lack
of knowledge of what you're getting at (but I do know my SQL very well, and I
do know declarative programming, of which SQL is an instance)

> EAVT database like Datomic where you don't need to normalise tables

That is a strange comment to me. Normalisation is not about databases but
about data management. The value of normalisation doesn't go away just because
you're using a different DB, because it's solely about relationships in the
data.

> and you don't have to index manually

Woo, don't know what to say to that. Could you provide some pointers to both
of these (normalisation and indexing) and I'll do some reading, thanks. I find
that very hard to believe (no offence!)

Agreed about the 'hard to make things simple' but

> if we can simplify to a data model then we can do declarative programming

That data model is arguably normalisation. SQL is declarative, and I've seen
the results of ignorance applied to that, so I can't buy that just using SQL
protects you much (although it does to an extent, I suppose).

Declarativeness makes things easier on the programmer up to a point. When
things break, there's not much you can do - and things can break easily in
SQL. Writing good SQL, like any program, takes skill.

Also I recall many years ago finding out the hard way that you have to
understand prolog's (relatively simple) search strategy to get decent results
from it. Just 'declaring' your relationship between input and output didn't
work at all well (I don't remember the details but I remember the lesson I
learned).

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

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

~~~
vsareto
Hah, you can still do that on Win10.

I wonder why they even bother letting it go to half-screen?

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

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

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

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

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

~~~
danShumway
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)

~~~
saagarjha
Nano doesn’t have a plugin interface, but you can customize it so it can run
the compiler or formats your code.

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

------
kazinator
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_ )

------
ChrisMarshallNY
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/#s...](https://littlegreenviper.com/miscellany/bluetooth/itcb-04/#squid)

------
CapriciousCptl
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
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 :)

~~~
philote
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).

~~~
denster
I think of this in two parts:

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)

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

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

~~~
denster
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
Dude pls with the spamming

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

------
ddevault
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
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
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
To be fair, a cat flipping me off and telling me to “go away” in the FAQ may
lead to misunderstandings.

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

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

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

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

------
rwmj
This is describing Smalltalk and Lisp Machines?

------
m0zg
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
Smalltalk, Lisp, Cedar, Emacs, Hypercard and Lotus Notes come to mind.

~~~
cosmotic
I'm sorry, how is emacs easy to use (as per manifesto)?

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

------
renewiltord
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.").

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

------
aey
The unfortunate outcome is more yaml and less lisp or small talk :(

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

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

------
tmikaeld
Eric Elliot would probably jump on this, considering his books and series
[https://medium.com/javascript-scene/composable-datatypes-
wit...](https://medium.com/javascript-scene/composable-datatypes-with-
functions-aec72db3b093)

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

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

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

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

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

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

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

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

------
dustingetz
“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
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-
interopera...](https://www.eff.org/deeplinks/2019/10/adversarial-
interoperability)

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

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

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

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

------
awinter-py
> software must be as easy to modify as it is to use

interesting metric, reallllllly bad target

------
bri3d
Wasn't this the idea of the 4GL and 5GL craze in the 1980s and 1990s?

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

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

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

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

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

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

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

------
mrfusion
I always liked the extension system in browsers.

------
PaulDavisThe1st
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-
fr...](https://discourse.ardour.org/t/is-open-source-a-diversion-from-what-
users-really-want/102665)

TLDR: i still don't know if most of our users would prefer a more scriptable
application even if it was closed source.

------
chrischen
Functional programming to the rescue!

------
jshap70
title makes it justifiable for systems to both be hard to modify and difficult
to use

------
_alex_
this is all just a long con to try to convince everyone to integrate Guile

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

~~~
scroot
The lisp/smalltalk style of computing was meant for a world in which there was
not such a strong divide between users and programmers. We did not get such a
world, and our consumer systems have taken on (an actively promote) the
opposing view. To me it's not necessarily about the popular language du jour,
or whether or not a certain currently embraced language will last the "test of
time," but rather how long our current short sighted computing culture overall
can last.

~~~
iLemming
> how long our current short sighted computing culture overall can last.

Well, we can keep adding new programming languages and keep "extending"
javascript (borrowing every single good and a bad idea from those new
languages) for a very long time. Today the demand requires narrow-focused
specialists with a median tenure in a company of 2.5 years. They don't even
want "front-end" or "back-end" engineers anymore, they want "React",
"Angular", "Flutter", "GraphQL", "Kotlin", "Swift", "Golang" etc. engineers.

Not too many companies see value in generalists. Those who can look at the
domain and design business logic, funneling data from back to front, to mobile
apps and back to the API. And it's not so simple anymore. Everything is
getting unnecessarily complicated.

~~~
scroot
Yeah stagnation can last for a long time, even as the structural aspects of
that stagnation become overwhelmingly apparent. We are in the "Brezhnev
Period" of computing in that sense

------
thesuperbigfrog
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...](https://malleable.systems/mission/#2-arbitrary-
recombination-and-reuse)

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.

~~~
badsectoracula
> Does this imply some kind of built-in DRM or is it merely copyright and
> licensing? How would ownership and control be enforced?

I think this refers to the _user_ being in control (as opposed to the
developer) and having ownership of their computing environment.

~~~
thesuperbigfrog
But in a Malleable System, the user becomes a developer or something closer to
a developer.

The links in the principles give more details:
[https://malleable.systems/mission/#4-retain-ownership-and-
co...](https://malleable.systems/mission/#4-retain-ownership-and-control)

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.

~~~
jryans
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!

------
fakedrake
I miss vimperator :(

------
MaxBarraclough
This is just silly. No, a C++ compiler cannot be as easy to change as it is to
use. Come on now.

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

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

