tincholio

At the same time, one should not automatically assume that "clean code" is actually readable. I've had to deal with architecture astronauts of the Uncle Bob school of "clean code", and their code was anything but readable.

Without meaning any offense to the OP, I think this is a pretty low bar for Emacs eye-candy... Nicolas Rougier's "Nano Emacs" [0], or his previous "Elegant Emacs" [1] are better examples. You can also get pretty far using variable-pitch mode for mixing fonts (for example in org-mode [2]).

[0]: https://github.com/rougier/nano-emacs

[1]: https://github.com/rougier/elegant-emacs

[2]: https://github.com/minad/org-modern

I would recommend looking into org-mode for task-based time tracking and documentation (probably using org-capture), it's one of the basic use cases.

Repeating a recent comment on another music-related link. I've recently come across the Humdrum [0] toolkit, which does a bunch of related stuff, in very interesting ways. Coltrane looks awesome! I'll have to delve into this :D

[0] https://www.humdrum.org/

I was thinking about trying Winamp again at some point, but nowadays I use Spotify, and shuffling a ton of MP3s across systems doesn't seem as compelling as it did 10 or 15 years ago. I guess I don't really have a strong need for an mp3 player anymore.

Well, there's the whole JS thing... :D

Same here... It's pretty mind blowing; I was getting ready to reinvent the wheel, but I think I'll be better off spending some time learning these tools

I've been looking into doing some automated analysis, and recentrly came across the Humdrum tools [0], and fell into the rabbit hole. I suspect that the type of 'linting' you'd like to do can be done with them. In any case, totally worth a look.

[0] https://www.humdrum.org/

The name is definitely derived from "cotorra", and likely refers to the noisy chatter that wild groups of parrots have.

I think the author conflates aspects of bad writing (which is rife, not only in academic papers, but everywhere), with the increased use of jargon and acronyms. I think jargon and acronyms serve two important purposes in academic writing. They help with conciseness and precision. For people working in the field, long, elaborate descriptions tend to just be noisy, when a more concise term would convey the same information. This can seem like gatekeeping, but in practice, scientific papers are not written for laymen, but for a (typically) rather small amount of other people working on the same, or closely related fields. Writing for dissemination purposes should be more explicit, and maybe avoid some acronyms and very specific jargon, but for scientific writing, please be short, sweet and to the point!

The cholera example, for me, shows the opposite of what the author is trying to put forward. The second paper conveys the information much more clearly, and in under half the space.

I'm not familiar with Janet, but I know it's Clojure-inspired, so it probably has threading macros, which are like shell pipes on steroids. In practice, when doing REPL-based development, it's very common to use these as opposed to (g(f x)).

I kept getting promoted posts for crypto bullshit stuff, even though I consistently disliked them. I'm not sure there was a proper implementation of that feature in Twitter at all...

Have you tried SponsorBlock? It basically allows auto-skipping of all that fluff.

Wonderful!

Kaffa roastery

I typically use a 30/70 blend (30% arabica, 70% robusta) from an artisanal roaster in Helsinki for my espresso. It's the cheapest one they have, but for espresso (and derived drinks), it's by far the best, imo. It's the same style of espresso you get in Italy.

At my previous job, we re-did some Java stream processing stuff in Clojure. We added functionality, made it more stable and dropped 6K lines of code (out of 18K for that particular component) in the process. It felt like magic...

I totally agree with your take (at least for the languages I know, out of the ones you mention). For me that right balance of beauty, productivity, and so on came with Clojure. I now find it painful to use any other language, tbh.

Well, calligraphy, it is not... Decent handwriting, though.

Sounds like he could use a language with multimethods...

"Simple made easy" [0] by Rich Hickey is a must-watch (even if you never touch Clojure)

[0] https://www.youtube.com/watch?v=SxdOUGdseq4

You seem to be implying that VSCode is "better" than Emacs or Vim, as cars are better than horses, but other than having wider adoption atm, I'm not sure it's "better" in any meaningful way.

At work, i3 on Plasma. At home, plain i3 (with polybar). Simple, and amazingly practical.

Why? Google owns ITA...

> each theme needs to be implemented separately for every mode

I am not sure whether you're trolling or just completely clueless about Emacs (despite your claims of using it for many years).

I suspect that Spotify's ad strategy is to make them as obnoxious as possible, just to get you to buy the subscription. For me, the ads they played made it seem like their data science were either completely inept, or extremely evil.

Related to this, there's an AWS SDK for Clojure [0] (created by the same people who are behind Clojure), which is generated from the AWS specs themselves. Carmine, a popular Clojure library for Redis does something very similar. There's also a library for generating SDKs from Swagger specs [2]. I implemented a similar solution (generating Python bindings for some of our APIs from Postman exports), and it was super simple, really.

I suspect doing the same in CL would be similarly simple.

[0] https://github.com/cognitect-labs/aws-api

[1] https://github.com/ptaoussanis/carmine

[2] https://github.com/oliyh/martian

Not really. On petrol cars, if you let go of the clutch in 1st gear and not pushing on the gas, you'll most likely stall. Diesels often don't do this, and creep instead (all of this assuming you're letting go of the clutch slowly enough, otherwise, you'll stall for sure)

Pretty much this. He pontificates from a position of authority that has nothing to back it up.

This is the same guy from the failed sudoku solver... http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s...

Maybe he had also tried TDD "wrong"? Or maybe he's just another snake oil salesman, like "uncle" Bob?