
What is PL research and how is it useful? - protomyth
http://www.pl-enthusiast.net/2015/05/27/what-is-pl-research-and-how-is-it-useful/
======
chipsy
I love PL research, for all its warts. I worry that it's wasted on most
programmers, because we don't get a comprehensive pedagogy of each type of
problem that these abstractions are meant to solve, and contexts where a less
abstracted approach is preferable. The result is the much maligned cargo cult
method - presented with so many options, we invariably end up with all of them
put into production at the same time, for the wrong reasons. Experience is
gained through a combination of guess and check, and rumor.

A lot of the confusion with current PL science as it's presented to
programmers is in the emphasis on mathematical methods. Restrictions that are
proven to improve statistical metrics or lead to important technology within
the toolchain get dismissed on the regular as being incomprehensible or
incompatible with "my style". Surface changes get the majority of attention,
bad or good.

The PL designer has a tough job in that, if they're going for the general
purpose crown, they have to comfort the nervous creatures that are ordinary
programmers while also incorporating the best practices of the known science.

------
JesperRavn
I think a better illustration of the usefulness of PL research is to compare
the languages produced my Microsoft and Google.

Microsoft produces C# and Typescript. Google produced Go and Dart. I think
it's fair to say that C# is a better language than Go. The biggest flaw in Go
(lack of generics) is met with the weak excuse that they haven't figured out
how to do it right. I don't know much about Dart, but Typescript is a stellar
language.

Microsoft has a lot of PL expertise in house, including Simon Peyton Jones.
Their languages clearly benefit from expertise in PL theory. Google, on the
other hand, favors pragmatism over theory and prefers to draw on software
engineering experience. Google's languages aren't bad, they just don't seem to
have much going for them _as languages_. Their failings are partly made up for
in other things, like the toolchain, libraries, etc.

So I think looking at these real world examples, it's clear that PL theory
does lead to better languages, even when one excludes languages like Haskell
with little industry adoption.

~~~
seanmcdirmid
> Microsoft has a lot of PL expertise in house, including Simon Peyton Jones.
> Their languages clearly benefit from expertise in PL theory. Google, on the
> other hand, favors pragmatism over theory and prefers to draw on software
> engineering experience.

Google has ALOT of PL expertise in house, so much so that a lot of them don't
work on PL. There language design is actually quite competitive to
Microsoft's, on the theory, design, and implementation sides. Whenever we go
to conferences, you'll usually have similar numbers of current and ex-
academics from MS and Google.

~~~
pjmlp
Yet the best that have came up with are Go and Dart....

While Apple and Microsoft have come up with Swift, F#, F*, C#, TypeScript....

I wonder what those so called PL researchers are doing at Google.

~~~
thomasvarney723
It seems to me that Apple has had a rich history of interesting languages:
Squeak, Dylan, Hypertalk, AppleScript and Swift. Those are just the ones I
know of.

~~~
pjmlp
You forgot Mac Lisp and Object Pascal. :)

~~~
the_why_of_y
Pedantic note: it was called Macintosh Common Lisp (MCL), not to be confused
with MacLisp, which predates both Apple and Common Lisp and is from MIT's
Project MAC.

~~~
pjmlp
I confess I didn't bother to search for the real name, so I typed from heart.

As side note, here is a very interesting post about the system:

[http://basalgangster.macgui.com/RetroMacComputing/The_Long_V...](http://basalgangster.macgui.com/RetroMacComputing/The_Long_View/Entries/2013/2/17_Macintosh_Common_Lisp.html)

------
imh
The best case for learning this stuff is the old adage along the lines of 'Any
sufficiently complicated program contains an ad hoc, informally-specified,
bug-ridden, slow implementation of half of common lisp.' While not exactly
true, it definitely rings familiar with some of the bigger projects I've been
on. If you're going to have an system that is practically it's own language,
it will benefit from you knowing about language design.

------
plsceptic
I don't think the author actually demonstrated the usefulness of PL research,
at least not enough to convince me of it. For that I would need to see actual,
regular controlled experiments from PL researchers showing that a given
language or construct yields measurable dividends over another, such as
reductions in deficits, program size, or development time. Instead what you
get from PL researchers is papers full of conjecture advocating some such
language or construct, but seldom any scientific evidence to support any of
it. Further, programming languages by themselves, in 2015, don't matter that
much. Unless a language has an industrial-strength implementation, a robust
tool chain, and a vast collection of libraries, it won't, or at least
shouldn't, gain widespread adoption.

I think we have far too many languages as it is. Of all the languages I've
learned or at least been exposed to, only a handful were genuinely novel, such
as Common Lisp/Scheme, Smalltalk, and Haskell, and rest were mere reskins of
C. The compile-to-JavaScript languages are easily some of the worst offenders,
and it leads me to wonder, how many new languages are the product of a good
faith effort to solve a yet-unsolved or poorly-solved problem, and how many
spring largely from the vanity of their inventor, who dreams of becoming the
next great BDFL, being invited to give keynotes at conferences, and
capriciously giving his thumb up or down to enhancement proposal like a Roman
Emperor deciding on the fate of a fallen gladiator in the Colosseum?

I actually think we as an industry could benefit from a PL moratorium. How
many of us have had to use a language with poor or no IDE support, or one that
lacked native code compilation (JiT or otherwise), or that had gaping holes in
its standard library simply because it was new and trendy?

~~~
reality_czech
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
The counterpoint is how many PL creators ignore all existing research and go
on to make the same old mistakes.

~~~
Retra
AKA, Java's 'billion dollar mistake' of allowing null references when there is
no great justification for it.

~~~
reality_czech
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
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.

~~~
reality_czech
_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 talked about this in my earlier comment, saying that we could solve the
efficiency problem with "a super-clever compiler and a built-in optional
type." (To respond to adwn's comment, I would view built-in support for sum
datatypes as "built-in support for optional.")

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

null IS a type which means "undefined/error to use this."

In the particular context of Java, null solves some of the problems of the
language, like what happens when a constructor invokes a derived method which
reaches up and accesses a not-yet-initialized variable in the superclass. I do
think some of these problems could be solved in a different way, but it's not
completely straightforward.

I am curious about how Rust solves some of these problems. I'll have to take a
look.

~~~
TheCoelacanth
> In the particular context of Java, null solves some of the problems of the
> language, like what happens when a constructor invokes a derived method
> which reaches up and accesses a not-yet-initialized variable in the super-
> class. I do think some of these problems could be solved in a different way,
> but it's not completely straightforward.

That's a non-issue. A derived class shouldn't be able to access any variables
from the super-class until after the super-class's constructor has completed.
All variables in the super-class should have to be initialized before the
constructor completes. The super-class constructor shouldn't be able to read
from a variable until after it can be statically determined that it has
initialized the variable.

If a class can't work within these constraints, then it can declare the
variable as Option<T> initialized to None, and then it is back to the normal
Java semantics for that one variable.

~~~
TheLoneWolfling
> If a class can't work within these constraints, then it can declare the
> variable as Option<T> initialized to None, and then it is back to the normal
> Java semantics for that one variable.

By doing that you lose the safety of variables being marked final.

I wish there was a way to seal a variable such that it could not be changed
(in the same sense that final works in, not truly readonly) after a certain
point, but it could be before then.

I find myself writing far too many variables that should be final, and indeed
are final after a certain point, but cannot be marked as such because said
point is after the constructor. In particular with lazy-loading.

~~~
TheCoelacanth
A final variable must be assigned in the constructor, so it already meets all
of those constraints.

~~~
TheLoneWolfling
I quote:

> In particular with lazy-loading.

Lazy loading != assigned in the constructor

~~~
TheCoelacanth
You can't lazy load a final variable. It has to be assigned in the
constructor. If your point is that getting rid of null doesn't solve every
single problem that exists, I agree. However, it in no way causes a
degradation from the current status quo in nullable-by-default languages.

------
ninkendo
Offtopic: So we're all just calling programming languages "PL"'s now? Why is
it so hard for people to type?

(Seriously though, it's a strange kind of memetic behavior, I rarely see it
abbreviated as "PL" ever, but in each comment I scan, people are using "PL"
here too. It was enough to get me to click the article just to see if "PL" was
some new thing I haven't heard of.)

~~~
nmrm2
PL is a _very_ common abbreviation in the research community and has been for
at least decades. Common usage in academia probably stems in part from the
fact that conferences are often named by their initials, so the conference on
"Principles of Programming Languages" becomes "POPL" and so on.

