4 ms·
While we're writing the wrongs of badly specified interfaces, can we please kill this stupid obsession with "writing code" to get work done? Code is buggy. It's
by peterwwillis 8y ago
While we're writing the wrongs of badly specified interfaces, can we please kill this stupid obsession with "writing code" to get work done? Code is buggy. It's difficult to write well, you have to write 10,000 tests for it, you have to have a testing framework, complex procedures to move it through pipelines and roll it back and version control it and debug it and maintain it and deploy it. It's annoying.
I don't want to hand-craft a file like a 14th century woodworker carving out letters on blocks. I want a program to just make the config or do the appropriate action for me, based on questions it asks me. I shouldn't have to write code to do that, or treat a file as code, or use a "language" to get work done, whenever it is possible (i.e. most of the time).
The only times I ever want a "language" is when I need to do something complex and iterative, like crafting a search query, or constructing a simple one-line pipeline of pre-defined functions. Aside from that, crafting configuration and performing operations should have a real user interface.
- nathanaldensr 8y agoI can't tell if this is sarcastic or not, but it doesn't seem to be. Binary computers are precise in their operation; that's why we use programming languages: to make it easier to create the underlying instructions to perform calculations. You are assuming that human answers to human questions in imprecise human language can even be converted to binary instructions. If it were that easy, general AI would've already been invented and self-driving cars would already exist.
- peterwwillis 8y agoYou're taking it too literally/assuming too much. It is super easy. Watch. $ awscli s3 ls Unable to locate credentials. You can configure credentials by running "aws configure". That is stupid. Let's fix it. #!/bin/bash [ -r .awssettings ] && . .awssettings [ -n "$USERN" ] || read -p "What is your username? " USERN if [ ! -n "$PASS" ] ; then read -s -p "Enter your password: " PASS ; echo "" fi [ -n "$REGION" ] || read -p "What region should I run this in? " REGION echo awscli --region $REGION --user $USER --pass $PASS "$@" \ && echo -en "USER=$USER\nREGION=$REGION\n" > .awssettings $ ./foo.sh s3 ls What is your username? peter Enter your password: What region should I run this in? us-east-1 awscli --region us-east-1 --user peter --pass blahblah s3 ls This is a contrived example, because of course AWS wants obscure tokens and secrets to log in, but the point is that it was trivial to write an interface that helped the user out. The fact that this isn't the default is stupid. (The argument that it fails by default to "help programs out" is dumb, because a simple argument like --no-questions which becomes default without a tty is easy)
- lmm 8y agoAnd how do I put process controls around that? How do I have confidence that someone I'm trying to help over the phone will see the same screens and get the same questions that I do? What do they do if it asks the wrong question? Having simple, predictable, consistent behavior from our tools is far better than trying to guess what the user wanted.
- peterwwillis 8y agoYou must live in a different universe from me. In my universe we have been successfully addressing those problems for over 60 years. Also, our tools aren't simple, or predictable, or consistent, which is why our universe created this software called "Docker". It helps, but there's no UI for anything (unless you pay a lot of money) so it's still a pain.
- lmm 8y ago> In my universe we have been successfully addressing those problems for over 60 years. In my universe people have been pushing "visual programming environments" for something close to 60 years, and they're still awful and haven't caught on. Over the last 10-20 years programs have taken a step away from "wizard" style interactions like you describe, as it turns out that a simple, automatable config format is more useful than a step-by-step interaction. API design has started to realise the importance of understandability over magic, e.g. the new generation of 3D graphics APIs are much less "do what I mean" than the previous generation.
- smhenderson 8y agoSo while obviously a bit data UI wise are CPAN's config script and/or the "make menuconfig" script for compiling a Linux kernel good examples of what you're talking about? While I haven't run menuconfig since the 90's I find myself setting up CPAN on just about every server I manage. Although a bit dated like I said above it's still very easy to use and provides clear instructions on why you should or should not choose certain options based on the environment you are setting up. Just wondering if these are good examples or not. If not, do you have any other examples of good config programs you can point to?
- peterwwillis 8y agoReally any of them are preferable to nothing at all. Yep, CPAN at least does the bare minimum to get you up and running and saves its configs, you don't have to do a mini research project just to get it working. I think Jenkins is a good model for basic web UIs. I wish tools like Terraform and Consul had a setup UI, but I guess that's how Hashi makes money.
- smhenderson 8y agoThanks, I’m not familiar with Jenkins but I’ll check it out. I have to admit that I used to spend time reading and painstakingly setting each and every option in CPAN, some of the time not even understanding why or what I was setting, but these days I just say yes to “do you want me to try and configure as much as possible automatically?”. It hasn’t failed me yet! :-) Any tool that can do the heavy lifting by poking the environment a bit like that seemed to fit what you were talking about so that’s why I mentioned it.
- lmm 8y ago> Code is buggy. It's difficult to write well, you have to write 10,000 tests for it, you have to have a testing framework, complex procedures to move it through pipelines and roll it back and version control it and debug it and maintain it and deploy it. It's annoying. All of that applies to config, or to any other solution to the problem, because the complexity is (usually) inherent to the business problem you're solving. The difference is that in config, none of that tooling is available. If I put some complex logic in config I still want to version control it and debug it and test it - but I can't. Give me a real programming language where at least I have standard tools available for managing complexity. > Aside from that, crafting configuration and performing operations should have a real user interface. Code is the best user interface anyone has ever come up with for specifying complex logic, precisely. Mathematicians use something very similar, not because maths is done on computers but because they have the same need to communicate precisely. Lawyers use a "plain english" language that ends up being more verbose and less readable. Any "visual" format, including every configuration UI I've seen in practice, is even worse.