There are _general_ questions with DSLs and embedded DSLs, including whether users are disciplined enough.
If you don’t trust your users, maybe you should prevent them from doing even pure computations. That’s basically the Go argument, but I totally buy that :-).
at least make them pay commensurately for pure computation, like on blockchains, heh
Except I usually don’t choose Go-like systems.
mind you, I’m also happy to rant about SBT, like any Scala user
I used Scala a while, SBT seemed like the hackiest hack ever
I don’t think _that_ is the problem.
Using higher-kinded types in a build system might be closer to it.
Not even Haskellers do that in _their_ build systems ;-)
did they even have a metaphor (mental abstract model) for SBT at all? If so, I never noticed
Yes. Took just a few years to document it.
And after a few more years, one developer managed to understand it and explain why it had a couple of concepts in excess.
this sounds familiar for the Scala community (Akka comes to mind, although in reverse)
there [in Akka], they started with a clean concept, and then made it unrecognizable
no no, in SBT the author started with a clean concept.
it’s even enforced by types and whatnot.
what was it, and why can't anyone tell what it is?
I suspect they had one of the first HList implementations in production? Actually a KList — so a list of type constructors.
Basically, it was written by a type astronaut who left very little documentation.
so the _usage_ was hacky, just cargo-cult what works.
but nowadays the model is documented, it’s just not immediate.
sorry, that was a slight understatement, and my “exercise for the reader” moment
"type astronaut" :laughter_tears:
oh, that’s a term of art, and not mine
the equivalent of the pattern-happy Java programmer?
this is an analysis: https://www.lihaoyi.com/post/SowhatswrongwithSBT.html
it’s more like somebody who in Coq picks Vector, or rather intrinsically-typed syntax
even when it’s overcomplicated for the task at hand
requiring multiple PhD to be able to contribute
for higher marks, they might want to paint themselves into a corner by being unable to wield the tools properly
(I recall a prominent Haskeller complaining about Haskell programmers bringing too many commercial Haskell projects to failure this way)
OTOH, (since we’re hopelessly OT) in this channel I’d rather be suspicious about OCaml’s lack of control for side effects — I am not sure, but it does seem like Coq suffers terribly from it
ah, the problem in many industry-oriented PL communities (in my opinion) is that they really have close to zero incentives to write anything but plain old how-do-I-use-this documentation
feel free to break this out from parent topic by changing the topic at some well-chosen point
(wouldn’t know where at this point, and I’m on the app which doesn’t seem to let me)
OK I will do it at what will probably be the wrong point in hindsight
re docs, that’s somewhat true but SBT seems a special case... all we know is the author disappeared from the Internet (maybe because of the reactions)
hmm, isn't the community a bit embarrassed that they adopted a tool they had no idea how it worked?
however, some of the SBT ideas are really nice, and I think it is in some sense declarative — a task can depend on another one by using its result — and that’s done automatically by defining an appropriate monad. And your build files just describe a build to be later executed :-)
hm, I’m not sure they should be embarrassed.
sigh, I would send them the original Mokhov et al. paper and tell them to get back on where SBT fits
SBT was the first tool to support fine-grained incremental builds...
for Scala, that is
by fine-grained, do you mean edits at the method level?
back then it wasn’t so good I think, but it was still better than the alternatives
and how do they deal with dynamic dependencies and reflection and so on?
in any case: like for dune, it builds Scala projects faster than alternatives, so people did the right thing
re dynamic deps, I’d have to look at your link on Selective to understand what you mean.
on reflection, do you mean Java reflection?
it's not really related to that. You have to do your change impact analysis accurately to get correct fine-grained builds
ah, the dependencies of a Scala file are completely static in that sense
if a class loads another class, you cannot predict the runtime types, that’s true
dynamic class loading/modification and so on?
not a problem in the compilation model
the _output_ of compilation only depends on the source and the dependencies.
there’s a strict stage separation between compile-time and runtime.
well. Except for (compile-time) macros, and those _are_ hackier in Scala 2.
those indeed are a problem because they’re basically compiler plugins, up to some sealing of ML-modules, which you can anyway bypass fairly easily with
Obj.magic and friends.
my number one mistake when reading tech writing by non-academics: scrolling directly to the conclusion and assuming it actually sums up what the document is about (re: https://www.lihaoyi.com/post/SowhatswrongwithSBT.html)
Last updated: Oct 16 2021 at 07:02 UTC