Re: Making technology more inclusive Was: Leaving the GNU Guix community

[raingloom]

On Sun, 2 May 2021 02:15:31 +0200
Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> wrote:

> On Fri, 30 Apr 2021 01:43:37 +0200
> Leo Le Bouter <lle-bout@zaclys.net> wrote:
> 
> > I think that the technicality of software development must be
> > redefined so that the hierarchy between the experienced and the
> > beginner disappears [...]  
> I've been thinking a lot about these topics, and there are radical
> solutions that can work today, but the scope is quite limited.
> 
> Sadly, technology in general is way too complex to enable any
> individual to be able to practically exercise the freedom to modify
> how it works at every level

A lot of complexity is essential complexity. Just as an example: type
systems are more complex than dynamic typing, but they would make it
easier to safely customize code without breaking crucial invariants.
Also s-expressions being "parsable" does not make them much better,
because often you have no way of knowing what type some piece of code
expects. They are better than sed, but they only enable intelligent
refactoring, they don't provide them automatically.

I am often more productive in Haskell than in Scheme, because I don't
waste time tracking down trivial errors that can be caught by a type
system, and because it has (and pervasively uses) typeclasses (aka.:
"interfaces"), so I can just use fmap instead of map, vector-map,
bytevector-map, and so on.
Of course you can add type systems to otherwise dynamic languages too,
so this isn't a dichotomy.

Simplicity also shouldn't come at the cost of efficiency. A compiler is
more complex than an interpreter, but it lets you target a wider array
of hardware.

There is a lot to be improved in programming languages and libraries,
but there there is a complexity bedrock you can't dig under.

Re: Symbolics. Look at a Symbolics demo if you want to see some frankly
embarrassing performance. Genera had interesting ideas but no one who
values making the most of their hardware is going to be using it. And
remember, it was even slower on Symbolics hardware, because they
couldn't iterate their CPU designs quickly enough, whereas general
purpose CPUs just kept getting faster and cheaper. Also Lisp compilers
became better at targeting generic ISAs.

But there are interesting ISA designs that actually do improve
performance. My favorites:
* Mill https://millcomputing.com/
* Reduceron https://github.com/tommythorn/Reduceron
* CHERI https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

As for languages, I want to see more types, generics/typeclasses,
effect systems, and more AOT or multi-stage compiled implementations.


Anyways, complexity probably won't entirely go away. It's very difficult
to make an already complex system simpler, building a new simpler one is
easier, which is sad, because I don't think we can afford not being
compatible with existing software and especially existing hardware.

But having a VM based system could help with both. See the classic
talk: The Life and Death of Javascript.

Oh and we should heed Chris Webber's advice and work on OCAP security.
Because yeah, simplicity also mustn't come at the expense of security,
but OCAP would make things both simpler and more secure.

So, yeah, a lot of this complexity is going to stay, but we can at
least try to not make it worse.

Oh, and social issues won't be solved by technology alone. There will
always be complex technological issues and the distribution of the
knowledge to tackle them is a social issue. We have to make our
communities inclusive for vulnerable people if we want to actually
meaningfully help them. Also sometimes you just have to work on featues
that other people want, not just features you want.

ps.: on that note, go ask some blind people about the state
of accessibility on Linux. It's not pretty.
And stop writing curses TUIs. And in general just go learn about
accessible design and test software with actual humans.

Okay, I'll stop here because this is a complex topic (quite fittingly)
and this mail is already (too) long enough.