Dynamic types have the potential to be more than "no static types"

Runtime metaprogramming has been the raison dêtre of Ruby since Rails first took off. And, yes, you can do really cool incredibly powerful stuff with it. Likewise any Lisp with their various macro systems. CLOS in Common Lisp can also do very powerful cross-cutting metaprogramming stuff.

The key problem has been that the resulting programs are fantastically hard to understand. One of the things I think Dijkstra got right in "Goto Considered Harmful" is that humans can reason about programs better when there's a strong correspondence between the textual structure of the code and its execution structure at runtime.

Runtime metaprogramming deliberately upends that.

I think it's probably totally fine to use those kinds of features as debugging aids when hacking on a program and figuring out where stuff is going wrong. That aligns with many of the use cases Hillel lists here. But you probably don't want to commit code like that to the repo and require everyone else maintaining the program to understand it.

For better or worse, we seem to lean strongly towards languages and language features that are used not just during the development process but also make sense in committed, maintained code.

Dynamically typed languages lean in the other direction. They can be very powerful and productive while you're in the middle of working on a program, but the resulting artifact is harder for others to understand and maintain.

Dynamically typed languages to me feel like unbaked plasticine. You can have a lot of fun molding it and you can get it into the shape you want much quicker than you could carving wood or stone. But if a dozen people are collaborating on a sculpture over months or years, it's impossible to build on top of someone else's plasticine part without it shushing down and falling apart.

Or course, the holy grail is baked plasticine: a language that is dynamically typed and moldable while you're figuring stuff out and then can be baked with static types for the parts that are solid and need to be reliable. I've yet to see an optionally or gradually typed language pull that off well. The boundary between them just gets too weird.

> They [dynamic types] have potential to be more than "no static types", but that hasn't happened.

It happened thirty years ago:

https://en.wikipedia.org/wiki/The_Art_of_the_Metaobject_Prot...

But the thing that really drives me nuts about this never-ending debate is that static and dynamic are not a dichotomy. You don't have to choose one or the other. You can have both.

The real choices are:

1. Do you want the language to require the coder to provide type information (e.g. Java), or permit the coder to provide type information (e.g. Common Lisp) or forbid the coder from providing type information (e.g. early versions of Python, Javascript).

2. How much work do you want the compiler to do with regards to finding potential problems at compile-time, and what do you want it to do when it finds one? Options include: do nothing (e.g. Javascript), warn if it finds a problem (e.g. C), or forbid you to run the program if it finds one (Java, Haskell).

Personally these choices have always seemed like no-brainers to me: allow but don't require type information, and warn when the compiler finds a problem but allow the program to run anyway. What possible advantage is there to be gained from any other choice?

This post seems to conflate runtime metaprogramming (and maybe operator overloading and proxies too) with dynamic typing. You can have runtime metaprogramming, reflection, and reified types with static type systems.

I feel like Common Lisp should be considered in this article. I think it can implement the specific points mentioned, and (quote x) introduces Gödelian difficulties for type systems that even the Haskells of the world don't handle well.

It's in some sense the "most dynamic" language, because you start one instance and repeatedly mutate it. And people mainly use introspection as the main tool for finding definitions/help/etc. instead of static documentation, so you don't have a half-hearted REPL.

I'm more of a static types person myself, but CL would be what I compare them to.

First off, interesting blog. I can appreciate the author thinks that dynamic types are cool, and he/she/they like being weird and contrarian. That's cool. Me too. That said, I'd like to point out that the article focuses on dynamic runtime-metaprogramming, but (largely) fails to address it's statically-typed cousin, compile-time metaprogramming. I'd like to broaden the conversation a bit.

I'll quote the author:

> a dynamically typed language is one where types are runtime values and manipulable like all other values. It’s a short hop from there to thinking of the whole runtime environment in the same way, where everything is a runtime construct.

If you have a decent compile-time metaprogramming system paired with a statically typed/compiled language, (almost) the same statement holds true. It's not as easy to, for example, instrument a production instance with brand new code at runtime, but the mental model while programming is very similar.

> The overall picture is of going one step further than homoiconicity: instead of code as data we have programs as data.

This is the heart of what metaprogramming is all about and, to my mind, really has nothing to do with static vs dynamic types.

The author finishes with 'crushing disappointment'. I somewhat share this sentiment, though I have great hope as well; there are some incredibly talented developers working on the compile-time version of these problems. Maybe one day we'll have good languages. I guess the only thing we can do is continue writing new ones until we do ;)

> I don’t know if any of these are impossible without runtime metaprogramming, but they all seem like they’d be more difficult.

Not really? I mean it is more difficult in that you have to specify all sort of things which are left unsaid in the article's snippet, but fundamentally you just need the ability to define or override the act of "calling" an object, aka

    void operator () ()

or

    impl FnOnce<...> for <...>

Something not all statically typed languages have, but not all dynamically typed languages either (doesn't exist in javascript for instance, you can staple shit on a function object or extend Function but AFAIK the language has no callability protocol).

> I can imagine all sorts of uses for this kind of trick. Here’s some I’d like to see:

Most (though not all) of these are already better and more generally solved via introspection tooling.

> I guess the closest to the hyperprogramming model is Pharo? The dynamic code inspector is a big deal, plus there’s this fun talk.

The author should take a look at Self. It has similarities with Smalltalk systems, but is an other window into an... interesting world.

In the end, static typing is just a means for the reasoning you do in your head about why your program is correct to be checkable by the compiler. Arguably, if you’re unable to explain that reasoning to a compiler-like checker, then you shouldn’t trust your reasoning. Of course, static type systems aren’t quite there yet in practice, but that’s the ideal. And runtime metaprogramming is no different. You have some reasoning in your head why your metaprogramming code is doing the correct thing, and it should be possible to have a type/theorem checker that validates your reasoning.

So static typing vs. dynamic typing isn’t about what you can or cannot do, it’s about having a mechanism to verify the soundness of your reasoning vs. having no such mechanism.

AFAIK, there is always a separation between the program (represented by the code) and the process (the execution of the program by the machine). To “hyperprogram”, we would need to merge the two. I view the program as a space-based entity and the process as a time-based entity. How do we map time to space? Especially if it's a non-deterministic process?

Lisp macros allow us to specify multiple versions of code at compile time. And Lisp conditions allow us to redefine or discard runtime contexts. But this time-based manipulation is simpler than what you seemingly want. The easiest way I can think of is to offer an API to track the evolution of types, but I'm guessing the performance hit would be heavy.

"smug static weenies" LOL.

I really, really don't mind if people have preference for static typing. I do too - not as strong as the 2022 zeitgeist to be sure but I still have it.

What I dislike is the inference that people who prefer dynamic typing are ignorant, that they just haven't discovered hindley-milner and need to be converted.

A lot of incredibly smart, talented programmers chose (and choose) to do work with dynamically typed languages. Don't assume it was because they knew less than you.

Wait till this guy discovers Lisp, self-modifying code, or eval()! Code and data are exactly the same thing, just stuff in memory!

The problem is that infinite malleability is cool, but a lot of tasks do not benefit from it. Static typing, on the other hand, keeps you from making a lot of dumb mistakes. Static typing lets you spend time on your logic, whereas with dynamic typed languages like JS or Python, you spend time on logic AND on typos, misremembering function arguments and or positions, etc. The thing is, most routines can only really accept one or two types, and only very rarely does one want to treat data as code.

A word processor, or a sorting algorithm, or banking library have no need to modify their code; in fact, doing so is likely to break something. The sorting algorithm would benefit from polymorphism, but the others would not. You cannot render an image the same way as text. And the banking library had better be adding integers, not strings or even floats. However, all programs will benefit from the compiler saying "the function doesn't accept this type" or "this variable doesn't actually exist".

This guy should find a job maintaining a complex Python server, he'll learn why people like static types. Nothing like digging through a bunch of code to find, "ah this looks like the function I need, what does it take? Oh 'connection'. What's that?" Static typing at least forces a minimum of documentation. Or you make a change, server runs but still not fixed. Then you notice it's not even doing what it used to do, but no errors or anything. After tearing your hair out, you discover you swapped two letters in a variable, which caused a syntax error exception loading the module, which was silently discarded by the dynamic loading code.

> I encounter a lot more smug static weenies than smug dynamic weenies, so I defend dynamic typing out of spite. There have been a few cases where I was surrounded by SDWs and I immediately flipped around to being pro-static.

I find such statements incredibly daunting. Like the person is acting like a child for no other reason then to be contrarian. I'd hate to work with such a person.

My suspicion is that what makes this hard is using higher-order dynamic programming facilities. If you just stick to first-order functions with relatively simple data structures and primitive types then there's a lot of cool, interesting runtime gadgets you can put in.

But the moment you try to use the full arsenal of dynamic reflection, metaprogramming, etc. then the runtime checks and gadgetry needed to analyze all of that explodes in complexity and even if it's possible to make an analysis framework capable of analyzing it, the results might be very difficult to interpret.

So as long as you try to stick to first-order constructs as much as possible, you can get quite far.

This doesn't seem specific or particularly enabled by dynamic types?

I don't really understand it yet and have barely used it but this seems like it's supported by expression trees / Roslyn / code gen stuff in .NET/C#?

Is there a difference I'm missing here, e.g. writing some lambda and having the code generate code to run it against NoSQL or SQL or some other storage at runtime which is what I think things like LINQ2SQL do under the hood is basically equivalent right?

This type of programming seems like it can be supported by both types of types?

Fragility of the more clever dynamic typing stuff like the "Replacer" is a big problem. An even bigger problem is the increasing difficulty of composing those things together when you want more than one at a time.

And that difficulty scales up fast. Consider the Python function decorator. It was quickly discovered that the decorators need to preserve the metadata for the function's name, etc., or the decorated functions broke in places that looked at that metadata. But if you have a "function name" parameter that the decorators can modify, now there's a mismatch between the fact that the function claims to be "the original GetUser function" but it's actually the decorated function. So now you ought to have "the visible function name" and "the real function name", so for instance, the former works with metaprogramming correctly but the latter allows for correct debugging output on crashes.

But what if you decorate a decorator and then want to do metaprogramming on it? Now you're got the apparent function name, the real name of the function beneath it, and the real name of the function beneath that.

And this is just one dimension of problem. There are many others when you get to metaprogramming like this.

The core problem is really this style of metaprogramming, in my opinion. It almost inevitably slips into becoming Deception-Based Programming, in which increasing swathes of the program are trying to figure out what lies to tell to other chunks of the program to get the desired effect. Dynamic typing makes this harder because it makes it very difficult to get a manifest that lists all the behaviors this particular chunk of code or code object has, but even if you were doing this in a static language that didn't make that hard, a language would still have a problem exposing all the correct properties and assisting programmers in getting them completely correct.

It's fun at first, and very powerful at first. But deception-based programming is one of the quintessential ways a code base fails to scale and becomes an incomprehensible tangled mass, code bases that use heuristics to figure out what lies to tell to other bits of the programming to cover up the effects of the lies the other bits of the code are telling. This leads to your programming becoming an embodiment of the phrase "What a tangled web we weave, when first we practice to deceive".

That said, before someone pops up with "but we could do that without deception"... I agree! Or at least, I agree that it should be explored better. I would be interested in a language that somehow enables such metaprogramming, but with a philosophy that says that it will stay "honest" throughout, and basically deliberately eschew and exclude this sort of "transparency". I don't think it's necessarily intrinsic to the style. I just think that it's sooooo tempting that if you don't build a language that excludes it from the get go that the temptation to just shim this little behavior in just here is too tempting, plus the languages tend to end up requiring it, be it accidentally or deliberately, because they afford that behavior and the language ends up being built around how it is at least supposed to be possible. I don't know entirely what this would look like.

Edit: I say I don't know what this would look like, but I have had a couple of ideas. One I've talked about before is to have a clean separation between an "initialization" phase in which metaprogramming is legal, and a "sealing" phase in which it is all done and the metaprogramming becomes invalid/illegal. I wrote this for the runtime not to have to be super flexible all the time, but it works for programmers using the system to know that things won't change out from under them.

The other is some convenient and powerful way to dump things out in their final state post-manipulation. I've gotten some good mileage out of this in my own code that is using a lot of composition. It is very helpful to be able to take the top level of the composed object and say "Tell me what exactly you are made out of". Even if I'm not doing metaprogramming based on the response, it's a huge debugging help. I see traces and fragments of this idea here and there, but no system that has it coherently integrated in a way I'd like to see.

100% agree with this. I recently had a problem in python where dynamically generating the classes was the cleanest implementation.

What I found was basically no IDEs supported runtime generation of code for things like autocomplete. Jupyter does but it’s a limiting environment.

It made me realize this is a mostly unexplored space with little tooling

I recommend learning static typed languages first, maybe even working in a large code base. Then you will truly appreciate the ambiguity of dynamic languages and look at them less like “baby languages”.

In app code bases, there are always multiple duplicates of the same type, no one truly respects reusability partially because it’s not always practical.

With dynamic typing, you can be completely transparent and have multiple “Car” classes. It doesn’t matter because types don’t matter. To us they both represent a car, no need for converters, helpers etc. Car1 definition has some method you need for Car2? No problem, just tack it on in that scope! It’s not polluting the definition of Car2, it's not going anywhere.

What does this have to do with dynamic typing specifically? A language "where everything is a runtime construct" can only be a language where there's no phase separation between compile time and run time. So it makes just as much sense to say that everything is a compile time construct.

Soooooooo... what he's looking for and failing to find is Perl, Type::Tiny, and Moose :P

  use Moose;

  sub foo {
    ...
  }

  around foo => sub {
    say "Called with args: @_";
  }

The thing most programmers forget:

We don't spend most of our time writing generic libraries.

We don't write generic code, nor do we want to. We write code that takes specific inputs, and generates specific outputs.

So I want to use statically typed languages, maybe with a template system at MOST.

If it makes my life more difficult when I write a library, I accept that.

Source: LISP programmer for 6 years. Learned the above the hard way.

Lisp seems alive and well.

Shame that "dynamic types" is often conflated with just non-static.

My favorite "dynamic" type that is stupid useful has to be numbers in Common Lisp. (I think most all lisps, actually?) Having it widen to be as big of a number as you need it to be, while you are using it, is stupid useful.

You want something called higher-order unification. For it to work you need totality checking. What you want is dependent types. Dependent types are sensible, navigable, comprehensible, ah-what-I-wrote-last-week-is-understandable metaprogramming.

Not pytest, but for ordinary python tests I have often got them running in Jupyter for prototyping purposes, it's pretty useful.

I'm not going to pick on anyone in particular but I came to the comments with a sense of forboding that people saw the words "static" and "dynamic" and wrote stuff unrelated to TFA.

I was not disappointed. This article is complex and interesting and deserves better.

Dynamic typing can be quize useful, but sadly languages like python, IMO, lack the supporting infra, compared to, lets say, LISP.

My personal opinion has become, do I want to write leaky tests to validate typing (in addition to functional tests) or do I want to let my compiler do my type validation for me in exchange for the boiler plate on the front end with my IDE providing auto complete along the way?

As a Java programmer, you can guess where I lean. Now excuse me while this autowired annotation Dependency Injection causes a new self inflicted level of hell.

I think we've largely settled on "doing clever things is bad, actually." At least, I have.

Your code should be obvious and self-documenting. Relying on language features to do a bunch of stuff behind the scenes more often leads to programs that are hard to debug and perform badly. How many times have you had to dig into C++ operator overloading compiler errors or someone being too clever with C macros (wait, that macro can return?!?) or someone overloading a Python built-in function in surprising ways. Coming across the short double example from the article in production code would make me groan. The "all sorts of uses for this kind of trick" the author lists sound like a nightmare for some poor employee to have to reverse-engineer five years from now.

I feel modern languages (Rust, Go, Swift) have moved away from clever, implicit behavior in favor of more considered and explicit code-efficiency mechanisms. For example making error handling (? error operator in Swift & Rust) an explicit first-class citizen, rather than some clever macro hacking; or the trend away from operator overloading and complicated class structures and towards explicitly declared interfaces; or the many restrictions on Rust macros[1] to help ensure they're maintainable.

[1] https://veykril.github.io/tlborm/decl-macros/minutiae/hygien... and related sections

Honestly, I always felt a bit lost in the whole “static vs dynamic types” debate because I dislike how it’s framed. So “a language is statically typed if you know its type at compile-time”. Ok, so you have ParentClass and ChildClassA and ChildClassB that inherit from it. And you create a variable that holds objects of the type ParentClass. But do you know at compile-time whether it is ChildClassA or ChildClassB? Only if your type inference system is strong enough and your code is structured appropriately for such possibility to even exist. And do you even need to know it? Most likely not unless that one time when you do in which case you use some ugly reflection tricks and whatnot. And, bam, now your “statically typed” language actually has dynamic type checking.

And if you use a “statically typed” language, but have an algebraic type that holds int or string or ClassA or Array, how useful is that static typing? That’s why I prefer calling the code either weekly typed or strongly typed. And some languages allow you to have strongly typed code with ease, and some languages allow you to have weakly typed code with ease, and some, like TypeScript, allow you both in which case the whole dilemma seems unwarranted or at least outdated.