Fork me on GitHub

Dumb question maybe, but are Alex Miller and David Miller related?


I doubt it. Miller is a pretty common name

Lennart Buit05:06:41

I find it funny that surname-choosing long ago resulted in many people choosing their profession as surname


iiuc, in some areas, these got assigned


since we’re on topic


but this is #off-topic kappa

😂 4


Daniel Hines19:06:06

I know this has probably been beaten to death elsewhere, and would be happy to be pointed to those resources, but is the dynamic typing of Clojure essential to the features it offers, or is dynamic typing more about opting out of certain complexities that static typing imposes? I really don’t know much about type theory, and almost all my functional programming experience is in Clojure, so I’m fairly ignorant on the static vs. dynamic debate from a formal perspective.


@d4hines My feeling -- having using Typed Clojure -- is that some of Clojure's idioms really do not lend themselves to static typing analysis. Nil punning, for example, makes it really hard to write type annotations that are accepted by Typed Clojure for some things.


I think when Rich unveiled transducers, there were quite a few Haskellers who tried to write articles showing transducers in Haskell with full static types but Rich had to point out that these were incomplete or incorrect implementations. I don't have links to the ensuing discussion but it seemed like transducers are almost impossible to specify complete static types for (that do anything useful)...


(and then there's a tired old argument that any dynamic language is really a static one with a single, unifying "God type" -- which is kind of a pointless approach and means you get all the baggage of static types without any of the actual benefits!)

💯 4
Daniel Hines19:06:03

So… Dynamic typing gives us transducers. Transducers are very powerful. Cool. Is that the tradeoff? Or is it deeper or more variegated than that?


currently reading, but relevant here:


discusses using Typed Clojure with transducers


also, I haven’t heard the argument that transducers require dynamic typing. is there a post about that somewhere?


sounds like it’s maybe trickier with pure FP and doesn’t have to do with static types

Daniel Hines19:06:28

I love using Clojure, but I have yet to wrap my head around transducers, and don’t think about them day-to-day. People were excited about Clojure before transducers officially came out. There have to be other features that have fueled this longstanding debate.


I think the static vs dynamic typing issue is irrelevant and unimportant, to be honest. As a developer, you general prefer one or the other, believing your preference to make you more productive.


That's why it's a near-religious debate! ¯\(ツ)

Daniel Hines19:06:29

So it comes back to “Clojure folks believe static typing’s drawbacks outweigh its benefits”. It’s not “Features X and Y are impossible with dynamic typing”.

Daniel Hines19:06:07

Mentally, I associate the REPL with dynamic typing, but some Haskeller’s told me they’ve got their own interactive development experience.


“Clojure folks believe static typing’s drawbacks outweigh its benefits” sounds like an accurate statement to me.


Yeah, that sounds right to me too.




Even there, Rich has mentioned that if you are developing systems that need proven assurances of meeting some spec, then using proof systems is a good idea. Those parts of systems just aren't necessarily a good fit for developing in Clojure.


Yeah, “Many Clojure folks” would be more accurate

Daniel Hines19:06:33

So if we could magically change the economics of working with types by reducing the drawbacks or increasing the benefits, Clojurists would at least be self-consistent in adopting static types (they wouldn’t have to sacrifice other features of Clojure they know and love, except maybe nil-punning, which is debated anyway).


non-magical methods would be greatly preferred 🙂

Daniel Hines19:06:22

I’m just trying to understand the argument in the abstract.


From a formal p.o.v. the unified God Type approach means that you can have any feature from a dynamically typed language in a "statically typed language" -- you just lose most of the benefits of static typing 🙂

Daniel Hines19:06:54

Yeah, and that’s a signal that I’m limiting myself by using a dynamic language. Which is fine - functional languages are more “limited” than imperative languages in some of the things they can express, but that turns out to be a benefit to my productivity. I just want to understand how I’m limiting myself.


Well, you lose the "safety net" of the compiler checking a lot of stuff for you. So you have to either compensate in other ways (RDD/TDD help here) or just ignore the safety net and relish the dynamic expressiveness and fast feedback 🙂


Then there are features in statically typed languages -- such as Type Classes in Haskell or Dependent Types in Idris -- that don't make sense in a dynamically typed language (they're either not needed or inexpressible or radically different).


You could also use something like Kafka in between and write the critical parts of the application statically typed and memory safe in Rust, and all the rest in Clojure.

Daniel Hines19:06:18

That makes it sound like Clojure is inherently less safe than those others. Do you think that?


I don't think Clojure itself is "inherently less safe" than any other JVM language but it depends what you mean by "safe".


Just wanted to react with what kind of safety your after. In some cases it might make a lot more sense to use proven JVM libraries then equivalent type safe rust ones that haven't been properly battle tested yet.


Clojure is at the mercy of any bugs in the JVM that impact safety/security, for example. But when most people talk about software safety, it's more about writing correct and resilient software -- which you can certainly do in a dynamic language (and, in fact, some aspects of resiliency can even be easier in a dynamic language because it can be more forgiving).

Daniel Hines19:06:14

Can you flesh that out a little more - how are dynamic languages more resilient?


Exactly in the way I said.

Daniel Hines19:06:33

How are they more forgiving? Since types exist at compile time, I’m having trouble understanding what that means.


Consider a function that accepts a hash map containing :lat and :lon and the only assumption it makes is that these both exist and are numbers of some sort. That function can accept any object that behaves like a hash map and can have any keys, as long as requesting :lat and :lon yield numeric values.


You side step any over-prescriptive constraints on those numeric types and any closedness in type systems. You're also only constrained by "map-like behavior", not a specific type with specific members.


I could give an example. I had the same program in Kotlin and Clojure, using PostgreSQL. I thought I could switch them out on the same instance. But switching from Clojure to Kotlin caused the whole program to crash because there where null in the database (which could not exist according to the Kotlin code, and did not occur using just Kotlin.


It's also easy to write code that accepts numbers or strings that can be converted to numbers (which can certainly be done in a statically typed language but then you're going to propagate union types outward from that code to all the functions that call it -- which is unnecessary overhead/complexity). That's a real use case for us when interacting with external 3rd party APIs that are supposed to return a particular type of value but can actually return other types sometimes -- and we can make a small, local change to handle that without the ripple effect that can happen in statically typed languages).


Fans of static typing will see these sorts of issues from the other side I expect 🙂


Which is a very good point. It seems like we’re solving much of the same problems, but the static type camp is approaching them from one angle, whereas the dynamic type camp is approaching them from another. Both angels present different tradeoffs.

👼 4

By the way, have you all seen the speakers list at Abstractions? Looks like there’s some pretty awesome talks being presented.

😍 4

Disclaimer: I volunteered to help review some of the submissions but I’m not on staff or anything. I just think it’s a cool conference.


Much is made out of the safety of static types, but I think those ML kind of languages bring something far more useful than safety with their type system. That is a powerful aid in designing your programs, laying out data.


Clojure take a very different path, certainly more permissive, a path i prefer, but i sometimes miss that help with design.


On that topic, in clojure, i see a trend with flattening maps, in pathom, in datomic/datascript ..we see a single map having some kind of a multiple nature, kind of a multiple inheritance. Made possible with namespaced keywords. I've been trying to push the limits on that in a library i'm making. That wouldn't be practical in a statically typed language, i wonder how this will pan out.


so for instance, instead of having a context object with a database inside, just put all those database keys and stick'em in the context object, they're all together, but still separated by their namespace, now i can use database functions on my context


is this good or bad practice ?


time will tell =)


i have this normalized tree of nodes, that's a static part, then the database and each node has a template, and a context encompassing all that, now live nodes are only meaningful with all that, so i stick it all in the live nodes which only exist while i'm visiting them. So i can now use functions from context, database, tree, template-node and nodes on these oh and node-type


now do something like it in haskell, i can imagine much lifting going on there