21 ms·
Types Are Moving to the Right
- karlakush 8y agoI'm not convinced. The article found one situation where it makes more sense for the type to be on the right, but in most situations it makes more sense for the type to be on the left. The reason being that it reads more naturally. It's the difference between saying "Golfer Tiger Woods adopted a cat" and "Tiger Woods, golfer, adopted a cat." Nobody speaks the latter.
- andolanra 8y ago'Naturally' is almost always a red herring in programming language design, because what is 'natural' tends to be 'whatever I was previously familiar with'. There are a lot of unstated assumptions here: · That what's best for natural language is also the best for programming languages. This is still a debated topic, but my personal feeling is that the two are different enough in both mechanism and purpose that what's good for one isn't necessarily good for the other. (For an illustrative example, look at how sigils worked in Perl 5, as they were explicitly designed to work like English demonstrative words like "that" or "these", and many programmers when first exposured to Perl feel like they were 'illogical'. They weren't, but in this case, mirroring a natural-language convention tended to obscure, rather than clarify, what was going on in the language!) · That phrase ordering in English is necessarily 'natural'. Lots of naturally-occurring spoken languages feature word order that differs tremendously from English! · That the English-language phrase you're describing as 'unnatural' is in fact unnatural: it's actually a common convention, especially when you're introducing a new fact to a conversation! "Tiger Woods, a famous golfer, adopted a cat."
- coldtea 8y ago>but in most situations it makes more sense for the type to be on the left. The reason being that it reads more naturally Not really. And the Tiger Woods example is a whole phrase with a verb and an noun (describing what he did to whom), so not representative of a type declaration (which is just just describing what thing something of a specific name is). So, it's more like: Tiger Woods: a golfer. vs: A golfer: Tiger Woods. Which of course is an argument for types on the right -- the first reads much better.
- Mirioron 8y agoIn my opinion the second reads better, because if you have multiple declarations (multiple rows) then they will all line up: Tiger Woods: a golfer. Jon Rahm: a golfer. Bryson DeChambeau: a golfer. vs A golfer: Tiger Woods. A golfer: Jon Rahm. A golfer: Bryson DeChambeau. This makes it easier to group up information when glancing at the code.
- makapuf 8y agoI don't understand the alignment argument. You can insert spaces (or your editor ) and align types on the right if needed.
- Mirioron 8y agoSo, will you go back and beautify code? When will you insert them? If there are 3 lines like that? 4? 5? It leaves so many questions that will have to be solved through "best practices" and everyone ends up doing it slightly differently.
- coldtea 8y agoThat's what TAB is for.
- int_19h 8y agoIt stops reading naturally as soon as you get composable type constructors, and people start actively using them. Even in English, once there's enough qualifiers, we move it to the right - e.g. "Tiger Woods, a famous but controversial golfer, adopted a cat".
- JadeNB 8y ago> "Tiger Woods, a famous but controversial golfer, adopted a cat". "Famous but controversial golfer Tiger Woods adopted a cat" might be awkward, but it's hard for me to buy an argument that it's either unnatural or even particularly hard to understand.
- krona 8y agoPython type hints (since 3.5) also follow the same pattern. see: https://www.python.org/dev/peps/pep-0483/ https://www.python.org/dev/peps/pep-0483/
- andrepd 8y agoSame syntax as Ocaml/ML family.
- int_19h 8y agoI don't think it has much to do with type inference. It's more that type systems became more complicated, and so did type names. And with a long composite type name, the name of the variable gets pushed too far out and obscured. It worked great in Algol, and still works pretty well in C (although that is partly because it splits the declarator to keep array and function syntax to the right of the variable name), but in C++ with templates it's already hard to read. There are also a variety of issues with parsing it that way, most of which go away entirely if the name is first.
- waterhouse 8y agoRob Pike wrote a rationale for Go's type syntax here: https://blog.golang.org/gos-declaration-syntax https://blog.golang.org/gos-declaration-syntax He seems to agree with you. "One merit of this left-to-right style is how well it works as the types become more complex." ... "Overall, though, we believe Go's type syntax is easier to understand than C's, especially when things get complicated." ... "Go's declarations read left to right. It's been pointed out that C's read in a spiral! See The "Clockwise/Spiral Rule" by David Anderson."
- theoh 8y agoPreviously: https://news.ycombinator.com/item?id=12775735 https://news.ycombinator.com/item?id=12775735 Apparently the Spiral Rule is not entirely correct.
- mehrdadn 8y agoIn C the type of a variable is "variable-centric" rather than "type-centric": it's denoted by syntax akin to the one you would use to use the variable. So if you have int (*arr)[2] that means "if you dereference arr, the expression represents an array of 2 elements". So, for example, if you want a pointer to a function that returns a pointer to an array of two elements, how do you denote it? You'd go step-by-step based on how you would use it: int a[2] int (*f)[2] int (*(*fp)())[2] Once you understand this, the typing syntax should make sense, and you see that any description like spirals or whatever misses the big picture.
- zwieback 8y agoI can see pros and cons for either but what about int i,j,k; I think that's clearer with type first.
- weberc2 8y agoi,j,k int Seems fine to me either way
- nicoburns 8y agoI think let i,j,k : int; is pretty clear. Although I'm not convinced that declaring multiple variables like this should be allowed at all. Imo it's clearer to declare them seperately when they're used. For example: for (let i in 0..n) { for (let j in 0..i) { // do stuff } }
- int_19h 8y agoIt's not so much that it's clearer, it's that it reads more naturally in English: "integer i" is very much akin to, say, "president Lincoln". Which is probably why it was adopted first. I suspect it's also why the colon is often used when the order is reversed, even when it's not strictly necessary to disambiguate parsing - you want something that reads "i is integer", and colon already kinda sorta has that meaning.
- jey 8y agoI thought this is from ML and related functional languages? (i.e. this is just the way they've always done it)
- andolanra 8y agoThere are several technical advantages to the types-to-the-right style. For one, it's often easier to write a parser for: having an explicit let or val keyword makes it immediately obvious to a parser without lookahead that the statement in question is a declaration, and not an expression. This is less of a problem in languages like Java, where the grammar of types is simpler, but in C and C++, if you begin a line with foo * bar then it's not yet clear to the parser (and won't be until after more tokens are observed) whether this is a variable declaration for bar or a statement multiplying foo and bar. This isn't a problem for name-then-type syntaxes. On a related note, it's also often advantageous for functions to indicate their return type last, as well, especially when the return value of the thing might be a function of an earlier argument. There are plenty of examples of this in functional or dependently-typed languages, but even C++ (which historically has listed the return type of a function first) has added an alternate (slightly clunky) syntax for function types where you can specify the return type after the arguments for this reason: template<typename Container, typename Index> auto foo(Container& c, Index i) -> decltype(c[i]) { ... }
- jeffrallen 8y agoCame here to say exactly this. The post's author has no idea what language designers are thinking about.
- chubot 8y agoPlease reconsider your tone. It sounds like you were disappointed that you didn’t get to show off something you know, so you chose to insult someone else instead. The site would be better without such comments. This might make you feel better but it’s just noise that hundreds of people have to skip over.
- HumanMusic 8y agoI did not get that meaning from the post at all. You should consider your tone, one might be lead to think you believe yourself some sort of paragon of propriety. I'd also advise a side course of thicker skin.
- majewsky 8y agoTypes are moving to the right because having them on the left makes the grammar undecidable. Languages like C or C++ can only be parsed when semantic information is passed back into the parser. For example, consider the following C++ statement: a b(c); This is a declaration of `b`. If `c` is a variable, this declares `b` of type `a` and calls its constructor with the argument `c`. If `c` is a type, it declares `b` to be a function that takes a `c` and returns an `a`.
- mehrdadn 8y ago> Types are moving to the right because having them on the left makes the grammar undecidable. This is just an artifact of how they designed the syntax in some languages like C++ or C#. You can easily put types on the left in a way that makes this false.
- SamReidHughes 8y agoThat's only if you have weird function type syntax like C does.
- colmvp 8y agoIs this an example of the 'Most Vexing Parse' problem?
- WalterBright 8y ago`a b(c);` is always a declaration of function `b` in D. To construct `b` of type `a`, it is written instead: a b = a(c); // one way auto b = a(c); // preferred way
- UIZealot 8y agoIf you're designing a new programming language anyway, why not go with: var int a function int f() Clear and easy to parse.
- seanwilson 8y agoType annotations on the right reads way more naturally to me e.g. "customerNameToIdMap is hash map of strings to UUIDs" over "there's a hash map of strings to UUIDs called customerNameToIdMap".
- Nimitz14 8y agoI disagree. Compare int num_entries = .. float div = .. float result = num_entries // div vs num_entries: int = .. div: float = .. result: float = num_entries // div And that's an extremely simple example. I tried out Nim but dropped it because while writing some code with list of lists of different types etc it became completely impossible to parse it quickly.
- faissaloo 8y agoYeah I experienced this with Crystal and really disliked it.
- seanwilson 8y agoI don't see much difference here. It's probably not a big deal when the type annotation is short but if it's something longer reading the short variable name first helps give some context first. When scanning code I think I read the variable name first as well. Type inference should be able to deal with the simple cases anyway.
- dragonwriter 8y agoTypes on the right reads better on those examples (read ":" as "is a(n)" and "=" as "which is").
- dom96 8y agoWhat does types being on the right have anything to do with parsing types representing lists of lists?
- Nimitz14 8y agoParsing as in reading and comprehending.
- rovyko 8y agoIs there a name for side on which the type declaration sits? Left/right typed? If that's the case, I'd argue for back/forward or start/end to account for right-to-left languages.
- dentemple 8y agoI propose: "Left-type-ness" and "Right-type-ness"
- deleted 8y ago[deleted]
- christofosho 8y agoPre-/post-typing?
- thanatropism 8y agoSmall-sidedian versus big-sidedian
- VWWHFSfQ 8y agoare there right to left languages
- wflann 8y ago
- chimi 8y agoVB and Pascal were way ahead of their time.
- Someone 8y agoWay ahead? VB is from ~1990, Pascal from around ~1970, Cobol had types on the right in 1960. Certainly, VB wasn’t way ahead of its time.
- mjw1007 8y agoLooks to me like the world had mostly settled on types-on-the-right already in the 1970s, except C was an anomaly and languages which imitated its syntax in other ways often imitated that too.
- htor 8y agothis article has little or no substance
- elizarov 8y agoThat is on purpose
- AnaniasAnanas 8y agoSomething that is not mentioned in the article, the mathematical way is that the types are to the right.
- dolguldur 8y agoexactly, e.g. let x ∈ ℝ
- AnaniasAnanas 8y agoJust a note, nowadays people tend to use : to denote the type of a value in type theory, while ∈ is used in set theory to denote that a value is a member of a set.
- trixie_ 8y agoSo much easier to read and write code with inferred types. Though my co-workers obsessed with writing ‘good’ code refuse to use them. They also refuse to write comments because their code is so good ‘it documents itself’.
- jstimpfle 8y agoI think most programmers end up in this place and I think they are right, at least concerning the reading part (which is often more important since most code is read more often than written)... How long have you been programming?
- int_19h 8y agoI disagree - there are places where explicit types help, but for most local variables they're just noise. An accurate name for a variable is much more important than a type when it comes to figuring out what the code does that involves it, and types are a mouse hover away in any decent tooling anyway. (I've been programming for 20 years, and mostly in statically typed languages.)
- trixie_ 8y ago20 years. I find reading code with inferred types much much easier. The signal is what the code is doing. The typings are noise. Edit: In a big complicated system, knowing the type like ‘user’ or ‘account’ doesn’t tell you much. There’s always more information and context. A small type definition is only the tip of the iceberg.
- josephg 8y agoThis is one of those aspects where a good editor makes a big difference. I've recently moved from writing javascript in vim, to writing typescript in vim, to writing typescript using VSCode. Being able to hover over a variable and see a variable's type makes it easier to read complex code. This is useful irrespective of whether or not you're using type inference, since you don't need to hunt down the variable's declaration to figure out its type. And if you're reading back the compiler's type information through your IDE while programming, you may as well take advantage of type inference.
- zwetan 8y agoLet me correct that for you That is essentially the way it is done in Scala (2004), F# (2005), *ActionScript 3 (2006)*, Go (2009), Rust (2010), Kotlin (2011), TypeScript (2012), and Swift (2014) programming languages.
- elizarov 8y agoActionScript does not make a cut on any popularity metric that I've used to select popular languages.
- zwetan 8y agoThe latest TIOBE index [0] put both ActionScript and TypeScript in "The Next 50 Programming Languages", from rank 51 to rank 100 also Pascal is mentioned at rank 204 based on that yes ActionScript do make the cut in term of popularity, or you can also remove TypeScript and Pascal from the article also hypocrisy much? in one of your other comments You are welcome. D did not actually made it to the list based on the language-popularity-selection criteria I’ve used, but I thought it is prominent enough to be included and overrode my criteria for it. so that part "prominent enough" is completely subjective right? [0]: https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/
- elizarov 8y agoOf course it is subjective, though I've used Tiobe, Redmonk and PYPL indices to compile a list of languages.
- dragonwriter 8y agoNitpick, but in the graphic at the beginning, C# is presented as being a language designed in the 21st century when it in fact was doing designed in, and released in the last year of, the 20th.
- elizarov 8y agoAha. Good catch.
- mruts 8y agoI think the modern practice of displaying types mostly comes from ML.
- WorldMaker 8y agoI wouldn't under-estimate the influence of Pascal here. Noted language designer Anders Hejlsberg for instance has a strong Pascal background (Delphi) and type location in C# was supposedly a heavy debate precisely because of that. Typescript benefited from the repercussions/learnings/findings of that debate and decades of C# usage. That said it's probably a "both" situation: ML and Pascal are both clear founders of type descriptions and their both deciding on relatively the same type syntax within just a few years of each other likely a convergent evolution indicator.
- JadeNB 8y ago… which got it, I think, from Milner's exposition; see, for example, p. 351 of https://www.sciencedirect.com/science/article/pii/0022000078900144 https://www.sciencedirect.com/science/article/pii/0022000078... . This notation makes particular sense for function types, where a mathematician would write `f : A → B` even if not thinking type-theoretically.
- craigharley 8y agoAnd php does it both ways with its type hinting... function foo(string bar): string { return “y u do this”; }
- deleted 8y ago[deleted]
- Aearnus 8y agoI disagree with the fact that types are moving over to the right side for readability's sake or anything like that. Modern theorem proving languages explicitly specify that type declarations are simply equivalent to set inclusion, which makes the type specification operator (usually :) equivalent to set inclusion (∈). This influence was what rubbed off onto modern MLs, and by extension, inspired many of the ML inspired/type safe languages that have come out recently.
- yonatron 8y ago"circa", not "sirca".
- elizarov 8y agoThanks!
- externalreality 8y agoInteresting observation. Is a wide enough sample of languages considered? What scares me is that we still use text files to program in 2019 such that we are having this conversation. The author makes a good observation nonetheless.
- cocochanel 8y agoWhat's wrong with text files?
- pxndx 8y agoMost of the ambiguity would be solved if you wrote an ast tree directly, like in scratch (or even lisp).
- icebraining 8y agoThere's no such thing as writing a conceptual entity like an AST "directly", you always have to use the mediation of some UI, be it text or a GUI. And you can definitively have ambiguous GUIs.
- deleted 8y ago[deleted]
- externalreality 8y agohttps://www.reddit.com/r/haskell/comments/ngn2c/a_concept_for_editing_haskell_as_an_ast_rather/ https://www.reddit.com/r/haskell/comments/ngn2c/a_concept_fo... I would still consider the link above editing text... but I posted it anyway for what it is worth. The idea seems to be to confine the text to its AST in a form like fashion.
- imtringued 8y agoWhy would it scare you? Computers have keyboards. Majority of program code consists of identifiers which is 100% text. Each line can contain several AST nodes without severe complexity issues in the average case. Unless someone invents a brain to machine interface computer languages will be based on text for the forseeable future.
- richardhod 8y agoThat first chart really annoys me because rather than giving us the names of the languages it uses a logo, which do not really describe what languages are if you do not recognize the logo. And generally it's an extra cognitive layer and load on your brain. Makes it pretty unreadable.
- stevefan1999 8y agoI have a question, are those languages that provide type inference inspired by HMT [1]? [1]: https://en.m.wikipedia.org/wiki/Hindley–Milner_type_system https://en.m.wikipedia.org/wiki/Hindley–Milner_type_system
- deleted 8y ago[deleted]
- Too 8y agoIn JavaScript with prototypical inheritance, where you inherit from an instance rather than a type, it becomes very confusing what Foo would mean in a line saying Foo bar. So there some more explicit distinction is needed which is easiest to do with colon and moving to the right.
- deleted 8y ago[deleted]
- deleted 8y ago[deleted]