
Summer of Programming Languages - platz
http://existentialtype.wordpress.com/2014/07/06/summer-of-programming-languages/
======
zak_mc_kracken
> Nowadays serious industrial-strength languages are emerging that are
> grounded in theory and informed by practice.

This seems a bit overly optimistic, but it's nice to see this kind of positive
attitude for a change instead of "Why invent yet another language?".

I am very excited about Swift and I have some respect for what Rust is trying
to accomplish, but none of these languages have much foundation in category
theory or the ambitious kind of type system that Haskell has been pioneering
for a while. And the fact that Go is seeing some traction is a stark reminder
that we still have ways to go.

Still, it's nice to see some of these concepts becoming mainstream
(lambdas/closures, fold and functional iteration, phasing off inheritance
based polymorphism, etc...).

~~~
jonnybgood
> but none of these languages have much foundation in category theory or the
> ambitious kind of type system that Haskell has been pioneering for a while.

Is that a requirement? If so, why?

~~~
lmm
I've never seen a "bolt-on" type system work, and I've used a few (e.g.
JSR308). So I think it's something that needs to be built into the language
itself.

Having used a system with higher-level type constructs I find myself thinking
in them. So many complex sequences of operations shake out as something much
simpler once you realise the right monad, or arrow, or so on. And it becomes
painful to manually expand it out; it would be like working in a language
without generics. So I couldn't stand to work in a language that can't express
these concepts; I need either higher-kinded types or something equivalent to
them.

And for a type system that powerful, I'd want some assurance it was correct.
Theoretical underpinnings are not the only way to do that - if it had been in
use a while, and had enough tests and experience to give me a decent level of
confidence, that would be enough. But for a new language I think the only way
I could be confident enough to use it would be if it had this kind of
theoretical backing.

~~~
Dewie
> I need either higher-kinded types or something equivalent to them.

FWIW it seems that many of the Rust developers want this for Rust.

~~~
steveklabnik
Yes, many of us do. Using Option/Result can often lead to a lot of pain
without their accompanying monads, and while you can write the specific ones
(there's a try macro for using Option), it'd be much, much nicer to just have
monads be possible in the language itself.

However, the Rust team is trying to get 1.0 out the door, and higher-kinded
types would be backwards compatible, so I don't think we'll be seeing them for
a while. There's also questions about the overhead and syntax that would need
to be resolved for them to make it in.

~~~
tel
The backwards compatibility argument is interesting. I think it's really
compelling, but it's also worth taking into account the pains that the Haskell
community has been feeling since standardizing the standard library as
insufficiently generic.

I have no idea if a similar problem is possible with Rust, but it'll be
interesting to see how HKTs enter the scene if and when they do.

~~~
kibwen
The Rust standard library will exist as an separate entity from the language
itself, and can be versioned, updated, and deprecated just as any other
library can, without being tied to any specific version of the language.

------
flebron
For anyone who's interested in type theory and programming language
foundations and modern development, I've found the talks of these summer
schools really interesting and useful. The videos and material are at
[https://www.cs.uoregon.edu/research/summerschool/summer14/cu...](https://www.cs.uoregon.edu/research/summerschool/summer14/curriculum.html)
, and you can change "14" in the URL to earlier years to see previous
material. It's really a highly valuable set of resources.

------
aidenn0
Why do programming languages researchers seem so enamored with type-safe
languages? It seems to be a given in academia that type-safe languages are not
just superior, but significantly superior to type-unsafe languages.

~~~
lmm
Academics don't care so much about things like programming speed. And the
academic environment focusses on proof; a type-safety property will seem much
better than a unit test even when both took the same amount of time and have
the same practical value.

(For all that, I agree with them though. Maybe the reason programming
languages researchers think that is because it's true? Do you have reason to
believe they're wrong?)

~~~
jballanc
I don't necessarily think they are wrong, but I also think that (as with most
"silver bullets") type-safety is not without it's shortcomings.

For example, consider the exponentiation function. When we raise an Integer to
a positive Integer (2^2), the result will always be a positive Integer. You
would expect the type of such a function to be: Integer -> Integer -> Integer

Except, that's wrong. When we raise an Integer to a negative Integer (2^-2),
the result will be some fractional value. If we want to retain full numeric
precision, it'll have to be something like a Rational. So now your function's
type signature is: Integer -> Integer -> Rational.

But that's also wrong. So what are we to do? Maybe positive and negative
integers should be separate types? PositiveInt and NegativeInt, let's say. But
then what about subtraction? Should it's type signature be: PositiveInt ->
PositiveInt -> PositiveInt? What about 2 - 3? Whoops!

So, there's no way, with types alone, to simply and accurately encode all
basic math operations. All you can do is throw a Domain Error when someone
violates certain boundary conditions, and tell them to check their arguments
before deciding which function to call.

...meanwhile, dynamic languages will happily return whatever type is most
appropriate for the arguments given.

~~~
lmm
Any property that you can actually be confident about, you can encode into the
type system. If you care that x ^ (y - z) is an integer, you'd better have
some reason to believe that y > z. If you don't care or can't be sure, let x ^
(y - z) return Integer | Rational, and pattern-match for the cases (or treat
them as some supertype, Numeric or some such). Or if you really can't figure
out the proof but still think it's correct, you can cast, and then your
program will error out at runtime if you're wrong, which is at least safe.

In a dynamic language, your mistake passes silently; the result you thought
was an integer is actually a fraction, but your program carries on going.
Maybe it turns it into a string and uses it as a file path, so something you
thought was a simple filename has a slash in it. Maybe that breaks your
security model. Pretty unlikely in this specific case, but that's how bugs
happen.

~~~
jballanc
Right, but it's also much simpler and faster for the programmer to write one
function with one return type, and later modify it to add a return type if the
requirements change. I think this is obviously why dynamic languages rose in
prominence coincidentally with the rise in rapid prototyping and agile
development. That said, this is also why large companies with codebases that
need to be maintained over multiple decades will always go with static
languages.

What really interests me are languages like Julia or Dart, with their gradual
typing, or Clojure and core.typed. You retain the flexibility and speed of
development of a dynamic language, with the possibility of later adding type
safety guarantees to your code without having to rewrite it from scratch.

~~~
steveklabnik
> it's also much simpler and faster for the programmer to write one function
> with one return type, and later modify it to add a return type if the
> requirements change.

How is this different? When you compile, your compiler will say "Hey, the
requirements have changed, your code is wrong here, here, here, and here," and
you modify those things, and you're done.

~~~
tormeh
....and then you've forgot what you were actually trying to solve.

~~~
the_af
What is the alternative? You change the code, the behavior gets changed but
the compiler doesn't warn you. At this point you have two possible paths:

1- You wrote tests which start failing. You must now spend time changing them.
You don't manage to avoid working in order fix your safety net (be it static
type checking or your test suite).

2- You didn't write the right tests, and don't notice the change in behavior.
The program later fails in production.

------
noobSemanticist
Any ideas why software verification videos are not published in the OPLSS web
page?

