Live data from Hacker News

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

github.com

81–90 of 117 posts

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

#81

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…

is there a correlation to "the economy" and the trend du jour?

seems "safe" would go over better in recession times, while "productivity" is just a nicer way of saying "move fast"

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

#82

Earlier quoted context omitted.

That doesn't mean gradual typing is the worst of both worlds though? It's bad but it's still not as bad as no static types.

it's worst of both worlds because types are not free. There is a certain amount of energy and effort and maintenance that you must put into type annotations. Before you reach the point of return on that investment you have to plow through the period of limbo where the cost of annotations is greater than the rewards. Some codebases never make it out of that morass. One could easily make the argument that adding types…

> Before you reach the point of return on that investment you have to plow through the period of limbo where the cost of annotations is greater than the rewards.

I'm a staunch supporter of static typing. But man, the amount of energy people put into getting things like mypy to go green in strict mode just doesn't make sense to me. There are going to be situations where the cost to avoid the mypy ignore on a line will *never* be worth the long term benefit. But nevertheless they persist

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

#83

Earlier quoted context omitted.

That doesn't mean gradual typing is the worst of both worlds though? It's bad but it's still not as bad as no static types.

it's worst of both worlds because types are not free. There is a certain amount of energy and effort and maintenance that you must put into type annotations. Before you reach the point of return on that investment you have to plow through the period of limbo where the cost of annotations is greater than the rewards. Some codebases never make it out of that morass. One could easily make the argument that adding types…

> Before you reach the point of return on that investment you have to plow through the period of limbo where the cost of annotations is greater than the rewards. Some codebases never make it out of that morass.

I disagree. In my experience of adding types to a terrible Python codebase the rewards are always greater than the cost, even if the effort is frustratingly high. In that situation the biggest rewards are that you make the code understandable, navigable and maintainable.

The frustrating effort must be paid whether or not you add static types. You can either pay it again and again over many years of people trying to figure out how the hell the code works and wasting time navigating and refactoring the slow way, or you pay it once up front and be done with it.

The only situation I can think of where it might not be worth it is if you have a codebase that is marked for death. If it's being replaced then.. eh. Leave it and let the problem solve itself. Otherwise I've found the effort to always be worth it.

The only big issue I've found is convincing colleagues of this. Especially colleagues that use Vim or Emacs and don't get half of the benefits of static types.

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

#84
post #3

I hate TypeScript so much it's unreal. A MS trojan horse to try and own the full stack, I hope you'll all be happy when we won't be able to use any of our tools without complying to corporate linguistic standards and watching the mandatory 20m of commercials per code scope.

That will undoubtedly happen. But hopefully by then we'll have moved on to more fertile ground.

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

#85

Typescript propaganda. Instead of worrying about types, why not worry about the actual code quality ? Half of all typescript I've seen uses "any", not to mention the fact that it obsfuscates what's actually running in the browser and forces an unnecessary build step for things that aren't "web apps".

The whole point of static types (well one big reason at least) is to improve the actual code quality. I don't understand how you think it obfuscates what is actually running in the browser. Nearly all non-trivial web projects have a build step even if they aren't "web apps". But I agree it would be nice to at least have the option to avoid it. There is a JavaScript proposal going through that should fix that.

> The whole point of static types (well one big reason at least) is to improve the actual code quality.

I have worked on multiple typescript projects that had terrible code quality. Types do not make you write SOLID code.

I find functional programming and well-used functional patterns do result in higher quality code. Typescript’s type system makes writing functional code more difficult. The documentation even recommends against it[1].

IMO typescript is easy to prescribe as a panacea, “just use typescript”, whereas understanding how to write SOLID code takes time.

[1] https://www.typescriptlang.org/docs/handbook/typescript-in-5...

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

#86
post #31

Earlier quoted context omitted.

Types slow you down. New work is first completed in untyped languages. People start using the work. People complain there aren't types. Types are added. Work is now slow in the language. New work is now done in another language without types. Rinse and repeat.

“Types slow you down” is the _stupidest_ excuse I hear all the time. As if developers of untyped languages don’t spend ungodly amounts of time pretending types don’t exist, but needing to manually check them everywhere, wonder why shit blows up at runtime, litter their code with “typeof” style checks, litter their tests with type checking. The types exist and need to be considered whether you believe it or not. Might…

[dead]

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

#87

Earlier quoted context omitted.

The whole point of static types (well one big reason at least) is to improve the actual code quality. I don't understand how you think it obfuscates what is actually running in the browser. Nearly all non-trivial web projects have a build step even if they aren't "web apps". But I agree it would be nice to at least have the option to avoid it. There is a JavaScript proposal going through that should fix that.

> The whole point of static types (well one big reason at least) is to improve the actual code quality. I have worked on multiple typescript projects that had terrible code quality. Types do not make you write SOLID code. I find functional programming and well-used functional patterns do result in higher quality code. Typescript’s type system makes writing functional code more difficult. The documentation even recomm…

> Types do not make you write SOLID code.

Of course. They are not sufficient but they are necessary.

I wouldn't see point free programming is the same as functional programming. Rust has many functional programming features and no currying.

In fact my experience of OCaml is that point free programming makes the code much harder to read.

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

#88
The biggest problem with most typed languages is string handling, especially null terminated strings. Returning a string from a function is a nightmare in almost every typed language, except Delphi/Free Pascal, which does auto-reference counting, and manages it all, you never have to allocate/free memory for them, and they can hold gigabytes.

Typed languages offer some efficiencies, and can, if properly used, help prevent entire classes of footguns, but they do require a bit of planning. I've always wished I could do the same "gradual type" thing with Pascal, Basic, etc. As the program is run, the types are checked, and slowly baked in automatically.

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

#89

The biggest problem with most typed languages is string handling, especially null terminated strings. Returning a string from a function is a nightmare in almost every typed language, except Delphi/Free Pascal, which does auto-reference counting, and manages it all, you never have to allocate/free memory for them, and they can hold gigabytes. Typed languages offer some efficiencies, and can, if properly used, help pr…

> Returning a string from a function is a nightmare in almost every typed language, except Delphi/Free Pascal, which does auto-reference counting, and manages it all, you never have to allocate/free memory for them, and they can hold gigabytes.

Why mention memory allocation at all? There are plenty of typed languages that have automatic garbage collection and handle strings just fine.

Go (Golang) comes to mind as a superb example of a typed language in which string handling is a breeze.

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

#90

Typescript propaganda. Instead of worrying about types, why not worry about the actual code quality ? Half of all typescript I've seen uses "any", not to mention the fact that it obsfuscates what's actually running in the browser and forces an unnecessary build step for things that aren't "web apps".

> Half of all typescript I've seen uses "any"

You're saying that half of the projects you've seen successfully adopted strict typing? And others use an occasional escape hatch, but still try to introduce reasonable typing? That sounds like a success story to me.

Post reply on HN