Fork me on GitHub
#other-languages
<
2022-01-03
>
emccue00:01:14

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

emccue00:01:09

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

emccue00:01:55

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
        );
    }
}

seancorfield00:01:14

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.

emccue00:01:32

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

emccue00:01:36

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

emccue00:01:54

and they are just as big and about as old

emccue00:01:09

so i don’t think that is the whole story

seancorfield00:01:10

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

seancorfield00:01:27

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

seancorfield00:01:40

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

emccue00:01:28

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

emccue00:01:51

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

emccue00:01:22

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

seancorfield00:01:52

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...

emccue00:01:12

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

emccue00:01:20

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

emccue00:01:12

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

seancorfield00:01:34

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

emccue00:01:57

I think its all about framing

emccue00:01:59

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

emccue00:01:45

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

emccue00:01:55

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

seancorfield00:01:49

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...

seancorfield00:01:51

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"...

emccue00:01:38

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()
        );
    }

emccue00:01:03

that would be a lot easier for me to teach

emccue00:01:54

{: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"}}

emccue00:01:06

and this is the deps for that project

emccue00:01:23

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

emccue00:01:41

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

emccue00:01:18

{: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"}}

emccue00:01:28

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

emccue00:01:32

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

emccue00:01:18

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

emccue00:01:23

like - what?

emccue00:01:07

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

seancorfield00:01:36

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.

emccue00:01:46

not if its a single file

emccue00:01:20

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

emccue00:01:56

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

emccue01:01:15

probably with a simpler build program

emccue01:01:31

hence the “bootstrap” issue

seancorfield01:01:09

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

emccue01:01:15

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

emccue01:01:52

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

emccue01:01:25

so make builds programs

1