7 ms·

I don't agree with this at all. Having the types of every variable written explicitly in the code is important documentation that answers very quickly the quest

by cjfd 7y ago

I don't agree with this at all. Having the types of every variable written explicitly in the code is important documentation that answers very quickly the question 'what is the type of this thing' without having to look everywhere and anywhere to perhaps find out that it could be any one of three types. If you do not know the type of something you also do not know what operations are available on that thing.

empath75 7y ago
Use an IDE
- wereHamster 7y ago
  I'm not always using an IDE when looking at code. Sometimes I read code directly on GitHub, or repl.it, or codesandbox, or ….
  - Waterluvian 7y ago
    Maybe those can evolve further too. I've always appreciated the advantages of code being legible as plain text files. But maybe it is just a little absurd when language design is shaped to fit the desire not to evolve the storage format and editing interface.
  - azhenley 7y ago
    I agree with your comment. GitHub does seem to be moving towards adding IDE-like features though: https://github.com/github/semantic https://github.com/github/semantic
pjc50 7y ago
It looks like there's two very different styles going on here. Most of us are used to the OO-type approach (Java, C#) where the operations are "inside" the object and defined on it. This article is coming from a very different place where the operations are "outside" the typed things, which are more like structs, and the programmer can write any operation that takes structs which have the right fields. The author doesn't make any comment on dispatch let alone multiple dispatch. They appear to be writing for the kind of quasi-schema'd information bureaucracy that's very important outside of SV. Lots of data in XML that never quite lines up with an object model. The Haskellite approach would also say that "what operations are available on that thing" is the wrong way round; you define your operation, and the type signature tells you what kind of things will work with it.
- gridlockd 7y ago
  > The Haskellite approach would also say that "what operations are available on that thing" is the wrong way round; you define your operation, and the type signature tells you what kind of things will work with it. Isn't the common case that you already have "the thing", you have a rough idea what should be done, and you want to see what operations/transformations are available? That's when autocomplete and a static type system comes in handy. Some (more obscure) languages unify this, i.e. f(x) is the same as x.f(). I don't think there's a "wrong way around", the difference is a technicality.
  - danShumway 7y ago
    > Isn't the common case that you already have "the thing", you have a rough idea what should be done, and you want to see what operations/transformations are available? I'm going to (very lightly) push back and say no, I don't think that's the way I want to program. Certainly I've seen functional systems where it's mostly about syntax, but I think there's also a difference here that is more than technicality. I'm having a hard time thinking more concretely about exactly what it is, but intuitively the statement you made rings a few alarm bells for me.
    - gridlockd 7y ago
      Is it because you associate methods with statefulness and because you believe statefulness is bad? If so, I'd point out that methods can just be pure functions and objects can be immutable. Or, more controversially, partial application is just a lazy person's method definition.
      - pjc50 7y ago
        > methods can just be pure functions and objects can be immutable. This is true, but then you start wondering what the data hiding is for, especially if an object has getters for all its immutable members.
      - danShumway 7y ago
z3t4 7y ago
If you find naming things difficult just append the type to the variable name, like strName, strCityName, nrAge, arrUserList, and try to make the types redundant. Then stop using the type annotations when you feel they are unnecessary: strName:string -> strName -> name This of course only works in high level dynamic languages where you wont have 25 ways to represent a number, or 32 ways to make a string (different encodings). In a typed systems level language the compiler should be able to optimize and figure out the best type to use though.
- golergka 7y ago
  But why would you use the type "string" in the first place, instead of declaring a type "name"?
  - z3t4 7y ago
    To take it one step further, why does it need to have a type? Why can't the compiler just figure it out?
    - golergka 7y ago
      Because a compiler can't figure out your business requirements?
karmakaze 7y ago
> If you do not know the type of something you also do not know what operations are available on that thing. I don't get why this is important. If the original author, you had an idea of what you wanted to do with the thing. As a reader the thing is whatever supports the functions called on it in the body. Naming is important. Adding type annotation for humans is a good pattern and requiring it everywhere as part of language spec doesn't seem beneficial. Heck even Java now has var like js in method bodies.
azhenley 7y ago
Relevant to this is the HN discussion [1] on my recent blog post, "Type inference has usability problems" [2]. The discussion here and on Twitter got quite lively :) [1] https://news.ycombinator.com/item?id=20296123 https://news.ycombinator.com/item?id=20296123 [2] http://austinhenley.com/blog/typeinference.html http://austinhenley.com/blog/typeinference.html
keymone 7y ago
author specifically mentioned spec, which is a runtime validation/destructuring library, more powerful and flexible than any compile-time type system can ever hope to get
javajosh 7y ago
>Having the types of every variable written explicitly in the code In fairness this sort of data is metadata that can be added at tooling time - there's no need to place it in the source itself.
awefns1235sa 7y ago
Ruby, JavaScript, & Python were all successful without explicit type annotations.
- oblio 7y ago
  Javascript is the extension language for the most successful platform in history. A lot of people consider it a horrible language, and yet, here we are. Ruby and Python both started as scripting/glue languages meant for small programs. At that scale, it doesn't really matter. When the codebases they were used for started getting bigger and started having longer histories and a need for refactoring, that's when people started asking for more structure.

by cjfd 7y ago

empath75 7y ago

Use an IDE

wereHamster 7y ago
I'm not always using an IDE when looking at code. Sometimes I read code directly on GitHub, or repl.it, or codesandbox, or ….
- Waterluvian 7y ago
  Maybe those can evolve further too. I've always appreciated the advantages of code being legible as plain text files. But maybe it is just a little absurd when language design is shaped to fit the desire not to evolve the storage format and editing interface.
- azhenley 7y ago
  I agree with your comment. GitHub does seem to be moving towards adding IDE-like features though: https://github.com/github/semantic https://github.com/github/semantic

pjc50 7y ago

It looks like there's two very different styles going on here. Most of us are used to the OO-type approach (Java, C#) where the operations are "inside" the object and defined on it. This article is coming from a very different place where the operations are "outside" the typed things, which are more like structs, and the programmer can write any operation that takes structs which have the right fields. The author doesn't make any comment on dispatch let alone multiple dispatch. They appear to be writing for the kind of quasi-schema'd information bureaucracy that's very important outside of SV. Lots of data in XML that never quite lines up with an object model. The Haskellite approach would also say that "what operations are available on that thing" is the wrong way round; you define your operation, and the type signature tells you what kind of things will work with it.

gridlockd 7y ago
> The Haskellite approach would also say that "what operations are available on that thing" is the wrong way round; you define your operation, and the type signature tells you what kind of things will work with it. Isn't the common case that you already have "the thing", you have a rough idea what should be done, and you want to see what operations/transformations are available? That's when autocomplete and a static type system comes in handy. Some (more obscure) languages unify this, i.e. f(x) is the same as x.f(). I don't think there's a "wrong way around", the difference is a technicality.
- danShumway 7y ago
  > Isn't the common case that you already have "the thing", you have a rough idea what should be done, and you want to see what operations/transformations are available? I'm going to (very lightly) push back and say no, I don't think that's the way I want to program. Certainly I've seen functional systems where it's mostly about syntax, but I think there's also a difference here that is more than technicality. I'm having a hard time thinking more concretely about exactly what it is, but intuitively the statement you made rings a few alarm bells for me.
  - gridlockd 7y ago
    Is it because you associate methods with statefulness and because you believe statefulness is bad? If so, I'd point out that methods can just be pure functions and objects can be immutable. Or, more controversially, partial application is just a lazy person's method definition.
    - pjc50 7y ago
      > methods can just be pure functions and objects can be immutable. This is true, but then you start wondering what the data hiding is for, especially if an object has getters for all its immutable members.
    - danShumway 7y ago

z3t4 7y ago

If you find naming things difficult just append the type to the variable name, like strName, strCityName, nrAge, arrUserList, and try to make the types redundant. Then stop using the type annotations when you feel they are unnecessary: strName:string -> strName -> name This of course only works in high level dynamic languages where you wont have 25 ways to represent a number, or 32 ways to make a string (different encodings). In a typed systems level language the compiler should be able to optimize and figure out the best type to use though.

golergka 7y ago
But why would you use the type "string" in the first place, instead of declaring a type "name"?
- z3t4 7y ago
  To take it one step further, why does it need to have a type? Why can't the compiler just figure it out?
  - golergka 7y ago
    Because a compiler can't figure out your business requirements?

karmakaze 7y ago

> If you do not know the type of something you also do not know what operations are available on that thing. I don't get why this is important. If the original author, you had an idea of what you wanted to do with the thing. As a reader the thing is whatever supports the functions called on it in the body. Naming is important. Adding type annotation for humans is a good pattern and requiring it everywhere as part of language spec doesn't seem beneficial. Heck even Java now has var like js in method bodies.

azhenley 7y ago

Relevant to this is the HN discussion [1] on my recent blog post, "Type inference has usability problems" [2]. The discussion here and on Twitter got quite lively :) [1] https://news.ycombinator.com/item?id=20296123 https://news.ycombinator.com/item?id=20296123 [2] http://austinhenley.com/blog/typeinference.html http://austinhenley.com/blog/typeinference.html

keymone 7y ago

author specifically mentioned spec, which is a runtime validation/destructuring library, more powerful and flexible than any compile-time type system can ever hope to get

javajosh 7y ago

>Having the types of every variable written explicitly in the code In fairness this sort of data is metadata that can be added at tooling time - there's no need to place it in the source itself.

awefns1235sa 7y ago

Ruby, JavaScript, & Python were all successful without explicit type annotations.

oblio 7y ago
Javascript is the extension language for the most successful platform in history. A lot of people consider it a horrible language, and yet, here we are. Ruby and Python both started as scripting/glue languages meant for small programs. At that scale, it doesn't really matter. When the codebases they were used for started getting bigger and started having longer histories and a need for refactoring, that's when people started asking for more structure.