Fork me on GitHub
#off-topic
<
2019-06-20
>
didibus05:06:21

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

andy.fingerhut05:06:10

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

sogaiu07:06:47

iiuc, in some areas, these got assigned

borkdude11:06:36

@alexmiller but are you related to https://twitter.com/akmiller78 then? šŸ˜‰

borkdude11:06:42

since weā€™re on topic

Mno11:06:10

but this is #off-topic kappa

šŸ˜‚ 4
Mno11:06:34

:rolling_on_the_floor_laughing:

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.

āž• 4
seancorfield19:06:10

@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.

seancorfield19:06:06

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)...

seancorfield19:06:26

(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?

drone19:06:59

currently reading, but relevant here: http://blog.podsnap.com/ducers2.html

drone19:06:15

discusses using Typed Clojure with transducers

drone19:06:48

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

drone19:06:13

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.

seancorfield19:06:10

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.

seancorfield19:06:36

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.

andy.fingerhut19:06:16

ā€œClojure folks believe static typingā€™s drawbacks outweigh its benefitsā€ sounds like an accurate statement to me.

manutter5119:06:08

Yeah, that sounds right to me too.

drone19:06:40

#notallclojurefolks

andy.fingerhut19:06:45

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.

manutter5119:06:04

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).

andy.fingerhut19:06:02

non-magical methods would be greatly preferred šŸ™‚

Daniel Hines19:06:22

Iā€™m just trying to understand the argument in the abstract.

seancorfield19:06:25

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.

seancorfield19:06:22

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 šŸ™‚

seancorfield19:06:54

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).

gklijs19:06:30

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?

seancorfield19:06:14

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

gklijs19:06:19

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.

seancorfield19:06:39

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?

seancorfield19:06:32

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.

seancorfield19:06:17

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.

seancorfield19:06:23

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.

gklijs19:06:57

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.

seancorfield19:06:54

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).

seancorfield19:06:54

Fans of static typing will see these sorts of issues from the other side I expect šŸ™‚

slipset20:06:07

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
manutter5120:06:44

By the way, have you all seen the speakers list at Abstractions? Looks like thereā€™s some pretty awesome talks being presented. https://abstractions.io/sessions/

šŸ˜ 4
4
manutter5120:06:49

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.

carkh22:06:41

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.

carkh23:06:46

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

carkh23:06:36

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.

carkh23:06:05

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

carkh23:06:53

is this good or bad practice ?

carkh23:06:05

time will tell =)

carkh23:06:02

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

carkh23:06:59

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