Anonymous 08/12/2017 (Sat) 09:12:46 No. 10693 del
(54.77 KB 554x830 1502409897755.jpg)
I don't know what psychedelic RCs you guys have managed to acquire, but I know Sasha would have been impressed.

>>10688

>this can be fixed by advocating for single purpose programs with lean code and minimal features

It can't, really. While I think there's a lot of truth in C.A.R. Hoare's quip here:

http://harmful.cat-v.org/software/

the fact is, people want complex behavior from software, and they want software that is simple for them to use in order to be able to do it. Software that looks simple but performs complex actions invariably hides a great deal of engineering complexity underneath. Take the example of web browsing. Very few people want to type in a command to fetch a URL, then pipe it to a command to (conditionally) handle the TLS handshake, then pipe that to a program to handle the parsing of the result, then pipe that to a program to interpret the Javascript, then pipe that back to the DOM parser, then pipe that to a program to decode the media container the video they want to watch uses, then pipe that to a program to actually decode the codec, then pipe that to a program to launch a GUI window to display the result. Frankly, you lost 90%+ of people at "type in a command" of any kind. They don't even want to type in "firefox". They want to click an icon, or, better yet, tap it on a touchscreen. They don't want to type a URL. They want to tap on the Facebook thumbnail that pops up in their browser (which they launched with a tap) and go immediately to their Facebook feed or homepage (or whatever it's called), because they don't even log out when they set their tablet or phone down.

And the example above, as ridiculous as it is, is only one level of granularity. How do you define "single-purpose"? Should fetching a URL, performing a TLS handhake, then handling the further symmetric encryption all be handled by the same program, or should that be three separate programs? After all, negotiating the connection is one task, handling the TLS handshake is another, and handling the symmetric encryption is yet another.

>with room for the user to build and add to it.

The most realistic outcome would not be people building a bunch of unique, simple, auditable solutions, but most people building nothing. Most people have neither the interest nor the ability to implement even simple algorithms. Even ostensibly educated computer programmers sometimes fail simple whiteboard interviews where they're asked to implement a simple algorithm in pseudocode.

Message too long. Click here to view full text.