111–120 of 216 posts
Earlier quoted context omitted.
As a user of Homebrew, I just wonder if Ruby's ever going to have performance.
It is no worse than python, but with the 3x3 initiative the main implementation will be a lot faster than today, which will never happen to python unless the current lead will go 180 degrees against what Guido always claimed.
Eeeeeeeh…
Earlier quoted context omitted.
The parser thinks that's a block not a hash.
Right, so why not implement the sig as a block and keep the syntax concise - the Ruby Way.
We had them as hashes for a while, but it meant that code in all sigs was loaded as the code was loaded, even if runtime typechecking was disabled. We were forced to load all constants in any signature in a file, an effect which cascades quickly. It had a big impact on the dev-edit-test loop.
For example, if we're testing `method1` on `Foo`, but `method2` has a sig that references `Bar`, we'd have to load `Bar` to run a test against `method1`.
Now sigs are blocks and lazy, and we pay that load penalty the first time the method is called and a typecheck is performed.
It looks like they've conflated type with class. If so, that's the antithesis of duck typing. The impedence mismatch to Ruby seems to me an overwhelming contraindication.
Having said that as far as I understand, type support in Ruby 3 will not prescribe which type checker is used and what limitations exist. Some of the mentioned projects are structural and I think even Sorbet might add support for it at some point.
The biggest problem for me with gradual typing is code clutter. My favourite languages are Clojure and Ruby precisely because they reduce code clutter. What I would prefer, if we are to have types, is for the signatures to go in a companion file. I've never understood why types have to be inlined. A good IDE can easily provide the signature in a mouseover or something similar.
Instead of: sig {params(name: String).returns(Integer)} ... why not simply: sig {name: String, returns: Integer}
Instead of: sig {params(name: String).returns(Integer)} ... why not simply: sig [String]=>[Integer] Yes, that's just ruby - see https://github.com/s6ruby/ruby-to-michelson/blob/master/cont... for example for live running code (in secure ruby) :-)
It was a design decision that all type annotation arguments be named as opposed to positional. As one example why, it makes the error messages better. You can always say "You're missing a type declaration for parameter 'foo'" as opposed to "You have four positional arguments and 3 types".
We could probably still bikeshed our annotations inside the `sig { ... }`. I'm not sure we'd make constants with unicode like BigMap‹Address→Account› for generics, though, how do you even type that? :)
I recommend whatching "Ruby3: What's Missing?", a presentation Matz gave earlier this month: https://www.youtube.com/watch?v=cmOt9HhszCI This might be misleading. That is, jump to around the 29 minute mark where he talks about the type profiler and .rbi file stuff.
As a user of Homebrew, I just wonder if Ruby's ever going to have performance.
also for some reason homebrew really likes to updates its index all the time (I think it got tamed in the newest version), but setting HOMEBREW_NO_AUTO_UPDATE to 1 helps a lot.
Earlier quoted context omitted.
I don’t know but I hate it. Not sure if I’m in the minority but it sure feels like it. In an ideal world. I feel that types are something that should be dealt with at the IDE level. In fact, there so many things that can be done at that level, but no one has really been brave enough to do so I suppose.
I come from Assembly and C, now working in Javascript. One of the reasons I made the move to JS is dynamic typing, getting rid of that administrative pain and now being able to create stuff much faster. Even in large JS apps I hardly ever have type related bugs at all, and when I have one I fix it mostly within minutes, don't need an entirely different language and ecosystem for that. Now the JS fanboys discovered an…