5 ms·

I think a big part of it is that a lot of the traditional programming language researcher obsessions are not that interesting to working developers. For exampl

I think a big part of it is that a lot of the traditional programming language researcher obsessions are not that interesting to working developers. For example, proving software correct is used in a very, very small number of cases (mostly safety-critical things like elevators or medical devices), but for most projets the extra development time is nowhere near worth the benefits. Plus for many things like user interfaces, the specification for getting them "correct" may not be any shorter than the code itself (sometimes it's longer.) Elegance and minimalism (how small can you make the language's standard library? etc.) are loved by academics but nobody else cares. Plus, most academics don't have any awareness that different languages are useful for different things-- because they've never actually done any of the different things. You might want a C-like language to write a kernel, but a TCL or Javascript-like language to write a graphical user interface. Perhaps you want a MATLAB or R-like language to do numerical work. Most PL people don't have any awareness of the different use-cases so they try to produce "the messiah language" that will solve all problems. It never works. The other thing is that there's not a lot of awareness of the psychological aspects of programming in the PL field. For example, sometimes it is desirable to limit the expressiveness of a programming language in order to make code easier to understand and share between people. These tradeoffs are almost never discussed (I have never seen an academic paper discuss them). Instead languages like Java and Go are ridiculed for the "missing" features (didn't they know that higher-order types were invented by academic language X Y years ago? etc. etc.)

the_af 11y ago
The counterpoint is how many PL creators ignore all existing research and go on to make the same old mistakes.
- Retra 11y ago
  AKA, Java's 'billion dollar mistake' of allowing null references when there is no great justification for it.
  - reality_czech 11y ago
    Honestly I don't think including null in the language is a big deal. Academics tend to think it is a big deal because it makes it harder to prove programs correct, but almost nobody does that with Java programs, so it doesn't really matter to most programmers. null is a natural representation for an optional type. It's efficient because the CPU can implement it by page faulting on null dereferences. Yes, you can have Optional<T> and so forth, but it uses more memory, and Java already has a problem with using a lot of memory. Even assuming we could somehow solve the efficiency problems with a super-clever compiler and a built-in optional type, the language needs a way to represent the state that an object starts out with. For integers and floats that is 0, for booleans it is false, and for objects it is null. You could argue with the whole concept of imperative programming (and many academics do), but if you have X happening before Y in your imperative program, you better have a way of representing the state of the objects that haven't yet been initialized by Y to X. C++ got a non-nullable type in the form of references, and it didn't exactly turn the language into a paragon of sweetness and light. It just made things more confusing and annoying since you had to keep flipping back and forth between pointers and refereences, depending on the API you were using. And in typical C++ fashion, they invoked undefined behavior to answer the question of what happened if you accessed a not-yet-initialized reference (for example in a constructor).
    - pherq 11y ago
      There's nothing stopping a compiler from implementing Option<T> as a possibly-null reference when T is a pointer type, which would give you the same efficiency as having nulls in the language while making unchecked usage easy to catch at compile time. (I don't know if any languages do this currently, but there's no reason it couldn't be done. It does turn Option into a special built-in type, but it's universal enough for that to be a decent idea.) And it's not clear that variables should have values before assignment, beyond "undefined"/"error to use this" -- explicitly initialising a variable to some sentinel value is clearer and safer than relying on the default value being something in particular.
      - adwn 11y ago
thechopkins 11y ago
Your comment about the lack of 'awareness on usages of different languages' rings so true. Especially for the cases where the research goes into making new 'uber' languages (which was my understanding of most of the research area until reading this article and then investigating more). I recently watched this talk at UW (http://www.cs.washington.edu/events/colloquia/search/details?id=2594 http://www.cs.washington.edu/events/colloquia/search/details...) and was frustrated by that exact problem. It is interesting to use data from engineers to determine the usefulness of a language, but you'll still never drive adoption everywhere. There are plenty of other aspects of programming languages which deserve to be applied to other fields of CS and more coverage on the research coming out of those areas.
- jules 11y ago
  Currently it is the case that certain languages are better for specific problem domains, but that's mainly a library issue or a platform constraint (e.g. web app -> js). I don't see any reason why we need so many general purpose languages. Domain specific languages, sure. Why do we need so many general purpose languages? What exactly are the design constraints that are fundamentally incompatible between those languages? Case in point: the comment above you cites TCL, Javascript, MATLAB, R as examples of why we need many languages, when all of them are terrible language design. TCL has good built-in gui facilities, Javascript is built into browsers, MATLAB has many scientific libraries, R has many stats libraries. That's why they are used, not because the languages are any good.

the_af 11y ago

The counterpoint is how many PL creators ignore all existing research and go on to make the same old mistakes.

Retra 11y ago
AKA, Java's 'billion dollar mistake' of allowing null references when there is no great justification for it.
- reality_czech 11y ago
  Honestly I don't think including null in the language is a big deal. Academics tend to think it is a big deal because it makes it harder to prove programs correct, but almost nobody does that with Java programs, so it doesn't really matter to most programmers. null is a natural representation for an optional type. It's efficient because the CPU can implement it by page faulting on null dereferences. Yes, you can have Optional<T> and so forth, but it uses more memory, and Java already has a problem with using a lot of memory. Even assuming we could somehow solve the efficiency problems with a super-clever compiler and a built-in optional type, the language needs a way to represent the state that an object starts out with. For integers and floats that is 0, for booleans it is false, and for objects it is null. You could argue with the whole concept of imperative programming (and many academics do), but if you have X happening before Y in your imperative program, you better have a way of representing the state of the objects that haven't yet been initialized by Y to X. C++ got a non-nullable type in the form of references, and it didn't exactly turn the language into a paragon of sweetness and light. It just made things more confusing and annoying since you had to keep flipping back and forth between pointers and refereences, depending on the API you were using. And in typical C++ fashion, they invoked undefined behavior to answer the question of what happened if you accessed a not-yet-initialized reference (for example in a constructor).
  - pherq 11y ago
    There's nothing stopping a compiler from implementing Option<T> as a possibly-null reference when T is a pointer type, which would give you the same efficiency as having nulls in the language while making unchecked usage easy to catch at compile time. (I don't know if any languages do this currently, but there's no reason it couldn't be done. It does turn Option into a special built-in type, but it's universal enough for that to be a decent idea.) And it's not clear that variables should have values before assignment, beyond "undefined"/"error to use this" -- explicitly initialising a variable to some sentinel value is clearer and safer than relying on the default value being something in particular.
    - adwn 11y ago

thechopkins 11y ago

Your comment about the lack of 'awareness on usages of different languages' rings so true. Especially for the cases where the research goes into making new 'uber' languages (which was my understanding of most of the research area until reading this article and then investigating more). I recently watched this talk at UW (http://www.cs.washington.edu/events/colloquia/search/details?id=2594 http://www.cs.washington.edu/events/colloquia/search/details...) and was frustrated by that exact problem. It is interesting to use data from engineers to determine the usefulness of a language, but you'll still never drive adoption everywhere. There are plenty of other aspects of programming languages which deserve to be applied to other fields of CS and more coverage on the research coming out of those areas.

jules 11y ago
Currently it is the case that certain languages are better for specific problem domains, but that's mainly a library issue or a platform constraint (e.g. web app -> js). I don't see any reason why we need so many general purpose languages. Domain specific languages, sure. Why do we need so many general purpose languages? What exactly are the design constraints that are fundamentally incompatible between those languages? Case in point: the comment above you cites TCL, Javascript, MATLAB, R as examples of why we need many languages, when all of them are terrible language design. TCL has good built-in gui facilities, Javascript is built into browsers, MATLAB has many scientific libraries, R has many stats libraries. That's why they are used, not because the languages are any good.