Consider Static Typing in Ruby • Hacker News Board

Re: Consider Static Typing in Ruby

#11

Post by 15155 » Sun, May 03, 2015, 9:46 PM UTC

pmontra wrote: post #6

As a 10 years Rubyist I'm conflicted about this. First, if I wanted to use a static typed language I have plenty of them to chose from, when I started using Ruby and more right now. One of the reasons I'm using Ruby is that it works well enough without having to tell types to the interpreter (which is already pretty strict about them because - example - it doesn't automatically cast strings and numbers into each othe…

> but if the price to pay is to start declaring types like I did in C and Java, no thanks

Modern type systems have such good inference that you won't need to declare types "everwhere."

Re: Consider Static Typing in Ruby

#12

Post by orodley » Sun, May 03, 2015, 9:58 PM UTC

rurban wrote: post #7

OP missed some more development on recent gradual typing efforts in dynamic languages. I collected those links below when implementing gradual typing for perl5. perl5 is more lucky than ruby, since perl5 supports syntax for types in lexical variable declarations for decades already, and more via attributes. http://www.typescriptlang.org/Content/TypeScript%20Language%... (microsoft's javascript with types) https://cod…

There's a great collection of gradual typing papers here:

https://github.com/samth/gradual-typing-bib

Re: Consider Static Typing in Ruby

#13

Post by ufo » Sun, May 03, 2015, 10:18 PM UTC

Weird to see references to soft typing (something quite old that didn't quite work out) and no references to the much more recent Diamondback Ruby: http://www.cs.umd.edu/projects/PL/druby/ It was a research project from the fine folks at the university of Maryland but it lost steam because Ruby is so dynamic that its very very hard to write static analysis tools for it.

http://www.cs.purdue.edu/homes/jv/events/PBD13/slides/JeffFo...

There are some misconceptions about the the Soft Typing approach though that I think I should clear out a bit:

* What a soft typing system does is use type inference techniques to try to figure out what locations in the program might raise dynamic type errors (accessing inexistent methods, etc).

* Soft typing systems do not check the types of function parameters and return values (since just passing a value around never cause the itnerpreter to throw an error). Some non-soft type systems might check though, adding runtime contract checks if needed.

* Soft typing can guarantee safety if you write your program in a way where the type checker manages to infer a static type for everything.

* On the other hand, writing things in a way that satisfies the type inferencer can be very hard. And to acomodate the flexibility of dynamic languages the type system might evolve into something quite complex. This is an even larger issue for Ruby, which is highly dynamic and has no formal spec.

* The 1991 soft typing paper focuses a lot on speed because back then dynamic type checks were a big reason for the slowness of dynamic language implementations. Nowadays we have tracing JITs (which "inline" away all the type checks, method dispatches, and so on) so there is less of a need to use type inference to speed things up.

Re: Consider Static Typing in Ruby

#14

Post by ddebernardy » Sun, May 03, 2015, 10:33 PM UTC

I wish Ruby would focus in immutability before this.

As things stand, the language is built in a way that you've no guarantee that any object you hold as variable won't change without you knowing. The net result is you either ignoring the problem entirely (until you runinto a bizarre bug introduced by a new library) or (more rarely) you re-inventing the wheel by being extremely verbose in all accessors where it matter.

Re: Consider Static Typing in Ruby

#15

Post by tosh » Sun, May 03, 2015, 10:34 PM UTC

rurban wrote: post #7

OP missed some more development on recent gradual typing efforts in dynamic languages. I collected those links below when implementing gradual typing for perl5. perl5 is more lucky than ruby, since perl5 supports syntax for types in lexical variable declarations for decades already, and more via attributes. http://www.typescriptlang.org/Content/TypeScript%20Language%... (microsoft's javascript with types) https://cod…

On Dart's type system:

https://www.dartlang.org/articles/optional-types/

https://www.dartlang.org/articles/why-dart-types/

Re: Consider Static Typing in Ruby

#16

Post by wpietri » Sun, May 03, 2015, 11:40 PM UTC

That's really interesting to me.

One of the things I like about Ruby its pliability. It's what I'll turn to when I'm just hacking something together, exploring a problem/solution space. But that very pliability becomes an issue when I'm trying to write something that's reliable. There, I'll often use something like Scala, which yells at me when it detects fuzzy thinking on my part.

My general approach here is to throw a lot of code out when I try to shift from exploration mode to high-reliability mode. I'd be very excited to see a language that let me make that transition gradually.

Re: Consider Static Typing in Ruby

#17

Post by lukeschlather » Sun, May 03, 2015, 11:53 PM UTC

grandalf wrote: post #9

pmontra wrote: post #6

As a 10 years Rubyist I'm conflicted about this. First, if I wanted to use a static typed language I have plenty of them to chose from, when I started using Ruby and more right now. One of the reasons I'm using Ruby is that it works well enough without having to tell types to the interpreter (which is already pretty strict about them because - example - it doesn't automatically cast strings and numbers into each othe…

The bad things about Ruby are mostly Ruby cultural norms, like willy nilly metaprogramming often done by unskilled people, published as a gem, and used by many others, some of whom create useful gems. Static typing would be a benefit. I think Matz realizes that with the rise of Javascript transpilers Ruby is going to have to fight hard to remain relevant. Give Swift a few more months and there is already a pretty sol…

Ruby obviously competes with Node, but is there any chance of Ruby and Swift competing directly?

Go or would probably be better examples.

Re: Consider Static Typing in Ruby

#18

Post by simplify » Mon, May 04, 2015, 12:11 AM UTC

pmontra wrote: post #6

As a 10 years Rubyist I'm conflicted about this. First, if I wanted to use a static typed language I have plenty of them to chose from, when I started using Ruby and more right now. One of the reasons I'm using Ruby is that it works well enough without having to tell types to the interpreter (which is already pretty strict about them because - example - it doesn't automatically cast strings and numbers into each othe…

From the article's introduction:

> That’s right: static typing! A lot of people were worried when they heard that, which is understandable; in the Ruby community we don’t get much exposure to static type systems, and they immediately make us think of languages like C and Java.

The author then proceeds to explain why static typing in ruby would be much better than "Java-flavoured-Ruby", and how it would "go beyond the features of the static type systems you’ve used in the past".

Re: Consider Static Typing in Ruby

#19

Post by EugeneOZ » Mon, May 04, 2015, 12:12 AM UTC

tosh wrote: post #15

rurban wrote: post #7

OP missed some more development on recent gradual typing efforts in dynamic languages. I collected those links below when implementing gradual typing for perl5. perl5 is more lucky than ruby, since perl5 supports syntax for types in lexical variable declarations for decades already, and more via attributes. http://www.typescriptlang.org/Content/TypeScript%20Language%... (microsoft's javascript with types) https://cod…

On Dart's type system: https://www.dartlang.org/articles/optional-types/ https://www.dartlang.org/articles/why-dart-types/

Dart has dynamic typing. Code will not fail on compilation step and in runtime, if type mismatch expectations. You can try to get warnings (at least warnings) with "checked" mode, but it works only with primitive cases, not with closures (no static analysis), so it's mostly useless and better to forget about it. It's only hinting for autocompletion in IDE (although autocompletion is a big thing). Even PHP 5 has strongest typing.

Re: Consider Static Typing in Ruby

#20

Post by ryan-allen » Mon, May 04, 2015, 12:59 AM UTC

learc83 wrote: post #4

So much of what makes Ruby Ruby is based on dynamic types. Is this going to be optional? I've been moving away from Ruby a bit over the years specifically because I want static typing, but I can't imagine that the majority of Ruby devs feel this way. Also isn't Crystal basically a compiled, statically typed version of Ruby?

I've been doing C# after years of Ruby, and every time I find myself needing or wanting to do 'duck typing', what falls out is an interface and then using generics.

After years of Ruby, this is so handy because you end up formalising 'on the side' the commonalities of your modelling.

I had no idea what generics were for, and I thought interfaces were mostly for over-abstraction but lo, I was wrong. They are very handy. They are typed duck typing!

Combine that with type inference, and you've limited all the ugly 'everything is typed' code, and what you get is code that looks a lot like Javascript.

And if you don't like, that, there's F#, that as an ex-Ruby guy, looks rather compelling, but with all the benefits of C# as well.

I didn't realise until I was out of the echo chamber that Ruby is only a small spot on the radar compared to the rest of the software world.