God, I have been trying to recall the name of this talk for ages! Thank you so much, it is a great recommendation

I’m not sure I get your point about about intent. Isn’t the same already true of, say, compilers? There are compiler bugs that we have to work around, there are programs that seem logical to us but the compiler won’t accept, and so on. Still, everybody seems to be mostly happy to file a compiler bug or a feature request, and live with a workaround for the present. Seems like it works well enough in practice.

I understand your concern about introducing a new format but it sounds like a case of worse-is-better. Sure, we get a lot of convenience from the ubiquity of text, but it would nevertheless be sad if we were stuck with it for the next two centuries.

Yeah, it’s obviously wasteful and limiting. Why do you think we are still stuck with text? Is it just sheer inertia and incrementalism, or does text really offer advantages that are challenging to recreate with other formats?

Python has a standard library module for parsing Python code into an AST and modifying the AST, but I don’t know of any Python tools that actually use it. I’m sure some of them do, though.

Lisp, in fact. Smalltalk lives in an image, Lisp lives in the real world. ;)

Besides, Lisp already is the AST. Smalltalk has too much sugar, which is a pain in the AST.

Possibly, but I’m only talking about a single aspect of it: being able to analyse and manipulate the code in more powerful ways than afforded by plain text. I think that’s equally possible for FP languages.

To be clear, you can absolutely render a file that doesn’t have elastic tabstops as if it did. The way a file is rendered has nothing to do with the actual text in the file.

It’s like you’re suggesting that you can’t render a file containing a ton of numbers as a 3D scene in a game engine. That would be just wrong.

Regardless, my point is specifically that this elastic tabstops thing is not necessary and hurts code readability more than it helps.

The pefantics of clarifying between tabs and tabstops is a silly thing as well. Context gives more than enough information to know which one is being talked about.

It sounds like this concept is creating more problems than it solves, and is causing your editor to solve problems that only exist in the seveloper’s imagination. It’s not “KISS” at all, quite the opposite.

An “unkind” flag seems like a good idea, and makes more sense to me than “unkind” as a reason for downvoting.

How about just calmly replacing it yourself the next day? Surely no one sets things up so a single drive failure is an emergency. Or a single entire machine, for that matter.

I’ll say that “Typing Ruby” is probably a pretty difficult endeavor. I come at this from a lot of strongly typed programming experience, significant experience with gradually-typed systems, and the experience of having written a few type systems. On top of that all, I used to use Ruby in anger quite a lot a long while ago. That said, I haven’t tried to actually write a type system for Ruby, so what follows is speculation.

There are at least two technical challenges. Broadly, applying types to dynamic languages refines them and adds more information. The complexity curve of this new information can be quite high since it’ll be describing a system that was designed outside of the influence of the refinement.

Firstly, this will make inference a really, really tricky proposition. Inference is very delicate in type systems and can go from complete-and-easy to completely inoperable in a flash. Annotation of methods and procs is a good first step—it sidesteps the need for inference by demanding that the programmer provides intent—but a practical type system will allow you to elide these types at least some of the time.

Secondly, there will be a tradeoff between complexity of the type language and the set of features which can be given types both at all and in practice. Since rising complexity makes the type system harder to use and breaks inference even more this will probably instead be interpreted at the cost of loss of Ruby features.

Both of these technical challenges apply pretty much only if your goal is to build a New Ruby With Types and are willing to lose the entire Ruby community and existing codebase. If that’s not your goal then you additionally need to handle code which is untyped alongside code which isn’t. There are roughly two approaches here that I know of:

• Give all untyped code the any type and be forced into doing manual value-shape checks at the boundaries between typed and untyped code (a la Typescript)
• Do the above semi-automatically by extending a contract system into the untyped fragment of the language (a la Typed Scheme)

You’ll also run into the question of “Can we give types to existing code?” which again you can follow Typescript’s lead here, but note that this is extra burden on either the community or the original maintainer and it gets a little dicey.

Finally, after all that we can scratch the surface a little bit of interesting Ruby features which would be difficult to typecheck. Assuming we don’t have a dependently typed system (which is a good assumption since those are still heavy research subjects) you’ve already struck the motherlode in naming Ruby’s runtime metaprogramming features. The easiest target is “eval”. This is pretty much right out. With dependent types we could add a new function “check” which, given a runtime type representation that reflects its compile-time type could link up a successful checking process with an option to evaluate the expression into that type… but let’s leave that for now.

Idiomatic Ruby makes heavy use of method_missing. There are worse offenders used popularly, but this one is simple to analyze and crushingly difficult to type. Let’s just leave on the table its relationship to respond_to? which allows even more dynamic use of the functionality (and room for error when respond_to? and method_missing don’t align). Under the presence of method_missing the fragment

x.method arg1, arg2, arg2

can take essentially any type whatsoever. It also provides zero information about what the types of arg1, arg2, and arg3 are. We can special case this to first infer x’s type and then read out its known methods via its class hierarchy so that at least if a known method exists we can easily do the right thing statically, but the level of runtime shenanigans available to change the type of x.method when method_missing is in use is extreme.

A sophisticated type language could constrain method_missing at least some of the time by constraining what sort of overloaded methods are allowed to exist, but this is (a) restricting its power to the point that it’s really almost completely defunct and (b) breaking most idiomatic use-cases of method_missing.

You could make it so that method_missing just accepts any types and returns an any type, but again this breaks inference since you often will want method calls to put constraints on their arguments so that type information can “flow backwards” and, additionally, it will force manual runtime type guards in places which are normally elided. The common practice is to just “know” that method_missing calls have certain behaviors without any static description amenable to the language.

So, where does this leave things? Really, there are a lot of great examples of type systems which are sufficiently rich and generic to make meaningful dents in dynamic languages today: Typed Scheme, Typescript, and Flow come immediately to mind. Additionally, Erlang’s Dialyzer should be studied although it tries to do a slightly different thing. All of them (except Dialyzer) face really enormous difficulties though in that they splinter the community. Javascript programmers are not immediately Typescript programmers, although Typescript programmers do sometimes get the opportunity to reuse some Javascript code.

These examples are probably the best leaders for any Typed Ruby exploration. They also set the limits for what people have figured out how to do with respect to gradual type systems in practice.

I’m sorry if that sounded condescending, it wasn’t my intention.

Notice the way that Haskell’s eval works

• It constrains the return type with a Typeable constraint meaning that we have access to runtime type representatives
• It can fail Maybe
• The IO is incidental to Haskell’s pure nature—an impure language won’t suffer too much here

Typeable and Maybe here are providing the structure for what’s known as a type safe cast. You can think of eval as working in stages:

• stage1 :: String -> IO (Maybe Dynamic) (see https://hackage.haskell.org/package/base-4.9.1.0/docs/Data-Dynamic.html)
• stage2 :: Typeable a => Dynamic -> Maybe a

Here, Dynamic represents a value which can take any type whatsoever—the specific type information is not known at compile time, but it’s guaranteed that Dynamic values will be stored alongside runtime type representations which match their actual type. Stage 2 is the type-safe cast (and actually already has a definition as Data.Dynamic.fromDynamic).

Stage 1 is just a hook into the Haskell compiler. It typechecks the code and if that check succeeds produces a runtime representation of the result type. It runs the code fragment and obtains the result and then packages that result up with its runtime type information into a Dynamic value.

Stage 2 is a trick. Since a is left generic, it’s up to the caller of stage2 (and ultimately eval) to pick what a they want. In effect, it’s a guess by the user of eval as to what the return type of their fragment will be. We use Typeable to obtain a runtime type representation of the caller’s “guessed” type and then compare that representation with the type we inferred/checked in stage1. If they match then we coerce the result into the “guessed” type and things are OK. If they don’t match, we fail and return Nothing.

Really, the stages probably ought to be mixed so that if the caller guesses the wrong type then perhaps the string fragment shouldn’t be run at all.

Finally, as the docs note, there is a limit to how much this guess-and-check game can be played with real code in that the eval’d fragment more-or-less has to be monomorphic.

Also worth noting is the unsafeEval variant there. As always in Haskell, unsafe means really, really unsafe and requires that the user is carefully checking invariants. It is equivalent to a call to unsafeCoerce and can be used to break type invariants in a completely arbitrary fashion. It also doesn’t provide much more power than normal eval.

article updated. thanks for pointing it out!