19

Types Are Moving to the Right

 5 years ago
source link: https://www.tuicool.com/articles/hit/bYnIfmm
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
eaym6jN.jpg!webQVRb6zq.jpg!web

If you take a look at statically-typed programming languages that are still popular today but were designed in the previous century, before the turn of millennium, you’d notice that most of them and, at the same time, the more popular and mainstream ones, like C++ (sirca 1985) and Java (1995), write types to the left of names:

Dog   fido = ...
^^^   ^^^^
Type  Name

It reads nicely when you write a lot of declarations, too:

int count= ...
double average= ...
List<String> strings= ...
Map<Warehouse, List<OrderItem>> items= ...

However, if you take a look at modern languages, designed in XXI Century, you cannot help but notice that the languages with some popularity increasingly put types to the right of names:

2YjENny.png!webArA3yyu.png!web

Why is it happening? It might seem strange and inconvenient to any developer who got used to the last-century type-name style, but modern language designers still do it despite the risk of breaking with tradition. Are they all Pascal fans or what?

Here is a plausible explanation. First of all, it has nothing to do with legacy of Pascal (sirca 1970) or even with Visual Basic (1991) for that matter. The real answer is that we have entered the age of type inference .

Type inference, which used to be a niche feature in programming language design, is now entering mainstream. It is appearing in our old programming languages where we can now omit types using var and auto keywords, too. Even in established programming languages we start seeing code like this:

var count= ...
var average= ...
var strings= ...
var items= ...

Woot! That’s nice and aligns, pleasure for our eyes to see. But what happens when the type is too complex for type inference or when it needs to be occasionally spelled out for human reader to understand? Behold:

var count= ...
var average= ...
var strings= ...
Map<Warehouse, List<OrderItem>> items= ...

Uh… that breaks the whole code-reading flow. So, if you are designing a programming language in the age of type inference from scratch, then you solve it by putting an optional type annotation to the right of the name:

var count= ...
var average= ...
var strings= ...
var items: Map<Warehouse, List<OrderItem>> = ...

Now it looks great again. That is essentially the way it is done in Scala (2004), F# (2005), Go (2009), Rust (2010), Kotlin (2011), TypeScript (2012), and Swift (2014) programming languages. There are many syntactic differences between them, but one thing is common — name-type order:

fido   Dog
^^^^   ^^^
Name   Type

This way of writing code is on the rise now. Is it going to become mainstream in the future? That is hard to tell for sure, but the trend does look so.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK