I apologize in advance for this seeming like a rant, but there's one bit of syntax that I've been seeing a lot lately, and I can't seem to figure o...
For further actions, you may consider blocking this person and/or reporting abuse
If I'm not mistaken, all of the languages that put types on the right seem to be able to infer types, so you can omit them in some cases; omitting them if they would stand before the variable name could easily lead to confusion, thus they opted for a syntax without any ambiguity.
Not all.
Please enlighten me about the exception(s)?
Ada is static and strong, it does not have type inference, most other languages are weak ;)
This was my first assumption too.
Yet, as someone who has recently begun exploring Typescript, it still throws me off every time.
I think it has more sense like "here is X, a type Y variable" but anywayI think it all started with Fortran (type on the left) but there were exceptions like Basic
ASTRING$ = "Hello World"
ANUMBER% = 10
There are also "neutral" ones, in which you do not have to specify the type (including Go), Lips or everything is a word (BCPL).
To answer your question I think this stackoverflow answer got it right
And New vs Old is relative to our age :))
Very good. Just as a side note, the type in UML goes to the right as well, I guess for similar reasons.
I came in here to add this
To begin with a caveat, the following is based on my own intuition and experience (and no time to do any research to back it up). That said...
This is part of a more general trend of programming environments and languages moving from accommodating the machine to accommodating the programmer. Ask yourself, in a function's declaration, what's more important: the parameter names or their types? Consider:
How would you call that function to make the fraction ½? If you said
make_fraction(1, 2)
, then you were probably too distracted by the type annotations to notice that I flipped the argument order from what you might have naively expected. Placing the annotations on the right makes it easier to focus on what's important:Furthermore, if the same function is overridden to accept more different types of arguments, but keeps the same basic semantics, it would be preferable if those functions looked similar at first glance:
So why, then, were type declarations ever put on the left? Well, if you look back far enough you'll find that C function definitions used to be written like so:
Well, now, that doesn't seem so developer hostile, aside from having to repeat the names of the parameters. It does give us a clue into how type-on-left probably came about, though. Remember that C was originally nothing more than "portable assembly". Well, in assembly when you want to define a function there are a few things you need to do, including setting aside registers and/or stack space for the arguments that will be passed to the function. The most important bit of information for this space allocation is not the names of the parameters, but rather the type.
So, if you're writing a compiler for a language (and especially if you're on a very memory constrained system such that you can't just go placing things in memory willy-nilly for later retrieval), you'd want the first thing your compiler encounters in the language to be the most important. In this case, that means putting the type first so your compiler can do its layout calculations.
As for why more modern, sophisticated compilers (e.g. C++ and Java) kept this declaration form, inertia is a helluva drug, and doubly so in programming language design.
It has to do with divorcing the type from the variable or symbol to which it is attached. This is primarily on the return type, and not the argument types.
Consider the C-like example you gave:
The problem with this syntax is we can't describe the type of this function without a name. You can't remove the
add
bit and still have it make sense. In C function pointer syntax is weird because of this:This defines
add_type
as the desired type, but we still don't have an actual way to say what that type without the name.The left-return type declaration limits us from speaking of function types. This problem has been amplified by lamba functions: those without names.
The right-return syntax allows you to talke about function types without needing a name. Consider, using Leaf syntax
The type of
add
is(a : int, b : int) -> ( : int )
. It doesn't require any new syntax, and can be specified without a name.The other problem with left-aligned types is due to a lack of separator for a type. It causes problems for parsing and user-defined types and variables.
If you have
public protected int add
there is a convention that the right-most value is thesymbol
name.But what about arguments?
add( int x, int y )
What if you want the type without the named arguments:(int, int)
. With extended type information though it becomes difficult to determine what is a type symbol and what is the argument symbol:(large int, int const, int large)
The right-aligned types differ in introducing an explicit type separator, the
:
in your TypeScript example. I use the same character in Leaf. This explicit type separator greatly simplifies parsing and eliminates all sorts of ambiguities, such as those in C++, when dealing with type names.This change in syntax is due to an inrease in the use of the functional paradigm. We need a clean and consistent way to talk about types separate from their variables.
I am not sure if this is a trend or not or why it is happening, but I do think I prefer the return type on the right.
When I write code in Scala, the method definitions look like:
So when you read from left to right you get the intuition that I am taking these parameters and turning them into the return type.
That being said I don't think the placement matters too much to me as long as I am not switching between the two styles too frequently.
I used to think that it was normal and preferred to have types definitions on the left of the variable or function name, I think it may be because of the languages that I learned to program with at first (C, C++, Java).
But as I started to work with TypeScript it became easier to read type definitions on the right. For variables, I read them as "X is of type Y", for functions "Function A returns type B" but that may have more to do with conditioning after TypeScript.
As of the reason, when I first saw type definition on the right was in TypeScript. Back then, I thought it may be a limitation of the language since it was a wrapper around JavaScript, but I have nothing but a gut feeling to back that up.
This makes sense
I think, that's just a language quirk and has been there all the way back. Just think about Pascal:
As others have noted, I've seen it as an indicator of languages with type inference. So you can omit the type if you don't need it.
The syntax itself is taken from Pascal, so not "new" in the strict sense but "new" in the "not seen in popular languages until recently".
Here's how I read each one in my head and I find the right-hand more like natural English:
I reckon it is just CS degree types creating new lex parsers to try and distinguish themselves and their new language. There is absolutely no other reason why you would change a traditional approach to programming. In essence there is no benefits of doing this apart from bucking from the norm. Doesn't matter if it is strongly typed or not (poor argument).
Right! Putting the type on the right is traditional (as mentioned in another comment, it was done so in Pascal (designed 1968–1969, released in 1970), ML (1973), CLU (1974), Modula-2 (1977–1985), Ada (1980), Miranda (1985), Caml (1985), Eiffel (1985)...) There is no good reason for putting types on the left, except for CS degree types creating new lex parsers. ;)
No, Java, C++, Objective-C/C++ and C# do it the C way as they're all derived from C. Algol "influenced" C.
Having them on the right is just another way. Doesn't really matter.
Delphi has always used the "sMyString: String" right-side syntax. But it's an interesting point you bring up.
I feel that it's also more readable because we usually read from left to right, therefore, I get to see the variable name first instead of a data type, which is way more helpful IMHO.
There's a blog article about Go's declaration syntax that explains the reasoning behind it: blog.golang.org/gos-declaration-sy...
The article gives a good example what a mess C code can become if pointers are used. In C, the declaration for the example function looks like this, parameter names omitted. The function returns a function pointer and also expects a function pointer as the first parameter.
In Go, the same is much easier to read:
That being said, Go also makes exceptions when needed. Read the article for more information.