Programming Languages are the Least Usable, but Most Powerful User Interfaces

http://blogs.uw.edu/ajko/2014/03/25/programming-languages-are-the-least-usable-but-most-powerful-human-computer-interfaces-ever-invented/

by newgame • 12 years ago

131 100 12 years ago

blogs.uw.edu

AdrianRossouw8• 12 years ago

Yeah. I've come to realize that the hard way.

It is also what it comes down to w.r.t. code-over-config.

To make a system sufficiently configurable, you end up having to re-invent a turing complete language inside it's configuration files, so it starts looking more like lisp.

This is due to the [1] Inner Platform effect.

The only interfaces I know of that's expressive enough to drive a turing complete language is either flowcharts, or actual code.

This is kind of why I feel that systems like gulp are just superior to grunt, because ultimately the config format can never be expressive enough to solve all the problems, and there's just so much less work to write-what-you-mean, the first time. properly.

This also relates my newly adopted philosophy w.r.t. software complexity. [2] Simple vs Easy.

[1] http://en.wikipedia.org/wiki/Inner-platform_effect

[2] http://daemon.co.za/2014/03/simple-and-easy-vocabulary-to-de...

coolsunglasses• 12 years ago

To make a system sufficiently configurable, you end up having to re-invent a turing complete language inside it's configuration files, so it starts looking more like lisp.

You need dependency injection too, unless you're going to let people just smash the definitions of existing code.

A good demonstration of safe, powerful, and type-checked configurability is Xmonad.

http://xmonad.org/

ericHosick9• 12 years ago

To make a system sufficiently configurable, you end up having to re-invent a turing complete language inside it's configuration files...

Isn't source code basically a configuration file for the compiler/interpreter?

because ultimately the config format can never be expressive enough to solve all the problems

And if so, I don't think this statement is quite true. Source code is expressive enough.

Configuration files give us flexibility but not expressiveness. Source code, as it exists today, gives us expressiveness but not flexibility[1].

This disparity should be a big red flag that we are doing something really wrong.

This disparity, in my opinion, is caused by the abstraction we use to communicate information between systems within source code: parameterized sub-routines.

A programming language that doesn't use parameterized sub-routines is basically a configuration file. This gives us both expressiveness and flexibility.

[1] Flexibility is within the context of config-vs-source code and ops post. Programming languages are very flexible when you know them.

kyllo6• 12 years ago

What would be an alternative to parameterized subroutines, though? Is there another way to avoid re-implementing an algorithm every time you want to use it? And keeping all source in one gigantic file?

Goladus3• 12 years ago

Isn't source code basically a configuration file for the compiler/interpreter?

Source code is input, not configuration. Every time you run the compiler, you give it different source code. The whole point of the compiler is to transform source code.

Configuration is "input" that is not expected to change very often, but that the application developer can not guarantee will never change. Configuration falls into a few categories:

1. Context-specific inputs that can not be predicted or discovered automatically by the application. (For example, the DNS zones the process is expected to host - named.conf)

2. Inputs that are not expected to change very often, but should be easy to change if necessary. (ssh client or server settings)

3. For applications with interactive user interfaces, customization and changes to the default interface.

For the vast majority of applications, a text file capable of expressing simple data structures is more than sufficient. Others advocate using only a database, but only to make configuration dynamic so explicit reloads aren't necessary, not to make it more like a programming language.

The source-vs-configuration question is usually only be an issue when dealing with large, complex applications with very general specifications.

jasey• 12 years ago

"To make a system sufficiently configurable, you end up having to re-invent a turing complete language inside it's configuration files"

This sums it up perfectly, I've had clients say 'oh and it has to be 100% customisable' and I've been like 'it is, it's called HTML, CSS and js'

nercury• 12 years ago

Turing-complete config files do not sound like proper config files :)

skywhopper2• 12 years ago

Using DSLs for configuration can be incredibly useful: allowing a single "config file" to respond to its environment and work differently in different contexts.

Of course at some point, you're just calling your program your config file. But don't tell Emacs users that config files can't be turing-complete.

AdrianRossouw8• 12 years ago

they can be turing complete. that just looks like lisp.

there are other turing complete DSL's too though. Puppet's isn't though...

mitchty• 12 years ago

You know I'll say emacs is a great example of how its a great idea to make your "config" files a programming language.

I'll also say it's a horrible idea to make your "config" files a programming language.

Overall though its hard to argue it doesn't do the job.

davidgerard4• 12 years ago

It's an antipattern the inexperienced frequently fall into. Just one little extra bit of functionality, and ... whoops! Suddenly, you can program there, so now you will have to program there.

Same applies to markup languages. TimBL held HTML back from Turing-completeness for ages, then JavaScript came along.

jt21903• 12 years ago

  > ... whoops! Suddenly, you can program [in the
  > configuration files], so now you will have 
  > to program there.

What's forcing a user to configure a system if they don't need to make changes? Why is it preferable to use something functionally restricted rather than a programming language to configure a system?

collyw• 12 years ago

Django embraces programming in the config files. They are pretty much all Python code. Means you can do some fairly cool stuff. It ends up making a lot more sense to configure a Python framework in Python, rather than XML or something else.

kyllo6• 12 years ago

Yep, this anti-pattern is well-known enough to get its own Wikipedia entry: http://en.wikipedia.org/wiki/Softcoding

klibertp• 12 years ago

Just one little extra bit of functionality, and ... whoops! Suddenly, you can program there, so now you will have to program there.

That's an argument for programming languages in configuration, not against. It's just that we need good languages there, so that if you "have to program there" it's not a painstaking experience.

Designing a programming language is hard. Really, really hard. Or rather it's extremely easy to make completely unusable language, especially if it wasn't designed as a language from the start. You don't want to do this to your users and to yourself.

You either just don't include a programmable configuration, which is a fine tradeoff, or you include a "real" language from the start. For scripting languages it's easy, just use themselves. For compiled languages it's even easier: just use Lua or Scheme and be done with it.

But please, whatever you do, don't invent your own configuration (what's wrong with standard "key = value" format anyway?) format and if you do DON'T try to gradually extend it into a language. It will be hideous, unusable, insecure, unreadable, impossible to debug, buggy like hell and will haunt you forever in nightmares.

That being said, don't be afraid to experiment and try to build a language if you want. Just don't force it on others in production environment until you're sure it's not as described above :)

skywhopper2• 12 years ago

Obviously there's lots of research to be done on the best ways to design programming languages and the best ways to teach them.

However, the headline presumes there can be some universal standard of measuring what we can "usability" that's somehow separate from the practical "usefulness" of the tool itself. Tools that do fewer things can be made easier to use that tools that do many things. Turing-complete programming languages can be made to do anything the computer can do, which is a lot. And so there's going to be a hard limit on how "usable" they can be. Not to say we're even close to reaching that limit, but you'll never make a programming language that's as "usable" as a screwdriver, and that's okay.

joe_the_user3• 12 years ago

Well, I'll admit that a rather debatable claim. But article provides reasonably good backup for that claim using the tools of professional user interface design, a field that has become a lot more systematic in recent years. Towards the end of the article, he describes a number of metric which can be used in measurement of programming languages as task-accomplishment tools.

kingmanaz4• 12 years ago

The "glue-language" philosophy underlying Tcl can strike an optimal balance between usability and power:

http://www.yosefk.com/blog/i-cant-believe-im-praising-tcl.ht...

Shells partition away sophistication.

dllthomas5• 12 years ago

"Shells partition away sophistication."

Could you elaborate on this? It sounds interesting, but I'm not quite grokking.

kingmanaz4• 12 years ago

I'll try.

Programming doesn't have to be hard. As in speech, the more one says, the less one means.

I know shell isn't going to with this popularity contest, but a return to it is what's badly needed in CS today. Instead of attempting to recreate the shell in C# or Java's supplied libraries and subsequently becoming frustrated when interaction with the "outside world" is clumsily accomplished through a FFI pinhole, just use the shell as it was intended: as a lingua franca between utilities. Write what requires prolog in prolog, what requires c in c, what requires awk in awk, etc. Use flat file databases such as starbase or /rdb and avoid data prisons such as MSSQL, Oracle, MySQL, etc. Make all of these utilities return sane return values and spit out JSON formatted output. Finally, tie it all together with shell. If you need a UI, code it as a thin layer in Tk, python/pytk, ansi c/gtk, or, consider pdcurses, etc. Profile your program and find any weak links in the chain. Recode in a lower level language only when needed.

Weighing the tradeoffs of adding language features is a sign of a false dilemma; rather than a single bigger or smaller language, what is actually needed are more specific languages which speak to each other through a lingua-franca. Tcl accomplishes this communication through a string representation, Powershell through an object representation, etc. Again, rather than choosing one solution over another, use them all where they work best. This is where Unix got it right all those years ago; Unix isn't just a slightly more stable platform for running today's bloated and monolithic software, rather, it's an elegant system for connecting maintainably-small utilities. The shell glues said utilities together into programs. Such an approach combines the best of high and low level programming, reuse and specificity, tradition and novelty, etc.

AdrianRossouw8• 12 years ago

Tcl is actually really powerful and fun.

Everything is a string is a bit quirky, but it's just lisp-like enough to allow you to do some really nifty things.

I don't ever want to write anything seriously in it again though, and I can't see myself starting a new project with it.

pjmlp• 12 years ago

I wrote many lines of Tcl back in the early .com days, as we had an in-house server stack based on Apache, similar in certain ways to AOL Server, but doing ORM stuff people only discovered a decade later with Ruby on Rails.

Only used a few times later to script Websphere via Jacl.

However, nowadays I don't have any reason to touch it as well.

jasonwatkinspdx4• 12 years ago

I think it's a massively fascinating question to ask "Why didn't something like hypercard become the web?"

And please don't knee jerk some story about some Apple decision making. That doesn't matter. If the hypercard model had the value I think it does, someone else should have surfaced and gained momentum.

That didn't happen, and while I don't have the answer for why, I think it would shed some light on why "code as a user interface" for non coders has had only limited successes (Spreadsheets, SQL).

david927• 12 years ago

For Hypercard, I think the answer is that, at the end of the day, people will write off any technology that gets "stuck". Spreadsheets are amazing (I have a secret deep love for them) but you can't code with them without hitting a wall of what they can do. SQL and declarative languages are better but still suffer from that granularity issue.

[Disclaimer: I work on a hypercard-like declarative language.]

toby4• 12 years ago

It's arguable that Excel is the most widely used "programming language" depending on your definition. If you've spent much time around certain business professionals, you'll see that they really push spreadsheets to do unexpected things to solve their problems.

I've actually wondered why there hasn't been more exploration into visual / declarative programming since it has the appeal of being very easy to get started.

AdrianRossouw8• 12 years ago

visual / declarative programming ... has the appeal of being very easy to get started

Does it, really? I spent the last 2 years building systems that ran off of workflows (as in flowcharts), and I think now that they don't make the big hurdle (capability for abstract reasoning) any easier at all.

They are fine to document and communicate things, but as input they are just flawed (except for some very very specific niches).

macNchz• 12 years ago

Excel is very often abused and made to do things it should definitely not be doing (massive files, enormously complex formulas). In many business situations, this may only lead to frustration and lost productivity, but in finance in particular the implications can be huge(1), and a faster, more stable, testable and transparent/auditable solution should definitely be found for critical applications.

[1] http://www.forbes.com/sites/timworstall/2013/02/13/microsoft...

Nekorosu2• 12 years ago

I'm not sure what you mean by more. Visual programming was explored a lot and became a popular approach for building non-standard interactive multimedia applications. I think the most famous and inspirational piece of this kind of software is Max/MSP which started as an interactive computer music environment (created by academic) and evolved into multimedia processing/generation powerhouse.

It's commercial and proprietary software but it has an open-source "cousin" called Pure Data.

Both applications were created by Miller Puckette and his creations inspired a lot of more or less similar systems.

One worth noting is vvvv. It doesn't have musical programming roots and uses some unique and really powerful concepts to make graphics programming easier. http://vvvv.org/documentation/of-spreads-and-slices

Also it's a very pragmatic system which is built and maintained by people who do really cool and sometimes complex projects. http://www.meso.net/vvvv

adw• 12 years ago

Visual programming languages have gone a long way in some niches, too; LabView (lab automation and experimental logging) and Max/MSP (audio and video synthesis) come to mind.

frik2• 12 years ago

There was, called Visual Basic 6 (1998), the best RAD tool for Windows back then. It's the full version of limited VBA that comes with Office. Instead of releasing a version 7, Microsoft scarified it in favor of dotNet Framework idea.

Hundreds of thousands developers are still pissed at Microsoft in 2014 (according to Wikipedia): http://en.wikipedia.org/wiki/Visual_Basic

(I moved on to various other languages, but I still have VB in fond memories.)

Rusky• 12 years ago

A couple of recent, interesting explorations:

Subtext (http://subtext-lang.org/) - in particular check out the video on "schematic tables," which is very immediate and direct like Excel but better for general purpose.

Some of Bret Victor's work: Inventing on principle (http://vimeo.com/36579366) Media for the Unthinkable (http://worrydream.com/MediaForThinkingTheUnthinkable/) He has a lot of examples of similar interfaces for more domains than just what Excel is good at.

Another example, although much less so, is Unity's editor- property editing and level editing are very immediate and visual even for things like behavior.

mkr-hn2• 12 years ago

There was a big underground movement using Visual Basic and variations on dos32.bas to do interesting things on top of AOL's client.

jasonwatkinspdx4• 12 years ago

That sounds fascinating. Is there a good write up for someone totally unfamiliar with that world and that doesn't want to get into the weeds, but is interested in what the community was like?

tiglionabbit• 12 years ago

Hypercard did take over the web. It's called Flash.

Even the JavaScript system we have now seems highly inspired by it.

jasonwatkinspdx4• 12 years ago

This is interesting, can you elaborate? My reaction is to disagree, I don't see any meaningful similarities.

ThomPete• 12 years ago

IMO It didn't happen because Hypercard does not provide a paradigm shift in application only in interpretation.

It's the same discussion you see around why 3D interfaces aren't more popular.

The second we need to manipulate more real world objects (like in robotics for instance) in real time, the more visual kind of programming languages will gain more popularity as they will provide faster access to controlling the already optimized algorithms.

0xdeadbeefbabe• 12 years ago

Yes, yes they are. I'm not a programmer, but a user with a refined taste for java--hah just kidding! Clojure isn't so bad though. Java is an interesting interface or programming language because you need an autocomplete editor i.e. another interface to really enjoy it. Don't forget maven and ant for libs and builds.

But some people are probably comforted by java ui maybe because it is so structured.

Edit: remember ant and maven.

joe_the_user3• 12 years ago

Wow, there are many ways to go with this...

I would claim that natural language is the most usable and the most powerful user interface. We humans have been relating with it for quite a while and there's no sign of a let-up.

And most programming language either contain fragments of natural natural language or can be translated into such fragments. Yet, the author is right, programming languages are "least usable". Indeed, consider SQL was created specifically to be usable like a natural language but it now considered more unusable than even an average programming language. What gives? (I have my suspicions but I wonder what people think).

thaumasiotes• 12 years ago

Utterances in any natural language are always ambiguous, often hopelessly so. It works out because the speaker and listener are cooperating towards a shared goal; the removal of this assumption of cooperation is why contracts and legal codes get longer and longer over time as they try to deal with the fact that they can't actually specify anything the way they'd like to.

The computer isn't like another person, and we'd really prefer to have it do what we say rather than guess what we want and act accordingly. Indeed, we are not yet able to have a computer guess what we want to any respectable accuracy.

(Think of it this way. In some languages you can provide compiler hints that say, for example, "this variable will usually be an integer, so please optimize for that". A natural language consists basically 100% of compiler hints and 0% of instructions.)

joe_the_user3• 12 years ago

The computer isn't like another person, and we'd really prefer to have it do what we say rather than guess what we want and act accordingly.

From the point of a view of a programmer, yes.

But isn't this kind of the division point between a "good user interface" and a programming language.

Lots of user level system are intended so the computer guesses what you want and does that.

PeterisP3• 12 years ago

In all areas where we need to transmit exact information or describe something in great detail - wether it's 'legalese'/contract language, mathematical notation, musical notation, computer code - we've found out that natural language doesn't fit it well, and chosen to use something less natural and more exact.

This is the sign of a flaw - we've stumbled upon the limit in many distinct areas, and ceased to use natural language in them.

If you want an architect to describe the builder how large a construction pit should be - you don't want a long description in natural language, you want a very specific diagram; i.e., natural language is not the most usable thing for this scenario. If you want to 'discuss' your computer which file to open, then clicking in a GUI is much more efficient than having the folder contents read to you and speaking the file name - since such technology exists, but only people with severe vision problems choose to use it. In niches where accuracy is important - say, "chat" between pilots and air traffic controllers - you migrate away from natural language by discouraging most phrases (e.g., words "to" and "for") and trying to replace them with domain-specific codenames and "formulas" for saying phrases with very exact meaning.

Natural language is a useful general-purpose UI; but for any specific niche we can have a better specialized UI than that - wether it's a controlled almost-natural language, a visual UI, or some specific notation like music scores.

vincvinc• 12 years ago

I agree with the you on the builder/construction pit and the air control examples. But don't underestimate what natural language can do for humans interfacing with computer systems.

The file system example:

"Computer, show me the document jake sent me the other day."

"Computer, I want to continue writing my thesis."

"Play the cute cat video again!!!"

Of course, it'll need agents with more deeper semantic understanding, advanced AI, NLP, computer vision, etc that is on the market today, but this is not a problem of natural language. See the work wit.ai is doing, we're pretty much there.

anon4• 12 years ago

Reminds me of the different ways the environment is set up in Windows and Linux. In Windows, when you want to edit your environment variables, there's a simple configuration utility with a list of them, you click and edit and it all takes effect immediately. In Linux, there's a chain of events where different shell scripts are ran in some way at different levels of the bootup process depending on strange and arcane factors, so when you edit ~/.profile that only takes effect in your terminals and not in applications started by the DE, but also not in tmux, because it's not sourced by ~/.bashrc somehow. And once you puzzle out the chain of command and edit everything you have to log out and back in. And when you want to make changes to the global environment, there's /etc/environment, /etc/profile and /etc/profile.d/yourscripthere.sh. Only one of these is the right choice but only for a specific distro, DE and shell combination. Oh, and if somehow you manage to source a script twice your PATH gets duplicate entries in it. Not technically a problem, but it kind of irks me.

Programming Languages are the Least Usable, but Most Powerful User Interfaces

Related Stories