Fork me on GitHub
#clojure-europe
<
2021-03-27
>
simongray10:03:05

@borkdude I think, whichever one you end up going with, using Hiccup for a DSL is a great choice. I'm a big fan of Hiccup for DSLs because it manages to combine both the overall semantics of SGML and the composable qualities of regular Clojure code. I think the XML fetishism of Java is misplaced, but obviously XML does have some great structural qualities that are known and understood by most developers and it is Just Data(tm), but the way it's usually approached in Java code is by trying to convert procedural Java code into markup. Hiccup on the other hand, started as a DSL for HTML, but has become a de facto lingua franca of Clojure libraries that have nothing to do with HTML too (e.g. malli, instaparse). Some great potential there. Since it's embedded within Clojure code it doesn't feel foreign like XML in Java, yet you can mostly always convert it directly into XML/HTML/SGML, should you want to. So what I'm saying is your DSL looks pretty readable to me. I think the use of metadata would make the conversion to some kind of SGML representation harder, though. Maybe worth thinking about, but if you want to keep it entirely within the confines of Clojure using metadata is fine IMO.

simongray10:03:17

And good morning!

borkdude10:03:05

@simongray Thanks! I think I will end up with:

{:tasks {:clean [:shell {:description "foo"} "rm" "-rf" "target"]}}
I think people should just get used to this and probably will within a few minutes.

borkdude10:03:52

(btw, I'm now working on tokenization of the shell command!

{:tasks {:clean [:shell {:description "foo"} "rm -rf target"]}}
)

ordnungswidrig12:03:38

Regarding testing i can recommend developers to get familiar with the v-model of testing. Most of the time when people talk about unit testing, the actually mean automated testing which is a different "dimension". Automation must be the goal, not only for time saving, which is not even always the case, but for reproducibility and thus reliability. The hard decision is what @borkdude described: what's a good coverage of unit tests, module tests, module-integration tests, system and System-Integration tests? because of cloud computing and tools like ansible, terraform and so on, we can even fully automate system-integration tests and spin up even a full aws account for the test run. I think this topic is totally no taken I to account enough in larger (and smaller) projects.

👍 2
reefersleep13:03:20

Do you have any particularly good sources for the v-model (other than yourself 😄 )?