4 ms·

That might be a matter of personal taste. How ones brain is wired. For me, types make code less expressive. I can grasp the structure of a piece of code the eas

That might be a matter of personal taste. How ones brain is wired. For me, types make code less expressive. I can grasp the structure of a piece of code the easier, the less meta data there is on top of the algorithmic structure.

tluyben2 6y ago
What are you working on though? What algorithmic structure?
- TooCreative 6y ago
  Compare this: private static function request(?string $method, ?string $url, array $options): array { ... } To this: function request($method, $url, $options) { ... } I can grasp the latter much better. It immediately forms a structure in my head that I will remember while I read other parts of the code. To do the same with the former, I think my brain uses up twice the energy or more. And even then, I will not have such a good grasp on it as with the former.
  - unrealhoang 6y ago
    Counter point: with the former, I know exactly how to use it: for item in request(“get”, “google.com”, []) { .... } Whereas if there’s no example for the latter, I’d have to read the code of that function (or sometime the code of the functions it called) to know how to use correctly.
    - TooCreative 6y ago
      Wishful thinking. You know it returns an array, but you don't know what the array contains. So you don't know how to use it. You still need to look into the code to see what it returns. Then you will see that it returns an array and what the array contains. And now you had to process the information that it returns an array twice. Once in the function definition and once in the function body.
      - castwide 6y ago
        > You know it returns an array, but you don't know what the array contains. So you don't know how to use it. That's a limitation of your specific example, not type systems in general.
        TooCreative 6y ago
        For the example I took a random line from Symfony and shortened it a bit: https://github.com/symfony/http-client/blob/master/HttpClientTrait.php#L33 https://github.com/symfony/http-client/blob/master/HttpClien... You are free to link to some other example.
        castwide 6y ago
        Any example where the type is defined as something more specific than an array (especially in PHP, where the `array` type doesn't even differentiate between numerically indexed arrays and dictionaries). Regardless, I still think the type hints in Symfony's version are better than nothing. It's also worth noting that `private static` is concerned with scope, not types.
      - mplanchard 6y ago
        Most type systems also provide information about what’s in the array, like Array<String> or int[]
        TooCreative 6y ago
        That is just another piece of metadata. But it does not help either. Now you know you get an array of strings. But you still don't know what is inside of the strings. It might be ['headers'=>'...','body'=>'...' ] or ['status'=>'...','response'=>'...'] or god knows what. And you are back to reading the function body.
        mplanchard 6y ago
        Is that like a hashed array you’re implying? In that case, the type wouldn’t be string anyway, but something like HashMap, Object, Dict, etc. More commonly though, something like HTTP options would be its own type, with defined properties, which you could browse via autocomplete or your IDE’s hover/peek functionality. That type would then specify the types of its values, so you can be certain that options.status is an integer, for example. You’d generally only use an otherwise untyped array of strings when you can’t know beforehand what their values can be.
  - viraptor 6y ago
    You're showing an example of a function signature in a specific language, not an example of typing though. These are related but not exactly the same. For example here is a Ruby version, very dynamic: def request(method, url, **options) end request("get", "http...", foo: "bar") And here is a completely statically typed Crystal version: def request(method, url, **options) end request("get", "http...", foo: "bar") The argument types are inferred automatically from the usage and mismatched usage will be caught at compile time. And in the second case the ide can still tell you the types in the signature if you want to know them. In the third example, here's completely dynamic python: def request(method: str, url: str, **options): Dict[...] No type checking happens here in the language itself. So what I'm getting at is - if you don't like languages with verbose explicit type signatures, it doesn't mean you don't like static types.
    - nyanpasu64 6y ago
      Nitpick: It's -> Dict[...]. Colons begin a function body.
  - tluyben2 6y ago
    Got that, but was triggered by ‘algorithmic structure’; that sounds a tad ‘over the top’ when you then come with some basic web request. However, I would not call your example particularly well typed. Array is still basically untyped. When I talk about types I mean things like; Either<Error,Group> AddGroup(string GroupName, User[]? users) In this case I know what I am getting and I know the users are already, when reaching the webserver, deserialized, validated (or the type would reject them and produce an error and I know I am getting an actual Group back. in your case that would be; function AddGroup(GroupName, Users) I have no idea how that is better or clearer or less work to write? No idea what it returns; Users probably is an array of users, but is it? Or is it a typo? And I need to validate whatever comes in. You can add docs but I do that still with the typed version (although thats automated mostly unless I need to explain something). Worse as well is that when I have this: function AddGroup(GroupName, Users) function AddGroups(GroupNames, Users) Now i'm completely lost. I'm not even sure these users as input are the same things? Both arrays? Both the same User 'things'? Output? But yes, in php I write typeless mostly too (although I luckily do not have to touch it much anymore) as the types mostly suck. But in more advanced type systems, the types will tell you a lot/all about the input/output, so you can do without a lot of docs and trying things out can be automated; as we know the precise input so some generator can generate example input that will immediately work; like swagger on speed. Etc. But agreed, your example does not benefit too much from typing, however I would define Option[] as something precise than just a void* and hope for the best. Also Method and URL so I know invalid input for those very well defined things cannot be violated. So your example: private static function request(Method $method, URL $url, Option[]? $options): WebResult would clear up a lot for me. Now, for instance, I can see, and not guess, that you are answering a web request instead of some request with confusingly similar names to webrequests. But how about some more 'concrete' examples; 'request' is rather a low level / abstract thing (I hope...). But your business logic would contain more concrete functions; any examples from those that are similarly badly geared to types?
    - TooCreative 6y ago
      And now instead of $body = Http::request('GET', 'https://example.com')['body']; You have to do this? $body = Http::request(new Method('GET'), new URL('https://example.com'))->body; And you have cuttered the global namespace with "Method", "URL" and "Option"?
  - jenscow 6y ago
    A better example for a typed function would be something like: function Request(string method, string url, RequestOptions options) : Result {...} or Result Request(string method, string url, RequestOptions options) {...} Here, we know `url` is a string (rather than the parsed object), we know all the supported options (they're members of the RequestOptions object/enum), and every value in the return value. Some might suggest even making `method` an enumeration. If the function name was better, you could call that function right now without needing any more information. Also, especially if you're a fan of defensive programming, most of the basic argument checking is performed at compile time, leaving the function body cleaner. Based on your example alone, perhaps you don't have enough experience with typed languages to appreciate the benefits. I don't mean that in a belittling way, but more of an invitation to learn more about the craft.
    - TooCreative 6y ago
      For the example I simply took to a random, recently updated file from Symfony: https://github.com/symfony/http-client/blob/master/HttpClientTrait.php#L33 https://github.com/symfony/http-client/blob/master/HttpClien... And shortened it a bit. In the real example, as you can see, there are even more parameters, making it even harder to read.
      - jenscow 6y ago
        Well, for me it's easier - perhaps because I'm used to reading parameters in type+name pairs. The data type is right next to the parameter name - and it will be in the pop-up provided by my IDE when I use the function... I don't need to look at the docs or comment (which may not exist).
  - sktguha 6y ago
    you could possible write an IDE plugin that hides the types information and only show them on hover etc. I don't think this reason is that strong of a point IMHO.

tluyben2 6y ago

What are you working on though? What algorithmic structure?

TooCreative 6y ago
Compare this: private static function request(?string $method, ?string $url, array $options): array { ... } To this: function request($method, $url, $options) { ... } I can grasp the latter much better. It immediately forms a structure in my head that I will remember while I read other parts of the code. To do the same with the former, I think my brain uses up twice the energy or more. And even then, I will not have such a good grasp on it as with the former.
- unrealhoang 6y ago
  Counter point: with the former, I know exactly how to use it: for item in request(“get”, “google.com”, []) { .... } Whereas if there’s no example for the latter, I’d have to read the code of that function (or sometime the code of the functions it called) to know how to use correctly.
  - TooCreative 6y ago
    Wishful thinking. You know it returns an array, but you don't know what the array contains. So you don't know how to use it. You still need to look into the code to see what it returns. Then you will see that it returns an array and what the array contains. And now you had to process the information that it returns an array twice. Once in the function definition and once in the function body.
    - castwide 6y ago
      > You know it returns an array, but you don't know what the array contains. So you don't know how to use it. That's a limitation of your specific example, not type systems in general.
      - TooCreative 6y ago
        For the example I took a random line from Symfony and shortened it a bit: https://github.com/symfony/http-client/blob/master/HttpClientTrait.php#L33 https://github.com/symfony/http-client/blob/master/HttpClien... You are free to link to some other example.
        castwide 6y ago
        Any example where the type is defined as something more specific than an array (especially in PHP, where the `array` type doesn't even differentiate between numerically indexed arrays and dictionaries). Regardless, I still think the type hints in Symfony's version are better than nothing. It's also worth noting that `private static` is concerned with scope, not types.
    - mplanchard 6y ago
      Most type systems also provide information about what’s in the array, like Array<String> or int[]
      - TooCreative 6y ago
        That is just another piece of metadata. But it does not help either. Now you know you get an array of strings. But you still don't know what is inside of the strings. It might be ['headers'=>'...','body'=>'...' ] or ['status'=>'...','response'=>'...'] or god knows what. And you are back to reading the function body.
        mplanchard 6y ago
        Is that like a hashed array you’re implying? In that case, the type wouldn’t be string anyway, but something like HashMap, Object, Dict, etc. More commonly though, something like HTTP options would be its own type, with defined properties, which you could browse via autocomplete or your IDE’s hover/peek functionality. That type would then specify the types of its values, so you can be certain that options.status is an integer, for example. You’d generally only use an otherwise untyped array of strings when you can’t know beforehand what their values can be.
- viraptor 6y ago
  You're showing an example of a function signature in a specific language, not an example of typing though. These are related but not exactly the same. For example here is a Ruby version, very dynamic: def request(method, url, **options) end request("get", "http...", foo: "bar") And here is a completely statically typed Crystal version: def request(method, url, **options) end request("get", "http...", foo: "bar") The argument types are inferred automatically from the usage and mismatched usage will be caught at compile time. And in the second case the ide can still tell you the types in the signature if you want to know them. In the third example, here's completely dynamic python: def request(method: str, url: str, **options): Dict[...] No type checking happens here in the language itself. So what I'm getting at is - if you don't like languages with verbose explicit type signatures, it doesn't mean you don't like static types.
  - nyanpasu64 6y ago
    Nitpick: It's -> Dict[...]. Colons begin a function body.
- tluyben2 6y ago
  Got that, but was triggered by ‘algorithmic structure’; that sounds a tad ‘over the top’ when you then come with some basic web request. However, I would not call your example particularly well typed. Array is still basically untyped. When I talk about types I mean things like; Either<Error,Group> AddGroup(string GroupName, User[]? users) In this case I know what I am getting and I know the users are already, when reaching the webserver, deserialized, validated (or the type would reject them and produce an error and I know I am getting an actual Group back. in your case that would be; function AddGroup(GroupName, Users) I have no idea how that is better or clearer or less work to write? No idea what it returns; Users probably is an array of users, but is it? Or is it a typo? And I need to validate whatever comes in. You can add docs but I do that still with the typed version (although thats automated mostly unless I need to explain something). Worse as well is that when I have this: function AddGroup(GroupName, Users) function AddGroups(GroupNames, Users) Now i'm completely lost. I'm not even sure these users as input are the same things? Both arrays? Both the same User 'things'? Output? But yes, in php I write typeless mostly too (although I luckily do not have to touch it much anymore) as the types mostly suck. But in more advanced type systems, the types will tell you a lot/all about the input/output, so you can do without a lot of docs and trying things out can be automated; as we know the precise input so some generator can generate example input that will immediately work; like swagger on speed. Etc. But agreed, your example does not benefit too much from typing, however I would define Option[] as something precise than just a void* and hope for the best. Also Method and URL so I know invalid input for those very well defined things cannot be violated. So your example: private static function request(Method $method, URL $url, Option[]? $options): WebResult would clear up a lot for me. Now, for instance, I can see, and not guess, that you are answering a web request instead of some request with confusingly similar names to webrequests. But how about some more 'concrete' examples; 'request' is rather a low level / abstract thing (I hope...). But your business logic would contain more concrete functions; any examples from those that are similarly badly geared to types?
  - TooCreative 6y ago
    And now instead of $body = Http::request('GET', 'https://example.com')['body']; You have to do this? $body = Http::request(new Method('GET'), new URL('https://example.com'))->body; And you have cuttered the global namespace with "Method", "URL" and "Option"?
- jenscow 6y ago
  A better example for a typed function would be something like: function Request(string method, string url, RequestOptions options) : Result {...} or Result Request(string method, string url, RequestOptions options) {...} Here, we know `url` is a string (rather than the parsed object), we know all the supported options (they're members of the RequestOptions object/enum), and every value in the return value. Some might suggest even making `method` an enumeration. If the function name was better, you could call that function right now without needing any more information. Also, especially if you're a fan of defensive programming, most of the basic argument checking is performed at compile time, leaving the function body cleaner. Based on your example alone, perhaps you don't have enough experience with typed languages to appreciate the benefits. I don't mean that in a belittling way, but more of an invitation to learn more about the craft.
  - TooCreative 6y ago
    For the example I simply took to a random, recently updated file from Symfony: https://github.com/symfony/http-client/blob/master/HttpClientTrait.php#L33 https://github.com/symfony/http-client/blob/master/HttpClien... And shortened it a bit. In the real example, as you can see, there are even more parameters, making it even harder to read.
    - jenscow 6y ago
      Well, for me it's easier - perhaps because I'm used to reading parameters in type+name pairs. The data type is right next to the parameter name - and it will be in the pop-up provided by my IDE when I use the function... I don't need to look at the docs or comment (which may not exist).
- sktguha 6y ago
  you could possible write an IDE plugin that hides the types information and only show them on hover etc. I don't think this reason is that strong of a point IMHO.