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

T-Ruby is Ruby with syntax for types

type-ruby.github.io

Post reply on HN
Print view View original

141–150 of 155 posts

Re: T-Ruby is Ruby with syntax for types

#141

Post by ReflectedImage »

blandflakes wrote: post #139
ReflectedImage wrote: post #86

Earlier quoted context omitted.

Nah that's just a lack of understanding in the role of unit tests in dynamically typed languages.

Elsewhere in this thread, dynamic typing advocates malign the hassle of maintaining types, and it is always coupled with strong advocacy for an entire class of unit tests I don't have to write in statically typed languages.

And that's the problem, if you want your code to actually work you do need to write those unit tests. A program not crashing doesn't mean it does the right thing.

With experience you will learn to either write unit tests or spend the same amount of time doing manual testing.

Once you start doing that then the unit tests just replace the static typing and you start shipping better code to your customers.

Re: T-Ruby is Ruby with syntax for types

#142

Post by blandflakes »

ReflectedImage wrote: post #141
blandflakes wrote: post #139

Earlier quoted context omitted.

Elsewhere in this thread, dynamic typing advocates malign the hassle of maintaining types, and it is always coupled with strong advocacy for an entire class of unit tests I don't have to write in statically typed languages.

And that's the problem, if you want your code to actually work you do need to write those unit tests. A program not crashing doesn't mean it does the right thing. With experience you will learn to either write unit tests or spend the same amount of time doing manual testing. Once you start doing that then the unit tests just replace the static typing and you start shipping better code to your customers.

This always feels like a bad faith argument. Nobody says that with static types, you don't need any unit tests.

And your suggestion that people who like static types "don't know how to write unit tests" is further bad faith.

Perhaps it's dynamic typing programmers who don't know how to write sound programs? Except I'm not making that claim, because I'm giving you all some benefit of the doubt, a degree of respect you are not giving others.

Re: T-Ruby is Ruby with syntax for types

#143

Post by jaapz »

ReflectedImage wrote: post #85
matteotom wrote: post #5

Earlier quoted context omitted.

At least for Python (since I'm more familiar with Python code and the Python ecosystem): progressive typing lets you incrementally add typing to an existing Python codebase. So you can have at least some of the benefits of typing for new or updated code without needing to re-write in a new language.

Gradual typing is the worse of both worlds. You get the complexity and slower development times of using statically typed languages along with the bad performance of using dynamically typed languages.

Have you actually used this in a real codebase? Because it is the opposite of my experience in gradually adding types to a large python codebase. There's no extra complexity or slower development. It's not like you need to suddenly move to a different coding paradigm with FactoryBeanFactoryBeans... You just keep writing python like you did, but add types here and there to help clarify things and make your LSP (like ty) work better.

If anything, it speeds up development. Plus it helps give more confidence in the correctness of your code.

Re: T-Ruby is Ruby with syntax for types

#144

Post by makeitdouble »

drdaeman wrote: post #75
torben-friis wrote: post #3

Honest question: I like typescript and I think it makes sense:, the web makes you married to JavaScript, so it’s the reasonable path forward if you want types in that context. But what is the point of the recent wave of types for python, Ruby, and similar languages? If it’s type safety you want there, there’s a bajillion other languages you can use right?

If you don’t specify types explicitly they have to still exist somewhere: in someone’s head (in oral tradition of “Ah, yea, those IDs are UUIDs, but not those - those are integers”), or denoted through some customary syntax (be it something more formal like Hungarian notation, or less so - suggestive suffixes, comments, supplementary documents). They still exist at runtime, and people who work on the codebase need to…

> people who work on the codebase need to somehow know what to expect.

IME this is the exception more than the rule. There will be a ton of manipulations where I don't really care what the types are, just whether I can do the specific thing I want on them.

For instance you receive the data from an API and want to pass it to the appropriate validator. The type definitions are noise, and checking them is the validator's job.

Now it's nice to be able to work with stricter types where needed, ideally I'd want to switch that on and off, instead of being stuck with them everywhere.

Re: T-Ruby is Ruby with syntax for types

#145

Post by ReflectedImage »

blandflakes wrote: post #142
ReflectedImage wrote: post #141

Earlier quoted context omitted.

And that's the problem, if you want your code to actually work you do need to write those unit tests. A program not crashing doesn't mean it does the right thing. With experience you will learn to either write unit tests or spend the same amount of time doing manual testing. Once you start doing that then the unit tests just replace the static typing and you start shipping better code to your customers.

This always feels like a bad faith argument. Nobody says that with static types, you don't need any unit tests. And your suggestion that people who like static types "don't know how to write unit tests" is further bad faith. Perhaps it's dynamic typing programmers who don't know how to write sound programs? Except I'm not making that claim, because I'm giving you all some benefit of the doubt, a degree of respect you…

Static typing doesn't have much value if there are proper unit tests. So it's fairly obvious that if people think there is value in static typing then they are shipping broken code to their customers.

It's called ratting yourself out.

Re: T-Ruby is Ruby with syntax for types

#146

Post by blandflakes »

ReflectedImage wrote: post #145
blandflakes wrote: post #142

Earlier quoted context omitted.

This always feels like a bad faith argument. Nobody says that with static types, you don't need any unit tests. And your suggestion that people who like static types "don't know how to write unit tests" is further bad faith. Perhaps it's dynamic typing programmers who don't know how to write sound programs? Except I'm not making that claim, because I'm giving you all some benefit of the doubt, a degree of respect you…

Static typing doesn't have much value if there are proper unit tests. So it's fairly obvious that if people think there is value in static typing then they are shipping broken code to their customers. It's called ratting yourself out.

> Static typing doesn't have much value if there are proper unit tests

Wasteful unit tests that assert your types are right don't have much value if there is a proper type system.

> It's called ratting yourself out.

Quit being childish.

Re: T-Ruby is Ruby with syntax for types

#147

Post by ReflectedImage »

blandflakes wrote: post #146
ReflectedImage wrote: post #145

Earlier quoted context omitted.

Static typing doesn't have much value if there are proper unit tests. So it's fairly obvious that if people think there is value in static typing then they are shipping broken code to their customers. It's called ratting yourself out.

> Static typing doesn't have much value if there are proper unit tests Wasteful unit tests that assert your types are right don't have much value if there is a proper type system. > It's called ratting yourself out. Quit being childish.

"Wasteful unit tests that assert your types are right"

You don't test whether the types are right, you test if your code actually does the right thing. That's what's important to your customers.

The types getting tested is incidental.

Re: T-Ruby is Ruby with syntax for types

#148

Post by ReflectedImage »

jaapz wrote: post #143
ReflectedImage wrote: post #85

Earlier quoted context omitted.

Gradual typing is the worse of both worlds. You get the complexity and slower development times of using statically typed languages along with the bad performance of using dynamically typed languages.

Have you actually used this in a real codebase? Because it is the opposite of my experience in gradually adding types to a large python codebase. There's no extra complexity or slower development. It's not like you need to suddenly move to a different coding paradigm with FactoryBeanFactoryBeans... You just keep writing python like you did, but add types here and there to help clarify things and make your LSP (like t…

Yep, the software development slows down to crawl. Yes, you can still code at the same speed as you were coding in a language like Java or C# but that is considerably slower then what's possible in languages like Ruby and Python.

To give you a roughly idea, you should always expect a 3x slow down when using static typing.

An recent example is Turborepo that went from basic types in Go to proper static typing in Rust. Just adding in the proper typing caused the codebase to grow from 20,000 lines to 80,000 lines and from 3 developer months to 14 developer months.

The stronger your typing system, the slower you will develop code. Whether you realise it or not.

Re: T-Ruby is Ruby with syntax for types

#149

Post by ReflectedImage »

rurban wrote: post #114
ReflectedImage wrote: post #85

Earlier quoted context omitted.

Gradual typing is the worse of both worlds. You get the complexity and slower development times of using statically typed languages along with the bad performance of using dynamically typed languages.

Nonsense. You get the simplification and faster development times of knowing some variable types statically, plus the performance improvements for the compiler which can move the type checks from runtime to compile-time. Plus all the new optimization possibilities. Common Lisp showed you the way. But almost none looked at it. Only PHP did.

Absolutely not. Duck type based development results in working code out of the door 3x faster than static type based development. It always has since ancient times.

If performance wasn't an issue, then the static type based developers would all be fired. Either directly or by the businesses who relied on them getting driven into bankruptcy by their competitors. You would still get some niche jobs in it where they like to do formal verification of the code.

Your problem is just that your development skills from static type based development don't transfer to duck type based development. Different style of codebases needs to be handed completely differently.

Re: T-Ruby is Ruby with syntax for types

#150

Post by ReflectedImage »

rurban wrote: post #131
dajonker wrote: post #126

Earlier quoted context omitted.

At least CPython and CRuby (MRI), the most common implementations of each language, ignore all type hints and they are not able to use them for anything during compile or runtime. So the performance argument is complete nonsense for at least these two languages. Both Python and Ruby (the languages themselves) only specify the type hint syntax , but neither specifies anything about checking the actual types. That exer…

Because the anti-types crew showed up and sabotaged it. Similar with perl and lua. But languages with stronger and more intelligent leadership showed what's possible. You cannot implement all the compiler optimizations for const and types in extensions. You need to fork it.

The problem is there are a lot of developers who have only coded with static typing and have no idea about the terrible drawbacks of static typing.

They don't understand what static typing does to code verbosity and development times.

Take Turborepo going from Go's typing light system (designed to emulate duck typing) to Rust's heavy typing system (true static typing). Originally the code was 20,000 lines and was coded by 1 developer in 3 months. When moved into the typing style you like so much, the same code is now 80,000 lines and was coded by a team of developers in 14 months.

Post reply on HN