[barrkel]

Static types limit the expressivity of your code to what the type system is able to prove. Depending on what you're trying to do, you can spend more time arguing with the type system than getting things done.

This really starts happening with a vengeance when you do increasingly lispy things, like creating dsls that move the language closer to your problem domain by writing programs that write programs.

Consider e.g. the way activerecord introspects the database schema to enrich your model declarations without further work from you.

Now there are ways to get similar effects in statically typed systems, but it's much more work, particularly if the dynamism comes from the execution environment (rather than compilation).

[ZenoArrow]

Okay, can you give me one example of a useful macro that you'd write in a dynamically typed language. I'd like to see what challenges there are recreating it in a statically-typed language.

Also, regarding activerecord, it seems you're hinting at the benefits you get from composibility, is that correct?

[phamilton]

For me, the benchmark is parsing a heterogenous data structure in JSON. For example, an array of inventory items. We get around this by shoehorning them all into a common structure, but in a dynamic language with a dynamic datastore we can store them and access them in a more native (to the problemspace) manner.

[ZenoArrow]

Okay, so what problems do you see in using something like active patterns in F# for either parsing an array or a single value within a JSON structure?

https://docs.microsoft.com/en-us/dotnet/articles/fsharp/lang...

[jonnytran]

That looks interesting. Is there an analogous Haskell or OCaml feature to F#'s active patterns?

Regardless, I still think it's a moot point. I understand that static typing can be great for catching bugs sooner rather than later. But doing that takes time and work. Basically the thing that all static typing advocates neglect is that sometimes I just don't want to put that time and work in up front.

Most people would agree they'd want to put that work in before shipping their software to millions of people, but most code is only used by a few people a few times. The line between development and production is blurry. Most of the time, I would much rather run code that mostly works _now_ and has tons of bugs than have to put in more work. Even if it's not much more work, it's still not nothing. I own my computer and tell it what to do. But a compiler rejecting my code b/c there _might_ be an edge case that has an error is unacceptable. Which is why I would love static typing if you could simply turn it off. I know of some research in gradual typing, but I've never seen it in any mainstream languages.

[ZenoArrow]

>"That looks interesting. Is there an analogous Haskell or OCaml feature to F#'s active patterns?"

Based on a quick web search, the equivalent of F#'s active patterns in Haskell appears to be view patterns...

https://ghc.haskell.org/trac/ghc/wiki/ViewPatterns

...and the closest I found for OCaml was polymorphic variants...

https://realworldocaml.org/v1/en/html/variants.html

>"I know of some research in gradual typing, but I've never seen it in any mainstream languages."

When you say gradual typing, do you mean optional type hinting like you can find in Python 3, or something else?

https://docs.python.org/3/library/typing.html

[jonnytran]

I believe the term is gradual typing: https://en.wikipedia.org/wiki/Gradual_typing

Thanks for the links. I didn't know about python's typing. It looks like a fairly recent addition.