4 ms·

> A decent IDE should make the type information available when you need it. A decent programming language shouldn't need an IDE to understand the code. What ha

by rakoo 6y ago

> A decent IDE should make the type information available when you need it. A decent programming language shouldn't need an IDE to understand the code. What happens when you post a snippet online ? Or when you look at a diff in github ?

lmm 6y ago
Why? Why make the common, important case worse for the sake of the uncommon case? In any language you have to make a tradeoff between concision and explicitness. With type inference you could write code whose text is just as explicit as you'd do in an untyped language, and use the types solely to provide more detail. Or you could put no more detail than in an untyped language, but move some of that detail into types and make your code more concise. Most people find a point somewhere in the middle, and end up with code that's both more concise and more explicit (when you look at the types); of course that means the code is more "magic" if you're looking solely at the text.
- rakoo 6y ago
  Merge requests/Pull requests are definitely an integral part of development, I don't think you can say it's an uncommon case. Same goes for sharing snippets with colleagues to explain/understand ehat is happening. Even Go has shown that there is value in not putting a lot of context in every single word of your language: it makes it longer to write, but easier to read whrn you have no prior experience of said piece of code. There is definitely a balance to be found, but I believe most languages today (and, unfortunately, programmers) rely too much on an IDE even though there's a large enough part of our work happening outside of it.
  - lmm 6y ago
    > Merge requests/Pull requests are definitely an integral part of development, I don't think you can say it's an uncommon case. Reviewing PRs is important, but you'd normally do it from a development machine with your normal tooling available; I don't think it's too big an imposition to say you should do it with an IDE, or else accept that you will have slightly less context available. (In some ways it's good to review that way, as it means you evaluate whether the code is still clear even with less information available). > Same goes for sharing snippets with colleagues to explain/understand ehat is happening. I hardly ever see that happen; it's usually much better to create a branch or worksheet. > There is definitely a balance to be found, but I believe most languages today (and, unfortunately, programmers) rely too much on an IDE even though there's a large enough part of our work happening outside of it. IMO it's just the opposite; there's a lot of good things we can do with the GUI tools that we realistically ~always have available. Programmers are rightly sceptical of "visual programming" tools that break VCS history, but a language that has an understandable textual representation enhanced by the GUI gets you the best of both worlds.

by rakoo 6y ago

lmm 6y ago

Why? Why make the common, important case worse for the sake of the uncommon case? In any language you have to make a tradeoff between concision and explicitness. With type inference you could write code whose text is just as explicit as you'd do in an untyped language, and use the types solely to provide more detail. Or you could put no more detail than in an untyped language, but move some of that detail into types and make your code more concise. Most people find a point somewhere in the middle, and end up with code that's both more concise and more explicit (when you look at the types); of course that means the code is more "magic" if you're looking solely at the text.

rakoo 6y ago
Merge requests/Pull requests are definitely an integral part of development, I don't think you can say it's an uncommon case. Same goes for sharing snippets with colleagues to explain/understand ehat is happening. Even Go has shown that there is value in not putting a lot of context in every single word of your language: it makes it longer to write, but easier to read whrn you have no prior experience of said piece of code. There is definitely a balance to be found, but I believe most languages today (and, unfortunately, programmers) rely too much on an IDE even though there's a large enough part of our work happening outside of it.
- lmm 6y ago
  > Merge requests/Pull requests are definitely an integral part of development, I don't think you can say it's an uncommon case. Reviewing PRs is important, but you'd normally do it from a development machine with your normal tooling available; I don't think it's too big an imposition to say you should do it with an IDE, or else accept that you will have slightly less context available. (In some ways it's good to review that way, as it means you evaluate whether the code is still clear even with less information available). > Same goes for sharing snippets with colleagues to explain/understand ehat is happening. I hardly ever see that happen; it's usually much better to create a branch or worksheet. > There is definitely a balance to be found, but I believe most languages today (and, unfortunately, programmers) rely too much on an IDE even though there's a large enough part of our work happening outside of it. IMO it's just the opposite; there's a lot of good things we can do with the GUI tools that we realistically ~always have available. Programmers are rightly sceptical of "visual programming" tools that break VCS history, but a language that has an understandable textual representation enhanced by the GUI gets you the best of both worlds.