Well, way back in the day, dev tools weren't free, either, for the most part.

In the 80s, a good compiler would cost several hundred dollars. Relentless competition pushed the prices down to zero.

There are those who started playing with computers when compilers were often more expensive than the computer they ran on, and those who came after you could download an entire "Unix" system and toolchain for free.

Entire industries and massive companies existed for tools and tooling that is now considered free and table-stakes. Heck, an operating system used to cost money and didn't come with much at all!

PC-DOS started out at $40. Since the IBM PC cost about $3000, the $40 was more or less free.

Along with distribution costs for information going to near zero.

It's excciting, but I saw a review of a pre-release c2 on youtube [0] the other day, and it seemed extremely slow in the interactions. Otherwise, it seems like a cool device.

[0] https://youtu.be/5titW5dclwg

The C2 is a different device than the new one linked above, which was way more affordable (~250 Euro) with a 4G Unisoc SoC.

He looks like Dracula on LinkedIn

My take on this is that when outsourcing the code writing, you miss out on building a mental model of how it works that you do develop when doing it yourself. The degree to which that is a problem is probably variable, I suppose.

Most of those are not really "frameworks" as such (with some exceptions, like Biff or Fulcro), but rather libraries, or curated collections of libraries. Most Clojure people tend to roll their own set of libraries, rather than use actual frameworks.

I've been experimenting with this (it's in Babashka, which is for scripting Clojure, but you can do it with just bash, if your bash-fu is stronger than mine :D ):

    #!/bin/env bb
    
    (ns switch
      (:require [clojure.java.shell :as sh]
                [babashka.process :refer [pipeline pb shell process]]
                [clojure.string :as str]))
    
    (def workspace-ids
      (-> (pipeline (pb "hyprctl workspaces")
                    (pb "grep 'workspace ID'")
                    (pb "awk '{print $3}'"))
          last
          :out
          slurp
          (str/split #"\n")
          (->> (reduce (fn[acc e]
                         (try (let [ee (Integer/parseInt e)]
                                (conj acc ee))
                              (catch Exception e acc))) [])
               (filter #(and (pos? %)
                             (not= 10 %))))))
    
    
    
    (doseq [w workspace-ids]
      (-> (process (str "hyprctl dispatch moveworkspacetomonitor " w " 1"))
          deref
          :exit
          println))
    
    (process "hyprctl dispatch workspace 8")

It basically just moves all workspaces with positive IDs (so not the special workspace) to the external monitor, which seems to have a consistent ID of 1.

Indeed!

I have been having some issues with X/i3 (using i3 as a WM for Plasma), mostly with multiple screen setups (windows getting all screwy when connecting/disconnecting, lots of flickering, etc.), and also with my trackpoint's middle button scrolling randomly going away, and needing to use xinput incantations to fix it. I tried Hyprland with QuickShell, and after some QS-related pains, I just dropped to plain Hyprland. It's been working quite nicely so far. There was a lot of trial and error, and there's still some bits that could use improvement, but overall things just work nicely. The main sticking point for me now is that the screen-sharing and using Flameshot is a bit convoluted, and that the workspaces configuration does not support multiple external monitors (as in, the one in my office, and the one home, it needs some resetting each time I change those, or at least I haven't found the way to configure it properly as I had on i3).

So far, it has been a moderately positive change.

> the ones that like to think everything up-front before doing anything.

I don't think that's the case. If they were really thinking up-front, they'd be doing proper req analysis and design work, rather than interactively growing a ball of mud that "does the minimal thing to pass a test". To me, it seems like TDD is sold as this "foolproof" design / dev approach, which is anything but.

Not the parent poster, but I suspect he's thinking of stuff like Lighttable, or Liquid. Editors that were written in Clojure, or specifically for Clojure, and had cool features that were not available elsewhere at the time. (I'm boring myself, and pretty much only ever used Emacs with Cider)

Correct, there's something I enjoy about editors designed for specific languages in mind, they feel like they're more refined. Like I use the really simple UI that Racket comes with Dr. Racket because it has some unique features, and it just works.