8 ms·

Because Matz won't let people add type annotations to the ruby grammar.

by burke 6y ago

jakearmitage 6y ago
Which is great.
- zeptonix 6y ago
  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 to catch/fix or show up straight away when running an app. It's mostly a documentation system. And it slows development down. Especially in Ruby which is such an elegant "programmer's language" I think it would just be silly.
  - sparker72678 6y ago
    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 fits that mold. So much of what I love about Ruby is what it doesn't make me do.
    - jolux 6y ago
      Type issues are 0% of your Ruby bugs because you're not using a typechecker. I guarantee you have type errors somewhere if your codebase is large enough.
      - sparker72678 6y ago
        My point is that imposing a big ass type system on developers as a "solution" to a trivial number of actual problems is overkill. I'm sure there are developer/projects that both enjoy and benefit from static typing and strict type systems of various kinds. I just want Ruby to remain a place for those of us who aren't in those positions.
        jolux 6y ago
        I'm not sure what a "big ass type system" is, and I disagree that the number of actual problems is trivial. However, I'm in no more position to say what Ruby should be than you are, and I'm sorry you're so opposed to static types that even attempting to support them is a minus in your book. However, even with TypeScript ascendant, the vast majority of people programming JavaScript write vanilla dynamic JS. I don't think dynamically typed Ruby is ever going to die. Whether large enterprise codebases will standardize on requiring type signatures is a different matter, because the benefits always outweigh what downsides you see in static typing once you surpass a certain scale.
        sparker72678 6y ago
        Swift's type system is what I have in mind: strict, complex, required, and in my experience, often petty. > "Whether large enterprise codebases will standardize on requiring type signatures is a different matter" Totally agree that there will always be people who value this tradeoff. That's fine, I just want the Ruby I know and love to keep existing.
        jolux 6y ago
        >Swift's type system is what I have in mind: strict, complex, required, and in my experience, often petty. I do hear a lot of complaints about Swift's type system. I wonder what the specific problems are, because I do not hear similar complaints about Rust. I wonder if it's the combination of subtyping with a lot of type inference and also a full-on trait system with protocols and extensions and such.
    - lmm 6y ago
      > Type issues are about 0% of my Ruby bugs Doubt. In my experience at least 70% of bugs are ones that you'd catch by using types - things like x instead of y, possibly-empty list instead of known-nonempty list, user ID instead of group ID. Logic errors that couldn't be caught by typing do exist, but they're very much the minority.
      - sparker72678 6y ago
        Maybe we just work on different kinds of problems. 70%+ of bugs I deal with are business logic issues that no type system could solve. Sure, as I code I run into an occasional nil object or NoMethod error, but those last as long in Ruby as they do in Swift (about 2-5 minutes while working on that specific part of the code).
        lmm 6y ago
        I've worked across a wide range of industries over several years, and it's always been pretty similar. You should be building the business constraints into your types so that errors in the business logic become errors in the types - in my experience if you actually work with the type system then most errors become type errors. If you've got examples of the kind of errors you're talking about then I could try to be more specific.
        sigmaml 6y ago
        Not the GP, but here is a scenario that I am interested in understanding from the perspective of types. A calculation that involves 21 parameters (in a particular insurance industry underwriting) yields a number. A threshold is read from the database. This threshold could change every month. Suppose that the current value of the threshold is 0.78. The calculation above can yield an `x` with the following cases: (i) x <= 0.78, (ii) x > 0.78. We have hundreds of test cases for the combinations of the 21 parameters, leading to hundreds of values for `x`. It is a bug for `x` to be > 0.78 when it should be the other way. Is there a way this can be encoded in types? That would be very interesting. Thanks.
    - djur 6y ago
      You've never had a NoMethodError in Ruby?
      - sparker72678 6y ago
        Sure, and I get compile time errors in Swift. Each last about 2-5 minutes. The actual bugs I have to fix are nearly always business logic issues. Edge cases around 3rd party integrations, incomplete implementations, unintended side effects, etc.
    - imtringued 6y ago
      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.
  - oblio 6y ago
    > It's mostly a documentation system. And it slows development down. Well, I guess this is also a matter of perspective. From where I'm standing, I'd rather you slow down and "document" your code. Code written at the speed of thought makes for an awesome MVP and for an awful legacy for your co-workers.
  - the_af 6y ago
    > Typing very occasionally prevents bugs that are generally easy to catch/fix or show up straight away when running an app. This is not true. You could paint almost every language feature aimed at producing correct software in this way: "writing tests makes me type more, and they catch very few bugs that would have been shown when running my app anyway". (Or, as an ex coworker once told me, "I don't need to write tests because I never have any bugs"). And what are types if not a kind of test/proof that the computer writes for you? > And it slows development down. There's a software development adage that goes like this: "I don't like writing tests, because they make me waste time I need to fix bugs on production that weren't caught because I don't write tests."
  - jolux 6y ago
    If your type definitions are 3x longer than the functions implementing them, something is wrong. In languages with complete type inference, you actually don't have to write types at all if you don't want to, though in practice you end up doing so to clarify your intentions. Static types do make certain classes of bugs impossible, like missing method bugs, typos, and the like. You can eliminate a large group of defensive programming techniques and trivial unit tests that you would need in a dynamic language to ensure a similar level of confidence in a program. Obviously they don't make all bugs impossible, there will be bugs as long as there are programs, because we write programs without perfect knowledge of the requirements, and this is an unavoidable pitfall of software.
  - mumblemumble 6y ago
    > And it slows development down. This can depend really heavily on what you mean by "development." If it's just getting the first version banged out, sure. If it includes coming back to code a couple years later in order to incorporate a new business requirement, having that documentation present can be a really big deal. 2 seconds spent typing out a type hint now might, down the line, save several minutes on average. Even in a recent Python project I did over the course of just a couple weeks, when I got to the "clean the code up and get it ready to put on the shelf for now" phase of the project, I ended up wishing that I had bothered to use type hints just a wee bit more when I was banging it out in the first place. It would have been a net time saver. I don't like static typing super a lot in all cases because it makes it hard to do data-level programming. Which I find to be the true productivity booster in dynamic languages. But optional typing seems to hit the sweet spot for a great many purposes.
    - jolux 6y ago
      I'm curious what you mean by "data-level programming."
      - mumblemumble 6y ago
        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 up-front, too. Even the bits you don't actually need to look at in order to accomplish the job at hand. IMO, that approach tends to mean creating a lot of unnecessary work for oneself. It also makes it harder to obey Postel's law. (The corollary to that last bit is that it is also possible for static typing to create bugs.)
        jolux 6y ago
        You can definitely still do this kind of programming in a statically typed language. There are a few ways to go about it. One way is to treat the JSON as a generic JSON structure, and traverse it manually. Of course, you will have to be explicit about what should happen when children are of different types from what you expect, though this explicitness could just be throwing an exception or ignoring it. Haskell's Aeson and Rust's serde_json both support this, as does .NET's JsonElement type. Unfortunately, this means you're passing around a lot of objects called something like "JSON" without any information about what they contain at the type level, and as an alternative between that approach and creating domain objects, there are row polymorphic records, which allow you to write functions that accept any record that has certain fields, and also specify that they may also contain other fields which you do not handle. This allows you to program to what you know about the types you're ingesting without having to write a lot of new types.
  - jakear 6y ago
    Types are great for tooling, which is a much bigger drive for me to use them than soundness guarantees. I can’t stand opening up API docs in a separate tab (or god-forbid browser window) once I got used to having literally everything I could want to know about how I can use a value available with a simple Cmd+Space.
  - dependenttypes 6y ago
    > I like typing 3x as much as I would otherwise need to 3x? Even on languages that do not support type inference I would say that this is at most 1.1x. Even then, type inference exists. > adding types now means bugs are impossible I usually see that as a mis-representation of what type advocates say. Rather, it seems that people just support that types reduce the amount of bugs. > or show up straight away when running an app Or that show up after you had said app running for a while, and then you get a run-time type error which appears only after doing certain actions. This is the main reason that I am avoiding languages like lua and python. (In addition languages with more advanced type-systems allow you to catch bugs such as buffer overflows or division by 0 at compile time)
- fimbulvetr 6y ago
  I don't use ruby, I am genuinely interested - why is it great? I'm assuming if it were ever allowed, it would be a use-at-will feature and wouldn't affect anyone who didn't use it. Typescript has probably doubled if not more my speed and accuracy since I've adopted it - yet I still do plenty of things in normal javascript. These days I'm usually unhappy when something does not have typings because it can make it terribly difficult to discover things.
  - sparker72678 6y ago
    The philosophical argument in the Ruby community is basically that Ruby is not a statically typed language, period. And a strong contingent, myself included, do not want a hybrid world where type annotations are optional, spattering redundancies all over our syntax. Mostly because I see that as a step in the direction of some kind of "strict" mode that will ultimately enforce type annotations and type-checking and destroy most of what I love about Ruby. That's why the approaches being used keep the type annotations out of the source files themselves.
    - jolux 6y ago
      The best type definition languages do not introduce redundancies. They describe information that is not already in the implementation itself.
    - ric2b 6y ago
      > I see that as a step in the direction of some kind of "strict" mode that will ultimately enforce type annotations and type-checking Ruby is not the first or the second or even the third dynamic language that has added static type checking support, has this _ever_ happened?
      - captn3m0 6y ago
        PHP has a strict typing mode: https://www.brainbell.com/php/strict-type.html https://www.brainbell.com/php/strict-type.html
  - 6y ago

Because Matz won't let people add type annotations to the ruby grammar.

by burke 6y ago

Because Matz won't let people add type annotations to the ruby grammar.

jakearmitage 6y ago

Which is great.

zeptonix 6y ago
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 to catch/fix or show up straight away when running an app. It's mostly a documentation system. And it slows development down. Especially in Ruby which is such an elegant "programmer's language" I think it would just be silly.
- sparker72678 6y ago
  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 fits that mold. So much of what I love about Ruby is what it doesn't make me do.
  - jolux 6y ago
    Type issues are 0% of your Ruby bugs because you're not using a typechecker. I guarantee you have type errors somewhere if your codebase is large enough.
    - sparker72678 6y ago
      My point is that imposing a big ass type system on developers as a "solution" to a trivial number of actual problems is overkill. I'm sure there are developer/projects that both enjoy and benefit from static typing and strict type systems of various kinds. I just want Ruby to remain a place for those of us who aren't in those positions.
      - jolux 6y ago
        I'm not sure what a "big ass type system" is, and I disagree that the number of actual problems is trivial. However, I'm in no more position to say what Ruby should be than you are, and I'm sorry you're so opposed to static types that even attempting to support them is a minus in your book. However, even with TypeScript ascendant, the vast majority of people programming JavaScript write vanilla dynamic JS. I don't think dynamically typed Ruby is ever going to die. Whether large enterprise codebases will standardize on requiring type signatures is a different matter, because the benefits always outweigh what downsides you see in static typing once you surpass a certain scale.
        sparker72678 6y ago
        Swift's type system is what I have in mind: strict, complex, required, and in my experience, often petty. > "Whether large enterprise codebases will standardize on requiring type signatures is a different matter" Totally agree that there will always be people who value this tradeoff. That's fine, I just want the Ruby I know and love to keep existing.
        jolux 6y ago
        >Swift's type system is what I have in mind: strict, complex, required, and in my experience, often petty. I do hear a lot of complaints about Swift's type system. I wonder what the specific problems are, because I do not hear similar complaints about Rust. I wonder if it's the combination of subtyping with a lot of type inference and also a full-on trait system with protocols and extensions and such.
  - lmm 6y ago
    > Type issues are about 0% of my Ruby bugs Doubt. In my experience at least 70% of bugs are ones that you'd catch by using types - things like x instead of y, possibly-empty list instead of known-nonempty list, user ID instead of group ID. Logic errors that couldn't be caught by typing do exist, but they're very much the minority.
    - sparker72678 6y ago
      Maybe we just work on different kinds of problems. 70%+ of bugs I deal with are business logic issues that no type system could solve. Sure, as I code I run into an occasional nil object or NoMethod error, but those last as long in Ruby as they do in Swift (about 2-5 minutes while working on that specific part of the code).
      - lmm 6y ago
        I've worked across a wide range of industries over several years, and it's always been pretty similar. You should be building the business constraints into your types so that errors in the business logic become errors in the types - in my experience if you actually work with the type system then most errors become type errors. If you've got examples of the kind of errors you're talking about then I could try to be more specific.
        sigmaml 6y ago
        Not the GP, but here is a scenario that I am interested in understanding from the perspective of types. A calculation that involves 21 parameters (in a particular insurance industry underwriting) yields a number. A threshold is read from the database. This threshold could change every month. Suppose that the current value of the threshold is 0.78. The calculation above can yield an `x` with the following cases: (i) x <= 0.78, (ii) x > 0.78. We have hundreds of test cases for the combinations of the 21 parameters, leading to hundreds of values for `x`. It is a bug for `x` to be > 0.78 when it should be the other way. Is there a way this can be encoded in types? That would be very interesting. Thanks.
  - djur 6y ago
    You've never had a NoMethodError in Ruby?
    - sparker72678 6y ago
      Sure, and I get compile time errors in Swift. Each last about 2-5 minutes. The actual bugs I have to fix are nearly always business logic issues. Edge cases around 3rd party integrations, incomplete implementations, unintended side effects, etc.
  - imtringued 6y ago
    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.
- oblio 6y ago
  > It's mostly a documentation system. And it slows development down. Well, I guess this is also a matter of perspective. From where I'm standing, I'd rather you slow down and "document" your code. Code written at the speed of thought makes for an awesome MVP and for an awful legacy for your co-workers.
- the_af 6y ago
  > Typing very occasionally prevents bugs that are generally easy to catch/fix or show up straight away when running an app. This is not true. You could paint almost every language feature aimed at producing correct software in this way: "writing tests makes me type more, and they catch very few bugs that would have been shown when running my app anyway". (Or, as an ex coworker once told me, "I don't need to write tests because I never have any bugs"). And what are types if not a kind of test/proof that the computer writes for you? > And it slows development down. There's a software development adage that goes like this: "I don't like writing tests, because they make me waste time I need to fix bugs on production that weren't caught because I don't write tests."
- jolux 6y ago
  If your type definitions are 3x longer than the functions implementing them, something is wrong. In languages with complete type inference, you actually don't have to write types at all if you don't want to, though in practice you end up doing so to clarify your intentions. Static types do make certain classes of bugs impossible, like missing method bugs, typos, and the like. You can eliminate a large group of defensive programming techniques and trivial unit tests that you would need in a dynamic language to ensure a similar level of confidence in a program. Obviously they don't make all bugs impossible, there will be bugs as long as there are programs, because we write programs without perfect knowledge of the requirements, and this is an unavoidable pitfall of software.
- mumblemumble 6y ago
  > And it slows development down. This can depend really heavily on what you mean by "development." If it's just getting the first version banged out, sure. If it includes coming back to code a couple years later in order to incorporate a new business requirement, having that documentation present can be a really big deal. 2 seconds spent typing out a type hint now might, down the line, save several minutes on average. Even in a recent Python project I did over the course of just a couple weeks, when I got to the "clean the code up and get it ready to put on the shelf for now" phase of the project, I ended up wishing that I had bothered to use type hints just a wee bit more when I was banging it out in the first place. It would have been a net time saver. I don't like static typing super a lot in all cases because it makes it hard to do data-level programming. Which I find to be the true productivity booster in dynamic languages. But optional typing seems to hit the sweet spot for a great many purposes.
  - jolux 6y ago
    I'm curious what you mean by "data-level programming."
    - mumblemumble 6y ago
      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 up-front, too. Even the bits you don't actually need to look at in order to accomplish the job at hand. IMO, that approach tends to mean creating a lot of unnecessary work for oneself. It also makes it harder to obey Postel's law. (The corollary to that last bit is that it is also possible for static typing to create bugs.)
      - jolux 6y ago
        You can definitely still do this kind of programming in a statically typed language. There are a few ways to go about it. One way is to treat the JSON as a generic JSON structure, and traverse it manually. Of course, you will have to be explicit about what should happen when children are of different types from what you expect, though this explicitness could just be throwing an exception or ignoring it. Haskell's Aeson and Rust's serde_json both support this, as does .NET's JsonElement type. Unfortunately, this means you're passing around a lot of objects called something like "JSON" without any information about what they contain at the type level, and as an alternative between that approach and creating domain objects, there are row polymorphic records, which allow you to write functions that accept any record that has certain fields, and also specify that they may also contain other fields which you do not handle. This allows you to program to what you know about the types you're ingesting without having to write a lot of new types.
- jakear 6y ago
  Types are great for tooling, which is a much bigger drive for me to use them than soundness guarantees. I can’t stand opening up API docs in a separate tab (or god-forbid browser window) once I got used to having literally everything I could want to know about how I can use a value available with a simple Cmd+Space.
- dependenttypes 6y ago
  > I like typing 3x as much as I would otherwise need to 3x? Even on languages that do not support type inference I would say that this is at most 1.1x. Even then, type inference exists. > adding types now means bugs are impossible I usually see that as a mis-representation of what type advocates say. Rather, it seems that people just support that types reduce the amount of bugs. > or show up straight away when running an app Or that show up after you had said app running for a while, and then you get a run-time type error which appears only after doing certain actions. This is the main reason that I am avoiding languages like lua and python. (In addition languages with more advanced type-systems allow you to catch bugs such as buffer overflows or division by 0 at compile time)
fimbulvetr 6y ago
I don't use ruby, I am genuinely interested - why is it great? I'm assuming if it were ever allowed, it would be a use-at-will feature and wouldn't affect anyone who didn't use it. Typescript has probably doubled if not more my speed and accuracy since I've adopted it - yet I still do plenty of things in normal javascript. These days I'm usually unhappy when something does not have typings because it can make it terribly difficult to discover things.
- sparker72678 6y ago
  The philosophical argument in the Ruby community is basically that Ruby is not a statically typed language, period. And a strong contingent, myself included, do not want a hybrid world where type annotations are optional, spattering redundancies all over our syntax. Mostly because I see that as a step in the direction of some kind of "strict" mode that will ultimately enforce type annotations and type-checking and destroy most of what I love about Ruby. That's why the approaches being used keep the type annotations out of the source files themselves.
  - jolux 6y ago
    The best type definition languages do not introduce redundancies. They describe information that is not already in the implementation itself.
  - ric2b 6y ago
    > I see that as a step in the direction of some kind of "strict" mode that will ultimately enforce type annotations and type-checking Ruby is not the first or the second or even the third dynamic language that has added static type checking support, has this _ever_ happened?
    - captn3m0 6y ago
      PHP has a strict typing mode: https://www.brainbell.com/php/strict-type.html https://www.brainbell.com/php/strict-type.html
- 6y ago