Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“The days of using untyped languages on non-trivial projects are over.”

github.com

Post reply on HN
Print view View original

21–30 of 117 posts

Re: “The days of using untyped languages on non-trivial projects are over.”

#21

Post by tmpz22 »

Pet_Ant wrote: post #8
tmpz22 wrote: post #4

It’s disappointing that a lot of arguments for typing fail to explore why untyped languages became popular to begin with and how those benefits can be maintained throughout the migration process through partial typing To complete typing. When typing is applied gradually throughout a codebase it can sometimes manifest as the worst of both world and a complete argument should at least acknowledge that as well as the im…

What are the downsides of gradual typing on a codebase? I've never worked with it, but watched some talks on it and it really sounds promising. I understand the downsides for compiler complexity and for performance, but not on the codebase itself.

> What are the downsides of gradual typing on a codebase?

Typing complex business domains and interactions is hard. Most developers don’t have a lot of experience with it or the time to do it properly as they produce features. It doesn’t help that many developers start their career with untyped languages and transition into typed languages without learning it properly.

Typescript is a great example because a lot of frontend developers may have only ever worked in JavaScript and have absolutely no foundation to build on but trial and error on your companies production codebase.

Re: “The days of using untyped languages on non-trivial projects are over.”

#22

Post by JohnFen »

chunkyguy wrote: post #16

Can we just agree that there can never be one solution that fits all problem spaces. I use both C++ and ruby for different jobs and I like/hate both equally.

This is a soapbox I've been on for decades. There's a reason why I have bothered to become competent in a large number of languages: each has their own strengths and weaknesses, and so there is no single language that is best for every sort of program and environment.

Re: “The days of using untyped languages on non-trivial projects are over.”

#23

Post by MrResearcher »

I came to typescript after many years of C++. I found typescript to be a much better language than C++ overall, and I'm far much more productive with typescript. I'm glad that a lot of people can manage without the types, and I've seen many successful big projects plowing along just nicely. I personally wouldn't be able to maintain a large project without types. It seems that a lot of people figured out for themselves how to do it. If you are one of them, how do you refactor the codebase? Are you relying solely on unit tests to avoid breaking all involved pieces? In Typescript I usually just go ahead and change the structure or method parameters in type-incompatible way. In many cases it's sufficient to fix all places to maintain the project in an unbroken state.

I'm looking forward to the launch of Zig, that should be a good choice for WASM. Only if I could get a pytorch-like interface in Zig now...

Re: “The days of using untyped languages on non-trivial projects are over.”

#26

Post by alwaysbeconsing »

jghn wrote: post #2

I always wonder why inference a la Hindley-Milner isn't what people push as the best of both worlds.

Inference for static types requires more from the compiler in two key ways that impact the developer experience. First, it's just plain more work to do when compiling, so compile times are longer than they might otherwise be. Second, error handling and messaging needs to be written very carefully to avoid dense and unhelpful output when inference fails. It's positive in many ways, but it's not a free lunch.

Re: “The days of using untyped languages on non-trivial projects are over.”

#27

Post by HPsquared »

jvanderbot wrote: post #5

The days of sweeping declarations regarding obviously periodic trends have never arrived. I've been around long enough that "safe" gave way to "productivity" and back to "safe". There's kind of a nascent ethos of being "better" in each new generation that just results in these pendulum effects. The overall effect seems to be enormously positive. I can now bounce between several completely valid build environments, ec…

I think eventually students will be taught the "classics".

Re: “The days of using untyped languages on non-trivial projects are over.”

#28

Post by justinpombrio »

Pet_Ant wrote: post #8
tmpz22 wrote: post #4

It’s disappointing that a lot of arguments for typing fail to explore why untyped languages became popular to begin with and how those benefits can be maintained throughout the migration process through partial typing To complete typing. When typing is applied gradually throughout a codebase it can sometimes manifest as the worst of both world and a complete argument should at least acknowledge that as well as the im…

What are the downsides of gradual typing on a codebase? I've never worked with it, but watched some talks on it and it really sounds promising. I understand the downsides for compiler complexity and for performance, but not on the codebase itself.

Some downsides of gradual typing:

- Worse type error messages, as the type system has to be more complicated to handle the sorts of patterns that are common in untyped code.

- You can still get type errors at runtime in your typed code, if it interacts with untyped code, because it isn't feasible to validate all types on the boundary. You're only guaranteed no runtime type errors if all of your code is typed.

- The migration path from untyped to typed isn't always easy. Depending on how your code is organized, it's possible to have correct untyped code such that there do not exist type annotations you could add to it that would make it type check.

Re: “The days of using untyped languages on non-trivial projects are over.”

#29

Post by nicoburns »

Pet_Ant wrote: post #8
tmpz22 wrote: post #4

It’s disappointing that a lot of arguments for typing fail to explore why untyped languages became popular to begin with and how those benefits can be maintained throughout the migration process through partial typing To complete typing. When typing is applied gradually throughout a codebase it can sometimes manifest as the worst of both world and a complete argument should at least acknowledge that as well as the im…

What are the downsides of gradual typing on a codebase? I've never worked with it, but watched some talks on it and it really sounds promising. I understand the downsides for compiler complexity and for performance, but not on the codebase itself.

Done badly you can end up doing a lot of admin to make the types work without actually getting the benefit of that type safety. Done well you can get the benefits of type safety where it really counts and avoid the overhead where it doesn’t.

Re: “The days of using untyped languages on non-trivial projects are over.”

#30

Post by Animats »

Programming seems to be settling down in this area. Parameters to functions and fields in data structures are usually explicitly typed, while local variable types are inferred when possible. C++, Go, and Rust have all converged on this.

C++ used to suffer from "for" loops with insanely long type declarations for iterator variables. "auto" fixed that.

Inter-function type inference, while technically possible, is just too confusing for people reading the code. So that went away. Mostly, type inference is now forward only. Inverse type inference through long chains is, again, possible but too confusing.

Explicit typing of structure fields and function parameters allows automatic generation of reasonably useful documentation. That gives programmers anchor points at which they can see types.

So this has become a solved problem for compiled languages.

Post reply on HN