ClojureScript Builds, Rebooted
adzerk.com
ClojureScript Builds, Rebooted
1–10 of 29 posts
Re: ClojureScript Builds, Rebooted
#2How will this work with tools like figwheel [1] and austin [2]?
Re: ClojureScript Builds, Rebooted
#3How will this work with tools like figwheel [1] and austin [2]? 1. https://github.com/bhauman/lein-figwheel 2. https://github.com/cemerick/austin
The post was a demonstration of exactly that: cljs incremental builds with live-reload and cljs browser repl.
Re: ClojureScript Builds, Rebooted
#4Boot looks interesting, but replacing an immutable data structure with side-effectful functions feels like a step in the wrong direction.
Re: ClojureScript Builds, Rebooted
#5Boot looks interesting, but replacing an immutable data structure with side-effectful functions feels like a step in the wrong direction.
The main reason why build tools exist is to perform transformations on a file set. The vast majority of the things build tools do that are useful are side effects.
These "side-effectful" functions are basically transducers; the reduction is performed on the file set instead of a sequence. They are mostly stateful transducers, but this does not fly in the face of functional programming. The opposite, in fact! They facilitate separation of concerns in a way that an immutable but global configuration map cannot.
Re: ClojureScript Builds, Rebooted
#6Boot looks interesting, but replacing an immutable data structure with side-effectful functions feels like a step in the wrong direction.
The main reason why build tools exist is to perform transformations on a file set. The vast majority of the things build tools do that are useful are side effects. These "side-effectful" functions are basically transducers; the reduction is performed on the file set instead of a sequence. They are mostly stateful transducers, but this does not fly in the face of functional programming. The opposite, in fact! They fac…
It's true that you need to interact with the filesystem eventually, but the longer that can be deferred, the more complexity can be avoided.
Ideally I'd want to construct a functional data structure that describes my build process, and at the end pass it to a side-effectful function to produce a change to the filesystem. Boot appears to be side-effectful from the get-go, but perhaps I'm mistaken about how it operates?
Re: ClojureScript Builds, Rebooted
#7Boot looks interesting, but replacing an immutable data structure with side-effectful functions feels like a step in the wrong direction.
The main reason why build tools exist is to perform transformations on a file set. The vast majority of the things build tools do that are useful are side effects. These "side-effectful" functions are basically transducers; the reduction is performed on the file set instead of a sequence. They are mostly stateful transducers, but this does not fly in the face of functional programming. The opposite, in fact! They fac…
its not at all clear to me that you are correct.
I'm glad that people are putting thought into the cljs build process though, to this day it is still a particularly un-fun part of clojurescript.
Re: ClojureScript Builds, Rebooted
#8Earlier quoted context omitted.
The main reason why build tools exist is to perform transformations on a file set. The vast majority of the things build tools do that are useful are side effects. These "side-effectful" functions are basically transducers; the reduction is performed on the file set instead of a sequence. They are mostly stateful transducers, but this does not fly in the face of functional programming. The opposite, in fact! They fac…
It's true that you need to interact with the filesystem eventually, but the longer that can be deferred, the more complexity can be avoided. Ideally I'd want to construct a functional data structure that describes my build process, and at the end pass it to a side-effectful function to produce a change to the filesystem. Boot appears to be side-effectful from the get-go, but perhaps I'm mistaken about how it operates…
All JVM build tools are side-effectful from the get-go, and they really have to be. Consider the :dependencies and :source-paths keys in a Leiningen project.clj. The purpose of these is to manipulate the mutable class path. To have a JVM build tool that doesn't revolve around the class path will require a complete reinvention of the JVM ecosystem and all of the existing tooling (like in our demo we use the Google Closure compiler, which mutates all kinds of things–that would have to go), which is, I'm sure, never going to happen.
Re: ClojureScript Builds, Rebooted
#9Earlier quoted context omitted.
The main reason why build tools exist is to perform transformations on a file set. The vast majority of the things build tools do that are useful are side effects. These "side-effectful" functions are basically transducers; the reduction is performed on the file set instead of a sequence. They are mostly stateful transducers, but this does not fly in the face of functional programming. The opposite, in fact! They fac…
It's true that you need to interact with the filesystem eventually, but the longer that can be deferred, the more complexity can be avoided. Ideally I'd want to construct a functional data structure that describes my build process, and at the end pass it to a side-effectful function to produce a change to the filesystem. Boot appears to be side-effectful from the get-go, but perhaps I'm mistaken about how it operates…
Sorry, I should have mentioned that while boot, like any JVM build tool, does begin and end with the class path, we have spent an enormous amount of time experimenting with ways to mitigate the effects. We ended up with a system that provides many of the benefits of immutability while still living in the real world where files actually exist.
Here are some of the things boot provides:
1. We have "pods", which are separate Clojure runtimes in isolated class loaders in which you can evaluate expressions. The actual building occurs in these things. They are lexically scoped and can have a different class path than the main Clojure runtime where your build pipeline runs.
2. Files emitted during the course of the build are created in temp dirs managed by boot. There are a few different kinds of these temp dirs, one of which is lexically scoped. We also have temp dirs that are effectively immutable from a given task's point of view (we use a copy-on-write scheme to achieve this).
3. We make liberal use of hard links and directory syncing to emulate immutability wherever we can. Boot provides a kind of structural sharing with these hard links that really makes the pain of dealing with files go away.
4. We put a great deal of thought into how artifacts flow through the build pipeline, and how tasks that don't know anything about each other can cooperate to work on these files.
This is the most interesting part of boot for me, and I'll be making a complete writeup about it soon.
Re: ClojureScript Builds, Rebooted
#10Earlier quoted context omitted.
It's true that you need to interact with the filesystem eventually, but the longer that can be deferred, the more complexity can be avoided. Ideally I'd want to construct a functional data structure that describes my build process, and at the end pass it to a side-effectful function to produce a change to the filesystem. Boot appears to be side-effectful from the get-go, but perhaps I'm mistaken about how it operates…
All JVM build tools are side-effectful from the get-go, and they really have to be. Consider the :dependencies and :source-paths keys in a Leiningen project.clj. The purpose of these is to manipulate the mutable class path. To have a JVM build tool that doesn't revolve around the class path will require a complete reinvention of the JVM ecosystem and all of the existing tooling (like in our demo we use the Google Clo…
You need to eventually be side-effectful, but that doesn't mean you need to start side-effectful. The :dependencies in a Leiningen project map are just a data structure until they're passed to eval-in-project, which happens at the end of a chain functional operations.
One of the core ideas of Clojure is that we should try to favour simple solutions over complex ones. Side-effectful functions are the some of the most complex tools we have, and while they are necessary eventually, it would be nice to have the majority of the code-base work with simple data structures, and push out the complexity of I/O to the edges of the application.