Clojurians Log v2

which is frustrating because i actually really like where the language is heading

which to the original thing i was gonna talk about - patterns like this are now representable

:conflict-handlers - map of string pattern (regex) to built-in handlers,
                       symbols to eval, or function instances

public sealed interface ConflictHandler {
    record Ignore() implements ConflictHandler {
    }
    record Overwrite() implements ConflictHandler {
    }
    record Append() implements ConflictHandler {
    }
    record AppendDedupe() implements ConflictHandler {
    }
    record Warn() implements ConflictHandler {
    }
    record Error() implements ConflictHandler {
    }

    non-sealed interface UserDefined extends ConflictHandler {
        ConflictResolution resolve(
                ConflictInformation conflictInformation
        );
    }
}

One problem with a language that is so incredibly widespread and mainstream is that it is really hard to form any sort of coherent "community" -- there can be localized communities, either geographically, or by domain. There's no one-size-fits-all.

is a decent translation of

Available built-in conflict handlers:
  :ignore - don't do anything (default)
  :overwrite - overwrite (replaces prior file)
  :append - append the file with a blank line separator
  :append-dedupe - append the file but dedupe appended sections
  :data-readers - merge data_readers.clj
  :warn - print a warning
  :error - throw an error

+  a function instance

that makes sense, but “the python community” does seem to very much exist

https://www.python.org/community/

and they are just as big and about as old

so i don’t think that is the whole story

Yeah, I attended PyCon in 2013 coz' it was local and I felt so welcome and it was a great conference.

But I've also attended a lot of large Java conferences and they always felt "corporate".

I used to go to JavaOne every year in San Francisco.

i started programming in python and got most of my “headstart” from watching pycon talks

I still have that pycon talk about choosing the default colors in matplotlib for medical imaging living rent free in my head

and from how dev.java and all the other “corporate initiatives” position themselves - it seems like oracle really wants that vibe of community to exist

I started Java back in '97 and parted ways with it after Java 5 some time. But I thought Java 8 was step in the right direction and some nice stuff has been added since -- but I could never go back to programming in Java these days. There are so many options on the JVM now... I could live with Kotlin if I had to. Maybe I could go back to Groovy or Scala if I had to...

Java is only slightly older than I am, but when i first started to hate it, it was on 6-7

and when i applied to my first internships in college i was adamant in not wanting to work with java

but after having to work with it and years of reflection i would prefer the newest java over scala and groovy for almost everything

I was 35 when I learned Java -- are you trying to make me feel even older than usual? 🙂

yes

I think its all about framing

I came back into java after having a haskell loving roommate followed by a scala and rust loving one and being the elm and clojure person

but without any of the context of how/why other communities do things I would be one of those people copy pasting getter and setter methods on everything still

and as per usual i don’t know where i was going with that

Yeah, if you go to large Java-focused events and talk to a lot of devs, there's so much of that copypasta code and bashing code out following standard "patterns" without actually understanding any of it...

I remember at one Java conference, there was a talk about continuous integration and I was listening to attendees coming out of it, and they seemed to think it was unattainable academic "magic"...

anywho my general thought was “what if instead of maven or gradle people wrote this”

public static void main(String[] args) {
        var buildTools = BuildTools.getInstance();

        buildTools.javac(
                List.of("src"),
                "target/classes",
                List.of("-source", "17", "--enable-preview"),
                buildTools.createBasis()
        );
    }

that would be a lot easier for me to teach

{:paths ["target/classes"]
 :aliases {:dev {:extra-paths ["src" "build"]}
           :build {:deps        {org.clojure/clojure {:mvn/version "1.10.1"}
                                 io.github.clojure/tools.build {:git/tag "v0.7.4" :git/sha "ac442da"}}
                   :paths ["src" "build"]
                   :ns-default  dev.mccue.jproject.build}}
 :deps {org.clojure/clojure {:mvn/version "1.10.1"}
        io.github.clojure/tools.build {:git/tag "v0.7.4" :git/sha "ac442da"}}
 :deps/prep-lib {:alias :build
                 :fn    compile
                 :ensure "target/classes"}}

and this is the deps for that project

the only clojure specific parts are :ns-default and :fn

there is a bit of a bootstrap issue, but if its one file then java can already launch it like a script

{:paths ["target/classes"]
 :aliases {:dev {:extra-paths ["src" "build"]}
           :build {:deps        {org.clojure/clojure {:mvn/version "1.10.1"}
                                 io.github.clojure/tools.build {:git/tag "v0.7.4" :git/sha "ac442da"}}
                   :paths ["src" "build"]
                   :class-default  "dev.mccue.jproject.build.Build"}}
 :deps {org.clojure/clojure {:mvn/version "1.10.1"}
        io.github.clojure/tools.build {:git/tag "v0.7.4" :git/sha "ac442da"}}
 :deps/prep-lib {:alias :build
                 :method compile
                 :ensure "target/classes"}}

i tried to write all of that from scratch months ago and got nowhere

now i’m thinking just 1. Wrap tools.build 2. Wrap the cli and replace :method and :class-default with something that monkey patches in the functionality for java

another thing pushing me is the one time a friend’s work moved to interacting with a WSDL api and the way to generate the glue code was a maven plugin

like - what?

as obtuse a use case as it is, “prep-able deps” + easy local/git dependencies would have solved it in a really straight forward way

With a wrapped build script, written in Java, don't you just have to first compile it and then run it? That seems a step back from Gradle -- at least that has a relatively-close-to-the-language DSL that you write as a script.

not if its a single file

and afaik gradle still works with a “lifecycle/plugin” model

but yeah if you had a complex build program you would have to build that somehow

probably with a simpler build program

hence the “bootstrap” issue

Ah, JEP 330. I missed that coming in with Java 11.

and if gradle or scala or kotlin or clojure works better there is no reason why they couldn’t be used

the central thesis here is just that no abstraction of build lifecycle is better than a lackluster one

so make builds programs