In my thesis – using Common Lisp – I automatically defined slots for classes and methods (in simple cases) based on how the code was written.

Basically, I setup a handler around function calls such that if the system signalled an error of type “undefined function” (*) it examined the call and, if it matched some predefined patterns, it would add the slot to the class, define an accessor method (or something similar), then restart the computation at that point.

After that finished, you could go and specialize the code that was produced so that the error handling wasn’t generated and the restarts would become unnecessary. I even got it to the point where it would derive subclass relationships, and it worked on simple cases of multiple inheritence.

(*) Not exactly that since I can’t remember the precise details, but that was the gist of it.

Something like Smalltalk is enabled by dynamic typing. It would be hard (impossible?) to build a statically typed self-modifying environment because you cannot know a priori all the types of objects that will be created.

Although this may be more to do with the idea of message passing than types. You could have a static typechecker for Smalltalk, but the only interface you can expect of objects outside your control is that they can receive messages. For anything else, you have to wait until runtime to ask them.

Which brings me to a side thought… message passing-based OOP is basically the weakest of typing. This is ironic considering how modern OOP is often associated with cumbersome static typing.

Macros are hard to do well in a statically typed language. Some important Clojure macros are inherently non-typed, e.g. the threading macros -> and ->>. You can replicate this well enough with other operator chains, but there’s no type to the concept of ->, which (conceptually) takes an a0 and arguments a0 -> a1, a1 -> a2, … aN-1 -> aN and produces an aN. I suppose you could say that it has an infinite “type schema” (like axiom schemas in math) but once you’re talking about type schemas, you’ve walked away from static typing.

Live code patching is likewise hard to do if you’re faithful to a statically typed model.

You can model any dynamically typed system in a statically typed world: just use tagged union types. The issue is that the programmer still has to know a priori what types he wants to model. Quantifying over all types in the world (or, say, a subset with a specific structure) is something that dynamically typed languages do with ease.

Most things you would want to do in a dynlang, there is a way to do in a language like Haskell. It might be hard to understand, though, if you’re not used to type systems. For example, it takes quite a bit of depth in understanding to know how lens works, and lenses are largely to do something that’s easy (player[i].stats.hp += 20) in dynamic, OOP languages.

Here’s another one that’s hard to model, in full faith, in a statically typed language: dataframes (as in R or Pandas). If you model a dataframe as a [[Double]] (i.e. a matrix) then you can do that in either type regime. But, let’s say that you want statically typed dataframes. Seems like a reasonable thing to ask for. You might have a dataframe of {Name: String, EyeColor: Color, Age: Double, Height: Double} where Color is a categorical variable. You need row types, which aren’t such a big thing to ask for… but, here’s where it gets messy. Let’s say that you have a 500-column dataframe. That’s not especially unusual. Let’s also say that you have data-dependent data-cleaning passes that affect the type of each row, like “Remove any column that’s 90% missing”, and “Remove columns if any are linearly dependent”. Now, you have 2^500 different possible output types to your data cleaning. (Dependent types, here we come!) Dynamic languages handle this with ease. Statically typed languages right now don’t, unless you use types that are less descriptive than what’s possible (i.e. a matrix of Double instead of a [UserSpecifiedRowType])… but then you’re not using the full power of static typing and you have to include a bunch of extra checks (i.e. does this double correspond to a meaningful category index) to avoid those errors.

To be honest, your CoordinateAbc technique seems like really complex and error-prone structural typing…

The Twisted Python networking framework uses a “Protocol” object to serialise and deserialise messages from a byte-stream, so protocols are not tied to any particular transport.

Some protocols (SOCKS being a good example) start with a request/authorization phase, but if the authorization succeeds, the protocol switches to a transparent byte-pipe. One implementation strategy might be something like:

def dataReceived(self, data):
    if self.auth_succeeded == True:
        self.pass_through(data)
    else:
        self.parse_request(data)

Alternatively, somebody who’s read Design Patterns might create a RequestState and a PipeState, and have the Protocol object replace one with the other when authentication succeeds.

But in Python… each class instance has a magic __class__ property that tells you what class the instance is an instance of… and that property is writable. I have seen (not written, but seen) production code for a SOCKS-like protocol that, upon successful authorisation did something like:

self.__class__ = PassthroughProtocol

…to suddenly and instantly switch which class the instance belongs to. The original author had the grace to leave a big scary “here be dragons” comment above the line in question, and for the application in question it probably was the right implementation choice, but I’ve always been impressed at the audacity of that trick.

[Comment removed by author]

erlang uses it to allow runtime update of code with zero downtime. OTP has hooks for transforming the old data formats to new data formats on live systems.

The live debugging and editing capabilities of the environments below. I want that in any computer I have. That capability appears to be both a “relic of the past” and also better than anything we have today if we’re talking whole stack.

http://www.symbolics-dks.com/Genera-why-1.htm

https://www.quora.com/What-was-it-like-to-be-at-Xerox-PARC-when-Steve-Jobs-visited

I think phuby qualifies?

I want to hear more about the kinds of tricks that would be hard or impossible to replicate in static type systems

There is nothing “impossible to replicate” and what is “hard to replicate” is usually not hard in other statically typed languages and just as hard in other dynamically typed languages. For the example with subclasshook, how would you do that in Javascript? And the statically typed C++ can probably replicate your CoordinateAbc via template instantiation. I use “probably” because I’m not quite sure what you are trying to achieve in this example.

For further inspiration, I can recommend Rob Harper:

To borrow an apt description from Dana Scott, the so-called untyped (that is “dynamically typed”) languages are, in fact, unityped. Rather than have a variety of types from which to choose, there is but one!

And this is precisely what is wrong with dynamically typed languages: rather than affording the freedom to ignore types, they instead impose the bondage of restricting attention to a single type!

I don’t know that it’s all that interesting but the way parameter rewriting is done in dpdb has always pleased me.

dpdb is a simple module that abstracts away the different parameter quoting styles allowed by Python’s DB-API (as well as doing a few other things). The rewriting is done by using Python’s string interpolation, but passing dictionary-like objects from which the keys are looked up. As a side effect of lookup, the final parameter substitution is built up.

This isn’t necessarily the most interesting use, but one I’m engaged with at the moment:

We’ve got a legacy codebase that uses a data access library (let’s call it Ballcap) that tries (unsuccesfully) to wrap an ActiveRecord-style interface around a niche graph database that’s incredibly slow to fetch from and even slower to write to. Ballcap tries to mitigate this by caching data on writes and trying to read from the cache first on reads, but it’s really flakey and there are tons of subtle and non-obvious ways in which this can fail and which will trigger an inopportune read from the primary graph db. We needed a long term plan to begin refactoring away from this, while keeping our data in the graph db compatible with this squirrelly Ballcap library for the short-to-medium term.

Approach is: Define a new root data model class, the LockedObject that always reads only from the cache, and never writes to anything. When you subclass LockedObject and define attributes on that model, it internally creates a subclass of Ballcap’s Base class with the same attributes. LockedObject defines getters for the attributes, and setters that throw an exception that tell you the object is locked and you need to pass a lambda to extreme_slow_long_awkward_unlock_method that can actually do mutation (the lambda gets passed an instance of the internal Ballcap class read from the slow graph db).

You can define methods in an unlocked block on your LockedObject class to define custom methods that need to deal with mutation – these method definitions are actually performed in the context of the internal Ballcap subclass, so that you can call them in your lambdas passed to extreme_slow_long_awkward_unlock_method. The equivalent of forwardInvocations are used so that (mutating) methods defined on the internal Ballcap instance can call non-mutatng methods defined on the LockedObject transparently, and so that if you try to call a mutating Ballcap method on the LockedObject, you get a meaningful error telling you you need to unlock the object first.

It’s complicated to describe but transparent in use, and has a very small implementation – it’s really just a couple of methods to shuttle invocations around, and some run-time subclassing and method definitions.

It wins us a UI always driven off of the fast cache, and complete containment of our interactions with this crappy Ballcap DB inside extreme_slow_long_awkward_unlock_method invocations that are obvious and easy to find. We’re currently playing with moving the actual performance of the extreme_slow_long_awkward_unlock_method lambda to a background worker, and replaying the lambda onto a second, better, datastore, so that we can get a second master copy of our data completely out of Ballcap and then axe it.

The trick was implementing nice RPC wrappers by automatically creating new classes at runtime. Introspecting the endpoint for the signatures and methods gave the information needed to generate these classes.

Kind of an overlap between dynamic typing and giving classes the ability to respond to unknown methods, but used to use a Smalltalk REST/JSON library that would write your code for you as you worked. Basically, in dev mode, you would call a method that didn’t exist, and it would then generate that method as a REST call to a URL based on fixed rules, then analyze the result and create a class to represent the result, and then return it. Sample usage looked something like this:

"UserClient is a subclass of RESTClient with zero (meaningful) methods".
"First, create a client, and turn on dynamic method generation."
client := UserClient newOn: 'http://whatever.com/api'. "This would be a normal client"
"Now it'll make any methods you call that do not exist."
client beDynamic.
"Smalltalk doesn't have real namespaces, so class prefixes are used. Set one for
data classes."
client usePrefix: 'LB'.
"Okay, the next line is gonna generate a method, do a REST call, make a new
class, and return an instance of it. Ready?"
user := client userWithFirstName: 'bob' lastName: 'joe'.
"The above a) creates a method called #userWithFirstName:lastName: on
 UserClient, b) has that method issue a GET request (based om naming conventions)
with ?firstName=bob&lastName=joe, c) generated a new class called LBUser, d)
built up that class based on whatever it saw returned from that endpoint, e) gave
us an instance deserialized from the JSON. So:"
Transcript show: user firstName. "presumably prints Bob."

In production mode, calling missing methods would result in a normal doesNotUndestand (DNU) being thrown, and a JSON structure being returned that didn’t match what was expected would throw a serialization error. So in the above example, if the JSON returned lacked a firstName fields, serialization would fail.

While this is all cool, I would point out that modern tooling in static languages, such as F# Type Providers, can trivially do the same thing, and (IMHO) in a saner way.

If JavaScript objects like Array, Object or Window had their interfaces statically set by the browser, the current scheme of polyfills to provide new methods on old browsers couldn’t work so transparently.

Dynamic typing’s especially handy when you want to retrofit code designed to accept an A to take an A’ (a different implementation of the same interface as A). For example, at work we had some configuration stored as plain Python dicts and lists and needed to change a particular part of it to update itself when it’s used. We could make something that looked like a dict but updated itself without touching the code that does the reading.

There’s a whole world of different typing arrangements (mixes of static and dynamic, type inference, approaches to metaprogramming) so it’s hard to say you can’t do X with static typing. But you can say dynamic typing tends to make a lot of code generic by default, which can be handy. It does not take that much fanciness to write functional tools in Python, for instance.

Personally I really enjoy the safety and easy code navigation that tools built on static type systems provide, enough that I’d use TypeScript or other things that add checks and tooling even where there’s no run-time performance payoff. But don’t want to deny where dynamic typing comes in handy.

The web.