500 karma · joined September 22, 2017
As for your build error I've only seen that with mismatched Java versions. If I run the repl (which is just a single mvn command) with JAVA_HOME pointing to jdk 19 I get the same error. But, I can see obviously you've installed jdk 20 and shown the version. I am unfamiliar with how nix sets up the environment, but is it possible it's running mvn with a different JDK than the version 20 you installed? The seems like it would be the most likely cause.
(def undef-fn)
It should work after that.And yet,
> My guess is that you don't see 'light' racist, misogynistic, or homophobic behavior as problematic
Name nameKey = ...;
Age ageKey = ...;
Optional<String> name = db.get(nameKey);
Optional<Integer> age = db.get(ageKey); interface Key<V> { ... }
class Name extends Key<String> { ... }
class Age extends Key<Integer> { ... }
interface DB {
public <V> Optional<V> get(Key<V> k) { ... }
}Without knowing any of the associated types and members how many interpretations could the prior expression 'a.b!c.d' have with UFCS and parens-less calling conventions (and any other feature that might contribute to different semantics)?
b!(c.d)(a)
b!(d(c))(a)
d(b!c(a))
d(a.b!c)
Might be more? Don't get me wrong I see the benefit. The vectorflow example I think is a good use case thought because it allows a more natural conceptualization of object -> member access -> conversion rather than having to call to!ulong(W.length) which forces the reader to start with the (pending) conversion. You get this same dataflow/conceptualization benefit in threading macros in clojure (->, ->>, etc).Anyway, thank you for all the work you've done.
But, I think one of the things that people seemed very happy about feature-wise that started to turn me off the language was UFCS. I don't deny that it makes the written code look more elegant but I think to me it existed as a net negative for other people who are unfamiliar with the code they are reading. There was an example someone gave years ago on reddit that was supposed to convey how clean the code to solve the problem was but it included an UFCS expression of the form 'a.b!c.d' which was sans-UFCS 'd(b!c(a))'. Trying to determine which reordering the compile would going to eventually choose seemed like more work than should be necessary for simple expression like that.
Having said all that it still might be a good choice for certain development environments and I should see whether there's a second edition of TDPL.