kewp's development

another one on trust.txt

i'm going to take another stab at this
though really just through frustration.
i'm afraid this post must just be garble
but let's see.

i am frustrated by hacker news.
largely because it seems it's full of a lot of
earnest people missing something i feel
i know to be true, and that is that
software can be 'fixed' in a real way.

i've gone through all this before (in this blog)
but perhaps this time round something will be
made clearer. everyone tries to do this,
all programmers try to write another language
or invent another system. which to me speaks
to the fact that we all have this underlying
sense. but then it gets bogged down by doubt,
or just despair. do you really think you have
'solved' it? there is nothing to solve. yes,
your idea seems nice but what about my idea.
what happens when 'x'? i think what you've
done is just OO but with signals.

something really struck me about the Elm
programming language. something about it -
it has to work. it's famous tag line is
"no runtime exceptions". it can't break.
that is quite remarkable. and it is, again,
frustrating that it's hardly spoken of by
web developers. it's been around for years
and it's still fringe.

but i'm not interested in prosletysing
people to Elm. rather i want to have a
discussion about what Elm means - what does
it take to trust code?

i got the idea of trust largely from the author
of PureScript
He takes a piece of javascript code and breaks
down how much trust you must have in the
surrounding environment (which brings about fear)
to use / interact with your code correctly.
It's a great article. Ultimately he argues
that javascript cannot be fixed (i.e. you need
to use another language like Purescript) which
I agree with.

But I feel as though a stronger point can be
made, or the same point but in a way that's
less refutable. Something so simple it forces
people to see it. Right now people just think
of choices of programming languages - should
I use ReasonML? Oh well thats 'functional
programming'. Rather just use TypeScript.
This bothers me - it's not about what system
you use. We should instead have... some kind
of irrefutable fact that has been discussed
ad nauseum about why software is bad. I think
this article gets closest to that but it
needn't be about why you should use his
programming language or the other functional
languages. This isn't about functional
programming. This is about why software fails.
And how they needn't. it's not about one
programming language 'product' or one system
or some person's pet project. It's a principle.
An engineering principal. And a special one -
because software lives in a purely abstract
place. Even though it needs to interact
with the outside world, you can still
mitigate all possible issues by anticipating
every eventuality.

What interests me the most is this: what will
it take to convince people of this? Say I'm
right - say there is some straight forward
principal one can apply to any software system
and when used will render all software errors
impossible. What would it take to make this
a global phenomenon? How do I convince people
of this? How do we stop all this inordinate
waste of time and money and get over the
notion of an 'error' once and for all?