Live data from Hacker News

RBS, Ruby’s new type signature language

developer.squareup.com

331–340 of 340 posts

Re: RBS, Ruby’s new type signature language

#331

Earlier quoted context omitted.

Strong typing generally does not mean much and everyone seems to be using a different definition. Would you consider Javascript weakly typed? What about Python?

I'd consider JavaScript to be more toward the weak typing end of things, because it does lots of automatic conversions with surprising results. (see, for example, Gary Bernhardt's "Wat?" lightning talk.) I don't think I'd consider it as weak as C, which has things like unions and pointers that let you just sort of fall out of the type system entirely. I'd consider Python to be more strongly typed than JavaScript. It…

What about Haskell then?

    {-# LANGUAGE MultiParamTypeClasses, TypeSynonymInstances, FlexibleInstances #-}

    import Prelude (String, (++), show, Int, (==))
    import qualified Prelude

    class Add x y where
      (+) :: x -> y -> y
    
    instance Add Int String where
      (+) x y = show x ++ y
    
    instance Add Int Int where
      (+) x y = x Prelude.+ y
    
    instance Add String String where
      (+) x y = x ++ y
    
    a = ((1 :: Int) + (1 :: Int)) == 2
    b = ((1 :: Int) + "aa") == "1aa"
    c = ("a" + "aa") == "aaa"

Re: RBS, Ruby’s new type signature language

#332
post #144

Earlier quoted context omitted.

I'm curious what you mean by "data-level programming."

Leaving the data in basic data formats. For example, JSON describes a logical structure of nested lists and dictionaries. If you were doing data-level programming, you would just map the JSON into actual nested lists of dictionaries and get on about your business. The alternative, which is more common in static languages like Java, is to transform it all into some set of domain model objects, and probably validate it…

What prevents you from just using maps and lists in Java? Nobody forces you to deserialise JSON into domain model objects.

Re: RBS, Ruby’s new type signature language

#333

Earlier quoted context omitted.

Yeah, it is. I'm having a really hard time understanding this "I need types forced down my throat" and "I like typing 3x as much as I would otherwise need to" and "yes, I want half my screen obscured by the types of everything I'm doing, not the actual code" and the "adding types now means bugs are impossible" mass cult hysteria that's running so rampant. Typing very occasionally prevents bugs that are generally easy…

A-fucking-men. In the course of my job I write Swift for iOS and Ruby for server APIs and our web-based UIs. Type issues are about 0% of my Ruby bugs, but dealing with all the damn type requirements in Swift regularly takes dozens of minutes to track down when some weird esoteric error message pops up. And God help you if you try to use generics. If you want strong typing, then good for you. Just pick a language that…

Don't you see the irony in your own comment? If you never create type related bugs in ruby then you shouldn't encounter them in a typed language either because you are infallible. The truth is probably that you see all the type errors at runtime instead and don't see them as such.

Re: RBS, Ruby’s new type signature language

#334

Earlier quoted context omitted.

Because when you see the benefit of type annotations (I’m not saying that’s objective, just if you do go that route) you want to add type information to as much as possible. Leaving them off because you want to is one thing. Not being able to is an unnecessary limitation.

The point is that the type of a local variable can almost always be inferred based on what it’s assigned to.

While that’s true, that’s not what I’m talking about. I’m talking about the communicative benefit of type annotations. If you get the benefit from seeing the types, you don’t want them to be inferred. You use them as a reading tool.

Re: RBS, Ruby’s new type signature language

#335

Earlier quoted context omitted.

Have you ever worked with a language that has header files (C/C++) or a language that can use them optionally (Ocaml)? In practice, keeping the files in sync isn’t difficult. In fact, it ends up being better (for me) in terms of readability, because I can look up the type definitions in one place, store them as context, and then read code that isn’t littered with type annotations. Type annotations add quite a bit of…

Not to anecdote too hard, but the practice of doing type signatures out-of-line that you are describing is my absolute least favorite part of OCaml, which is otherwise a very lovely language. As for C++, it has enough other stuff going on that I probably can't say the header files are my least favorite feature, but they certainly don't make life easy. I think it makes sense to challenge that decision from an ergonomi…

I very much like Ocaml signature files. Jane street recommends using them, as an example. There’s no other way to communicate the high level contract of a module. With type signatures that are in line with the code, the high level contract gets lost.

Re: RBS, Ruby’s new type signature language

#336

Earlier quoted context omitted.

I wouldn’t call it “embarrassing.” What is the actual benefit of having inline type annotations? What is the actual downside of having them in a separate file?

The benefit is being able to see what type a variable is without having to open a separate file. Having an option to also have them in a separate file (ala TypeScript) is perfectly fine

Type info on hover in your editor gives you that.

Re: RBS, Ruby’s new type signature language

#337

Earlier quoted context omitted.

That is a fallacy in language design. Humans do not have an algorithmic shortcut for parsing; if it's hard for the machine, it's hard for the human. For short chunks of program text, we can probably rely on our natural language abilities to some extent. Those capabilities allow us to deal with transformational syntax, and ambiguities. So that is to say, we have a kind of general parsing algorithm that is actually way…

The idea that human and machine language parsing have any underlying similarity is amusing but pretty absurd. It depends upon the idea that we're somehow doing the "same essential thing", which we are not. Humans do not translate text to serial machine instructions for a processor. They do many things with text, but that is (very seldom) one of them. I meant literally that Ruby is easier for a human to read for compr…

If you think that you have an algorithmic shortcut when parsing code, try cramming even a moderate amount of code into a single line with no indentation, and go by the token syntax alone. You will find yourself doing ad hoc parsing: scanning the code for matching tokens to extract what goes with what to reconstruct the tree structure.

Humans don't have a magic algorithmic shortcut. If I give you scrambled word decks of various sizes to sort manually, the best time performance you will be able to show will appear as an N log N curve. Maybe you can instantly sort seven objects just by looking at them, but not 17.

Re: RBS, Ruby’s new type signature language

#338

Earlier quoted context omitted.

Crystal is nice since they added a decent concurrency model, but it doesn't support one of the major platforms (windows)

Didn't ruby historically have poor support for windows? Everything great has to start small either eay.

Yeah no, you can say this against literally every criticism and be right unless someone comes up with time spans and user experiences of other great things to disprove it. Ruby was great on windows since 1.8, don't know how it was before that. I recently scripted AIX with it, so not really a contender on the same lane.

Re: RBS, Ruby’s new type signature language

#339
post #308

Earlier quoted context omitted.

Quibbles with your final paragraph: that's not what strongly typed means. It refers to when a language has strict rules restricting implicit type conversions. [0] Also, C++ has RTTI. [0] https://learn.adacore.com/courses/intro-to-ada/chapters/stro...

It's not that simple. There's no uniform definition of strong. You're right strong typing is often used to refer to absence of (or restrictions to) implicit type conversions, but it has also since the beginning been used to reference languages that does not prevent obscuring the identity of the type of an object. E.g. Liskov and Zilles [1] defined it this way for example: "whenever an object is passed from a calling…

If C++ fails when you do casts, why doesn't Haskell fail since it allows infinite recursion to build terms of whatever type you like? You can make the same argument: "don't do that". C++ compilers can warn when you cast. Haskell compilers can warn on incomplete pattern matches.

Is the definition you use not so broad as to admit all invariants being described as types?

If a method requires a dictionary arguments with a certain key, is that a type to you? If you extend the term "type" to cover all invariants, I don't think that is the way that the term is commonly used, even though many invariants can be proven in e.g. dependently typed languages.

All these terms are so wonky because a C++ type is not equal to a Haskell type. So I feel we can't ever have solid definitions of terms like "strong", since it depends what you compare it to, and it also depends what you compare from. So while X is strong in comparison to Y, that doesn't say much about X's relation to Z.

Post reply on HN