-
My experience so far with Clojure’s spec library is that it provides exactly the experience Michael describes here. Start at the REPL to get a sketch together, then “finish” it with specifications of arguments/return values and property-based testing.
-
My Struggle Volume I by Karl Ove Knausgaard. Really enjoying it so far.
-
This is a mix of great advice, things that are hopefully obvious, and a few terrible ideas just to spice things up. In particular the example of
(comp str/capitalize str/trim)being labeled as “hard to read” compared to the lambda version is just bizarre, and the convention of marking reference types with*“because it resembles C/C++ pointers” would be a huge red flag if I saw it during code review. Adding in extra newlines sounds like a great idea if you always work plugged into an external display or two but shows a disregard for your colleagues who may prefer to work from a laptop.-
-
I think you could make a case for a special naming convention for top-level
defreference types, but it’s not helpful when it’s a local, which hopefully is the more common case.
-
-
I had similar thoughts. It seems peculiar to offer a recommendation “Avoid higher-order functions” in a functional language.
The article did put me in mind of Stuart Sierra’s series of posts Clojure Dos and Don’ts. I also like How to Name Clojure Functions.
Regarding the recommendation to replace the threading macro with a
let: an advantage (for me) of the threading macro, is that it’s immediately clear that the result of a function is not used again. It’s a temporary value that doesn’t matter after the next function in line has been called. In aletyou have to scan the surrounding code to see how the value is used.As an aside: I quite dislike that the code examples are images without alt text.
-
Also, avoiding the threading operator just to obscure the computation going on with some (probably badly) named steps (remember, naming is hard) is not the best.
At work we used
->>a lot, because it both frees you from giving strange names to intermediate computation results and allows you to plug in whatever function you want to intercept the computation without having to rewrite your code.
-
-
Gitless has no staging area
I frequently use
git add -pto stage chunks of diffs, so that I can make separate commits of unrelated changes in a single file. I would miss that feature greatly.-
Gitless has a
--partialflag that can be used to interactively select segments of a file to commit. -
-
-
For non-trivial changes, I don’t know. But if it gets to the point where I have non-trivial changes in my working copy, I’ve already lost.
In my experience, a common pattern is:
- start editing some function
- realise this function would be easier/safer/simpler with a change to the helper function it’s based on.
- go off and edit the helper function, write some tests, make sure it’s solid
- come back and finish the outer function, to make sure that the changes to the helper function actually accomplish the thing I needed
-
git add -pthe changes to the helper function and the tests, which I’m confident can stand alone because the existing tests still pass, plus my new ones - commit the changes to the outer function
…times as many stack-levels of yak-shaving as you can stand.
-
-
-
-
-
-
Just started The Confusion by Neal Stephenson, and it’s really fun
-
-
-
Hah, I disagree with that completely. I thought Snow Crash was a great novel, and The Diamond Age was the one with a lot of nice ideas but a bit weak as a novel. Especially the ending, but of course Stephenson is weak at endings.
-
-
-
-
Feature flags are technical debt, they’re inseparable. You’re trading for a number of benefits now for some complexity that will be dealt with later.
-
If you haven’t used Smalltalk before, it can be eye-opening just how good the programming environment is (and Pharo looks great).
I’m in