@guizmaii My understanding is that the default executor is the most efficient, if nothing is hogging it. Loom based executor is less efficient but hogging doesn't result in drastic throughput decrease when hogged.
Would love if someone more knowledgeable step in and correct me XD
I can think of two things that are the highest leverage items that humans can drive: test policies (what to test, how to test, how to discover what to test) and architecture (anticipating future changes).
What AI lacks in terms of software engineering is not capability anymore. What it lacks is trust and accountability.
SWE will likely pivot from solving first-order business problems directly into making the most out of the new scarce resource: accountability of human teammates.
AI generated code need not be hard to review. After the changes look more or less complete, make them create commits in logical* order.
*Not necessarily in the order it was written, but in the order you (as a human) would like to review them.
@olafurpg Can you share the script? I tinkered with it and ended up with so much pain. It kept saying the compiler had a bug, and I had to tell it the classpath is missing jars over and over again.
I used to also avoid leaking mutation in public APIs, but at one point I realized my literal job was to write APIs that mutate state or do side effects, just over HTTP.
Imperative core, functional shell is my favorite design principle. Many algorithms are dramatically simpler to implement with mutable state (for example, depth first search in graphs with cycles). Just don’t leak the mutation into your public API
@Hasen_Judi LLMs work very well if the patterns are well established and the requirements are clear (== dayjob code)
It works abysmally if either the structure or the goal is not well defined, and I'm just exploring the problem space.
Tried writing some decrel code today.
Opus 4.1 has absolutely no idea what needs to be done to add a simple new feature even with ultrathink, despite relevant code fits entirely in its context size.
I'll believe this AGI thing once it can write a substantial PR on decrel.
@guizmaii@augustnagro Mill is better designed than sbt, but my experience is that it requires some more polish. It's not as smooth as I wish it had been.
@Krever01 ... and I'm in a situation where I have to meet extremely tight deadlines, let alone filing bugs with minimal reproductions (which are time consuming often!). It's stressful when I get hit by bugs from all over the toolchain. That's what I mean by tooling is objectively bad.
@Krever01 ... Why mill-bsp and mill cli can't share build outputs unlike bloop, why mill classpath and bloop classpaths from mill are different, why scala-steward suddenly broke for mill, why IJ was unusably broken for Scala 3.4 (I had to switch to metals during this period), ...