6 ms·

>even the most jaded systems programmer can see are not ideal, like the fact that types precede names in variable declarations, Honestly, I find it shocking an

by F-0X 8y ago

>even the most jaded systems programmer can see are not ideal, like the fact that types precede names in variable declarations, Honestly, I find it shocking anybody can hold this opinion. I hate that every single new language insists on types being on the right. I searched for a reason why this is, and typically the results are along the lines of type inference being easier to implement. I'd prefer to take no inference at all and have my types on the left, where they belong. I'm totally serious. Types on the right are a readability disaster.

andrewla 8y ago
For me it's about compactness of type representation -- types are on the right, except when they're not -- in arrays or function pointer declarations, you have to deal with the fact that the variable name being introduced may be nested in unintuitive ways deep inside the declaration. By moving it to the right, you make that much clearer. In Java, they made it so that array information went on the left, which made it a little clearer, but was still kind of ugly, and Java really had no notion of function pointers anyway. The other problem with the type-on-the-left is that variable declarations are hard to find without tooling designed for that purpose. Being able to search for "var x" is a nice feature that makes it easy to separate out the declarations from the usage. I agree that type inference and optional types is something of an anti-feature from my perspective as well; even more frustrating is languages that treat a type declaration as a type assertion rather than a declaration, which serves to divorce ideas about physical storage from the code; abstract types like "bool", though, have already crept into C to make the type model a little more complicated than it has to be. Types in C used to be declarations of storage class as well; now I know that a bool in a struct will take up a byte, but that byte and bool are not really compatible types makes it a little harder to reason about, even if that does give better hinting to the compiler.
matthiaswh 8y ago
I agree. It's such an illogical and unreadable construct to me. Even after working with a typed language for awhile my instinct is to declare the type before the variable name. I've been envisioning a future programming environment that automatically aids in code readability by hiding unnecessary information when you're not using it. Manual code folding was sort of a first step, but this environment would take it further by hiding things like types until you need them. So something like proc eval(c: Criterion, token: Token): bool = let tokenCrit = (token.identifier, token.token) return tokenCrit == c Might look like proc eval(c, token) = let tokenCrit = (token.identifier, token.token) return tokenCrit == c Or even proc eval(c, token) = ... return tokenCrit == c It would have to be smart enough to expand the hidden blocks when you need them and in an unobtrusive way. It's also possible that the type declarations wouldn't actually expand in this editor, but would be set by some sort of popup selector (similar to how autocomplete works, but you'd select the variable type). This is just a rough idea and I'm not sure how well it works in reality. But when code starts looking like `proc add*[T](root: var BinaryTree[T], n: var seq[BinaryTree[T]]) =` it starts to lose its at-a-glance readability.
- angleofrepose 8y ago
  Gary Bernhardt has a good take on this in his talk A Whole New World [1]. He introduces an editor which has these layers which can display or hide orthogonal information such as types, a short view or profiling details. That talk, and your comment and my inability to find anything that does this kind of work simply surprises me. Are there no good examples of systems that allow these kind of simple transformations out there? I remember someone pointing me to a clojure editor a while back, maybe? I can't remember. Seems to me there is a desire for editors that allow a user to transform code, whether it be annotations or raster graphics as Bernhardt puts it. The closest I know of is org mode, and how it works on a plaintext interface but has no qualms about displaying it in wildly different ways than an org file might look opened up in vim, though it still does maintain readablity. I think this is the way to go and I've been playing around with a personal workflow on top of org mode lately. What do you think? [1]: https://www.destroyallsoftware.com/talks/a-whole-new-world https://www.destroyallsoftware.com/talks/a-whole-new-world
jolmg 8y ago
I don't know, take a look at this random Haskell function from Yesod[1]: isValidPass :: Text -- ^ cleartext password -> SaltedPass -- ^ salted password -> Bool isValidPass ct salted = PS.verifyPassword (encodeUtf8 ct) (encodeUtf8 salted) || isValidPass' ct salted The stuff after `::`, including the following indented lines, are the type of this function. The text after the `--`s are comments. That's a very, very simple one. Take look at this other type signature: widgetToPageContent :: (Eq (Route site), Yesod site) => WidgetT site IO () -> HandlerT site IO (PageContent (Route site)) or this one: selectFieldHelper :: (Eq a, RenderMessage site FormMessage) => (Text -> Text -> [(Text, Text)] -> WidgetT site IO () -> WidgetT site IO ()) -> (Text -> Text -> Bool -> WidgetT site IO ()) -> (Text -> Text -> [(Text, Text)] -> Text -> Bool -> Text -> WidgetT site IO ()) -> HandlerT site IO (OptionList a) -> Field (HandlerT site IO) a Do you think it would be more readable if the type came before the identifier? I know these types might look needlessly complicated to someone that doesn't know how to read them, but when you learn to understand them, they are a blessing. Most of the time, a type will tell you everything you need to know about a function or other value. They're often better than the documentation to know what they do. Another advantage is that they simplify looking for the type signature of a function. You just need to `grep '^identifier'` instead of what you would do for C++, for example, `grep 'identifier\('` and manually filter out the calls. Also, having it on the right permits one to comment on different parts of it, just like one would do with non-type code. I don't see the sense in ever having it on the left (where's the benefit? just having it look like C?), but I guess it's not unacceptably bad on unexpressive type systems where the type is hardly more than a type identifier. [1] https://www.yesodweb.com/ https://www.yesodweb.com/
- andrewla 8y ago
  I don't know that you'll be able to sell a programmer that has stuck with C on Haskell. The ability to look at code and have a rough idea of what the assembly will look like is, in my opinion, fairly high up on the list of desired features. Haskell does ... not really provide that. And as for greppability, it has become very common now to use keywords, which were very common once upon a time but went out of favor with Algol, so that you get declarations like "fn isValidPass(...)" to make grepping even easier. And easy grepping also means easy parsing, which works both for machines and for humans when you're trying to digest unfamiliar code.
lifthrasiir 8y ago
Types on the left are a parsing disaster. At the very least, a C-style definition demands too much parsing power for questionable benefits. It blurs the boundary between types and expressions and thus complicates essentially everything that has to deal with source codes. This has nothing to do with type inference. If type expressions were readily recognizable from other expressions (for example, you can force types to be CamelCased and assigned different lexical classes like ML) then it'd be probably a pure personal taste. But a C-style definition? Big no-no.
- tasubotadas 8y ago
  It's not like we don't have enough power with our modern CPUs.
saghm 8y ago
I'm super curious about your strong opinion on this, especially since it's seemingly stated as something more universal than just your personal preference (i.e. "readability disaster"). Is there anything specific about types being on the right that you feel makes them objectively worse, or do you just personally not like them (which is totally valid and would be much more understandable to me)?

by F-0X 8y ago

andrewla 8y ago

For me it's about compactness of type representation -- types are on the right, except when they're not -- in arrays or function pointer declarations, you have to deal with the fact that the variable name being introduced may be nested in unintuitive ways deep inside the declaration. By moving it to the right, you make that much clearer. In Java, they made it so that array information went on the left, which made it a little clearer, but was still kind of ugly, and Java really had no notion of function pointers anyway. The other problem with the type-on-the-left is that variable declarations are hard to find without tooling designed for that purpose. Being able to search for "var x" is a nice feature that makes it easy to separate out the declarations from the usage. I agree that type inference and optional types is something of an anti-feature from my perspective as well; even more frustrating is languages that treat a type declaration as a type assertion rather than a declaration, which serves to divorce ideas about physical storage from the code; abstract types like "bool", though, have already crept into C to make the type model a little more complicated than it has to be. Types in C used to be declarations of storage class as well; now I know that a bool in a struct will take up a byte, but that byte and bool are not really compatible types makes it a little harder to reason about, even if that does give better hinting to the compiler.

matthiaswh 8y ago

I agree. It's such an illogical and unreadable construct to me. Even after working with a typed language for awhile my instinct is to declare the type before the variable name. I've been envisioning a future programming environment that automatically aids in code readability by hiding unnecessary information when you're not using it. Manual code folding was sort of a first step, but this environment would take it further by hiding things like types until you need them. So something like proc eval(c: Criterion, token: Token): bool = let tokenCrit = (token.identifier, token.token) return tokenCrit == c Might look like proc eval(c, token) = let tokenCrit = (token.identifier, token.token) return tokenCrit == c Or even proc eval(c, token) = ... return tokenCrit == c It would have to be smart enough to expand the hidden blocks when you need them and in an unobtrusive way. It's also possible that the type declarations wouldn't actually expand in this editor, but would be set by some sort of popup selector (similar to how autocomplete works, but you'd select the variable type). This is just a rough idea and I'm not sure how well it works in reality. But when code starts looking like `proc add*[T](root: var BinaryTree[T], n: var seq[BinaryTree[T]]) =` it starts to lose its at-a-glance readability.

angleofrepose 8y ago
Gary Bernhardt has a good take on this in his talk A Whole New World [1]. He introduces an editor which has these layers which can display or hide orthogonal information such as types, a short view or profiling details. That talk, and your comment and my inability to find anything that does this kind of work simply surprises me. Are there no good examples of systems that allow these kind of simple transformations out there? I remember someone pointing me to a clojure editor a while back, maybe? I can't remember. Seems to me there is a desire for editors that allow a user to transform code, whether it be annotations or raster graphics as Bernhardt puts it. The closest I know of is org mode, and how it works on a plaintext interface but has no qualms about displaying it in wildly different ways than an org file might look opened up in vim, though it still does maintain readablity. I think this is the way to go and I've been playing around with a personal workflow on top of org mode lately. What do you think? [1]: https://www.destroyallsoftware.com/talks/a-whole-new-world https://www.destroyallsoftware.com/talks/a-whole-new-world

jolmg 8y ago

I don't know, take a look at this random Haskell function from Yesod[1]: isValidPass :: Text -- ^ cleartext password -> SaltedPass -- ^ salted password -> Bool isValidPass ct salted = PS.verifyPassword (encodeUtf8 ct) (encodeUtf8 salted) || isValidPass' ct salted The stuff after `::`, including the following indented lines, are the type of this function. The text after the `--`s are comments. That's a very, very simple one. Take look at this other type signature: widgetToPageContent :: (Eq (Route site), Yesod site) => WidgetT site IO () -> HandlerT site IO (PageContent (Route site)) or this one: selectFieldHelper :: (Eq a, RenderMessage site FormMessage) => (Text -> Text -> [(Text, Text)] -> WidgetT site IO () -> WidgetT site IO ()) -> (Text -> Text -> Bool -> WidgetT site IO ()) -> (Text -> Text -> [(Text, Text)] -> Text -> Bool -> Text -> WidgetT site IO ()) -> HandlerT site IO (OptionList a) -> Field (HandlerT site IO) a Do you think it would be more readable if the type came before the identifier? I know these types might look needlessly complicated to someone that doesn't know how to read them, but when you learn to understand them, they are a blessing. Most of the time, a type will tell you everything you need to know about a function or other value. They're often better than the documentation to know what they do. Another advantage is that they simplify looking for the type signature of a function. You just need to `grep '^identifier'` instead of what you would do for C++, for example, `grep 'identifier\('` and manually filter out the calls. Also, having it on the right permits one to comment on different parts of it, just like one would do with non-type code. I don't see the sense in ever having it on the left (where's the benefit? just having it look like C?), but I guess it's not unacceptably bad on unexpressive type systems where the type is hardly more than a type identifier. [1] https://www.yesodweb.com/ https://www.yesodweb.com/

andrewla 8y ago
I don't know that you'll be able to sell a programmer that has stuck with C on Haskell. The ability to look at code and have a rough idea of what the assembly will look like is, in my opinion, fairly high up on the list of desired features. Haskell does ... not really provide that. And as for greppability, it has become very common now to use keywords, which were very common once upon a time but went out of favor with Algol, so that you get declarations like "fn isValidPass(...)" to make grepping even easier. And easy grepping also means easy parsing, which works both for machines and for humans when you're trying to digest unfamiliar code.

lifthrasiir 8y ago

Types on the left are a parsing disaster. At the very least, a C-style definition demands too much parsing power for questionable benefits. It blurs the boundary between types and expressions and thus complicates essentially everything that has to deal with source codes. This has nothing to do with type inference. If type expressions were readily recognizable from other expressions (for example, you can force types to be CamelCased and assigned different lexical classes like ML) then it'd be probably a pure personal taste. But a C-style definition? Big no-no.

tasubotadas 8y ago
It's not like we don't have enough power with our modern CPUs.

saghm 8y ago

I'm super curious about your strong opinion on this, especially since it's seemingly stated as something more universal than just your personal preference (i.e. "readability disaster"). Is there anything specific about types being on the right that you feel makes them objectively worse, or do you just personally not like them (which is totally valid and would be much more understandable to me)?