6 ms·

> Types are meant to document code. Without the annotations, you can't look at code and know what is going on With the rise of VSCode IntelliSense/JetBrains co

> Types are meant to document code. Without the annotations, you can't look at code and know what is going on With the rise of VSCode IntelliSense/JetBrains code inspection, do you believe this is still true today? The programmer now has easy ahead-of-time access to inferred types that used to become available only at compile time or runtime

mamcx 6y ago
I think yes. I do F# for a lot of time, and looking at past code I can't just figure some stuff. Not only their type system look alike dynamic, it make you build some stuff that is IMPOSSIBLE to get without a serious look at the types: And the types are invisible and behind abstracts constructs. With python, for example, I can't at first see what a function need but at least see the body give huge clues, because python rely less of abstract type stuff (it have a issue with monkey patching and delayed build of objects BUT, "if look like a duck.." is most of the time enough to get things..
- gmfawcett 6y ago
  F# lets you specify the types of function arguments and return values. If it will make your code easier to read and reason about, why not just do that? I use Ocaml a lot, which is very similar to F# as you know... and I document the types of all toplevel values in my code. Not because the compiler needs it, but because it helps me navigate the code more easily.
  - mamcx 6y ago
    Yeah, but it is not very idiomatic and if I need to put types everywhere, but is the point of it at the end? Is like people that type python: Is screaming is the wrong tool for the job :)
watwut 6y ago
The types make those uis much more powerful.
ysavir 6y ago
Should it be expected that all programmers use these text editors and have access to these tools? As someone that likes to keep his editor simple (to an extent--I'm using VIM after all), I always get frustrated when people try to introduce policies or procedures that work for them and their preferred setup, and who look at me as an obstacle because I prefer a different setup. I'm of the opinion that code should be written independent of the tools used to understand and modify that code. If there's anything about the code that needs to be communicated, it should be communicated via the code itself, whether through naming patterns, comments, types, or any other methodology that can be encapsulated in a text file. Other than letting each developer have their own preferred processes and coding environment, it also makes it easier to SSH into a remote box and know what's going on. A quick google shows that VS Code does allow for SSHing and browsing the remote files via VSCode. That's nice, but I don't know how well it works, and how much I like the idea of allowing another program to run commands on the remote box. I like that I can SSH into a box and use the tools natively available there to read and modify the code, and that the code is prepared in a way that makes it as easy as possible.
- bdavis__ 6y ago
  i tend to agree with you. maybe more than just agree. if any of these "IDE's", or "tools", or whatever they are called actually provided a universal improvement in software quality and development time, then i would change my view. experienced developer, the tools don't make a difference. VSCode, VisualStudio, Eclipse, tried many of them. This is from my experience, it may or may not be universal.
  - ysavir 6y ago
    > VSCode, VisualStudio, Eclipse, tried many of them. This is from my experience, it may or may not be universal. Exactly. If specific tools allow specific people to work better, great. I completely support them. But it's unfair to say that what works for some will work for all. My goal when adapting practices is to adapt the practices that allow each developer on the team to work in the way that's best for them, and to avoid rules that limit developers in their choices. Always willing to update when a clear case is made, though. Recently I stopped my rule of "80 characters per line max" because I don't think 80 character wide screens are common enough to warrant my consideration. Now I limit line length based on what makes that line of code most easily digestible--whether 30 characters, 80, 140.
dboreham 6y ago
Definitely not true.

mamcx 6y ago

I think yes. I do F# for a lot of time, and looking at past code I can't just figure some stuff. Not only their type system look alike dynamic, it make you build some stuff that is IMPOSSIBLE to get without a serious look at the types: And the types are invisible and behind abstracts constructs. With python, for example, I can't at first see what a function need but at least see the body give huge clues, because python rely less of abstract type stuff (it have a issue with monkey patching and delayed build of objects BUT, "if look like a duck.." is most of the time enough to get things..

gmfawcett 6y ago
F# lets you specify the types of function arguments and return values. If it will make your code easier to read and reason about, why not just do that? I use Ocaml a lot, which is very similar to F# as you know... and I document the types of all toplevel values in my code. Not because the compiler needs it, but because it helps me navigate the code more easily.
- mamcx 6y ago
  Yeah, but it is not very idiomatic and if I need to put types everywhere, but is the point of it at the end? Is like people that type python: Is screaming is the wrong tool for the job :)

watwut 6y ago

The types make those uis much more powerful.

ysavir 6y ago

Should it be expected that all programmers use these text editors and have access to these tools? As someone that likes to keep his editor simple (to an extent--I'm using VIM after all), I always get frustrated when people try to introduce policies or procedures that work for them and their preferred setup, and who look at me as an obstacle because I prefer a different setup. I'm of the opinion that code should be written independent of the tools used to understand and modify that code. If there's anything about the code that needs to be communicated, it should be communicated via the code itself, whether through naming patterns, comments, types, or any other methodology that can be encapsulated in a text file. Other than letting each developer have their own preferred processes and coding environment, it also makes it easier to SSH into a remote box and know what's going on. A quick google shows that VS Code does allow for SSHing and browsing the remote files via VSCode. That's nice, but I don't know how well it works, and how much I like the idea of allowing another program to run commands on the remote box. I like that I can SSH into a box and use the tools natively available there to read and modify the code, and that the code is prepared in a way that makes it as easy as possible.

bdavis__ 6y ago
i tend to agree with you. maybe more than just agree. if any of these "IDE's", or "tools", or whatever they are called actually provided a universal improvement in software quality and development time, then i would change my view. experienced developer, the tools don't make a difference. VSCode, VisualStudio, Eclipse, tried many of them. This is from my experience, it may or may not be universal.
- ysavir 6y ago
  > VSCode, VisualStudio, Eclipse, tried many of them. This is from my experience, it may or may not be universal. Exactly. If specific tools allow specific people to work better, great. I completely support them. But it's unfair to say that what works for some will work for all. My goal when adapting practices is to adapt the practices that allow each developer on the team to work in the way that's best for them, and to avoid rules that limit developers in their choices. Always willing to update when a clear case is made, though. Recently I stopped my rule of "80 characters per line max" because I don't think 80 character wide screens are common enough to warrant my consideration. Now I limit line length based on what makes that line of code most easily digestible--whether 30 characters, 80, 140.

dboreham 6y ago

Definitely not true.