> with almost no one in industry applying these lessons
Straight-up incorrect. Language designers think long and hard about how typings work in their languages. Rob Pike, Ken Thompson, and Russ Cox deliberated generics for like a decade[1] before finally allowing them in Go.
> a proper type system
I'm not sure exactly what you mean by "proper" -- but "rigid" type systems are extremely cumbersome to use practically. (Typed) λ-calculus is an academic example; Haskell is a real-world example.
> not too hard to retrofit dependent types (just don’t bother with Turing-incompleteness)
Hard disagree. It actually is extremely hard: type resolution is undecidable, for one. So you need to carefully design type resolution in a way that the "edges" of types don't (or can't) break the runtime too badly.
> why not go the extensible route of letting anyone hook into the “type checking” phase
Absolutely terrible idea, for many reasons, but mainly because, if C/C++ macros are any indication, people will abuse any kind of compile-time (or pre-processing) trickery you give them access to.
> write your own domain-specific checker, even
I guess I'm in the opposite camp here, I think domain specific languages are an absolute dumpster fire of abstraction and 99.9% of the time completely exceed the scope of the problem they're trying to solve. The purpose of a programming language is to be applicable to many classes of problems, and DSLs fly in the face of that pretty common-sense tenet.
I think that kind of proves their point. Parametric polymorphism is one of the most well-understood, least contentious extensions to the lambda calculus. It's formalized by System F and has been implemented in programming languages 40 years ago with great type inference for an important subset (Hindley-Milner). Yet generics was highly controversial in the Go community. And now since none of the standard library was designed with generics in mind, it's full of unsafe patterns that involve essentially dynamic typing (e.g., the `Value` method of `Context`).
Despite Rob Pike et al. designing one of the most popular languages today (Go), I consider them more experts in systems rather than programming languages.
> I'm not sure exactly what you mean by "proper" -- but "rigid" type systems are extremely cumbersome to use practically. (Typed) λ-calculus is an academic example; Haskell is a real-world example.
I find Haskell a joy to use, and I cringe at having to use languages like Java and Go, which are a minefield of error-prone programming patterns (like using products instead of sums to represent "result or error"). Generally speaking, my Haskell code is shorter, less buggy, and more reusable than my Go code, so I'm not sure what you mean by "cumbersome".
There is very good reason that Go's initial compromise was to use built-ins for a small number of highly useful generics like arrays and maps.
I just want you to realize that you are in the extreme minority here, but just from a common-sense POV, if I'm prototyping a project, looking for product-market fit, the last thing I want to care about is that my typeability is recursively enumerable or what-have-you. I just want to build something quickly without much hoopla (hence the massive popularity of very weakly-typed languages like JS and Python).
FWIW, I think that generics are a mistake in Go, but I was just trying to counter the point that language designers don't think long and hard about type-theoretic features. I think the main issue with generics, wasn't so much an inept "we don't know how to do this," but rather "is this worth the code complexity?" and "is this worth the added compile times?" -- both of which were main selling points of Go.
I'm in the minority because I've spent an unusual amount of time investing in my understanding of programming languages and their features, not because I have some fringe unjustified opinion.
> if I'm prototyping a project, looking for product-market fit, the last thing I want to care about is that my typeability is recursively enumerable or what-have-you.
With this comment you've lost your credibility in my mind. No one actually goes through this train of thought. I don't wonder about recursive enumerability whenever I start a project. I just use tools that help me build high quality software, such as principled static type systems.
I was just making a statement of fact. You're probably a very good programmer (as most type nerds, to coin a new term, tend to be), but still in the minority. Most programmers are not very good, and even good ones sometimes want to build things fast. (Where type ambiguity or even incorectness is accepted as a viable trade-off.)
This is why I stopped prototyping in Java, for example. JS just let me "do stuff" without thinking about it too hard. Lower code quality? Of course; but it let me try out more ideas in the same amount of time. Should you use JavaScript to write the operating system of a pacemaker? Probably not.
Considering how much people love and use Rust, Typescript and typechecking in Python, I don't think your point about people prefering JS and Python is that strong. There is one thing that's sure: people hate typing Car car = new Car(). var car = new Car()? That's already better. Python and JS got popular in reaction to Java/C#/C++, which were painful to use. Even Go now has type inference, which helps a lot. Now in 2022 it's not the same as 2005. You can have static types and a fast time to market. Before thinking about dynamic vs static, we should first try to see what the best dynamic and static typing schemes we can come up with.
> if I'm prototyping a project, looking for product-market fit, the last thing I want to care about is that my typeability is recursively enumerable or what-have-you
That's a bit of a strawman. If I'm prototyping a project, the last thing I want to care about is the weird API design that the author of that library I need came up with, instead of just implementing a common interface. Python and JS both have iterators for a reason. People in the functional world talk about monads all the time for a reason too: it's a general interface that allows you to write code fast. Nullable code is the same as async code, is the same as iteration (well, mapping) code, is the same as parsing code.
I do think there's been a "type renaissance" in the past 5 or so years, after we all dove headfirst into JS and Python and broke the whole internet.
Then don't. It's not like Haskell forces you to, that's a myth about Haskell. You can get away with strings and integers everywhere if you so fancy.
There is just no common-sense in thinking that computer assisted programming is slower than unassisted.
I think most type systems are, in fact, Turing complete (there's a fun proof somewhere that TypeScript is, for example). And most typed languages (Go, C++, Java, TypeScript) have pretty mature static type-checkers, unless I'm misunderstanding your ask.
> Zig
> undecidable, since evaluation of recursive functions at compile time is possible, thus requiring the compiler to solve the halting problem.
For some reason, I find that amusing.
If you want a language, and have legit need, fire up antlr and build a quick compiler.
Parser cleverness if the “internal DSl” variety is on par with the C++ windowing libraries that used heavy operator overloading to be clever, the stuff like “window += new Button()” and other nonsense. Just awful and torturous.
As you start adding types to your working program compiler debugs your program for you finding various corner cases.
This motivates you to add more types.
[0]: 1982 version: https://raw.githubusercontent.com/michaelt/martin-lof/master...
But one area of large impact for this pure type theory research seems to be the mechanization of mathematics. It looks probable that in the future, the standard way to do mathematics will be by programming it in a proof development system, aka dependently typed programming language.
This is a controversial opinion, and not all mathematicians are enthusiastic about it, whether rightly or wrongly. Michael Harris, for instance, is a major sceptic and opponent.
It is still a very interesting idea. And it has had some notable successes already.
I think some of it may have to do with the fact that in programming, one can get immediate and non-judgmental feedback about the correctness of ones solution. In mathematics, it's usually a lot more difficult to verify a solution if you don't already know the answer, so you're dependent on people for it.
So perhaps, interactive theorem provers may make mathematics a lot more accessible. But I hope the art of doing it with pen and paper doesn't get lost on us with it.
There are proof assistants without dependent types, like Isabelle/HOL.
The more abstract parts like dependent types are really complicated and even unintuitive to use. See: issues with Rust’s borrow checker, or Haskell being so confusing.
Earlier languages like C and Java are mostly legacy code, they use libraries in legacy code, or they’re for developers familiar with them.
Untyped scripting languages are fine for scripts. Honestly idk why developers write big libraries in untyped languages like JavaScript and Python.
The main case where advanced formal methods are particularly useful is proving program correctness. And AFAIK this stuff is used by industry, although you don’t hear about it as much. The thing is, most programs either don’t “need” to be proved, or they’re way too big.
I disagree with this: dependent types are way easier than lots of the convoluted schemes that non-dependent languages have come up with.
As a simple example, dependently-typed languages don't need parametric polymorphism or generics: we can achieve the same thing by passing types as arguments; e.g.
map: (inType: Type) -> (outType: Type) -> (f: inType -> outType) -> (l: List inType) -> List outType
map inType outType f l = match l with
Nil inType -> Nil outType
Cons inType x xs -> Cons outType (f x) (map inType outType f xs)
When I program without dependent types, I regularly find myself getting "stuck" inadvertently; knowing that (a) there's no way to make my current approach work in this language, (b) that it would be trivial to make it work if I could pass around types as values, (c) that I need to throw away what I've done and choose a different solution, and (d) the alternative solution I'll end up with will be less correct and less direct than my original approach (e.g. allowing more invalid states)- Type-checking is undecidable. I've not found that to be much of a problem, since it can be given a timeout (or hit Ctrl-C).
- Soundness requires functions to be total (either terminating or co-terminating). That's generally a good idea anyway, but the approaches for doing this aren't particularly great; e.g. structural recursion is simple to implement and understand, but is very restrictive.
Idris makes the pragmatic choice of allowing the totality-checker to be turned off on a per-function basis; which is certainly no worse than using a language with no totality checking.
Another approach I've enjoyed using is Mtac in Coq: general recursion is an effect, which gets wrapped in a type (similar to Haskell's IO); there is an unwrapping function (like unsafePerformIO) but it gets executed at compile-time, so non-total functions create an infinite loop at compile time (rather than at runtime).
This is only true if you allow non-total functions in your types, which most dependently-typed languages don't by default (i.e. the condition implied by your soundness condition).
By default in e.g. both Idris and Agda type-checking is decidable.
Nor do I think the value of dependent types comes from proofs, which I agree are still too cumbersome to really use at a large scale for most codebases.
My hypothesis for the sweet spot for dependent types is to express invariants, and then use other mechanisms such as property tests to check those invariants, rather than actual proofs (except for trivial proofs). This does mean that I favor a very proof irrelevant style of dependently typed programming (i.e. in the language of Agda, way more `prop` than `set` or in Idris lots of zero multiplicities for dependently typed arguments) which is quite different from the way a lot of current dependently-typed code is written.
julia> factorial(3) # term -> term
6
julia> typeof(3) # term -> type
Int64
julia> one(Float32) # type -> term
1.0f0
julia> Vector{Float32} # type -> type
Vector{Float32} (alias for Array{Float32, 1})
And actually more mixed: julia> using StaticArrays
julia> SVector{3, Float32}(1, 2, 3)
3-element SVector{3, Float32} with indices SOneTo(3):
1.0
2.0
3.0
julia> convert(Float32, 1)
1.0f0
Julia is of course dynamic, so maybe it's cheating? I'm writing this comment because all the greek in that cube, and actually using a cube, makes this look like very abstract stuff but I consider Julia a very practical language.> Untyped scripting languages are fine for scripts. Honestly idk why developers write big libraries in untyped languages like JavaScript and Python.
And yet it works
I don’t know the peculiarities of julia to comment on this specific language though.
In the case of Julia for example static arrays can be created, at runtime or not, with a fixed length that is part of the type definition, to give a less trivial example than "is an instance of". It's actually a very practical example as static arrays are of great importance for performance on certain applications.
I think most people would dismiss dynamic language examples, and that's the reason I comment Julia is dynamic in my comment, because most people interested in types are interested in using them at compile time to prove, or strengthen at least, correctness. In the case of dynamic languages types feel like just another piece of metadata and if you have "eval" available you basically can do anything. Julia actually does not use types to catch bugs but to structure programs and to improve performance when possible (to great extent).
x = Vector{Float64}(1, 2, 3)
y = SVector{3, Float64}(1, 2, 3)
Both store the same data, and as a matter of fact you probably can pass them as arguments to most functions that accept arrays (if the functions are well designed). The difference however is that `y` has a more restricted interface: you cannot resize `y`. This restriction allows the compiler to optimize better the code both in time and space: dynamic arrays for example may allocate more memory than strictly necessary to speed up resizing and may do more bounds checks. In an ideal world should also catch bugs like detecting that `y[4]` is an error. So, to summarize, when you use `y` instead of `x` you are telling the computer that `length(y) = 3` is an invariant of your code and that it's safe to make that assumption. Having the number "3" stored as a type has an special meaning.Off tangent, but these reminds me the first time I read the phrase "everything in Python is an object". That got me puzzled because in my mind if "everything is an object" then the phrase has zero information content. You cannot understand what is an object in isolation, you need to consider how the interpreter uses them. Or the first time you try understand what is a vector in mathematics. You cannot understand a vector in isolation, you need to consider the vector space it lives in, what operations are allowed.
So it is probably meaningless to talk about it in case of dynamically typed languages, even though type enforcement may not be needed (as it is impossible in the generic case for dependent types)