111–120 of 133 posts
100% agreed. I want to see the types, and not just when hovering. Now, if the IDE autocompletes the type declaration for me somehow, that's great! That's a win-win: I save time but still maintain readability.
Then you will need type inference to some extend. :D
Ditto.
The world where data and it’s type is the SSOT means you can trivially validate every bit of code that touches it.
I’ve been working with TypeScript and it’s literally wrong half the time. This code is 100% correct according to TS: x: number[] = [] y: number = x[0] The array type is missing information about the length of the array, and types are very often missing important information like this. Say you want to describe an array containing only odd integers - good luck. Types are simply a heuristic for humans to try and remembe…
"noUncheckedIndexedAccess": true
type OddNumber = number & { __BRAND_ODD_NUMBER: true }
OddNumber[]
const isOddNumber = (x: unknown): x is OddNumber => typeof x === 'number' && x % 2 === 1Bullocks. I wrote thousands if not hundred thousandths lines of untyped Python code in over 15 years, for critical systems and thousands of users. It works for me. I'm not confused about the code, I can code and debug quicker than many of my typed-language colleagues and even now that python supports type hints I often only use them in bigger projects or in places where they're actually convenient. It's simply the wa…
Man I wish I could somehow convince developers to learn the difference between "dynamically typed", "statically typed", and "gradually typed" languages. An "untyped" language nearly doesn't make any sense semantically: when you have more than one type of value, you have types . In Python's case, there are probably thousands of types in the standard library alone.
You know exactly what that person meant.
Earlier quoted context omitted.
It's not even factual. > In Rust and Haskell you have to at least annotate the parameter types and return type of functions. Type inference is only for variable bindings inside the function body. This is false for Haskell. Can't speak for Rust.
In rust, you are required to annotate at least the interface. In Haskell, if I remember it well, it is allowed but not required. Even in Rust, I tend to specify types at variable bindings if the type gets overly complex, just to push errors closer to their cause. A nice feature of Rust is you can specify partial types, wih underscores for the still-to-infer part. E.g. let x:Vec =someexpression; is a vector of somethi…
Yup. I love that. And it even lets you say things like for example:
let res: Result, _> = someexpression;Earlier quoted context omitted.
Man I wish I could somehow convince developers to learn the difference between "dynamically typed", "statically typed", and "gradually typed" languages. An "untyped" language nearly doesn't make any sense semantically: when you have more than one type of value, you have types . In Python's case, there are probably thousands of types in the standard library alone.
This is one of those cases where I fully stand with the people saying that you should read the writers intent and assume that they just didn't have enough coffee that morning yet to be thinking pedantically. You know exactly what that person meant.
Explicit is better than implicit. But I can see the value of inference if the type is defined by a constant. If the rule is "Variables are the type of the constant that you assign in the definition, anything else is manual" it's pretty obvious.
> Type inference is bad. It makes code harder to read, and languages that use it too much are harder to write. If inference is bad, maybe the second sentence shouldn't leave it up to the reader to infer what "it" means. Surely it would be much easier to read as "Type inference [...] type inference [...] type inference".
Funny enough this is the approach taken in legal writing as to limit misinterpretation... especially purposeful misinterpretation from opposition legal teams! This results in highly repetitive, and as you've pointed out, somewhat tedious reading. F# is my daily driver at work and I definitely benefit from both the type inference as well as my IDE making those types explicit for my reading pleasure!
> languages that use it too much are harder to write. It’s a false economy whereby you save unobservable milliseconds of typing today and make everything else worse. I enjoyed this reference to a false dichotomy while making one itself. Languages don't make programmers leave out annotations where it aids readability.
> Languages don't make programmers leave out annotations where it aids readability. This is true, but most people are not going to incur write-time penalties to benefit read-time later on. Annotations (usually) benefit read-time at the expense of write-time. Having had to work on codebases that were written by people who were furiously trying to "get things done" because not shipping or shipping late might mean going…
I'd say that for most people, use annotations most of the time is good advice, but there are exceptions and people should refrain from casting judgment on other's work due to a dogmatic instance on others using their preferred style.