+1 to everything said so far.
I also found that types are great for articulating a well-known, static set of
structures, but almost all of the projects I worked in in a strongly and
statically typed language (Java) involved living on the edge of typing _just_
the right level of abstraction - specifically, code which really only cared
about one aspect of a type versus having so many types you couldn’t see the
wood for the trees. Structural typing (or duck typing if you prefer) would have
gone a long way. Typing the _end_ result - sure, but discovering the end result
quickly - not so much.
In Clojure I can still name and describe my abstractions through Schema (I use
it religiously and it has solved so many pain points, particularly ‘6 months
down the line’ - and it is turned on in production as the overhead is
negligible for my usage) but I have the flexibility to _not_ name them as well
and the ‘Any’ predicate is a fantastic nod to pragmatism.
To put it another way, almost all of my pain points are looking at forms,
particularly long ’threaded’ forms and thinking ‘how on earth does that
sequence of transformations work’ rather than ‘exactly what data is that
expecting’.
To be clear - the rigour of being forced to come up with a decent name for an
important abstraction is great, and (Java’s) types force you to do that, but it
also quickly becomes the demoralising stick that leads to
‘ICantBeBotheredToThinkOfAnotherName’.
When it comes to _consuming_ unfamiliar code then yeah, types are incredibly
potent as a form of documentation, assuming those types have good names of
course :-).
So for me, Clojure maps and Prismatic Schema give me pretty much all of the
good stuff I got from typing in the first place. I miss the ‘correctness’ check
that strong and static types give you but that is a small pain for the
increased expressiveness I have of describing my data/abstractions.
> On 1 Dec 2015, at 01:15, Timothy Baldridge <tbaldri...@gmail.com> wrote:
>
> I believe that working with maps is a lot like working with locals and
> function names...nothing will help you with bad naming. So don't do stuff
> like {:foo 42 :bar 33} when you can do stuff like {:min-age 42 :max-age 33}.
> Also stick with sane naming conventions. Don't do {:maxAge 42} in some places
> and {:MaxAge 42 :max-age 33} in others. And finally using namespaced keywords
> can really help, so perhaps even consider {:age/min 42 :age/max 33} or
> perhaps even {:age-range [42 33]}. In short, think about how you structure
> your data and you will go far.
>
> And to be frank, on the average project I work on I very rarely run into the
> "bag of data" problem. Intact I spend way less time working on the structure
> of the data than I do actually getting work done. And in the past, when I've
> used strongly typed data I often found myself arguing with my co-workers
> about type inheritance and co-variance/contra-variance (sp?), instead of
> actually coding the logic I was being paid for. So to quote a wise saying I
> heard once...."statically typed languages don't solve the problems I have".
> Perhaps I'm unique in this regard, but my time spent with other Clojure
> programmers tells me otherwise.
>
> As an aside, I recommend playing with stuff like tools.analyzer to see how
> far the "bag of data" can take you:
> https://www.youtube.com/watch?v=KhRQmT22SSg
> <https://www.youtube.com/watch?v=KhRQmT22SSg>
>
> Timothy
>
> On Mon, Nov 30, 2015 at 5:49 PM, Sean Corfield <s...@corfield.org
> <mailto:s...@corfield.org>> wrote:
> Gary Trakhman wrote on Monday, November 30, 2015 at 2:26 PM:
> I'd like to try haskell, but I'm not sure types in general would provide
> enough benefit to be worth it for small projects and well-written/tested
> large ones.
>
> There’s always https://github.com/Frege/frege-lein-plugin
> <https://github.com/Frege/frege-lein-plugin> and
> https://github.com/Frege/frege-lein-template
> <https://github.com/Frege/frege-lein-template> if you want to try Haskell
> (Frege) inside your Clojure app!
>
> Sean
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> <mailto:clojure@googlegroups.com>
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> <mailto:clojure%2bunsubscr...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> <http://groups.google.com/group/clojure?hl=en>
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com
> <mailto:clojure+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C programs.”
> (Robert Firth)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> <http://groups.google.com/group/clojure?hl=en>
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com
> <mailto:clojure+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
