A Ruby compiler that learns

[mindaslab (Karthikeyan A K)]

Hello All,

I came across this link https://developer.squareup.com/blog/the-state-of-ruby-3-typing/ and it worried me a lot, I saw what people said on twitter and I was not alone. Looks like most people do not like to add typing in Ruby. Yes I do realize the benefits we might get like faster programs and so on but....

I strongly feel Ruby should be a language for humans and not language for corporate's. It's big companies that want these typing. At the same time it will be great if Ruby can learn to add types automatically. Lets say I have a function add(a, b), on running it lot of times, Ruby can infer that most of the time a and b are Number, and hence it can keep a meta data of this thing it learned in a file in the same project folder. This way we can have faster Ruby with less programmer frustration. May be we can use test file that tests these programs (during TDD) to add types.

I am not an language expert, but I Love Ruby, I just want it to be the best language for programming (for humans). What do you think about it?

- Karthikeyan A K

···

Sent with ProtonMail Secure Email.

[Ken_D_Ambrosio]

Bah and humbug. I'm not wild about how it's being done, but none of it is being *forced* on anyone. I promise: every language in existence has features that are only asked for and used by a subset of its users, and, while there is a technical debt incurred by adding new features, there's essentially zero impact (in this case) on what and how you decide to use Ruby, aside from the fact that there are now more options.

$.02,

-Ken

···

On 2020-07-30 09:52, Karthikeyan A K wrote:

Hello All,

I came across this link
The State of Ruby 3 Typing and it
worried me a lot, I saw what people said on twitter and I was not
alone. Looks like most people do not like to add typing in Ruby. Yes I
do realize the benefits we might get like faster programs and so on
but....

[Xavier_Noria]

I am not an language expert, but I Love Ruby, I just want it to be the
best language for programming (for humans). What do you think about it?

I think it is fine! I annotate type signatures on my own code, because
people have to know what they can pass, and what they get back. And “they”
includes “me”.

Type checking validates those (now) manually maintained annotations.

[Lee_Hambley]

I came across this link
The State of Ruby 3 Typing and it
worried me a lot, I saw what people said on twitter and I was not alone.
Looks like most people do not like to add typing in Ruby.

Why would you be worried about an optional feature that has the support of
the language author and overseers?

Yes I do realize the benefits we might get like faster programs and so on
but....

I'm not sure faster programs is a design goal here, as far as I'm aware the
proposal doesn't really address runtime performance at all, your variables
will still be backed by R_VALUEs under the hood, and all the runtime
reflection in the VM will still have to be done to figure out of an
"object" is a string, hash, int or other when called.

I strongly feel Ruby should be a language for humans and not language for
corporate's. It's big companies that want these typing.

I work for a company with ~20 Ruby developers, we are desperate for the
type system. We're a Rails app with some peripheral things (REST APIs,
GraphQL, that aren't strictly Rails) and most of our methods take hashes as
arguments and return hashes of hashes. This is pretty typical Ruby in my
decade of experience. We have little-to-no way of knowing what is
*necessary* in any of those hashes.

Being that we have ActiveSupport, we could pass strict instances of
ActionController::Params around, a kind of type-system that ActiveSupport
embedded into Rails for dealing with the problems of receiving untyped,
mixed-content payloads from HTTP requests. The need for a type system is
there, and it's been a core part of Rails for half a decade.

We also make extensive use of things like `dry-types`
<https://dry-rb.org/gems/dry-types/1.2/&gt;, `dry-schema`
<https://dry-rb.org/gems/dry-schema/1.5/&gt; and things such as Re:Form and
form-objects, all of which do type structure verification and guard against
unwanted "types" (although, in the end we get hashes of hashes) into the
boundaries of the system.

Without language-level support, we're constantly reinventing variations on
"types" across the various layers in the stack, we have lots of controller
tests for our REST APIs using JSON schema to validate the "type" structure
of JSON headed out to API clients.

Are we the big corporates you're referring to when you suggest that people
are turning Ruby into a language for machines? We certainly feel like a
small shop operating in a real world of daily problems not knowing the
shape of the data going over our system boundaries.

At the same time it will be great if Ruby can learn to add types
automatically. Lets say I have a function add(a, b), on running it lot of
times, Ruby can infer that most of the time a and b are Number, and hence
it can keep a meta data of this thing it learned in a file in the same
project folder.

You touched on two things here, the first thing is absolutely planned. The
design of RBS being separate in separate files is great, it means that Gem
authors can ship those support files in their gems, and people on older
Rubies before 3.0 can continue to use things without needing to support
this new magic syntax. Surely tools will be written, or have been written
already to do a type inferrence and generate types. The TypeScript
community design for this problem is almost exactly the same, and has
worked really, really well. They have CI/CD in a meta project which fetches
the untyped libraries from the most popular node projects and generates
types, and provides them via separate packages.

This way we can have faster Ruby with less programmer frustration. May be
we can use test file that tests these programs (during TDD) to add types.

Most of my frustration from Ruby comes from _not_ knowing the shape of my
incoming and outgoing data. I look forward to having a declaration file
that describes the interface unambiguously, and making sure I can write
fewer tests, and still improve the quality of my code.

I hope my position can change your opinion a bit, types are going to be
_Great_. The RBS proposal does, after all, retain the duck-typing
properties of Ruby via "interfaces". So far as I can see, there's literally
no down-side to the RBS proposal.

···

---

Please excuse the wall of text, the type system is the feature of Ruby I am
most excited about since learning Ruby in 2008.

[Peter_Hickman2 (Peter Hickman)]

While we obviously will have to see how this works out I am wary of the
fact that the signatures are in a different file. This could mean that if I
change code in the .rb file it might then conflict with the .rbs file and
either fail to run or misbehave

Signatures will end up like documentation, no one keeps them up to date as
they write the code. Only at the end of the project, if there is time

Or we could simply switch to Crystal or Sathar

[Fellipe_Fingoli]

Isn't typing params violating the duck type principle?

···

Em qui, 30 de jul de 2020 12:19, Peter Hickman < peterhickman386@googlemail.com> escreveu:

While we obviously will have to see how this works out I am wary of the
fact that the signatures are in a different file. This could mean that if I
change code in the .rb file it might then conflict with the .rbs file and
either fail to run or misbehave

Signatures will end up like documentation, no one keeps them up to date as
they write the code. Only at the end of the project, if there is time

Or we could simply switch to Crystal or Sathar

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

[Xavier_Noria]

Isn't typing params violating the duck type principle?

No if the type system supports it (or interfaces). For example, in YARD
notation you can declare a “type” #foo, meaning anything that responds to
#foo.

···

On Thu, 30 Jul 2020 at 17:33, Fellipe Fingoli <fellipe.fingoli@gmail.com> wrote:

--

Sent from Gmail Mobile

[Leland_Miller]

How so? If done right it really just gives you a way to communicate that
your method needs something that quacks, and a way to verify that the
caller gave it something that quacks. A good type system doesn’t force you
to ask for a duck

···

On Thu, Jul 30, 2020 at 8:33 AM Fellipe Fingoli <fellipe.fingoli@gmail.com> wrote:

Isn't typing params violating the duck type principle?

Em qui, 30 de jul de 2020 12:19, Peter Hickman < > peterhickman386@googlemail.com> escreveu:

While we obviously will have to see how this works out I am wary of the
fact that the signatures are in a different file. This could mean that if I
change code in the .rb file it might then conflict with the .rbs file and
either fail to run or misbehave

Signatures will end up like documentation, no one keeps them up to date
as they write the code. Only at the end of the project, if there is time

Or we could simply switch to Crystal or Sathar

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

[Gerard_Fowley]

I see the benefit of typing but am concerned about the implications for
Ruby development culture. It is going to depend upon how it's used. Typing
could enable over-specified interfaces, spelling an end to duck typing
conventions.

I suspect we will see some library developers pedantically specifying
overly complex specific types (classes of objects) at their boundaries,
causing application developers to have to use those types in their code or
pay performance penalties for conversion/translation.

This often turns into a classes vs. interfaces discussion. But both are
harder edges than convention.

-gf-

···

On Thu, Jul 30, 2020 at 11:33 AM Fellipe Fingoli <fellipe.fingoli@gmail.com> wrote:

Isn't typing params violating the duck type principle?

Em qui, 30 de jul de 2020 12:19, Peter Hickman < > peterhickman386@googlemail.com> escreveu:

While we obviously will have to see how this works out I am wary of the
fact that the signatures are in a different file. This could mean that if I
change code in the .rb file it might then conflict with the .rbs file and
either fail to run or misbehave

Signatures will end up like documentation, no one keeps them up to date
as they write the code. Only at the end of the project, if there is time

Or we could simply switch to Crystal or Sathar

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

[Gerard_Fowley]

A good type system doesn’t force you to ask for a duck

That's a good way to put it. Considering the application developer and
expanding on that...

A good Ruby type systems doesn't let you require a duck

-gf-

[Peter_Hickman2 (Peter Hickman)]

Some of our apps already have this sort of problem. One library returns
hash keys as strings, another symbols. We have to manually convert the
output of one to the other so that they can interoperate. This can be a
frustrating source of errors if not handled correctly. Seems like a type
system could make this worse

···

On Thu, 30 Jul 2020 at 16:57, Gerard Fowley <gerard.fowley@iqeo.net> wrote:

I suspect we will see some library developers pedantically specifying
overly complex specific types (classes of objects) at their boundaries,
causing application developers to have to use those types in their code or
pay performance penalties for conversion/translation.

[Brandon_Weaver1 (Brandon Weaver)]

Hey! I'm one of the editors of that post, and I work with Soutaro.

Karthikeyan: I have seen your tweet on this, and would encourage you again
as I did on that tweet to engage in a more constructive dialogue. Saying "Ruby
will suck now <https://twitter.com/karthik_ak/status/1288789360712847361&gt;&quot;
is not constructive.

Those who know me know that I do not always agree with decisions made by
core Ruby committers, and I will write about them on occasion. I've done so
several times with one of the most substantial ones being the pipeline
operator <https://dev.to/baweaver/ruby-2-7-the-pipeline-operator-1b2d&gt;\.

I am not here to convince you, merely to explain and clarify a few factors
mentioned.

"Looks like most people do not like to add typing in Ruby"

I would encourage you not to speak for "most people" as that may not be
accurate. This would be very hard to quantify, and I have seen people in
both camps on this matter.

"I strongly feel Ruby should be a language for humans and not language

for corporate's"

Square, Stripe, and Shopify are not exactly large corporations. Supposing
we ignore that, the implication here is that RBS is a standard that will be
forced down people's throats. This is not accurate. RBS is, and always will
be, optional. If you don't like it you are not required to use it. Framing
it as such is not in the best interest of discussion.

" It's big companies that want these typing"

Again, I would encourage you not to try and speak for audiences you do not
represent. Big companies are not the only ones who are interested in these
features, and presenting it as such is dishonest and disenfranchises
smaller companies which may also have legitimate interest in these features.

"At the same time it will be great if Ruby can learn to add types

automatically. Lets say I have a function add(a, b), on running it lot of
times, Ruby can infer that most of the time a and b are Number, and hence
it can keep a meta data of this thing it learned in a file in the same
project folder. This way we can have faster Ruby with less programmer
frustration. May be we can use test file that tests these programs (during
TDD) to add types."

This is the intention of RBS, and exactly what most of the tooling around
it is intended to do. RBS files are automatically generated by Ruby via
inference for the most part into a separate folder. Steep builds upon this
to add those tests to ensure these items are accurate. Matz and the ruby
contributors spend a lot of time working on exactly this type of
functionality, and in doing so have made a very transparent system that
does not interfere with programmers explicitly except in the rare cases
where they want to be more specific in their type definitions.

···

----

Now then, as far as the rest of the email. Dynamic and duck typing are both
supported through interfaces, union, and product types. YARDoc
<https://yardoc.org/&gt; is a current annotation and documentation system that
many Rubyists use, and there are tools that exist
<https://github.com/AaronC81/sord&gt; to convert them to RBI/Sorbet. I've chatted
with the author
<https://twitter.com/keystonelemur/status/1288850551938195464&gt; of the tool
briefly about doing this for RBS so we can approach a unified standard.

In any case we're always seeking to improve things and learn, just wanted
to set some of the record straight on what's going on. We've also posted
some updates to the article for clarifications that should be coming up
soon.

If you have any questions or otherwise feel free to ask either here or on
Twitter (@keystonelemur)

- Brandon

On Thu, Jul 30, 2020 at 11:05 AM Peter Hickman < peterhickman386@googlemail.com> wrote:

On Thu, 30 Jul 2020 at 16:57, Gerard Fowley <gerard.fowley@iqeo.net> > wrote:

I suspect we will see some library developers pedantically specifying
overly complex specific types (classes of objects) at their boundaries,
causing application developers to have to use those types in their code or
pay performance penalties for conversion/translation.

Some of our apps already have this sort of problem. One library returns
hash keys as strings, another symbols. We have to manually convert the
output of one to the other so that they can interoperate. This can be a
frustrating source of errors if not handled correctly. Seems like a type
system could make this worse

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

[mindaslab (Karthikeyan A K)]

Okay. I am not an expert, and I do have lot of ignorance. Time and future will decide stuff. Let's wait and watch.

I am sorry to have offended you people. I am from a country where we are encouraged to speak our mind out.

- Karthikeyan A K

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

···

Sent with [ProtonMail](https://protonmail.com) Secure Email.
On Thursday, July 30, 2020 10:12 PM, Brandon Weaver <keystonelemur@gmail.com> wrote:

Hey! I'm one of the editors of that post, and I work with Soutaro.

Karthikeyan: I have seen your tweet on this, and would encourage you again as I did on that tweet to engage in a more constructive dialogue. Saying "[Ruby will suck now](https://twitter.com/karthik_ak/status/1288789360712847361)" is not constructive.

Those who know me know that I do not always agree with decisions made by core Ruby committers, and I will write about them on occasion. I've done so several times with one of the most substantial ones being [the pipeline operator](Ruby 2.7: The Pipeline Operator - DEV Community).

I am not here to convince you, merely to explain and clarify a few factors mentioned.

"Looks like most people do not like to add typing in Ruby"

I would encourage you not to speak for "most people" as that may not be accurate. This would be very hard to quantify, and I have seen people in both camps on this matter.

"I strongly feel Ruby should be a language for humans and not language for corporate's"

Square, Stripe, and Shopify are not exactly large corporations. Supposing we ignore that, the implication here is that RBS is a standard that will be forced down people's throats. This is not accurate. RBS is, and always will be, optional. If you don't like it you are not required to use it. Framing it as such is not in the best interest of discussion.

" It's big companies that want these typing"

Again, I would encourage you not to try and speak for audiences you do not represent. Big companies are not the only ones who are interested in these features, and presenting it as such is dishonest and disenfranchises smaller companies which may also have legitimate interest in these features.

"At the same time it will be great if Ruby can learn to add types automatically. Lets say I have a function add(a, b), on running it lot of times, Ruby can infer that most of the time a and b are Number, and hence it can keep a meta data of this thing it learned in a file in the same project folder. This way we can have faster Ruby with less programmer frustration. May be we can use test file that tests these programs (during TDD) to add types."

This is the intention of RBS, and exactly what most of the tooling around it is intended to do. RBS files are automatically generated by Ruby via inference for the most part into a separate folder. Steep builds upon this to add those tests to ensure these items are accurate. Matz and the ruby contributors spend a lot of time working on exactly this type of functionality, and in doing so have made a very transparent system that does not interfere with programmers explicitly except in the rare cases where they want to be more specific in their type definitions.

----

Now then, as far as the rest of the email. Dynamic and duck typing are both supported through interfaces, union, and product types. [YARDoc](https://yardoc.org/) is a current annotation and documentation system that many Rubyists use, and there are [tools that exist](GitHub - AaronC81/sord: Convert YARD docs to Sorbet RBI and Ruby 3/Steep RBS files) to convert them to RBI/Sorbet. I've [chatted with the author](https://twitter.com/keystonelemur/status/1288850551938195464) of the tool briefly about doing this for RBS so we can approach a unified standard.

In any case we're always seeking to improve things and learn, just wanted to set some of the record straight on what's going on. We've also posted some updates to the article for clarifications that should be coming up soon.

If you have any questions or otherwise feel free to ask either here or on Twitter (@keystonelemur)

- Brandon

On Thu, Jul 30, 2020 at 11:05 AM Peter Hickman <peterhickman386@googlemail.com> wrote:

On Thu, 30 Jul 2020 at 16:57, Gerard Fowley <gerard.fowley@iqeo.net> wrote:

I suspect we will see some library developers pedantically specifying overly complex specific types (classes of objects) at their boundaries, causing application developers to have to use those types in their code or pay performance penalties for conversion/translation.

Some of our apps already have this sort of problem. One library returns hash keys as strings, another symbols. We have to manually convert the output of one to the other so that they can interoperate. This can be a frustrating source of errors if not handled correctly. Seems like a type system could make this worse

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

[Lee_Hambley]

Please don't feign offense, you were on Twitter earlier trying to cause
controversy https://twitter.com/karthik_ak/status/1288789360712847361

We offered good-faith arguments here taking the time to answer your
questions.

Lee Hambley

Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.

+49 (0) 170 298 5667

···

On Thu, 30 Jul 2020 at 19:22, Karthikeyan A K <mindaslab@protonmail.com> wrote:

Okay. I am not an expert, and I do have lot of ignorance. Time and future
will decide stuff. Let's wait and watch.

I am sorry to have offended you people. I am from a country where we are
encouraged to speak our mind out.

- Karthikeyan A K

Sent with ProtonMail <https://protonmail.com> Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, July 30, 2020 10:12 PM, Brandon Weaver < > keystonelemur@gmail.com> wrote:

Hey! I'm one of the editors of that post, and I work with Soutaro.

Karthikeyan: I have seen your tweet on this, and would encourage you again
as I did on that tweet to engage in a more constructive dialogue. Saying "Ruby
will suck now <https://twitter.com/karthik_ak/status/1288789360712847361&gt;&quot;
is not constructive.

Those who know me know that I do not always agree with decisions made by
core Ruby committers, and I will write about them on occasion. I've done so
several times with one of the most substantial ones being the pipeline
operator <https://dev.to/baweaver/ruby-2-7-the-pipeline-operator-1b2d&gt;\.

I am not here to convince you, merely to explain and clarify a few factors
mentioned.

> "Looks like most people do not like to add typing in Ruby"

I would encourage you not to speak for "most people" as that may not be
accurate. This would be very hard to quantify, and I have seen people in
both camps on this matter.

> "I strongly feel Ruby should be a language for humans and not language
for corporate's"

Square, Stripe, and Shopify are not exactly large corporations. Supposing
we ignore that, the implication here is that RBS is a standard that will be
forced down people's throats. This is not accurate. RBS is, and always will
be, optional. If you don't like it you are not required to use it. Framing
it as such is not in the best interest of discussion.

> " It's big companies that want these typing"

Again, I would encourage you not to try and speak for audiences you do not
represent. Big companies are not the only ones who are interested in these
features, and presenting it as such is dishonest and disenfranchises
smaller companies which may also have legitimate interest in these features.

> "At the same time it will be great if Ruby can learn to add types
automatically. Lets say I have a function add(a, b), on running it lot of
times, Ruby can infer that most of the time a and b are Number, and hence
it can keep a meta data of this thing it learned in a file in the same
project folder. This way we can have faster Ruby with less programmer
frustration. May be we can use test file that tests these programs (during
TDD) to add types."

This is the intention of RBS, and exactly what most of the tooling around
it is intended to do. RBS files are automatically generated by Ruby via
inference for the most part into a separate folder. Steep builds upon this
to add those tests to ensure these items are accurate. Matz and the ruby
contributors spend a lot of time working on exactly this type of
functionality, and in doing so have made a very transparent system that
does not interfere with programmers explicitly except in the rare cases
where they want to be more specific in their type definitions.

----

Now then, as far as the rest of the email. Dynamic and duck typing are
both supported through interfaces, union, and product types. YARDoc
<https://yardoc.org/&gt; is a current annotation and documentation system
that many Rubyists use, and there are tools that exist
<https://github.com/AaronC81/sord&gt; to convert them to RBI/Sorbet. I've chatted
with the author
<https://twitter.com/keystonelemur/status/1288850551938195464&gt; of the
tool briefly about doing this for RBS so we can approach a unified standard.

In any case we're always seeking to improve things and learn, just wanted
to set some of the record straight on what's going on. We've also posted
some updates to the article for clarifications that should be coming up
soon.

If you have any questions or otherwise feel free to ask either here or on
Twitter (@keystonelemur)

- Brandon

On Thu, Jul 30, 2020 at 11:05 AM Peter Hickman < > peterhickman386@googlemail.com> wrote:

On Thu, 30 Jul 2020 at 16:57, Gerard Fowley <gerard.fowley@iqeo.net> >> wrote:

I suspect we will see some library developers pedantically specifying
overly complex specific types (classes of objects) at their boundaries,
causing application developers to have to use those types in their code or
pay performance penalties for conversion/translation.

Some of our apps already have this sort of problem. One library returns
hash keys as strings, another symbols. We have to manually convert the
output of one to the other so that they can interoperate. This can be a
frustrating source of errors if not handled correctly. Seems like a type
system could make this worse

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

[Brandon_Weaver1 (Brandon Weaver)]

I appreciate people speaking their mind, I would just encourage civility
when doing so. We've addressed this, so let's drop discussion on those
points and focus instead on the technical.

I do not want to turn this entire chain into an attack on Karthikeyan, and
think we have established and discussed these points. Let us not belabor
that point.

···

On Thu, Jul 30, 2020, 12:25 PM Lee Hambley <lee.hambley@gmail.com> wrote:

Please don't feign offense, you were on Twitter earlier trying to cause
controversy https://twitter.com/karthik_ak/status/1288789360712847361

We offered good-faith arguments here taking the time to answer your
questions.

Lee Hambley
http://lee.hambley.name/
+49 (0) 170 298 5667

On Thu, 30 Jul 2020 at 19:22, Karthikeyan A K <mindaslab@protonmail.com> > wrote:

Okay. I am not an expert, and I do have lot of ignorance. Time and future
will decide stuff. Let's wait and watch.

I am sorry to have offended you people. I am from a country where we are
encouraged to speak our mind out.

- Karthikeyan A K

Sent with ProtonMail <https://protonmail.com> Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, July 30, 2020 10:12 PM, Brandon Weaver < >> keystonelemur@gmail.com> wrote:

Hey! I'm one of the editors of that post, and I work with Soutaro.

Karthikeyan: I have seen your tweet on this, and would encourage you
again as I did on that tweet to engage in a more constructive dialogue.
Saying "Ruby will suck now
<https://twitter.com/karthik_ak/status/1288789360712847361&gt;&quot; is not
constructive.

Those who know me know that I do not always agree with decisions made by
core Ruby committers, and I will write about them on occasion. I've done so
several times with one of the most substantial ones being the pipeline
operator <https://dev.to/baweaver/ruby-2-7-the-pipeline-operator-1b2d&gt;\.

I am not here to convince you, merely to explain and clarify a few
factors mentioned.

> "Looks like most people do not like to add typing in Ruby"

I would encourage you not to speak for "most people" as that may not be
accurate. This would be very hard to quantify, and I have seen people in
both camps on this matter.

> "I strongly feel Ruby should be a language for humans and not language
for corporate's"

Square, Stripe, and Shopify are not exactly large corporations. Supposing
we ignore that, the implication here is that RBS is a standard that will be
forced down people's throats. This is not accurate. RBS is, and always will
be, optional. If you don't like it you are not required to use it. Framing
it as such is not in the best interest of discussion.

> " It's big companies that want these typing"

Again, I would encourage you not to try and speak for audiences you do
not represent. Big companies are not the only ones who are interested in
these features, and presenting it as such is dishonest and disenfranchises
smaller companies which may also have legitimate interest in these features.

> "At the same time it will be great if Ruby can learn to add types
automatically. Lets say I have a function add(a, b), on running it lot of
times, Ruby can infer that most of the time a and b are Number, and hence
it can keep a meta data of this thing it learned in a file in the same
project folder. This way we can have faster Ruby with less programmer
frustration. May be we can use test file that tests these programs (during
TDD) to add types."

This is the intention of RBS, and exactly what most of the tooling around
it is intended to do. RBS files are automatically generated by Ruby via
inference for the most part into a separate folder. Steep builds upon this
to add those tests to ensure these items are accurate. Matz and the ruby
contributors spend a lot of time working on exactly this type of
functionality, and in doing so have made a very transparent system that
does not interfere with programmers explicitly except in the rare cases
where they want to be more specific in their type definitions.

----

Now then, as far as the rest of the email. Dynamic and duck typing are
both supported through interfaces, union, and product types. YARDoc
<https://yardoc.org/&gt; is a current annotation and documentation system
that many Rubyists use, and there are tools that exist
<https://github.com/AaronC81/sord&gt; to convert them to RBI/Sorbet. I've chatted
with the author
<https://twitter.com/keystonelemur/status/1288850551938195464&gt; of the
tool briefly about doing this for RBS so we can approach a unified standard.

In any case we're always seeking to improve things and learn, just wanted
to set some of the record straight on what's going on. We've also posted
some updates to the article for clarifications that should be coming up
soon.

If you have any questions or otherwise feel free to ask either here or on
Twitter (@keystonelemur)

- Brandon

On Thu, Jul 30, 2020 at 11:05 AM Peter Hickman < >> peterhickman386@googlemail.com> wrote:

On Thu, 30 Jul 2020 at 16:57, Gerard Fowley <gerard.fowley@iqeo.net> >>> wrote:

I suspect we will see some library developers pedantically specifying
overly complex specific types (classes of objects) at their boundaries,
causing application developers to have to use those types in their code or
pay performance penalties for conversion/translation.

Some of our apps already have this sort of problem. One library returns
hash keys as strings, another symbols. We have to manually convert the
output of one to the other so that they can interoperate. This can be a
frustrating source of errors if not handled correctly. Seems like a type
system could make this worse

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org
?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

[Lee_Hambley]

Thanks for your work on this Brandon, I found the notes you added here
about the breadth of capabilities in the type system, and the symmetry with
YARD very useful, I hadn't realized quite how "ruby-like" it was, I think
it's a very faithful extension of the language.

Regards,

Lee Hambley

Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.

+49 (0) 170 298 5667

···

On Thu, 30 Jul 2020 at 19:50, Brandon Weaver <keystonelemur@gmail.com> wrote:

I appreciate people speaking their mind, I would just encourage civility
when doing so. We've addressed this, so let's drop discussion on those
points and focus instead on the technical.

I do not want to turn this entire chain into an attack on Karthikeyan, and
think we have established and discussed these points. Let us not belabor
that point.

On Thu, Jul 30, 2020, 12:25 PM Lee Hambley <lee.hambley@gmail.com> wrote:

Please don't feign offense, you were on Twitter earlier trying to cause
controversy https://twitter.com/karthik_ak/status/1288789360712847361

We offered good-faith arguments here taking the time to answer your
questions.

Lee Hambley
http://lee.hambley.name/
+49 (0) 170 298 5667

On Thu, 30 Jul 2020 at 19:22, Karthikeyan A K <mindaslab@protonmail.com> >> wrote:

Okay. I am not an expert, and I do have lot of ignorance. Time and
future will decide stuff. Let's wait and watch.

I am sorry to have offended you people. I am from a country where we are
encouraged to speak our mind out.

- Karthikeyan A K

Sent with ProtonMail <https://protonmail.com> Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, July 30, 2020 10:12 PM, Brandon Weaver < >>> keystonelemur@gmail.com> wrote:

Hey! I'm one of the editors of that post, and I work with Soutaro.

Karthikeyan: I have seen your tweet on this, and would encourage you
again as I did on that tweet to engage in a more constructive dialogue.
Saying "Ruby will suck now
<https://twitter.com/karthik_ak/status/1288789360712847361&gt;&quot; is not
constructive.

Those who know me know that I do not always agree with decisions made by
core Ruby committers, and I will write about them on occasion. I've done so
several times with one of the most substantial ones being the pipeline
operator <https://dev.to/baweaver/ruby-2-7-the-pipeline-operator-1b2d&gt;\.

I am not here to convince you, merely to explain and clarify a few
factors mentioned.

> "Looks like most people do not like to add typing in Ruby"

I would encourage you not to speak for "most people" as that may not be
accurate. This would be very hard to quantify, and I have seen people in
both camps on this matter.

> "I strongly feel Ruby should be a language for humans and not
language for corporate's"

Square, Stripe, and Shopify are not exactly large corporations.
Supposing we ignore that, the implication here is that RBS is a standard
that will be forced down people's throats. This is not accurate. RBS is,
and always will be, optional. If you don't like it you are not required to
use it. Framing it as such is not in the best interest of discussion.

> " It's big companies that want these typing"

Again, I would encourage you not to try and speak for audiences you do
not represent. Big companies are not the only ones who are interested in
these features, and presenting it as such is dishonest and disenfranchises
smaller companies which may also have legitimate interest in these features.

> "At the same time it will be great if Ruby can learn to add types
automatically. Lets say I have a function add(a, b), on running it lot of
times, Ruby can infer that most of the time a and b are Number, and hence
it can keep a meta data of this thing it learned in a file in the same
project folder. This way we can have faster Ruby with less programmer
frustration. May be we can use test file that tests these programs (during
TDD) to add types."

This is the intention of RBS, and exactly what most of the tooling
around it is intended to do. RBS files are automatically generated by Ruby
via inference for the most part into a separate folder. Steep builds upon
this to add those tests to ensure these items are accurate. Matz and the
ruby contributors spend a lot of time working on exactly this type of
functionality, and in doing so have made a very transparent system that
does not interfere with programmers explicitly except in the rare cases
where they want to be more specific in their type definitions.

----

Now then, as far as the rest of the email. Dynamic and duck typing are
both supported through interfaces, union, and product types. YARDoc
<https://yardoc.org/&gt; is a current annotation and documentation system
that many Rubyists use, and there are tools that exist
<https://github.com/AaronC81/sord&gt; to convert them to RBI/Sorbet. I've chatted
with the author
<https://twitter.com/keystonelemur/status/1288850551938195464&gt; of the
tool briefly about doing this for RBS so we can approach a unified standard.

In any case we're always seeking to improve things and learn, just
wanted to set some of the record straight on what's going on. We've also
posted some updates to the article for clarifications that should be coming
up soon.

If you have any questions or otherwise feel free to ask either here or
on Twitter (@keystonelemur)

- Brandon

On Thu, Jul 30, 2020 at 11:05 AM Peter Hickman < >>> peterhickman386@googlemail.com> wrote:

On Thu, 30 Jul 2020 at 16:57, Gerard Fowley <gerard.fowley@iqeo.net> >>>> wrote:

I suspect we will see some library developers pedantically specifying
overly complex specific types (classes of objects) at their boundaries,
causing application developers to have to use those types in their code or
pay performance penalties for conversion/translation.

Some of our apps already have this sort of problem. One library returns
hash keys as strings, another symbols. We have to manually convert the
output of one to the other so that they can interoperate. This can be a
frustrating source of errors if not handled correctly. Seems like a type
system could make this worse

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org
?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org
?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

[Sean_Felipe_Wolfe]

The Crystal programing language is inspired by Ruby and has a well
developed type system. Check it out for some more perspective.

#minaswan

···

On Thu, Jul 30, 2020, 10:58 AM Lee Hambley <lee.hambley@gmail.com> wrote:

Thanks for your work on this Brandon, I found the notes you added here
about the breadth of capabilities in the type system, and the symmetry with
YARD very useful, I hadn't realized quite how "ruby-like" it was, I think
it's a very faithful extension of the language.

Regards,

Lee Hambley
http://lee.hambley.name/
+49 (0) 170 298 5667

On Thu, 30 Jul 2020 at 19:50, Brandon Weaver <keystonelemur@gmail.com> > wrote:

I appreciate people speaking their mind, I would just encourage civility
when doing so. We've addressed this, so let's drop discussion on those
points and focus instead on the technical.

I do not want to turn this entire chain into an attack on Karthikeyan,
and think we have established and discussed these points. Let us not
belabor that point.

On Thu, Jul 30, 2020, 12:25 PM Lee Hambley <lee.hambley@gmail.com> wrote:

Please don't feign offense, you were on Twitter earlier trying to cause
controversy https://twitter.com/karthik_ak/status/1288789360712847361

We offered good-faith arguments here taking the time to answer your
questions.

Lee Hambley
http://lee.hambley.name/
+49 (0) 170 298 5667

On Thu, 30 Jul 2020 at 19:22, Karthikeyan A K <mindaslab@protonmail.com> >>> wrote:

Okay. I am not an expert, and I do have lot of ignorance. Time and
future will decide stuff. Let's wait and watch.

I am sorry to have offended you people. I am from a country where we
are encouraged to speak our mind out.

- Karthikeyan A K

Sent with ProtonMail <https://protonmail.com> Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, July 30, 2020 10:12 PM, Brandon Weaver < >>>> keystonelemur@gmail.com> wrote:

Hey! I'm one of the editors of that post, and I work with Soutaro.

Karthikeyan: I have seen your tweet on this, and would encourage you
again as I did on that tweet to engage in a more constructive dialogue.
Saying "Ruby will suck now
<https://twitter.com/karthik_ak/status/1288789360712847361&gt;&quot; is not
constructive.

Those who know me know that I do not always agree with decisions made
by core Ruby committers, and I will write about them on occasion. I've done
so several times with one of the most substantial ones being the
pipeline operator
<https://dev.to/baweaver/ruby-2-7-the-pipeline-operator-1b2d&gt;\.

I am not here to convince you, merely to explain and clarify a few
factors mentioned.

> "Looks like most people do not like to add typing in Ruby"

I would encourage you not to speak for "most people" as that may not be
accurate. This would be very hard to quantify, and I have seen people in
both camps on this matter.

> "I strongly feel Ruby should be a language for humans and not
language for corporate's"

Square, Stripe, and Shopify are not exactly large corporations.
Supposing we ignore that, the implication here is that RBS is a standard
that will be forced down people's throats. This is not accurate. RBS is,
and always will be, optional. If you don't like it you are not required to
use it. Framing it as such is not in the best interest of discussion.

> " It's big companies that want these typing"

Again, I would encourage you not to try and speak for audiences you do
not represent. Big companies are not the only ones who are interested in
these features, and presenting it as such is dishonest and disenfranchises
smaller companies which may also have legitimate interest in these features.

> "At the same time it will be great if Ruby can learn to add types
automatically. Lets say I have a function add(a, b), on running it lot of
times, Ruby can infer that most of the time a and b are Number, and hence
it can keep a meta data of this thing it learned in a file in the same
project folder. This way we can have faster Ruby with less programmer
frustration. May be we can use test file that tests these programs (during
TDD) to add types."

This is the intention of RBS, and exactly what most of the tooling
around it is intended to do. RBS files are automatically generated by Ruby
via inference for the most part into a separate folder. Steep builds upon
this to add those tests to ensure these items are accurate. Matz and the
ruby contributors spend a lot of time working on exactly this type of
functionality, and in doing so have made a very transparent system that
does not interfere with programmers explicitly except in the rare cases
where they want to be more specific in their type definitions.

----

Now then, as far as the rest of the email. Dynamic and duck typing are
both supported through interfaces, union, and product types. YARDoc
<https://yardoc.org/&gt; is a current annotation and documentation system
that many Rubyists use, and there are tools that exist
<https://github.com/AaronC81/sord&gt; to convert them to RBI/Sorbet. I've chatted
with the author
<https://twitter.com/keystonelemur/status/1288850551938195464&gt; of the
tool briefly about doing this for RBS so we can approach a unified standard.

In any case we're always seeking to improve things and learn, just
wanted to set some of the record straight on what's going on. We've also
posted some updates to the article for clarifications that should be coming
up soon.

If you have any questions or otherwise feel free to ask either here or
on Twitter (@keystonelemur)

- Brandon

On Thu, Jul 30, 2020 at 11:05 AM Peter Hickman < >>>> peterhickman386@googlemail.com> wrote:

On Thu, 30 Jul 2020 at 16:57, Gerard Fowley <gerard.fowley@iqeo.net> >>>>> wrote:

I suspect we will see some library developers pedantically specifying
overly complex specific types (classes of objects) at their boundaries,
causing application developers to have to use those types in their code or
pay performance penalties for conversion/translation.

Some of our apps already have this sort of problem. One library
returns hash keys as strings, another symbols. We have to manually
convert the output of one to the other so that they can interoperate. This
can be a frustrating source of errors if not handled correctly. Seems like
a type system could make this worse

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org
?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org
?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org
?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

[Brandon_Weaver1 (Brandon Weaver)]

Yep, I've used Crystal in the past for a few side projects as well as
several other languages. I believe I still have a copy of the Pragmatic
Programmers book on Crystal I need to read more of. Never met a language I
didn't learn a few things from, and always fun to see what's coming out

I will caveat and say I had no hand in defining the RBS language but I do
critique it and try to improve documentation as I see it. I'm not formally
on Ruby as a core committer whereas Soutaro is. I will see about actively
investing in this in the future and budgeting time for it, and one of my
first goals would be to write more about these topics openly and continue
work with the Sord maintainers to enable RBS generation from YARDoc.

I've also used and am fond of the work Sorbet does, one of the core
contributors is a good friend of mine and I try to talk to them where
possible. I even made a cute little Sorbet lemur in one of the early
articles about Sorbet
<https://dev.to/baweaver/a-scoop-of-sorbet-first-impressions-f30&gt;\. Granted
I don't like sig{stuff} vs sig { stuff } but we each have our preferences.

Ruby grows through community, discussion, and hammering out difficult
topics. In that spirit feel free to bring up concerns any time on Twitter
or via this email, I want to make sure they're addressed.

···

On Thu, Jul 30, 2020 at 1:30 PM Sean Felipe Wolfe <ether.joe@gmail.com> wrote:

The Crystal programing language is inspired by Ruby and has a well
developed type system. Check it out for some more perspective.

#minaswan

On Thu, Jul 30, 2020, 10:58 AM Lee Hambley <lee.hambley@gmail.com> wrote:

Thanks for your work on this Brandon, I found the notes you added here
about the breadth of capabilities in the type system, and the symmetry with
YARD very useful, I hadn't realized quite how "ruby-like" it was, I think
it's a very faithful extension of the language.

Regards,

Lee Hambley
http://lee.hambley.name/
+49 (0) 170 298 5667

On Thu, 30 Jul 2020 at 19:50, Brandon Weaver <keystonelemur@gmail.com> >> wrote:

I appreciate people speaking their mind, I would just encourage civility
when doing so. We've addressed this, so let's drop discussion on those
points and focus instead on the technical.

I do not want to turn this entire chain into an attack on Karthikeyan,
and think we have established and discussed these points. Let us not
belabor that point.

On Thu, Jul 30, 2020, 12:25 PM Lee Hambley <lee.hambley@gmail.com> >>> wrote:

Please don't feign offense, you were on Twitter earlier trying to cause
controversy https://twitter.com/karthik_ak/status/1288789360712847361

We offered good-faith arguments here taking the time to answer your
questions.

Lee Hambley
http://lee.hambley.name/
+49 (0) 170 298 5667

On Thu, 30 Jul 2020 at 19:22, Karthikeyan A K <mindaslab@protonmail.com> >>>> wrote:

Okay. I am not an expert, and I do have lot of ignorance. Time and
future will decide stuff. Let's wait and watch.

I am sorry to have offended you people. I am from a country where we
are encouraged to speak our mind out.

- Karthikeyan A K

Sent with ProtonMail <https://protonmail.com> Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, July 30, 2020 10:12 PM, Brandon Weaver < >>>>> keystonelemur@gmail.com> wrote:

Hey! I'm one of the editors of that post, and I work with Soutaro.

Karthikeyan: I have seen your tweet on this, and would encourage you
again as I did on that tweet to engage in a more constructive dialogue.
Saying "Ruby will suck now
<https://twitter.com/karthik_ak/status/1288789360712847361&gt;&quot; is not
constructive.

Those who know me know that I do not always agree with decisions made
by core Ruby committers, and I will write about them on occasion. I've done
so several times with one of the most substantial ones being the
pipeline operator
<https://dev.to/baweaver/ruby-2-7-the-pipeline-operator-1b2d&gt;\.

I am not here to convince you, merely to explain and clarify a few
factors mentioned.

> "Looks like most people do not like to add typing in Ruby"

I would encourage you not to speak for "most people" as that may not
be accurate. This would be very hard to quantify, and I have seen people in
both camps on this matter.

> "I strongly feel Ruby should be a language for humans and not
language for corporate's"

Square, Stripe, and Shopify are not exactly large corporations.
Supposing we ignore that, the implication here is that RBS is a standard
that will be forced down people's throats. This is not accurate. RBS is,
and always will be, optional. If you don't like it you are not required to
use it. Framing it as such is not in the best interest of discussion.

> " It's big companies that want these typing"

Again, I would encourage you not to try and speak for audiences you do
not represent. Big companies are not the only ones who are interested in
these features, and presenting it as such is dishonest and disenfranchises
smaller companies which may also have legitimate interest in these features.

> "At the same time it will be great if Ruby can learn to add types
automatically. Lets say I have a function add(a, b), on running it lot of
times, Ruby can infer that most of the time a and b are Number, and hence
it can keep a meta data of this thing it learned in a file in the same
project folder. This way we can have faster Ruby with less programmer
frustration. May be we can use test file that tests these programs (during
TDD) to add types."

This is the intention of RBS, and exactly what most of the tooling
around it is intended to do. RBS files are automatically generated by Ruby
via inference for the most part into a separate folder. Steep builds upon
this to add those tests to ensure these items are accurate. Matz and the
ruby contributors spend a lot of time working on exactly this type of
functionality, and in doing so have made a very transparent system that
does not interfere with programmers explicitly except in the rare cases
where they want to be more specific in their type definitions.

----

Now then, as far as the rest of the email. Dynamic and duck typing are
both supported through interfaces, union, and product types. YARDoc
<https://yardoc.org/&gt; is a current annotation and documentation
system that many Rubyists use, and there are tools that exist
<https://github.com/AaronC81/sord&gt; to convert them to RBI/Sorbet.
I've chatted with the author
<https://twitter.com/keystonelemur/status/1288850551938195464&gt; of the
tool briefly about doing this for RBS so we can approach a unified standard.

In any case we're always seeking to improve things and learn, just
wanted to set some of the record straight on what's going on. We've also
posted some updates to the article for clarifications that should be coming
up soon.

If you have any questions or otherwise feel free to ask either here or
on Twitter (@keystonelemur)

- Brandon

On Thu, Jul 30, 2020 at 11:05 AM Peter Hickman < >>>>> peterhickman386@googlemail.com> wrote:

On Thu, 30 Jul 2020 at 16:57, Gerard Fowley <gerard.fowley@iqeo.net> >>>>>> wrote:

I suspect we will see some library developers pedantically
specifying overly complex specific types (classes of objects) at their
boundaries, causing application developers to have to use those types in
their code or pay performance penalties for conversion/translation.

Some of our apps already have this sort of problem. One library
returns hash keys as strings, another symbols. We have to manually
convert the output of one to the other so that they can interoperate. This
can be a frustrating source of errors if not handled correctly. Seems like
a type system could make this worse

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org
?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org
?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org
?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org
?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

[Sean_Felipe_Wolfe]

Here's a pretty interesting podcast, some of you probably have heard it
before ~~

Chicago Crystal

Chicago Crystal group.

···

On Thu, Jul 30, 2020, 11:40 AM Brandon Weaver <keystonelemur@gmail.com> wrote:

Yep, I've used Crystal in the past for a few side projects as well as
several other languages. I believe I still have a copy of the Pragmatic
Programmers book on Crystal I need to read more of. Never met a language I
didn't learn a few things from, and always fun to see what's coming out

I will caveat and say I had no hand in defining the RBS language but I do
critique it and try to improve documentation as I see it. I'm not formally
on Ruby as a core committer whereas Soutaro is. I will see about actively
investing in this in the future and budgeting time for it, and one of my
first goals would be to write more about these topics openly and continue
work with the Sord maintainers to enable RBS generation from YARDoc.

I've also used and am fond of the work Sorbet does, one of the core
contributors is a good friend of mine and I try to talk to them where
possible. I even made a cute little Sorbet lemur in one of the early
articles about Sorbet
<https://dev.to/baweaver/a-scoop-of-sorbet-first-impressions-f30&gt;\.
Granted I don't like sig{stuff} vs sig { stuff } but we each have our
preferences.

Ruby grows through community, discussion, and hammering out difficult
topics. In that spirit feel free to bring up concerns any time on Twitter
or via this email, I want to make sure they're addressed.

On Thu, Jul 30, 2020 at 1:30 PM Sean Felipe Wolfe <ether.joe@gmail.com> > wrote:

The Crystal programing language is inspired by Ruby and has a well
developed type system. Check it out for some more perspective.

#minaswan

On Thu, Jul 30, 2020, 10:58 AM Lee Hambley <lee.hambley@gmail.com> wrote:

Thanks for your work on this Brandon, I found the notes you added here
about the breadth of capabilities in the type system, and the symmetry with
YARD very useful, I hadn't realized quite how "ruby-like" it was, I think
it's a very faithful extension of the language.

Regards,

Lee Hambley
http://lee.hambley.name/
+49 (0) 170 298 5667

On Thu, 30 Jul 2020 at 19:50, Brandon Weaver <keystonelemur@gmail.com> >>> wrote:

I appreciate people speaking their mind, I would just encourage
civility when doing so. We've addressed this, so let's drop discussion on
those points and focus instead on the technical.

I do not want to turn this entire chain into an attack on Karthikeyan,
and think we have established and discussed these points. Let us not
belabor that point.

On Thu, Jul 30, 2020, 12:25 PM Lee Hambley <lee.hambley@gmail.com> >>>> wrote:

Please don't feign offense, you were on Twitter earlier trying to
cause controversy
https://twitter.com/karthik_ak/status/1288789360712847361

We offered good-faith arguments here taking the time to answer your
questions.

Lee Hambley
http://lee.hambley.name/
+49 (0) 170 298 5667

On Thu, 30 Jul 2020 at 19:22, Karthikeyan A K < >>>>> mindaslab@protonmail.com> wrote:

Okay. I am not an expert, and I do have lot of ignorance. Time and
future will decide stuff. Let's wait and watch.

I am sorry to have offended you people. I am from a country where we
are encouraged to speak our mind out.

- Karthikeyan A K

Sent with ProtonMail <https://protonmail.com> Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, July 30, 2020 10:12 PM, Brandon Weaver < >>>>>> keystonelemur@gmail.com> wrote:

Hey! I'm one of the editors of that post, and I work with Soutaro.

Karthikeyan: I have seen your tweet on this, and would encourage you
again as I did on that tweet to engage in a more constructive dialogue.
Saying "Ruby will suck now
<https://twitter.com/karthik_ak/status/1288789360712847361&gt;&quot; is not
constructive.

Those who know me know that I do not always agree with decisions made
by core Ruby committers, and I will write about them on occasion. I've done
so several times with one of the most substantial ones being the
pipeline operator
<https://dev.to/baweaver/ruby-2-7-the-pipeline-operator-1b2d&gt;\.

I am not here to convince you, merely to explain and clarify a few
factors mentioned.

> "Looks like most people do not like to add typing in Ruby"

I would encourage you not to speak for "most people" as that may not
be accurate. This would be very hard to quantify, and I have seen people in
both camps on this matter.

> "I strongly feel Ruby should be a language for humans and not
language for corporate's"

Square, Stripe, and Shopify are not exactly large corporations.
Supposing we ignore that, the implication here is that RBS is a standard
that will be forced down people's throats. This is not accurate. RBS is,
and always will be, optional. If you don't like it you are not required to
use it. Framing it as such is not in the best interest of discussion.

> " It's big companies that want these typing"

Again, I would encourage you not to try and speak for audiences you
do not represent. Big companies are not the only ones who are interested in
these features, and presenting it as such is dishonest and disenfranchises
smaller companies which may also have legitimate interest in these features.

> "At the same time it will be great if Ruby can learn to add types
automatically. Lets say I have a function add(a, b), on running it lot of
times, Ruby can infer that most of the time a and b are Number, and hence
it can keep a meta data of this thing it learned in a file in the same
project folder. This way we can have faster Ruby with less programmer
frustration. May be we can use test file that tests these programs (during
TDD) to add types."

This is the intention of RBS, and exactly what most of the tooling
around it is intended to do. RBS files are automatically generated by Ruby
via inference for the most part into a separate folder. Steep builds upon
this to add those tests to ensure these items are accurate. Matz and the
ruby contributors spend a lot of time working on exactly this type of
functionality, and in doing so have made a very transparent system that
does not interfere with programmers explicitly except in the rare cases
where they want to be more specific in their type definitions.

----

Now then, as far as the rest of the email. Dynamic and duck typing
are both supported through interfaces, union, and product types.
YARDoc <https://yardoc.org/&gt; is a current annotation and
documentation system that many Rubyists use, and there are tools
that exist <https://github.com/AaronC81/sord&gt; to convert them to
RBI/Sorbet. I've chatted with the author
<https://twitter.com/keystonelemur/status/1288850551938195464&gt; of
the tool briefly about doing this for RBS so we can approach a unified
standard.

In any case we're always seeking to improve things and learn, just
wanted to set some of the record straight on what's going on. We've also
posted some updates to the article for clarifications that should be coming
up soon.

If you have any questions or otherwise feel free to ask either here
or on Twitter (@keystonelemur)

- Brandon

On Thu, Jul 30, 2020 at 11:05 AM Peter Hickman < >>>>>> peterhickman386@googlemail.com> wrote:

On Thu, 30 Jul 2020 at 16:57, Gerard Fowley <gerard.fowley@iqeo.net> >>>>>>> wrote:

I suspect we will see some library developers pedantically
specifying overly complex specific types (classes of objects) at their
boundaries, causing application developers to have to use those types in
their code or pay performance penalties for conversion/translation.

Some of our apps already have this sort of problem. One library
returns hash keys as strings, another symbols. We have to manually
convert the output of one to the other so that they can interoperate. This
can be a frustrating source of errors if not handled correctly. Seems like
a type system could make this worse

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org
?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org
?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org
?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org
?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org
?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

[Martin_DeMello]

I may be biased because my day job involves writing a static type checker
for python, but I'm really excited to see type annotations coming to ruby.
The fact is that even most dynamic-language code is, for want of a better
word, singly typed - functions expect every argument to have a certain
type, and likewise return a certain type. Furthermore, even when you have
function parameters that can accept objects of several types, it is usually
a fixed set of types (which can be expressed as a union), and there is very
often explicit branching code within the function body that checks the
object's type and then does something with it.

Type annotations serve two purposes - they let static analysis tools help
verify that you are passing objects around correctly, but also they offer a
very convenient and compact way to document your function signatures, and
make reading and working with an unfamiliar codebase a lot easier. I
definitely prefer reading type annotated python code myself. (There was
also Ashley Yakely's great quip that "every sufficiently well-documented
lisp program contains an ML program in the comments")

Now, do the type annotations interfere with ruby's duck-typed nature? No,
for several reasons. The most obvious one is that the language itself
neither mandates nor enforces them - you can treat them as pure
documentation, or ignore them altogether. But assuming you want to opt in
for all the benefits they provide, and run the type checker over your code,
is there anything you can't do? The answer, again, is no - there are
several escape hatches for more duck typed code, including

- Union types: If a parameter can take any of a fixed set of types, you can
just type it as a union. The type checker can then do control flow analysis
to see if some code branches narrow the union to a single type, and if not
it checks that any method calls on the variable are compatible with all its
types. For example

def f(x: A|B)
  case x
    when A
      # x is of type A in here

- Subclassing: This is a standard method for polymorphism in statically
typed OOP languages, and ruby of course supports it

- Interface types: Also called 'protocols' in some languages. This is a
formalisation of "duck typing" - you specify the methods that your argument
must support, and give that set of methods a name. There's an example in
the blog post.

- The Any type: Any is a type that simply specifies that the argument can
be anything. The type checker won't complain about any method you might
want to call on it.

Again, I want to emphasise that your code *already uses these typing
concepts*, it just does so implicitly without any good way to communicate
that to the reader. Now there is a good way.

martin

···

On Thu, Jul 30, 2020 at 7:38 AM Karthikeyan A K <mindaslab@protonmail.com> wrote:

Hello All,

I came across this link
The State of Ruby 3 Typing and it
worried me a lot, I saw what people said on twitter and I was not alone.
Looks like most people do not like to add typing in Ruby. Yes I do realize
the benefits we might get like faster programs and so on but....

I strongly feel Ruby should be a language for humans and not language for
corporate's. It's big companies that want these typing. At the same time it
will be great if Ruby can learn to add types automatically. Lets say I have
a function add(a, b), on running it lot of times, Ruby can infer that most
of the time a and b are Number, and hence it can keep a meta data of this
thing it learned in a file in the same project folder. This way we can have
faster Ruby with less programmer frustration. May be we can use test file
that tests these programs (during TDD) to add types.

I am not an language expert, but I Love Ruby, I just want it to be the
best language for programming (for humans). What do you think about it?

- Karthikeyan A K

Sent with ProtonMail Secure Email.

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;