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

101–110 of 216 posts

Re: Types will be part of Ruby 3 stdlib source

#101

Post by rubyfan »

geraldbauer wrote: post #97
cutler wrote: post #83

Instead of: sig {params(name: String).returns(Integer)} ... why not simply: sig {name: String, returns: Integer}

Instead of: sig {params(name: String).returns(Integer)} ... why not simply: sig [String]=>[Integer] Yes, that's just ruby - see https://github.com/s6ruby/ruby-to-michelson/blob/master/cont... for example for live running code (in secure ruby) :-)

Ruby has named parameters right? In theory signature needs parameter name and wouldn’t be sufficient for all cases to with a simple String in Integer out I think.

Re: Types will be part of Ruby 3 stdlib source

#102

Post by cutler »

didibus wrote: post #10

It's an interesting turn of event that Ruby, Python and JavaScript are all getting types. Meanwhile, I've gotten myself more and more into Clojure. Which now that other dynamic languages seems to move closer to types, seems to be in a niche in that Clojure is moving further away from types. It'll be interesting to see what happens at both extremes and in the happy middles.

>Clojure is moving further away from types

What about clojure.spec?

Re: Types will be part of Ruby 3 stdlib source

#103

Post by cutler »

carmate383 wrote: post #69

Ah yes, a last ditch effort to claw back an inferior language into the popularity again. This is nothing more than a knee-jerk reaction to loss of market-share to TypeScript / Python / Name your other buzz-language here (R)

Ruby inferior to Javascript and Python? What are you smoking? Python's BDFL begrudgingly added lambda to Python but amputated it to single-line expressions because he didn't want to "encourage" functional programming. By contrast Ruby is an artistically-curated blend of the best of Smalltalk, Lisp and Perl fully embracing functional programming. No contest.

Re: Types will be part of Ruby 3 stdlib source

#104

Post by adimitrov »

cutler wrote: post #99

The biggest problem for me with gradual typing is code clutter. My favourite languages are Clojure and Ruby precisely because they reduce code clutter. What I would prefer, if we are to have types, is for the signatures to go in a companion file. I've never understood why types have to be inlined. A good IDE can easily provide the signature in a mouseover or something similar.

The way to reduce clutter in strongly, statically typed languages is to use strong, robust type inference.

For example, Java is pretty terrible at type inference (still) and you have to annotate types almost everywhere (Java 8 had a very tepid improvement on that front.)

But languages like Haskell and Rust are very good at type inference, and you almost never actually need to specify the types.

It's still good Haskell style to always annotate the type sigs of top-level functions. Why? Because they serve as more than just hints to the compiler: they are part (and a very important part!) of the documentation. That is why they're in-line. Because A function like

    zipWith:: [a] -> [b] -> (a -> b -> c) -> [c]
tells you what it does in its type signature.

Re: Types will be part of Ruby 3 stdlib source

#105

Post by imhoguy »

ricardobeat wrote: post #76

I don't use Ruby day-to-day other than a few small tools, but why not focus efforts on evolving Crystal [1] to make it more suited for rapid web development? It already has a powerful type system and incredible performance, and should be an easy transition for rubyists. [1] https://crystal-lang.org/

Because it is about Rails and tons of useful gems which would need to be ported 1:1 to Crystal, plus keep compatibility with CRuby for some time. Too much effort which nobody would pay for.

Re: Types will be part of Ruby 3 stdlib source

#106

Post by mratzloff »

darkdimius wrote: post #17

We're collaborating with @yukihiro_matz, @mametter, @soutaro and Jeff Forster to make sure that types are not disruptive to Ruby. Thus, types are optional. The intention is to deliver value for unmodified Ruby programs. Hear more from Matz at https://youtu.be/cmOt9HhszCI?t=2148

As long as types can be required to be explicit where ambiguous (e.g., TypeScript) in the file itself (via a magic comment or similar), I'm all for it. I am happy to declare types for external calls if I need to.

I have said for awhile that "Ruby with types" would be my favorite language to work in. I recently returned to Ruby briefly and had to integrate with a poorly-documented API. I spent more time digging through third-party code trying to figure out what certain parameters were supposed to be than writing the program itself.

Re: Types will be part of Ruby 3 stdlib source

#107

Post by cutler »

adimitrov wrote: post #104
cutler wrote: post #99

The biggest problem for me with gradual typing is code clutter. My favourite languages are Clojure and Ruby precisely because they reduce code clutter. What I would prefer, if we are to have types, is for the signatures to go in a companion file. I've never understood why types have to be inlined. A good IDE can easily provide the signature in a mouseover or something similar.

The way to reduce clutter in strongly, statically typed languages is to use strong, robust type inference. For example, Java is pretty terrible at type inference (still) and you have to annotate types almost everywhere (Java 8 had a very tepid improvement on that front.) But languages like Haskell and Rust are very good at type inference, and you almost never actually need to specify the types. It's still good Haskel…

There's nothing lost by putting the sig in a companion file and leaving it to your editor/IDE to provide a popup.

Java 10 and 11 introduced real type inference, at least for local variables and function parameters.

Re: Types will be part of Ruby 3 stdlib source

#108

Post by crnkofe »

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, so I feel that all the feature stealing in the end will be detrimental to all but the best supported omni language.

I guess some companies started fast with Ruby/Python and similar and instead of rewriting to static/typed languages they pushed forward features that would allow them to just continue where they left off at the expense of having a more concise problem oriented programming language that's good for solving specific problems.

Re: Types will be part of Ruby 3 stdlib source

#109

Post by jmkni »

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.

You could argue that something that has been around for decades is unstoppable :)

Re: Types will be part of Ruby 3 stdlib source

#110

Post by cutler »

mnarayan01 wrote: post #100
bhuga wrote: post #92

Earlier quoted context omitted.

Ruby itself has zero changes from sorbet, so all sorbet syntax has to be valid Ruby. `sig` is implemented as a library. In this case, your example is not valid syntax, which violates this rule. Not that I personally could tell you why the parser makes a distinction here, but it's at least part of the reason :) irb(main):010:0> foo {a: "b"} SyntaxError: (irb):10: syntax error, unexpected ':', expecting '}' foo {a: "b"…

The parser thinks that's a block not a hash.

Right, so why not implement the sig as a block and keep the syntax concise - the Ruby Way.
Post reply on HN