3 ms·

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

by 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.

by DasIch 11y ago

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.