1. 10

  2. 2

    Documentation doesn’t have to be “interactive” - it has to be exhaustive! In particular, the pre and postconditions of every function must be explicitly stated as formally as possible, within reason.

    1. 1

      That’s the goal for Clojure Spec, I think both are important in different ways.

    2. 1

      I have a love hate relationship with Clojure.

      There is soo much to love about it…. I just so wish it wasn’t tied to the jvm/jre.

      Half of me loves D’s static “everything that can get sorted out at compile time is” ethic, half of me loves the lispy you can eat your own dog food ethic, much of me loves the directions Hickey took Clojure.

      1. 2

        Nowadays there’s also a lot of work going into ClojureScript on top of Node as well. Lumo is pretty nifty, there’s also shadow-cljs that provides Node based tooling.

        1. 2

          I just so wish it wasn’t tied to the jvm/jre

          The main problem with that is all the baggage that comes with Java’s library ecosystem, i.e. that you can’t do anything without Maven/Leiningen, because everything depends on a gazillion largely pointless libraries.

          It’s a lot like the front-end ecosystem with NPM and left-pad and other glorious creations people have adopted to avoid committing the sin of reinventing the wheel.

          1. 3

            I far prefer this situation to what’s available in many other languages. When I’m using the Java ecosystem, I have a wealth of mature libraries available to me for pretty much any task imaginable. Meanwhile, tools like Maven and Leiningen are incredibly useful for writing and maintaining large projects.

            1. 1

              Oh I can see why the choice was made… I’m in the embedded “speak to bare metal registers in a real time critical manner” realm…. and the jvm explicitly excludes me from that…. so the choice excludes me from Clojure.

              Hence my fascination with D…. but having dabbled a fair bit in lispy languages… I do love homoiconicity.

              It’s just one of those features in a language (like introspection and reflection and monkey patching) where you look at the feature and say, that’s Dark Magic, I’m not going to use that in production code….. and then you look under the hood of the system libraries…. and you realise, hey, I’m using that dark magic all the time, and it’s the reason why my environment is so powerful.

              1. 2

                Carp is a more interesting language than Clojure for those kinds of environments.

                1. 2

                  Hmm. A statically typed linear lisp with good integration with C….

                  ie. Sort of like Rust but with immutability and homoiconicity….

                  Ok, you’ve got me “Hooked” on Carp!

              2. 1

                Meanwhile, tools like Maven and Leiningen are incredibly useful for writing and maintaining large projects.

                You know, before the world adopted Maven, people needed to make sure they had the required JARs on their classpath. We’d carefully gather them and put them under the WEB-INF directory in a Java Servlet -based application :)

                That was getting increasingly troublesome, I’m guessing because people were already adopting dependencies they shouldn’t have adopted, and Maven was invented to sweep that problem under the rug.

                And with Maven’s help, you could add as many dependencies as your heart desired. It seemed like there was no price to be paid either, but.. the problem of careless dependencies was exacerbated, and now you can’t do anything without Maven.

                The point here is that Maven is only “incredibly useful” because there’s a shitload of needless baggage being hauled around in every single JVM project.

                1. 1

                  I have to disagree. Code reuse is a good thing, and therefore being able to reliably include interdependent libraries is also a good thing. I don’t see anything being swept under the carpet here.