I spend most of my time on application code, I think the tradeoffs are different when shipping public libraries. Obviously, I would prefer my libs to be more slow-moving, more well-documented, more generally useful and well-defined. I want my application code to be quick to change and develop first and foremost.
As time goes on, I am more likely to end up having to read the source code of the libraries I use. I'm willing to accept that risk if using the library in the first place lets me ship faster with fewer errors than reinventing what it does from scratch. I don't think understanding all dataflow upfront is a useful way to spend time, and most libraries I've used try to provide a sane interface and document it well via test-cases, at least. Doing clojure work in a large codebase taught me to create orderly namespaces with few data shapes and the tightest code possible to express them, which helps when someone (or myself 6 months later) has to read it, to be more concerned with what it 'does' than the names I gave things. 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 is that intermediate stage of a project, where many things have been written in a hurry, and tests are not comprehensive, where I think types would help keep up development speed a little longer before hitting the tech-debt wall. Perhaps the curves look different to a haskeller :-). I like prismatic schema, but have only used it at module boundaries and for more dynamic use-cases (to avoid having to write user-facing validation code myself), and don't hold to it as a discipline except in the context of a team. It's hard to know if I could write the same code faster by following a compiler's types, but my instinct says that it would get in the way for prototyping, and provide less security and more noise the more decoupled your code, which is a practice that clojure encourages. Printing stuff in the REPL is kind of great: http://www.learningclojure.com/2010/09/clojure-macro-tutorial-part-i-getting.html https://github.com/dgrnbrg/spyscope On Mon, Nov 30, 2015 at 4:49 PM Jonathon McKitrick <jmckitr...@gmail.com> wrote: > I've read the recent comments on 'the end of dynamic languages' and I'm > curious what ways you have found for dealing with one of the issues I've > heard mentioned frequently: when libraries (or functions in general) pass > maps around as arguments or return values, how to go about finding out > exactly what those maps contains without slogging through source code. > > Any suggestions? > > -- > 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. > -- 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.
