6 ms·

What makes you think language designers have no experience of programming? Rest assured that the Simon Peyton Joneses and Martin Odersky's of this world have be

by mafribe 11y ago

What makes you think language designers have no experience of programming? Rest assured that the Simon Peyton Joneses and Martin Odersky's of this world have been doing a lot of programming in their time. To be sure, they do program applications that are quite different from what 'bread-and-butter' programmers do, and that might influence their taste in programming language features.

hyperpape 11y ago
PHP and Perl were both written by people actively running into limitations of their existing tools (results may have varied!). Honestly, I'd reverse it and instead of looking for exceptions, ask which languages the OP was thinking of? I'm sure they exist.
DasIch 11y ago
Many people use software all the time. Software developers obviously do. That doesn't mean they are magically able to themselves create applications that have a good UI and UX. In fact a lot, possibly most, are really bad at it. The same goes for language designers. I don't think that they have no experience programming, they obviously do. I just don't think that it matters all that much. Additionally the experience of developing software varies widely. Some use IDEs, some don't, some people use debuggers, others use print statements, some people use profilers, others never have a need to. Even if you have programming experience, your particular experience will be very different from the experience other people have, even developing in the same language. So no matter how little or much programming experience you have, you can't create a great programming experience based on your experience alone. You need to have an understanding of other programming experiences.
- mafribe 11y ago
  You need to have an understanding of other programming experiences. Part of the problem of designing programming languages is that there is little agreement and extreme heterogeneity in the opinions of what is and what isn't a good idea in programming language design. Ideally, PL design statements like "language X is better than Y" should be accompanied by rigorous empiricism. Clearly, the field of PL design has a measurement problem. PL design doesn't have empirically validated and methodologically sound studies that quantify the "dividends" of one PL or PL feature "over another, such as reductions in defects, program size, or development time. Of course PL development isn't the only field that lacks easy empirics. And PL development shouldn't let the perfect be the enemy of the good. It's quite clear that PL features do have positive productivity consequences, with garbage collection being the most clear-cut example. The interesting question is what do we do the absence of good empirical methods. There are several valid answers to this question. One of them is to be strongly guided by mathematical beauty and elegance. This is the family of languages that started with Lisp and is today represented most purely by Haskell, Scala, Clojure, Ocaml and F#. The key ideas from this family: garbage collection, higher-order functions, rich types, have been accepted by the programming mainstream. One wonders if these ideas would have been discovered if John McCarthy had studied the programming experience of working Fortran / Cobol programmers, rather than Church's purely theoretical lambda-calculus.
- bad_user 11y ago
  In order to have an understanding of what a programming experience is, the designer either has to look at his own experience and also observe others, possibly taking input from likeminded people. Further than that, in language design you obviously can't do A/B testing, since the cost would be too high, focus groups are in general fundamentally flawed because you can validate whatever you want and UX studies in language design would be too superficial, unless performed for a long period of time, but then you get to the same problems the scientists have to deal with in studies on nutrition. So unless you're proposing design by committee, which never worked in language design, you tend to get the best results from one language designer that outlays the foundation based on personal opinions and ideally on the prior work of others and is then helped by the community. I do understand your point on different styles of programming. However you can't please everybody. For example if you choose for your language to be IDE friendly, you end up with Java. Not sure how many people remember, but one reason for why Java EE has been a complete clusterfuck was the IDE oriented design, as in this belief that an IDE can help with the boilerplate and the wiring. The availability of IDEs is also why XML become popular. Even today Java is not usable without an IDE, because Java's libraries have been designed with IDEs in mind and they are too verbose for your brain to even remember the names of methods, let alone the happy path. Ruby's libraries on the other hand have been designed for expressiveness, for being easy to remember, also to counteract the poor IDE support. Neither approach is superior, but the choice in design was very conscious.
lotyrin 11y ago
I don't think the hypothesis is that language designers have no experience programming, I think it's quite the opposite, that they have experience with poorly designed languages and tools, and perpetuate a sort of stockholm syndrome for the current state of what it means to be a developer. We need languages designed to be used by future generations of programmers in a world where usability and tools come first. The "Manipulate symbols in this arcane syntax and hit F5/Run until it does what you want" experience is fundamentally at fault. Sure we have debuggers and IDEs, but they're more or less tacked on top of core flaws, things that allow for whitespace formatting debates or semicolon religion. My IDE and my VCS should just edit and encode the AST of my language. The compiler and IDE should share the exact same code for indexing and finding symbols in that AST -- the language acting as a library to the IDE so new releases with new features are automatically understood instead of lots of duplicated language for highlighting/completing/searching every language for every IDE. These are just a couple examples of the ways we're currently living in a state of sin.
- DasIch 11y ago
  Indeed. It's beyond my understanding how one could even consider not providing a public API to the parser, when one develops an interpreter or a compiler. Given all the complexity of such programs, this is trivial. The standard library of a language should provide access to the parser, so that developers can easily create tools for the language they're using.
  - NhanH 11y ago
    You just sang the song of Lisp programmers all over the worlds.
    - DasIch 11y ago
      In Lisp basically everyone starts to develop their own languages. Given that most people can barely get a reasonable API together that's just a bad idea.
      - 11y ago
izym 11y ago
I think you're misunderstanding Daslch. He's saying that language designers should look at the entire user experience of programming. No doubt that language designers have plenty of programming experience.

by mafribe 11y ago

hyperpape 11y ago

PHP and Perl were both written by people actively running into limitations of their existing tools (results may have varied!). Honestly, I'd reverse it and instead of looking for exceptions, ask which languages the OP was thinking of? I'm sure they exist.

DasIch 11y ago

Many people use software all the time. Software developers obviously do. That doesn't mean they are magically able to themselves create applications that have a good UI and UX. In fact a lot, possibly most, are really bad at it. The same goes for language designers. I don't think that they have no experience programming, they obviously do. I just don't think that it matters all that much. Additionally the experience of developing software varies widely. Some use IDEs, some don't, some people use debuggers, others use print statements, some people use profilers, others never have a need to. Even if you have programming experience, your particular experience will be very different from the experience other people have, even developing in the same language. So no matter how little or much programming experience you have, you can't create a great programming experience based on your experience alone. You need to have an understanding of other programming experiences.

mafribe 11y ago
You need to have an understanding of other programming experiences. Part of the problem of designing programming languages is that there is little agreement and extreme heterogeneity in the opinions of what is and what isn't a good idea in programming language design. Ideally, PL design statements like "language X is better than Y" should be accompanied by rigorous empiricism. Clearly, the field of PL design has a measurement problem. PL design doesn't have empirically validated and methodologically sound studies that quantify the "dividends" of one PL or PL feature "over another, such as reductions in defects, program size, or development time. Of course PL development isn't the only field that lacks easy empirics. And PL development shouldn't let the perfect be the enemy of the good. It's quite clear that PL features do have positive productivity consequences, with garbage collection being the most clear-cut example. The interesting question is what do we do the absence of good empirical methods. There are several valid answers to this question. One of them is to be strongly guided by mathematical beauty and elegance. This is the family of languages that started with Lisp and is today represented most purely by Haskell, Scala, Clojure, Ocaml and F#. The key ideas from this family: garbage collection, higher-order functions, rich types, have been accepted by the programming mainstream. One wonders if these ideas would have been discovered if John McCarthy had studied the programming experience of working Fortran / Cobol programmers, rather than Church's purely theoretical lambda-calculus.
bad_user 11y ago
In order to have an understanding of what a programming experience is, the designer either has to look at his own experience and also observe others, possibly taking input from likeminded people. Further than that, in language design you obviously can't do A/B testing, since the cost would be too high, focus groups are in general fundamentally flawed because you can validate whatever you want and UX studies in language design would be too superficial, unless performed for a long period of time, but then you get to the same problems the scientists have to deal with in studies on nutrition. So unless you're proposing design by committee, which never worked in language design, you tend to get the best results from one language designer that outlays the foundation based on personal opinions and ideally on the prior work of others and is then helped by the community. I do understand your point on different styles of programming. However you can't please everybody. For example if you choose for your language to be IDE friendly, you end up with Java. Not sure how many people remember, but one reason for why Java EE has been a complete clusterfuck was the IDE oriented design, as in this belief that an IDE can help with the boilerplate and the wiring. The availability of IDEs is also why XML become popular. Even today Java is not usable without an IDE, because Java's libraries have been designed with IDEs in mind and they are too verbose for your brain to even remember the names of methods, let alone the happy path. Ruby's libraries on the other hand have been designed for expressiveness, for being easy to remember, also to counteract the poor IDE support. Neither approach is superior, but the choice in design was very conscious.

lotyrin 11y ago

I don't think the hypothesis is that language designers have no experience programming, I think it's quite the opposite, that they have experience with poorly designed languages and tools, and perpetuate a sort of stockholm syndrome for the current state of what it means to be a developer. We need languages designed to be used by future generations of programmers in a world where usability and tools come first. The "Manipulate symbols in this arcane syntax and hit F5/Run until it does what you want" experience is fundamentally at fault. Sure we have debuggers and IDEs, but they're more or less tacked on top of core flaws, things that allow for whitespace formatting debates or semicolon religion. My IDE and my VCS should just edit and encode the AST of my language. The compiler and IDE should share the exact same code for indexing and finding symbols in that AST -- the language acting as a library to the IDE so new releases with new features are automatically understood instead of lots of duplicated language for highlighting/completing/searching every language for every IDE. These are just a couple examples of the ways we're currently living in a state of sin.

DasIch 11y ago
Indeed. It's beyond my understanding how one could even consider not providing a public API to the parser, when one develops an interpreter or a compiler. Given all the complexity of such programs, this is trivial. The standard library of a language should provide access to the parser, so that developers can easily create tools for the language they're using.
- NhanH 11y ago
  You just sang the song of Lisp programmers all over the worlds.
  - DasIch 11y ago
    In Lisp basically everyone starts to develop their own languages. Given that most people can barely get a reasonable API together that's just a bad idea.
    - 11y ago

izym 11y ago

I think you're misunderstanding Daslch. He's saying that language designers should look at the entire user experience of programming. No doubt that language designers have plenty of programming experience.