baweaver

That's definitely one of the core motivations is to capture, contextually, as much of an upgrade as possible in hard code.

It's also a perniciously hard problem I'm very far from solving well quite yet.

The testing utilities are also great. The difficulty, I'd say, is inherit to working with ASTs and simplifying it is hard. They tried with Node Pattern, synvert tried with NQL, and I wanted to try with pattern matching and potentially more in-Ruby approaches.

Nothing particularly wrong with any of them, but trying to sort out what's not matching and getting an answer for now "close" a node was is a bit involved. Go far enough down that hole and you hit tree edit distance and Zhang Sha Sha algorithms.

Consider it a sandbox and a more minimal syntax around what Rubocop already does well. If anything I may try and upstream some of it later after it takes more shape.

It's also used to wrap a lot of AST tools for a talk I have next week, hence the earlier release even if it's fairly simple.

To be fair I didn't post it :)

Yeah, it's still very very early in the process and I released it as I have a talk at Ruby Kaigi going over some of how this works next Tuesday, so I wanted something out even if it's simple for now.

You know I'm friends with @bbatsov right? That's reaching pretty far. I've actively funded the maintainers in the past as well, doesn't mean I agree with everything or every name, but I respect their work.

Agreed. Currently at Square so watching some of this.

The best path forward will be a lot of discussion, especially around learnings with production codebases where possible.

Personally I prefer inline annotations, but want to explore the possibilities of both and see what comes of it. I've written on Sorbet in the past and have used it on a few toy projects.

Also working on some analysis documentation comparing the two if you'd be interested in chatting later. Feel free to DM @keystonelemur on Twitter.

That's definitely fair, and probably a large reason why they're so paranoid about repeating that.

The intention right now is for the StdLib to provide known types to build off of written in RBS. There's no requirement to use them necessarily.

Steep and Sorbet are second-level, they build off of RBS. Matz has mentioned offhandedly in conversations I'd had with him in the past that there's a ton more in store with RBS beyond just type checking, so we'll see where they go with it.

As far as YARDoc I've been eyeing that one for a while now since I first heard about Steep at a Braintree Ruby meetup before Soutaro was at Square. We're still talking about what and how as far as that one.

Yep, and glad to see the work Stripe is doing on things as well. Always enjoy seeing where you all are going.

Soutaro has been great to work with over here (Square), and he has a ton of really amazing things coming soon that we're working on OSS'ing later.

Yeah, there was a ton of discussion on this in the Ruby bugtracker and at core meetings. Matz is very sensitive to breaking the language with Ruby 3 and the core team is doing their best to ensure an easy transition.

Sorbet was written in C++ and is a great piece of work, Stripe did a great job with it. It does have some issues as soon as someone gets into the magic weeds with metaprogramming like Rails does.

Disclaimer: Working at Square, have friends at Stripe, enjoy both type checkers.

It was, and I was around during one of his discussions on that at RubyConf last year. It's a very valid concern and Matz is very sensitive to it. There are a lot of things he's joked about removing or changing but won't because of those reasons.

If you take a look at his keynote video he says quite a bit on this too.

Pretty much. Matz is very sensitive to breaking the language in any way with the Ruby 3 upgrade, which brought up the true keyword argument hard-break and [likely got that pushed back](https://discuss.rubyonrails.org/t/new-2-7-3-0-keyword-argume...).

RBS and type files on the side were really hotly debated for a while and the core team settled on this as a way to not break the existing parser among other reasons.

While I don't 100% agree with them I have faith that Matz and the team make the decisions they do based on impact and what they see in the community.

Matz had mentioned this as a key reason he was interested in working on this, as well as a "language server" with a lot of really interesting features like what JS/TS has with VS Code.

I had the good fortune to hear him talk about it at length at a conference a while ago and there's all types of fun stuff on the way.

That would be correct.

Soutaro is indeed a code member of the Ruby team, he also happens to work at Square. Soutaro is also one of the main contributors to RBS and helped define that standard.

He was going to keynote on this at RubyKaigi this year until it was cancelled, and had a talk at RubyConf as well on this.

That's correct. Sorbet currently uses RBI but after meeting with core they standardized on RBS and are migrating to present a more unified front and enable easier development of type checking libraries on top of it.

Very little of this will need to be written by hand. The underlying tech is pretty decent at guessing types, the idea is that if it's not quite specific enough you adjust it, but it should otherwise be transparent.

It is, and checkers like Steep and Sorbet can infer these types. We're currently playing with the idea of deriving from documentation like YARDoc as well.

This. RBS is the underlying language for defining type checkers. Sorbet and Steep both utilize it, and this allows future type checkers to evolve from a known-base instead of having to reinvent everything.

I was more of referring to the level of separation.

Careful on that line as some of us become programmers and are quite apt at playing both roles when needed.

In reality separation of concerns is a luxury only afforded to larger teams and orgs.

If you have the people, do it. If you don't, you're in for a bad time concerning yourself with it.

Granted the html in Java is just straight idiocy, and my point refers to far less insidious mixings.

OP Here. Had a bit of fun playing around with world theory, decided to share for kicks and giggles. More of a 'what if?' scenario than anything.

I have a slight feeling I'm likely to talk myself into a hole no matter what I say on this matter.

Yes, there are overlaps. From what experience I've had at least, their opinions are valuable to me. Not necessarily as better or worse, but as coming from a different perspective.

Having all of one type of thinking is a horrible idea. It leads to a certain amount of groupthink. The more diversity in a team, the less likely it is to happen.

You seem to be reading into it quite differently than I meant it. What I'm saying is that they think differently in some cases which can lead to more thought out code, and by result better architecture.

Granted, though it's a compounding problem. Even if they get out of College they end up with that type of hurdle.

You think that may be contributing to the issue with women in the college pipeline at all?

Interesting point. Really it seems to be something ingrained in our mentality that would take something truly significant to change.

OP here.

Which really gets me, and I mention it in another comment on site. It's probably a good portion of the reason we don't have a great deal of women in the tech industry.

They tend to have a lot more modesty on their resumes, and a nightmarishly disturbing amount of impostor syndrome dragging them down like cinder blocks. What's annoying is that without a woman on team, it legitimately feels like you're missing something.

Put simply, we think differently, and that manner of different thinking is critical to preventing some really unruly code and architectural patterns from happening. I get worried every time I see an all-male team because there's not that dissonance there to keep things more on the level.

Almost sounds like a cause for making some type of TODO tool for TMUX

TMUX is a thing. People should really be using it for this type of workflow considering you can set up environments that don't necessarily have to be running all the time for other projects. This seems far more like a self-inflicted problem than anything.

> customers don't need that kind of speed.

Sure they don't, they also don't need bluray or terabyte hdds either... Should be rephrased to 'We hope customers don't realize they can use that type of speed.'