Consider Static Typing in Ruby • Hacker News Board

Re: Consider Static Typing in Ruby

#31

Post by rimantas » Mon, May 04, 2015, 7:37 AM UTC

jawngee wrote: post #30

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…

I know this is off topic, but I'm genuinely curious why people refer to themselves in such isolated bins like Rubyist and Pythonistas? Why do you refer to yourself in that way, instead of, say, a developer or programmer or software engineer?

Because it clearly states what the current area of work and experience is?

Re: Consider Static Typing in Ruby

#32

Post by takeoutweight » Mon, May 04, 2015, 7:49 AM UTC

Too wrote: post #28

I find it interesting that almost all dynamic programming languages eventually get some kind of static type system or type annotations, but very rarely the other way around, C# is the only one i can think of, although i've never seen anyone actually use the dynamic keyword there. PHP, Perl, Python, JS(via typescript or other preprocessors) all got it after years of arguing.

Haskell has dynamic types, too https://hackage.haskell.org/package/base-4.8.0.0/docs/Data-D...

Re: Consider Static Typing in Ruby

#33

Post by spion » Mon, May 04, 2015, 7:57 AM UTC

pmontra wrote: post #27

15155 wrote: post #11

Earlier quoted context omitted.

> 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."

I know, but I think it's difficult to make static type inference when you can build both the class and the method dynamically. Examples: object.send(expression) or Class.send(expression) are hard enough, building the value of Class at runtime adds extra complication, adding that method only to that object is further along the way of complication. And I'm probably only scratching the surface. So, either Ruby 3 is so d…

If its a gradual type system, you can choose whether to use it or not in a specific situation. Because of that it simply becomes just another tool in your toolbox, unlike in languages such as Java where its more of a anchor and chain

Re: Consider Static Typing in Ruby

#34

Post by [deleted] » Mon, May 04, 2015, 8:38 AM UTC

rimantas wrote: post #31

jawngee wrote: post #30

Earlier quoted context omitted.

I know this is off topic, but I'm genuinely curious why people refer to themselves in such isolated bins like Rubyist and Pythonistas? Why do you refer to yourself in that way, instead of, say, a developer or programmer or software engineer?

Because it clearly states what the current area of work and experience is?

[deleted]

Re: Consider Static Typing in Ruby

#35

Post by skybrian » Mon, May 04, 2015, 5:17 PM UTC

EugeneOZ wrote: post #29

skybrian wrote: post #24

Earlier quoted context omitted.

Dart has static analysis as well. There is a server that reports errors and warnings in an IDE, and you can also run it as a batch job using the dartanalyzer command if you like. You can run dartanalyzer in a test, parse the output, and treat warnings as errors, and some people do. The question is whether the existing static analysis is enough. Some people think it isn't, and the Dart team has a couple of projects to…

I have quite opposite information from one of Dart authors, as response to my bug report: https://code.google.com/p/dart/issues/detail?id=23148 Sorry for offtopic, ruby devs :)

It's confusing, but that's not a contradiction. The Dart spec defines the official set of errors and warnings and that particular snippet of code is within the spec, even though it's broken. The dartanalyzer tool follows the spec.

But there are other possibilities. The dartanalyzer has hints which aren't part of the spec. Other tools (like the linter and DDC) can and will check for more problems.

You could try refiling that as a feature request that the analyzer should provide a hint here, or perhaps try out DDC.

Re: Consider Static Typing in Ruby

#36

Post by Psyonic » Tue, May 05, 2015, 2:11 AM UTC

Too wrote: post #28

I find it interesting that almost all dynamic programming languages eventually get some kind of static type system or type annotations, but very rarely the other way around, C# is the only one i can think of, although i've never seen anyone actually use the dynamic keyword there. PHP, Perl, Python, JS(via typescript or other preprocessors) all got it after years of arguing.

Scala has a Dynamic type that is used occasionally.

http://www.scala-lang.org/api/current/scala/Dynamic.html

Re: Consider Static Typing in Ruby

#37

Post by lamontcg » Fri, May 08, 2015, 7:53 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…

I would like to see optional static type checking. I don't even really care that much if the error is caught at runtime or not. I'd just like to be able to assert that certain functions always took or returned certain types, or that certain variables were always of a certain type.

I'm already winding up documenting these interfaces in YARD and testing this in spec tests. It'd be nice to just assert it in code as well.

I still like duck types to be able to write methods that take random objects and #to_s them or whatever without having to worry about declaring that they implement some Stringable interface -- but the more common case I'm running into is where parameters, variables and return types could really use strong typing to avoid errors.