
The design side of programming language design - panic
http://tomasp.net/blog/2017/design-side-of-pl/
======
munin
IMO, this is blind spot in the research community right now. The programming
language community doesn't care about the ergonomics of language use and is
only interested in theoretical evaluation of their work with rigorous proofs.

The Human Computer Interaction (HCI) community should care about this, but is
beset by two problems: people in PL don't take people in HCI seriously because
the people in HCI don't do proofs, and, the people in HCI generally don't have
the background to start tackling the mathematical principles of programming
language design.

This seems like a natural time for some kind of cross discipline
collaboration, but the two forces above keep potential collaborators apart. PL
people talk about judgements and sub-structural typing and HCI people's eyes
glaze over, HCI people talk about human subjects, experimental methodology and
statistics and PL people's eyes glaze over.

I've advocated for the creation of a new field of study, call it Programmer
Computer Interaction. No one takes it that seriously though, and the
intersection of researchers that care simultaneously about things like good
experimental design, statistical significance, type theory and constructive
logic seems to be just me.

~~~
tikhonj
My only worry with the HCI community is that they seem to over-focus on
beginners and prioritizing systems that are _intuitive_ rather than
_powerful_. I am absolutely not worried about whether they write proofs or
not!

This might just be an issue of perception on my end, although it seems
consistent with the HCI-conscious PL work I've seen.

Personally, I have two priorities in PL design: expressiveness and aesthetics.
Both of these seem perfectly suited to a design-oriented approach. But are
they a good fit with the sort of work regularly done in HCI? I genuinely don't
know.

~~~
kd0amg
HCI's methods in particular are too expensive to test the conjectures we
normally offer about our designs though. A sizeable team of experienced
programmers designing, building, or maintaining a significant software product
can't be paid for on anyone's research budget, so everyone uses small, short-
term projects written by undergrads (or maybe MS students) instead. The
results may be real enough, but they won't address our actual questions.

Looking in the other direction, I would like to think that even the most
theory-obsessed PL people can appreciate that "intuitive" and "powerful" can
both arise from clean design, but I've also been told, "your proofs are
boring" as though that's a bad thing.

~~~
munin
It might be my cynicism, but in the PL literature I find "intuitive" to be a
very low calorie word. Obviously you would describe your own system as
"intuitive" what are you going to do, write a paper that says "we have a
complicated and difficult to understand system S that..."

"intuitive" is very subjective, I think. I know lots of PL people that think
that functional programming, for example, is intuitive. After many years of
study and practice, I too find functional programming intuitive, but I can
remember a time when I did not, but I could still program. From this I
conclude that something being "intuitive" is very subjective.

Expressive power, on the other hand, I think we can put an objective
definition on. My favorite take of this is Felleisen "On the Expressive Power
of Programming Languages." Of course, what use is something being powerful?

~~~
Pete_D
It always felt to me like when people use words like "intuitiveness" or
"usability", they're all pointing at slightly different things. Matt Fuller's
partitioning of user-friendliness into "easy to use", "easy to learn", and
"easy to use without learning"[0] feels like it might be easier to set
objective criteria for. For your example, you might say functional programming
tends to be easy to use, but hard to learn and hard to use without learning.

(I'm not current on PL/HCI literature, so it wouldn't surprise me if they
already have these concepts, just with different labels.)

[0] [https://www.over-
yonder.net/~fullermd/rants/userfriendly/2](https://www.over-
yonder.net/~fullermd/rants/userfriendly/2)

~~~
zzzcpan
I don't think you can define an objective criteria for any of these terms,
since they depend on previous experience and are inherently subjective.
Instead more commonly used terms to more precisely describe "intuitiveness" or
"usability" are: simplicity, consistency, universality, familiarity and
flexibility.

------
jlesk
I've been a designer/programmer pretty much my entire career and currently
work on a research-centric UX design team. So while I've been designing my own
language (THT, a language that compiles to PHP, aiming to fix most of the
issues with that language), I've been applying usability concepts to the
design.

A few principles:

\- Acknowledging that the user is probably familiar with other languages, so
stay within those conventions when possible. This is inspired by Jakob
Nielsen's maxim that web designers should acknowledge that their users send
99% of their time on other websites.

\- Making the most common activities the easiest. Larry Wall refers to this as
applying Huffman coding to the syntax itself.

\- Safe defaults. Making dangerous operations less convenient than the safe
path. PHP has pretty much the opposite behavior, where many of the default
design choices lead to security issues.

\- Cognitive Load. Minimizing visual noise and the number of micro-decisions
the user has to make. i.e. There should be one (good) way to do it.

\- Preferring shorter, clearer terms over technical jargon. e.g. I use the
terms "Flag" instead of "Boolean" and "List" instead of "Array". One can get
pedantic over the exact meanings of symbols, but during the actual act of
programming, simpler terms can help reduce friction.

The project is at [https://tht.help](https://tht.help) if anyone is curious.

~~~
thethirdone
> e.g. I use the terms "Flag" instead of "Boolean" and "List" instead of
> "Array"

It some cases "Flag" makes much more sense than "Boolean", but when using
logic gates does "Flag" make any sense? Wouldn't it make people think of
actual flags more than an on or off signal.

"List" and "Array" mean different things in CS. Lists cannot be accessed
arbitrarily whereas arrays can be.

> One can get pedantic over the exact meanings of symbols, but during the
> actual act of programming, simpler terms can help reduce friction.

"Simpler" is a matter of perspective. Any experienced programmer should not
have any problem with Arrays vs Lists vs Queues, etc, and they are all
necessary concepts to be able to talk about and program with.

Most jargon exists because it is able to describe things that are not used in
everyday life much more efficiently than without it.

~~~
liamzebedee
Depends on the context. If you're writing a CRUD web app with simple business
logic, is the mental priming of data structures like arrays relevant helping
you develop?

------
lmeyerov
The modern practice of programming is increasingly around social acts of
building software with your team and surrounding community. Yet, evidenced by
even this discussion thread, when someone says 'design' and 'hci', the focus
gets tunnel vision around the individual user experience. Rethinking the
individual human factors of languages is great. But for broader impact, I've
long shifted towards rethinking the socio-technical design.

When I think of what's interesting about Go and NodeJS, and about even more
ambitious ideas for the next 10 years, my head is around languages built for
communities of programmers. Even better, designing languages that improve over
time by leveraging the combined activities of programmers and users, in code
and out.

------
everdev
Really appreciate this article. Some languages feel like their syntax was
designed by developers and others feel like it was designed by designers. It
seems totally appropriate that the UI (language design) should be a different
skill and created with a different mindset than the back end (language
implementation). I hope that this focus can lead to more beautifully designed
languages, not just faster languages.

~~~
nailer
Most technologists don't seem to believe that design applies to programming
languages at all. Programming languages are tools and tools are typically
designed for efficiency, which is measurable - but you'll still hear things
like 'syntax is personal'.

\- It's worth optimizing for more people than fewer.

\- There are a thousand times as many future programmers than there are
existing ones.

\- One can measure how easy it is for a clean-room human to read and create
software in different languages and build something for them.

~~~
icek
I'd be happy to just have less variation in the syntax corresponding to
established semantics; if you're designing a new language, please don't make
some 'nifty' new way of typing out dictionaries. All this does is force me to
hunker down with several beginning chapters of your programming language book
instead of just skipping to the relevant differences from languages I already
know.

If there's a good reason for the difference, by all means, go for it. But if
there isn't, please reconsider.

~~~
jnordwick
Strongly disagree.

So that leaves little room for alternative language paradigms then. If you
want dictionaries to look like JS or Python then what are languages like Lisp
and APL to do, not use coherent syntax. Or what about just making different
use of the limited number of symbols on the keyboard to make the use more
consistent?

Id rather have a more consistent language or one that introduced new concepts
than one familiar in syntax just for the sake of being familiar.

~~~
coldtea
> _So that leaves little room for alternative language paradigms then. If you
> want dictionaries to look like JS or Python then what are languages like
> Lisp and APL to do, not use coherent syntax._

Yes, but what about the benefits from the regularity and uniformity?

------
taeric
I just picked up Knuth's Selected Papers on Computer Languages[1] which has
some fun exploration of this topic. Mostly, I will confess, much denser than I
am probably prepared for. The initial essay on languages before the 1950s was
remarkably interesting. In particular, to see some of the early languages
mathematicians were using.

[1] [https://smile.amazon.com/Selected-Papers-Computer-
Languages-...](https://smile.amazon.com/Selected-Papers-Computer-Languages-
Lecture/dp/1575863820)

------
hood_syntax
A key point (perhaps well known but still very important) is the "let mutable"
vs "let" for declaring mutable variables. It really does change tendencies of
developers by putting the burden of effort on one of two paths, and
encouraging people to write code a certain way can have significant effects on
the end product.

~~~
taeric
Any studies exploring that? Many claims like this are highly prone to
confirmation bias. Specifically, you will notice the times it favorably
changes your tendencies. Ignoring all of the times it was irrelevant or
cumbersome.

Note that I am specifically _not_ arguing against immutability. I have,
however, seen bugs caused both ways. When I was a TA, Java students were
notorious for not understanding why calling "trim" on their string left the
whitespace. To often disastrous consequences. I would be delighted to see
empirical studies to weigh against all of the anecdotes in my head. :)

~~~
arwhatever
It's a kind of trivial side-note, but F# would provide a compiler warning
(configurable to be a compilation error, if you like), if you were to call
myString.Trim() without binding the result to a value, _unless_ you explicitly
pipe the result to "|> ignore". This language in particular has oodles of
great default behaviors, most of which can be overridden, but you must do so
explicitly.

Unfortunately, I have no more data on the real-world results than anyone else.
:-)

~~~
icek
Can I butt in with an aside about how nice F#'s physical unit type handling
is? Seriously, that's some nice design right there.

------
azhenley
There has been some great work in this area (but not near enough!).

One of the more well known pieces that is worth a read is Cognitive Dimensions
of Notations [1]. I've even used them in my research on the usability of
debugging tools.

It is composed of 14 dimensions to evaluate your design (of a PL or UI).

[1]
[https://en.wikipedia.org/wiki/Cognitive_dimensions_of_notati...](https://en.wikipedia.org/wiki/Cognitive_dimensions_of_notations)

~~~
amelius
I also think that reading and writing code are often asymmetrically addressed.
Some languages are far easier to write in than to read in.

~~~
noir_lord
Agreed and our tooling is heavily optimised towards writing code and testing
it now, not reading it and testing it 2 years from now when you trace the code
into the briar patch.

It drives me crazy that in my main editors/IDE's of choice I can't just _hide
all traces of comments_ when I'm writing code until I'm ready to comment it up
or that I can't layer comments, since half the languages now have annotations
for everything from documentation to configuration either built in or as add-
on's.

It's a lot of noise when you trying to grok just code and gets in the way.

------
stcredzero
That book cover -- A bicycle frame with only right angles!? Is that supposed
to be ironic? Anyone with "mechanical sympathy" should be gritting their
teeth.

~~~
catpolice
Yeah, I was cringing the moment I saw it. No rake on the fork? All that extra
frame weight, only to introduce joints that maximize /lateral/ flex? Imagine
the stress that top tube joint must be under in even normal riding conditions.
This is a bike designed by a graphic designer who intends to decorate a wall
with it.

~~~
stcredzero
_This is a bike designed by a graphic designer who intends to decorate a wall
with it._

There is a key analogy here for programming language design!

The analogy also extends to specific languages. There are some bikes which are
keenly optimized for short distance performance. There are other bikes
optimized for long distance performance. There are some bikes which are
optimized for comfort. Yet other bikes which are optimized for folding
compactly.

All of the above are valid designs, just for different contexts.

------
labster
Coming from the Perl 6 project, it feels to me like design is a major part of
modern computer languages, like Perl 6 and ES6+.

Perl 6 started with its design documents[0] -- the apocalypses led to the
exegeses, which finally settled into a synopsis. The Perl 6 language itself is
not any of these: The test suite defines the language, but the reasons they
are the way they are came first. It has design features like hyperoperators to
make parallel code easier to write -- which of course should encourage people
to write parallel code.

Perl 5 is explicitly a postmodern language[1], and Perl 6 is the same but
more. From my point of view, Python looks like it has a strong modernist
philosophy. So I'm not really getting where OP is coming from.

[0]: [https://design.perl6.org](https://design.perl6.org) [1]:
[http://www.wall.org/~larry/pm.html](http://www.wall.org/~larry/pm.html)

------
14113
I think this article misses a crucial point with it's phrasing, or
construction of the "design vs mathematics" tradeoff. Mathematics is superior
for underpinning programming languages because it is _universal_. Design, like
art, relies on a shared view on the world to be appeasing. Design from the
70's, or 80's is often unappealing to modern viewers because of the lack of
shared experience with the designer, for example.

Mathematics solves this by appealing to a shared underlying "truth", that
allows not only programmers with different backgrounds, but also computers to
understand and process a programming language.

~~~
zokier
What do you think programming languages are standing upon if not math?

And I don't think math really "solves" any of the issues that are on debate
here. You still need language and notation to express your precious maths, and
that falls to the very same pitfalls as what is seen in PL design.

~~~
kd0amg
_What do you think programming languages are standing upon if not math?_

Many do, especially in academia, but quite a few seem to be standing on a
combination of "this looks like it'll do what I want" and "this interpreter is
the spec."

~~~
marktangotango
Indeed, It's almost as if the gp has never seen cobol or early fortran. Zero
theoretical basis for either of those very popular languages (for their time).

------
misterHN
you have a matrix, one axis is names of programming languages and the other
axis is names of things a language can do

the entries are 0 or 1.

If language L can do thing T, then there is a 1 in in cell L,T. Otherwise
there is a 0.

For example, a thing could be, "you can feed it a math text and it will give a
list of defined terms and expand the definition of any term in the list in the
signature {<-}.

