There is something similar (but more powerful) for Smalltalk, it collects the types as you run the code and then it is used to improve the refactors.
Check it out. https://github.com/hernanwilkinson/LiveTyping
Types will be part of Ruby 3 stdlib source
161–170 of 216 posts
Re: Types will be part of Ruby 3 stdlib source
#162Earlier quoted context omitted.
There's nothing lost by putting the sig in a companion file and leaving it to your editor/IDE to provide a popup. Java 10 and 11 introduced real type inference, at least for local variables and function parameters.
> There's nothing lost by putting the sig in a companion file and leaving it to your editor/IDE to provide a popup. I don't want to go back to having to keep C header file in sync. Your IDE can hide that information from your as well, if you don't want to see it all the time.
It's been a while since I wrote Ocaml, but IIRC the compiler yells at you if your mli files are out-of-date, for whatever that's worth. So keeping them synced isn't really an issue.
Re: Types will be part of Ruby 3 stdlib source
#163Earlier quoted context omitted.
As a user of Homebrew, I just wonder if Ruby's ever going to have performance.
homebrew's performance is mostly network (git / http / https) and compilation times when needed. 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.
Does homebrew still download sources and compile them? I thought it moved to only downloading binaries.
Re: Types will be part of Ruby 3 stdlib source
#164Earlier quoted context omitted.
I get what you mean, but dynamic typing is a feature, just like static typing is. Some languages are better from a static POV, and offer some auto features. Some languages are better from a dynamic POV and offer some hinting feature. You don't want to type your code to do data exploration and analysis, but you may want to extend the original project later to something bigger and move on to types. There is no such thi…
> There is no such thing as the perfect language for everything anyway. People tend to forget this all to easily. For example most of the static type discussions for the past 10 years have taken place on a website built in a dynamic programming language, I'm talking about http://lambda-the-ultimate.org/ which afaik is built in Drupal (i.e. PHP).
To elaborate, I think people don't care what medium they have their discussions in as long as it works.
Are you not going to use StackOverflow because it is written in C# using Microsoft servers instead of Go on Linux?
Did you not use Twitter originally because it was built on Rails?
10 years ago... what CMS was popular in a static typed language? Hell today... what statically typed CMS is popular?
But if that still matters to someone, PHP now supports types!
Re: Types will be part of Ruby 3 stdlib source
#165Great for Ruby (OP was arguably the most important compiler dev behind Martin Odersky on the Dotty/Scala 3 project), types for the win.
Re: Types will be part of Ruby 3 stdlib source
#166Very cool! I didn't think this would happen, as Matz has expressed disinterest in adding type annotations. However, keeping an open mind and reconsidering one's positions are the hallmarks of a great leader :D I worked on a summer project to add type annotations to Ruby. Didn't get very far since I ran into some challenges with the internals of the parser and the parser library, Ripper. I'm extremely interested in se…
What is the rationale of adding types to a language that will still retain all performance penalties from the need to have dynamic typing code to interact with non-typed data?
Optimizing is possible even in those cases. A JIT usually runs a function hundreds of times to collect type data before attempting to optimize the function. Types can be used to pre-fill that type data. The JIT can then optimize immediately, but still bailout if the wrong types show up in the future. I wouldn't think such an approach would yield huge benefits overall (the most used code will be optimizing pretty quickly anyway), but on server apps, it could speed up edge-case behaviors a bit.
Another feature of even optional types is creating uniformity to allow JIT optimization. A great real-world example of this is Typescript or ReasonML. It's converted to JS, but still winds up faster on average. The JS JITs have multiple tiers of optimization. Changing data types and function signatures are the biggest performance killers. If you can ensure a list is always strings or numbers, then the optimizer can reach the top tier of optimization. When lots of people work together on untyped languages, there tend to be small changes in the signatures and structures that drop you out of that top optimization level. Even partial types are useful for preventing this.
Related to that is the potential for runtime type warnings. Even though the types aren't used by the JIT, it should be possible to give a warning message if the received types don't match up. That could be a huge assistance in finding where a bug is located.
Re: Types will be part of Ruby 3 stdlib source
#167FYI: You can add the missing Bool type today :-), use the safebool library / gem - https://github.com/s6ruby/safebool
Are TrueClass/FalseClass being united under one class for 3?
Re: Types will be part of Ruby 3 stdlib source
#168I understand why PHP started to add support for type annotations as the hype around type annotations (Dart, Flow and Typescript) still was quite strong a few years ago. By now I think it is quite obvious that type annotations aren’t as helpful as initially expected and that a library approach seems more pragmatic and more powerful. See Clojure + Spec. The thing is dynamically typed languages with type annotations ten…
Types are massively helpful with JavaScript. I’ll never write untyped JS again if I can help it. Switching to typescript has done wonders for my productivity and code quality.
Tell me few .. to me types were useful for hinting in ide but vscode already gives good hints
Re: Types will be part of Ruby 3 stdlib source
#169Earlier quoted context omitted.
I honestly think that more than Matz reconsidering his own opinions, it probably turned out that having types is an instrumental thing to enable performance improvements. Keep in mind, Ruby development is headed towards a goal that the dev team has called "3x3" as in Ruby 3 aims to be three times faster than current Ruby implementation.
>it probably turned out that having types is an instrumental thing to enable performance improvements. I was disappointed to find out that adding more types in Perl6 actually slows down performance. I wonder what the differences are that adding types in one language speeds it up, while adding types in another language slows it down.
Could you elaborate on how you got to the conclusion that adding types in Perl 6 slows things down? They shouldn't, unless you create types that actually run Perl 6 code during type checking. Which is usually not the case.
Re: Types will be part of Ruby 3 stdlib source
#170Earlier quoted context omitted.
>it probably turned out that having types is an instrumental thing to enable performance improvements. I was disappointed to find out that adding more types in Perl6 actually slows down performance. I wonder what the differences are that adding types in one language speeds it up, while adding types in another language slows it down.
It depends what do the type annotations do. I'm not sure how perl6 does it, but for example in python type annotations are completely ignored at runtime, so don't have any impact. We'll see how much / for what does Ruby 3 actually want to use the type information. Sorbet on its own is unlikely to affect runtime either.
Type checking is runtime, although if the static optimizer can figure out that a certain call will never work at compile time, it will throw a compile time error.