I don't need to turn it off to find out - I've worked in enough untyped languages (Python, Ruby) or badly set up ones (C++) where code intelligence tools don't work to know what it's like, and none of your points are true.
1. I know where the reference docs live already. Auto-complete doesn't obviate that need.
2. Again auto-complete doesn't completely obviate the need to navigate by file name/path (though it does reduce it), so I already know that is valuable.
3. The speed of typing sometimes is a limitation. I'm not a slow typer but sometimes there are situations where you just have to type out something tedious, and you're not doing anything other than typing. Yes even with fancy Vim/multiple cursor editing. Auto-complete speeds that up a little, but Copilot sometimes speeds it up a lot. You should try it.
For example for printf debugging, with copilot you can pretty much just type `dbg!` and hit tab. Much faster.
You also missed some significant advantages:
1. go-to-definition makes navigation much faster
2. type inlays make understanding the code much faster
3. auto-complete makes looking up method names much faster (is it .starts_with or .has_prefix? .contains, .has, .any, or .some?)
The only upside of not using LSP tooling is that sometimes it can bring your computer to it's knees, whereas plain text editing will always be fast. Easily worth it though.
It seems you're confusing the fact that the type checking happens at runtime (that is to say, that they are dynamically typed) to mean that they're "untyped", but that's just not the case.
If one is confused about the languages one is using at this level, then modern tooling features aren't likely to help much.
I'm not confusing anything. It's relatively common to call the use of dynamically typed languages without static type hints "untyped". I'm pretty sure you knew what I meant and are just trying the classic "you used this word in a way I don't agree with therefore you're wrong".
Those terms have actual meaning, I've never heard Python or Ruby referred to as untyped. Because they both definitely have types and are in fact strongly typed.
Like, no one would call Ocaml untyped if you used type inference and didn't spell them out yourself... Or if you used the auto keyword everywhere in C++... The Ruby and Python runtimes both definitely enforce types.
In fairness I think it is a fairly recent linguistic shift, probably because there's no debate between weakly typed and strongly typed - strongly typed is oblivious the right answer. Instead the debate is between dynamically-typed-without-static-type-annotations and statically-typed-or-dynamically-typed-with-static-type-annotations, but obviously people need a more succinct term for that.
> Like, no one would call Ocaml untyped if you used type inference and didn't spell them out yourself... Or if you used the auto keyword everywhere in C++... The Ruby and Python runtimes both definitely enforce types.
Static type inference still counts as having static types. That's totally different to dynamic typing without static type annotations ("untyped").
Not a good option - then you'll get a whole different set of pedants saying that Python is always dynamically typed, which I think is a lot more reasonable than quibbling over the use of "untyped" to describe Forth.
Adding type annotations doesn't make Python statically typed. Type annotations are borderline meaningless, they're basically just a type of documentation that helps your tools spit out better suggestions and makes your tools yell at junior developers.
Python isn't taking advantage of type annotations to produce better compiled code or anything, it's still a dynamic language that infers types at runtime.
If by one of those you mean a solopreneur who doesn't have any junior devs to yell at then yes. If I wanted to use static types I'd use an actual statically typed language with all of the performance benefits (Go, Java, Rust, Haskell, Ocaml, etc...).
Using a dynamically typed/interpreted language with type annotations is literally the worst of all worlds...
It's relatively common to call the use of dynamically typed languages without static type hints "untyped".
And it's relatively common for people to be simply wrong, or to be careless in their word choice in regard to lots of other matters.
I'm pretty sure you knew what I meant and are just trying the classic "you used this word in a way I don't agree with therefore you're wrong".
It wasn't, i.e. I wasn't considering the possibility that that was what you meant. This is the first time I've encountered this broken usage of the term.
1. I know where the reference docs live already. Auto-complete doesn't obviate that need.
2. Again auto-complete doesn't completely obviate the need to navigate by file name/path (though it does reduce it), so I already know that is valuable.
3. The speed of typing sometimes is a limitation. I'm not a slow typer but sometimes there are situations where you just have to type out something tedious, and you're not doing anything other than typing. Yes even with fancy Vim/multiple cursor editing. Auto-complete speeds that up a little, but Copilot sometimes speeds it up a lot. You should try it.
For example for printf debugging, with copilot you can pretty much just type `dbg!` and hit tab. Much faster.
You also missed some significant advantages:
1. go-to-definition makes navigation much faster
2. type inlays make understanding the code much faster
3. auto-complete makes looking up method names much faster (is it .starts_with or .has_prefix? .contains, .has, .any, or .some?)
The only upside of not using LSP tooling is that sometimes it can bring your computer to it's knees, whereas plain text editing will always be fast. Easily worth it though.