11 ms·

The design side of programming language design

188 points by panic 9y ago

everdev 9y ago
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 9y ago
  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 9y ago
    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.
    - 14113 9y ago
      Doesn't the author somewhat argue the opposite? If form follows function, then surely a "new" way of doing dictionaries should have a new syntax?
      - icek 9y ago
        I'll be more specific: if it's the same construct, please make it look familiar. If it's novel, then surely, yes, appearing novel will help me.
        AnimalMuppet 9y ago
        I like your word choice: "help". Not just not hurt; it will help. Different things should look different.
    - jnordwick 9y ago
      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.
      - icek 9y ago
        Sure, I understand. But it's not just a case of new languages coming up and reusing concepts from the set of all currently-available syntaxes; they in fact invent wholly new ones. It's reminiscent of this: https://xkcd.com/927/ https://xkcd.com/927/ Edit: further to your point, I agree that my gripes are merely about an up-front cost, whereas consistency can be helpful throughout your use of a language. Edit again: I essentially seek consistency within and among languages. I don't mean to state one should come at the cost of the other at all times.
      - coldtea 9y ago
        >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?
    - nailer 9y ago
      > All this does is force me If you're a programmer now, you're a secondary audience to the masses of people who will program in the future. If the language is going to have the most impact, what they prefer supersedes what you (and I) prefer. > If there's a good reason for the difference, by all means, go for it. Of course and agreed. Nothing should exist without reason. Antoine de Saint Exupery etc.
  - taeric 9y ago
    This seems to be blurring a use of "design". Not all design is chrome on top of things. Some literally leads to better use. Some design is required for safe use. I think it is oversold, but the book "Design of Everyday Things"[1] goes over this for many common items. There is a long section on doors with many interesting points to consider. [1] https://www.amazon.com/Design-Everyday-Things-Revised-Expanded/dp/0465050654 https://www.amazon.com/Design-Everyday-Things-Revised-Expand...
    - nailer 9y ago
      > This seems to be blurring a use of "design". Not all design is chrome on top of things. You're thinking of syntax as chrome. It is more than that.
      - taeric 9y ago
        Apologies, that is exactly what I was trying to say. Specifically, I was arguing against "Most technologists don't seem to believe that design applies to programming languages at all." I was speculating that this belief is from folks that think design is just chrome.
        nailer 9y ago
        Ah that explains things perfectly, sorry I misinterpreted you.
        taeric 9y ago
        No worries. I should write more clearly and take this as help along the way!
  - seanmcdirmid 9y ago
    I disagree. Most technologists agree design is important in PX (PL + tools), but programmers are more willing to put up with poorly designed experiences in exchange for the latest technology.
- WalterBright 9y ago
  As the designer of D, I can attest that syntax matters very, very much and it is not just a 'personal' issue. Many times I've discovered that altering the syntax for something (not its semantics) can completely transform its use.
  - le-mark 9y ago
    Interesting, do you have an example in mind?
    - WalterBright 9y ago
      The original syntax for lambdas in D worked, but it was so clumsy nobody used it, and people even said "D doesn't have lambdas". Changing it to a much simpler syntax changed everything. old: function double(double a, double b) { return a + b; } new: (a, b) { return a + b; } Currently, the syntax for in/out contracts is being revised for usability: https://github.com/dlang/DIPs/blob/98052839441fdb8c6cc05afccb9a81d084051c4d/DIPs/DIP1009.md https://github.com/dlang/DIPs/blob/98052839441fdb8c6cc05afcc... D has a different syntax for templates than C++, and is far more approachable and convenient: C++: template<class T> void foo(T t) { } template<class T> class S { }; D: void foo(T)(T t) { } class S(T) { }
14113 9y ago
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.
- taeric 9y ago
  See my post regarding Knuth's studies of languages for programming pre 1950. Simply put, mathematics had very little to help in the way of describing iterative processes. Arguably, we are still debating the mathematics of iterative processes to this day.
- zokier 9y ago
  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 9y ago
    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 9y ago
      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).
- 9y ago
azhenley 9y ago
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_notations https://en.wikipedia.org/wiki/Cognitive_dimensions_of_notati...
- amelius 9y ago
  I also think that reading and writing code are often asymmetrically addressed. Some languages are far easier to write in than to read in.
  - azhenley 9y ago
    Definitely! Another factor is how fun is it to write in? That is a hard one to measure.
  - noir_lord 9y ago
    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.
- haskellandchill 9y ago
  Wow I love this framework. I wish there was a book or something, seems a little neglected, but I have compiled a good week or two of papers to read. Thanks!
hood_syntax 9y ago
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 9y ago
  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. :)
  - hood_syntax 9y ago
    I didn't necessarily mean the effects would be positive, just that there would be effects. I would also like to see studies done regarding decisions such as the one we're discussing
  - arwhatever 9y ago
    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 9y ago
      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.
taeric 9y ago
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-Lecture/dp/1575863820 https://smile.amazon.com/Selected-Papers-Computer-Languages-...
stcredzero 9y ago
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 9y ago
  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 9y ago
    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.
munin 9y ago
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.
- zzzcpan 9y ago
  I don't see how good experimental design could benefit from type theory and such. There is no need for an intersection, just the first group of researchers working on programming language design.
  - yorwba 9y ago
    Well thought-out type systems allow decidable inference. Inference lets you omit details about the program that are already obvious from its structure. Omitting obvious details lets you focus on the important parts. Focus helps creating better programs quicker.
- vanderZwan 9y ago
  There are people doing research into this, for example comparing how quickly various styles of loops are understood by beginning users (I wish I could find the talk on that right now). Like you said, it's not taken very seriously though. The problem I have with that is that it seems to be limited to verifying existing structures and solutions. That kind of quantitative research has its use, but is not really helping with exploring novel ideas in human friendly interfaces. For example, I stumbled across Céu a few years back and I have never seen concurrency and timing done in such an intuitive style before[0]. Other things that have blown my mind in the last few years include Halide's decoupling of algorithm and scheduling[1], Jonathan Edwards' experiments with schematic tables as an alternative to if-statements[2], vega-lite's grammar of interactive graphics to declaratively construct interactive plots[3], and aprt.us' hybrid graphics/text programming environment[4]. These are all novel ideas that you cannot find through quantitative measurements about which syntax is optimal. Not that the latter is without use, since it can make people shut up about pointless disagreements (although I think the better solution to ending a holy war on bracket style is to get rid of it altogether and use something one default style like elm-format[5]). And maybe we're also not looking outside of our own field enough. For example, I recently read Steven Pinker's "The Stuff of Thought". There was a chapter discussing all kinds of (human) language paradoxes and hidden rules based on how humans have different ways of thinking about aggregates, and how we use those subconsciously in our daily language. As I was reading it, it made me think "this makes so much sense of how different languages use collections differently, they're just applying different styles of intuition described here!" The funny thing about most language paradoxes is that they require very specific ways of framing a question, and that they disappear when framed differently. Which sounds a lot like how some problems are easier in one style of programming or the other. And that makes me wonder if we can't learn a lot from these branches of linguistics about how we might set up our computer languages in such a way that humans are less likely to make errors of thinking in them. [0] http://www.ceu-lang.org/ http://www.ceu-lang.org/ [1] http://halide-lang.org/ http://halide-lang.org/ [2] https://vimeo.com/177767802 https://vimeo.com/177767802 [3] https://vimeo.com/177767802 https://vimeo.com/177767802 [4] https://www.youtube.com/watch?v=i3Xack9ufYk https://www.youtube.com/watch?v=i3Xack9ufYk and http://aprt.us/ http://aprt.us/ [5] https://github.com/avh4/elm-format https://github.com/avh4/elm-format
deleted 9y ago
[deleted]
misterHN 9y ago
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 {<-}.
deleted 9y ago
[deleted]
jlesk 9y ago
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.
- rolodato 9y ago
  > e.g. I use the terms "Flag" instead of "Boolean" I'm not familiar with THT and this is a nitpick, but doesn't this contradict the first principle? Pretty much every language I've ever used has some notion of "boolean", and I don't know one that uses "flag". Don't want to bash, just curious how that decision was taken.
  - jlesk 9y ago
    Most of the principles are always in tension to some degree, and come down to a design decision. In this case, the shorter, clearer term won out. The two terms are practically synonymous, so if you know what a "boolean" is, you probably know what a "flag" is. In actual use, you rarely interact with the names anyway -- you use `true` and `false` as values like most other languages.
    - 9y ago
lmeyerov 9y ago
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.
labster 9y ago
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

188 points by panic 9y ago

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 9y ago
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 9y ago
  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.
  - 14113 9y ago
    Doesn't the author somewhat argue the opposite? If form follows function, then surely a "new" way of doing dictionaries should have a new syntax?
    - icek 9y ago
      I'll be more specific: if it's the same construct, please make it look familiar. If it's novel, then surely, yes, appearing novel will help me.
      - AnimalMuppet 9y ago
        I like your word choice: "help". Not just not hurt; it will help. Different things should look different.
  - jnordwick 9y ago
    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.
    - icek 9y ago
      Sure, I understand. But it's not just a case of new languages coming up and reusing concepts from the set of all currently-available syntaxes; they in fact invent wholly new ones. It's reminiscent of this: https://xkcd.com/927/ https://xkcd.com/927/ Edit: further to your point, I agree that my gripes are merely about an up-front cost, whereas consistency can be helpful throughout your use of a language. Edit again: I essentially seek consistency within and among languages. I don't mean to state one should come at the cost of the other at all times.
    - coldtea 9y ago
      >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?
  - nailer 9y ago
    > All this does is force me If you're a programmer now, you're a secondary audience to the masses of people who will program in the future. If the language is going to have the most impact, what they prefer supersedes what you (and I) prefer. > If there's a good reason for the difference, by all means, go for it. Of course and agreed. Nothing should exist without reason. Antoine de Saint Exupery etc.
- taeric 9y ago
  This seems to be blurring a use of "design". Not all design is chrome on top of things. Some literally leads to better use. Some design is required for safe use. I think it is oversold, but the book "Design of Everyday Things"[1] goes over this for many common items. There is a long section on doors with many interesting points to consider. [1] https://www.amazon.com/Design-Everyday-Things-Revised-Expanded/dp/0465050654 https://www.amazon.com/Design-Everyday-Things-Revised-Expand...
  - nailer 9y ago
    > This seems to be blurring a use of "design". Not all design is chrome on top of things. You're thinking of syntax as chrome. It is more than that.
    - taeric 9y ago
      Apologies, that is exactly what I was trying to say. Specifically, I was arguing against "Most technologists don't seem to believe that design applies to programming languages at all." I was speculating that this belief is from folks that think design is just chrome.
      - nailer 9y ago
        Ah that explains things perfectly, sorry I misinterpreted you.
        taeric 9y ago
        No worries. I should write more clearly and take this as help along the way!
- seanmcdirmid 9y ago
  I disagree. Most technologists agree design is important in PX (PL + tools), but programmers are more willing to put up with poorly designed experiences in exchange for the latest technology.
WalterBright 9y ago
As the designer of D, I can attest that syntax matters very, very much and it is not just a 'personal' issue. Many times I've discovered that altering the syntax for something (not its semantics) can completely transform its use.
- le-mark 9y ago
  Interesting, do you have an example in mind?
  - WalterBright 9y ago
    The original syntax for lambdas in D worked, but it was so clumsy nobody used it, and people even said "D doesn't have lambdas". Changing it to a much simpler syntax changed everything. old: function double(double a, double b) { return a + b; } new: (a, b) { return a + b; } Currently, the syntax for in/out contracts is being revised for usability: https://github.com/dlang/DIPs/blob/98052839441fdb8c6cc05afccb9a81d084051c4d/DIPs/DIP1009.md https://github.com/dlang/DIPs/blob/98052839441fdb8c6cc05afcc... D has a different syntax for templates than C++, and is far more approachable and convenient: C++: template<class T> void foo(T t) { } template<class T> class S { }; D: void foo(T)(T t) { } class S(T) { }

14113 9y ago

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.

taeric 9y ago
See my post regarding Knuth's studies of languages for programming pre 1950. Simply put, mathematics had very little to help in the way of describing iterative processes. Arguably, we are still debating the mathematics of iterative processes to this day.
zokier 9y ago
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 9y ago
  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 9y ago
    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).
9y ago

azhenley 9y ago

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_notations https://en.wikipedia.org/wiki/Cognitive_dimensions_of_notati...

amelius 9y ago
I also think that reading and writing code are often asymmetrically addressed. Some languages are far easier to write in than to read in.
- azhenley 9y ago
  Definitely! Another factor is how fun is it to write in? That is a hard one to measure.
- noir_lord 9y ago
  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.
haskellandchill 9y ago
Wow I love this framework. I wish there was a book or something, seems a little neglected, but I have compiled a good week or two of papers to read. Thanks!

hood_syntax 9y ago

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 9y ago
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. :)
- hood_syntax 9y ago
  I didn't necessarily mean the effects would be positive, just that there would be effects. I would also like to see studies done regarding decisions such as the one we're discussing
- arwhatever 9y ago
  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 9y ago
    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.

taeric 9y ago

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-Lecture/dp/1575863820 https://smile.amazon.com/Selected-Papers-Computer-Languages-...

stcredzero 9y ago

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 9y ago
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 9y ago
  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.

munin 9y ago

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.

zzzcpan 9y ago
I don't see how good experimental design could benefit from type theory and such. There is no need for an intersection, just the first group of researchers working on programming language design.
- yorwba 9y ago
  Well thought-out type systems allow decidable inference. Inference lets you omit details about the program that are already obvious from its structure. Omitting obvious details lets you focus on the important parts. Focus helps creating better programs quicker.
vanderZwan 9y ago
There are people doing research into this, for example comparing how quickly various styles of loops are understood by beginning users (I wish I could find the talk on that right now). Like you said, it's not taken very seriously though. The problem I have with that is that it seems to be limited to verifying existing structures and solutions. That kind of quantitative research has its use, but is not really helping with exploring novel ideas in human friendly interfaces. For example, I stumbled across Céu a few years back and I have never seen concurrency and timing done in such an intuitive style before[0]. Other things that have blown my mind in the last few years include Halide's decoupling of algorithm and scheduling[1], Jonathan Edwards' experiments with schematic tables as an alternative to if-statements[2], vega-lite's grammar of interactive graphics to declaratively construct interactive plots[3], and aprt.us' hybrid graphics/text programming environment[4]. These are all novel ideas that you cannot find through quantitative measurements about which syntax is optimal. Not that the latter is without use, since it can make people shut up about pointless disagreements (although I think the better solution to ending a holy war on bracket style is to get rid of it altogether and use something one default style like elm-format[5]). And maybe we're also not looking outside of our own field enough. For example, I recently read Steven Pinker's "The Stuff of Thought". There was a chapter discussing all kinds of (human) language paradoxes and hidden rules based on how humans have different ways of thinking about aggregates, and how we use those subconsciously in our daily language. As I was reading it, it made me think "this makes so much sense of how different languages use collections differently, they're just applying different styles of intuition described here!" The funny thing about most language paradoxes is that they require very specific ways of framing a question, and that they disappear when framed differently. Which sounds a lot like how some problems are easier in one style of programming or the other. And that makes me wonder if we can't learn a lot from these branches of linguistics about how we might set up our computer languages in such a way that humans are less likely to make errors of thinking in them. [0] http://www.ceu-lang.org/ http://www.ceu-lang.org/ [1] http://halide-lang.org/ http://halide-lang.org/ [2] https://vimeo.com/177767802 https://vimeo.com/177767802 [3] https://vimeo.com/177767802 https://vimeo.com/177767802 [4] https://www.youtube.com/watch?v=i3Xack9ufYk https://www.youtube.com/watch?v=i3Xack9ufYk and http://aprt.us/ http://aprt.us/ [5] https://github.com/avh4/elm-format https://github.com/avh4/elm-format

deleted 9y ago

[deleted]

misterHN 9y ago

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 {<-}.

deleted 9y ago

[deleted]

jlesk 9y ago

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.

rolodato 9y ago
> e.g. I use the terms "Flag" instead of "Boolean" I'm not familiar with THT and this is a nitpick, but doesn't this contradict the first principle? Pretty much every language I've ever used has some notion of "boolean", and I don't know one that uses "flag". Don't want to bash, just curious how that decision was taken.
- jlesk 9y ago
  Most of the principles are always in tension to some degree, and come down to a design decision. In this case, the shorter, clearer term won out. The two terms are practically synonymous, so if you know what a "boolean" is, you probably know what a "flag" is. In actual use, you rarely interact with the names anyway -- you use `true` and `false` as values like most other languages.
  - 9y ago

lmeyerov 9y ago

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.

labster 9y ago

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