I would like to have a language with a scalable type system. That means the type system should accommodate everything from dynamic typing for quick hacks, all the way to finely-grained static typing suitable for safety-critical systems.
For example, a particular variable's typed might be refined over time in stages like this.
1. dynamically typed
2. number
3. floating-point number
4. floating-point number between 0.0 - 100.0
5. floating-point number between 0.0 - 100.0, with a minimum of 40 bits in the fractional part
6. floating-point number between 0.0 - 100.0, with a minimum of 40 bits in the fractional part, and tell the execution environment to optimize for memory use instead of performance
The languages in use today can cover parts of that spectrum, but nothing allows the whole range.
Type systems that are concerned with representation and range of primitive values aren't very useful. Replacing representation/structure with type names doesn't improve things.
If I'm adding 3.5 oz of OJ to 6.7 oz of vodka, that's either a programming mistake or a strong drink (represented programatically). (Yes, the correct answer depends on context.) A type system that helps me in that situation is worth something.
A type system that only addresses representation and range of primitive values can't even begin to help in that situation.
Yes, units are a partial solution. (They also reduce programmer work - you can add feet to furlongs and get something sensible.)
Agreed. I just used that floating-point variable as a simple example.
It would certainly be useful to have some concept of units built into the language. I'm actually working on handling units in Java right now, as part of a larger library for healthcare data.
http://www.hl7.org/v3ballot/html/infrastructure/datatypes/da...
Cool, that covers storage-class and precision. I'd add lifetime, volatility, value dependencies, reference dependencies...
I'd like to see that and more, not because I want arcane syntax but because the compiler/runtime could then fold code, ensure correctness, optimize, track dataflow, and generally cover my butt so I could get from here to there using fewer critically-scarce braincells. The slowest component of any software is the programmers brain.
He says that garbage collection makes languages more scalable and lack of it makes them less scalable. That flies in the face of reality. In practice garbage collection bogs down huge applications. Microsoft tried to rewrite major portions of Windows with GC and it was a dog and they killed it. It seems that most of the biggest applications and systems use a classic memory management scheme, directly or indirectly.
He's talking about the cognitive overhead of programming in the large, not the computational overhead.
I'm into OCaml but I think he's wrong to recommend it so highly in this specific niche - OCaml's namespacing mechanism is weak compared to C++ and Java's for example. Probably the most serious commercial users of OCaml are Jane Street Capital, and their Yaron Minsky has complained about this.
Has HN just discovered the awesomeness of Mike Vanier? He's the best /teacher/ in the CS department because he can speak to those of us who aren't programmers at heart. He's also a brilliant programmer, from what I understand, but his best skill is that he can operate on a scale of abstractions to reach a range of audiences.
He is exactly right with respect to the language concepts. The language analysis is hit-or-miss; but nobody uses every programming language, so it's hard to be informative here.
I can read Perl programs that are more than 100 lines long. It is all a matter of learning Perl first. The same applies to every other programming language.
For example, a particular variable's typed might be refined over time in stages like this.
1. dynamically typed
2. number
3. floating-point number
4. floating-point number between 0.0 - 100.0
5. floating-point number between 0.0 - 100.0, with a minimum of 40 bits in the fractional part
6. floating-point number between 0.0 - 100.0, with a minimum of 40 bits in the fractional part, and tell the execution environment to optimize for memory use instead of performance
The languages in use today can cover parts of that spectrum, but nothing allows the whole range.