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

Types will be part of Ruby 3 stdlib source

twitter.com

Post reply on HN
Print view View original

121–130 of 216 posts

Re: Types will be part of Ruby 3 stdlib source

#121

Post by creatio »

Shish2k wrote: post #82
tomc1985 wrote: post #26

Earlier quoted context omitted.

So, what, everyone standardizes around an IDE then? You really think that's gonna unite the vim and emacs camps? I'm personally tired of staring at variables trying to figure out what they're supposed to be, then having to dive into source to see how its used. C/C++/C# solved that problem, why are we still dealing with it?

C had some typing, but I'm not going to call it "solved" until "numberOfHats = distanceInPixels + weightInKg" is considered a compile-time error due to the three "int" values being incompatible; but "numberOfHats = aliceHatCount + bobHatCount" is acceptable. How does nobody(?) support this yet? Python supports some parts: you can subclass int, and you get all of the int methods like addition and subtraction for free,…

Do they, the language is called F#.

Re: Types will be part of Ruby 3 stdlib source

#122

Post by snrji »

Guthur wrote: post #86
snrji wrote: post #62

The trend of adding type annotations to dynamically typed languages is now unstoppable. I wonder if some more exotic features (eg. side effects handling, monads or dependent types) will ever become mainstream in the feature.

It's hardly unstoppable its been there for literally decades. Common lisp had it for a very long time for example and has a few compiler implementations that are really quite sophisticated. The problem is that most popular dynamic languages are really quite terrible. They have atrocious runtime environments and usually quite limiting language semantics.

It was not mainstream back then.

I agree that most popular dynamic are quite terrible. But, honestly, I think the real problem is not the particular implementations, but the whole idea of dynamic typing. At first it did make sense, but now that compiler writers have figured out "cheap" and general type inference, I don't see the point anymore.

However, I use Python on a daily basis because I have no decent alternative for the libraries I use.

Re: Types will be part of Ruby 3 stdlib source

#123

Post by nevertoolate »

joelbluminator wrote: post #74
trixie_ wrote: post #50

Earlier quoted context omitted.

Generally no one uses dynamic typing for the abilities it gives you. Do you declare string variables to later assign them to numbers? Do you dynamically add new functions and properties to objects? Do you ever really need the flexibility that dynamic typing is giving you? If not then why are you using a dynamically typed language? If you're not using it's abilities then it doesn't sound like the right tool for the jo…

I think most rubyists do benefit from dynamic types. How easy would it be to build rspec and Rails in java? The whole dependency injection thing in Spring is in part a by product of types making it way harder to test things. That's just one example.

Can you give a concrete code example you are talking about? What is your problem with DI with spring? Why do you feel it is a problem with static type checker?

Re: Types will be part of Ruby 3 stdlib source

#124

Post by aasasd »

localhostdotdev wrote: post #118
aasasd wrote: post #54

Earlier quoted context omitted.

As a user of Homebrew, I just wonder if Ruby's ever going to have performance.

homebrew's performance is mostly network (git / http / https) and compilation times when needed. also for some reason homebrew really likes to updates its index all the time (I think it got tamed in the newest version), but setting HOMEBREW_NO_AUTO_UPDATE to 1 helps a lot.

With HOMEBREW_NO_AUTO_UPDATE and HOMEBREW_NO_GITHUB_API, it still gobbles up a core for a full minute to find a substring in a list of strings. Even if it looks through directories for this, I can't imagine how this task would perform so badly. It's not system cpu time primarily.

Re: Types will be part of Ruby 3 stdlib source

#125

Post by steveklabnik »

Shish2k wrote: post #82
tomc1985 wrote: post #26

Earlier quoted context omitted.

So, what, everyone standardizes around an IDE then? You really think that's gonna unite the vim and emacs camps? I'm personally tired of staring at variables trying to figure out what they're supposed to be, then having to dive into source to see how its used. C/C++/C# solved that problem, why are we still dealing with it?

C had some typing, but I'm not going to call it "solved" until "numberOfHats = distanceInPixels + weightInKg" is considered a compile-time error due to the three "int" values being incompatible; but "numberOfHats = aliceHatCount + bobHatCount" is acceptable. How does nobody(?) support this yet? Python supports some parts: you can subclass int, and you get all of the int methods like addition and subtraction for free,…

(They won’t be subclasses in Rust, Rust doesn’t have classes nor inheritance. They’d be “newtypes”, a struct with one member.)

Re: Types will be part of Ruby 3 stdlib source

#126

Post by pjmlp »

readittwice wrote: post #96
z1mm32m4n wrote: post #55

Earlier quoted context omitted.

Who's to say we couldn't use the types to make the runtime faster in the future? One of the reasons why Sorbet does both runtime checking[1] more than just static checking is so that we can know that signatures are accurate, even when a typed method is called from untyped code. If the signatures are accurate, a future project could take advantage of method's signatures to make decisions about how the code should actu…

Well I am skeptical about performance improvements due to type annotations as well. Other languages have similar different systems and didn't get faster. Dart had gradual types but didn't enforce them at runtime because of performance. The PyPy devs don't believe that type annotations help them for performance ( http://doc.pypy.org/en/latest/faq.html#would-type-annotation... ). Also there is no JS engine that uses Ty…

Dart has long changed.

Re: Types will be part of Ruby 3 stdlib source

#127

Post by black-alert »

DCoder wrote: post #98
black-alert wrote: post #58

Earlier quoted context omitted.

I come from Assembly and C, now working in Javascript. One of the reasons I made the move to JS is dynamic typing, getting rid of that administrative pain and now being able to create stuff much faster. Even in large JS apps I hardly ever have type related bugs at all, and when I have one I fix it mostly within minutes, don't need an entirely different language and ecosystem for that. Now the JS fanboys discovered an…

I started using TypeScript back when it was 0.8, before it even had generics. Does that make me a fanboy? I have a project with about 45k SLOC of TypeScript (using Knockout.js for presentation). There is really no way I would maintain that same project without types. > For my work I look at horrible code bases, perfectly typed and strictly formatted by tslint. There is no language that can stop people from producing…

> There is really no way I would maintain that same project without types.

That's bold. Do you think no developer would be able to manage it without TS? In that case you must be a fanboy!

And honestly, are you not using 'any'? And do you think your app cannot crash because of a type error at runtime? And do you trust all the third party libraries you are using that they always provide you with consistent types, also during runtime? I ask this because most TS proponents live in some kind of dream.

Re: Types will be part of Ruby 3 stdlib source

#128

Post by pjmlp »

crnkofe wrote: post #108
cocochanel wrote: post #15

Why is everything moving to types?

It's a sad state of affairs. Every programming language is just copying the 'next cool' feature from another language. Duck typing, deconstruction, functional stream-like constructs you name it. I guess this ends when every language features is copied and we get X omni languages with Y omni SDK's all having same features with different syntax. The thing is that I only really need 1 omni language, not a dozen of them,…

Not really, what many seem to keep missing is that programming languages are products like anything else.

One buys into eco-systems, not language features bullet point list.

And there isn't something like an universal eco-system for any kind of business case, hence multiple languages.

Re: Types will be part of Ruby 3 stdlib source

#129

Post by pjmlp »

tomc1985 wrote: post #26
jaequery wrote: post #22

Earlier quoted context omitted.

I don’t know but I hate it. Not sure if I’m in the minority but it sure feels like it. In an ideal world. I feel that types are something that should be dealt with at the IDE level. In fact, there so many things that can be done at that level, but no one has really been brave enough to do so I suppose.

So, what, everyone standardizes around an IDE then? You really think that's gonna unite the vim and emacs camps? I'm personally tired of staring at variables trying to figure out what they're supposed to be, then having to dive into source to see how its used. C/C++/C# solved that problem, why are we still dealing with it?

Algol solved the problem.

Re: Types will be part of Ruby 3 stdlib source

#130

Post by pjmlp »

mruts wrote: post #120
black-alert wrote: post #58

Earlier quoted context omitted.

I come from Assembly and C, now working in Javascript. One of the reasons I made the move to JS is dynamic typing, getting rid of that administrative pain and now being able to create stuff much faster. Even in large JS apps I hardly ever have type related bugs at all, and when I have one I fix it mostly within minutes, don't need an entirely different language and ecosystem for that. Now the JS fanboys discovered an…

C/C++ doesn't really have much static typing to speak of. I don't think you are realizing the power of real statically type languages, such as Haskell, OCaml, or Scala.

Not much experience with C++ I suppose.
Post reply on HN