[billisonline]

> 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

[ysavir]

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.

[billisonline]

> Should it be expected that all programmers use these text editors and have access to these tools?

If they don't have access, then the tools ought to be standardized to the point where they can be integrated into any editor. The Language Server Protocol[1] seems like a step toward this.

> I'm of the opinion that code should be written independent of the tools used to understand and modify that code.

This a widespread, "common sense" opinion that I've come to disagree with strongly. No one would argue that, e.g., illustrators, 3D modelers, music producers, etc. should be so tool-agnostic—and yet their situation is quite similar. One could produce a complex piece of music in Audacity instead of using Logic or Ableton, but musicians don't have the same mentality of picking the cheapest, most austere, or lowest-common-denominator tool. Instead, they invest in tools that enhance their productivity. And that's precisely what's at stake here. Pairing (a) a language that allows implicit "smart" features like type inference with (b) an equally smart editor to make what is implicit in the code explicit to the developer as needed, is more productive than forcing the developer to make everything explicit themselves.

Re: using VIM over ssh, your choice of scenario is revealing. Why would you limit your everyday development work based on the lowest common denominator tool you're forced to use in an emergency? Also, it's not necessary to run code inspection on the remote box. JetBrains IDEs, for example, will copy a folder from ssh or a similar environment, index and inspect them locally, and then sync them back as needed.

1: https://microsoft.github.io/language-server-protocol/

[overgard]

Well, to turn around your question: should languages enforce verbosity to satisfy a vocal minority using ancient tools? I'm not going to tell you what tools to use, but if your tools can't understand let/var/auto, then that's not my problem.

[dcre]

You can use these features very easily in Vim with ALE. Map a shortcut to :ALEHover and that's it.

https://github.com/dense-analysis/ale

[ysavir]

Upvoting so that people who need this may see it and benefit from it.

However, it's not that I'm not aware of features available to my editor of choice, it's that I specifically don't want an editor with those features. I don't want that functionality as part of my workflow. I prefer to reduce the noise and distraction so that I can keep concentrating on what's currently important to me.

Bringing this back to what the root parent was talking about, a significant part of code maintainability comes down to how we design our classes, services, etc. It's not so much about static or dynamic typing--both can experience their fair share of problems--it's about approaching our code in a way that makes it easiest for future readers and maintainers to pick up where we left off. That's a difficult task, but one that makes a huge difference. Saying that specific editors can alleviate some of those problems misses the point: that the underlying code itself is not well designed. What I meant to add is using these editor tools not only fails to fix the underlying problem, but that it also forces developers into tools they may not want to use.

[dcre]

I think you point to an important tradeoff. I also think it's clear the industry is leaning toward the decision that it is not worth giving up the advantages of static typing for the 0.1% of users who really don't want type info in their editor.

Your distinction between the code itself and editor-based tools I think is a false one. The types are part of the code, and while one can use them tolerably well on the command line alone, they are most helpful with things like type hovers. The line is blurry between language features and code structure on the one hand and the editor tooling that gets the most out of it on the other.

[bdavis__]

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.

[solidasparagus]

It's weird to make this argument in a thread about how type inference is only problematic if you aren't using a modern tool that understands the code at a level higher than raw text. Clearly the tool is making a difference.

[ysavir]

> 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.

[SebastianKra]

These features are now available in all common text editors.

Also keep in mind that you're missing out on many other arguably essential tools such as debuggers, smarter shortcuts, and other static analysis.

Therefore, yes, I think it should be expected of a programmer to pick the right tools for the job, in the same way that it can be expected of a designer to be able to work with Adobe files.

If classic VIM doesn't offer these features, then it isn't sufficient as a code editor anymore.

[ysavir]

> These features are now available in all common text editors.

It's not just a matter of whether they're available, it's a matter of whether it's a fair expectation.

I've been developing for a decade and never found that I'm "missing out on many other arguably essential tools". Typically I'm as productive or more productive than my peers.

I get that you think usage of these features is a fair expectation. Can you provide your argument for why you think that's a fair expectation?

[solidasparagus]

Working with code as if it is raw text is strictly inferior to working with code as raw text + AST. If that’s how you want to work, that’s fine, but it’s probably not good to choose your team's technologies because you want to work at that lower lever of abstraction.

[dathanb82]

> Typically I’m as productive or more productive than my peers.

This seems like a case of assuming the conclusion, tho. Whether a text editor-based workflow is as productive as an IDE-based workflow when avoiding feature that advantage the IDE doesn’t impact on whether the IDE-favoring features are valuable enough to adopt and assume everyone has access to.

[mamcx]

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]

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]

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]

The types make those uis much more powerful.

[dboreham]

Definitely not true.