Many people have been misled by LLMs into believing they have an important breakthrough when they don't. If you think you have a breakthrough, please try the reality checks in this post (the first is fast and easy). If you're wrong, now is the best time to figure that out.
> It's just incredible what a surplus value this dude alone provides to the ecosystem)
Seconded; it's pretty jaw-dropping!
> The tight feedback loop you have while molding a running program in your editor and the constant dopamine drip feed it causes are just too addictive.
Well-said -- I've been needing to write some Python recently, and it's only redoubled my preference for Clojure; the Python shell is a poor substitute at best for the Clojure REPL :(
I found it pretty easy to set up a Python REPL in VS Code, which would allow me to do similar things to the Clojure REPL such as highlighting some text in the editor and evaluating. All in all it was pretty close. I guess the only thing that is really different is that it was not connected to the same process I'm debugging, but a different python process. Is that the main thing you're missing?
Yeah, quite different. Technical as much as procedural and psychological.
In a Clojure REPL, you navigate "modules" like directories. And each directory has "files", or vars you've defined. Basically 'cd' and 'ls', but for module-level structures.
So you 'cd' to one "directory", query an AWS service or read a CSV file, and save results in that namespace ("my_namespace/my_results"). While you're at it, you save the results to a JSON file ('echo ... > tests/saved_results.json').
(You type this all into a REPL, no need to save this one-time command in a file. You can always re-run it by pressing UP like in bash.)
Then, you write a function called 'save_to_db()' in your text editor in the "database" namespace that accepts the input and writes to a database. You send that function to the REPL, and in the REPL, run the function on the results you saved from the first step in the var ("database.save_to_db(my_namespace/my_results)".
While you're at it, you 'cd' to your "tests" namespace in the REPL, and write a quick test in your test editor that parses 'tests/saved_results.json' and calls your "save_to_db" function and verifies the database. Send test to REPL (keyboard shortcut), run the test (another keyboard shortcut), fix the code, send updated code to REPL, rinse and repeat.
And this is all in one process, so you only "start up" Java once. Everything else is basically instant.
There's a ton of Youtube videos on using Clojure REPLs. It's really a game changer...
Yeah, that's it exactly. For me there's a power and an ease of flow that comes from having the REPL in the context of your running software, with access to program state and the easy ability to modify your code as it runs without having to restart anything or lose state, that's really unbeatable.
I can say that I (like many others) have built a thriving career on Clojure. I like to change jobs every couple of years, and I've never yet had any trouble finding a Clojure job I'm excited about (and I only consider well-paid remote jobs with friendly teams with companies doing something I feel good about). The community is mostly active on the Clojurians slack (currently ~24,000 users) and clojureverse.org.
So -- it's a niche for sure, but a very successful niche, and one that many people are very happy in. There aren't a ton of jobs out there relative to, say, Python, but there are also fewer people competing for those jobs, so it works out fine for individuals. It can be tricky to find your first Clojure job, but I think that's true in most languages.
I plan to stick with it for the foreseeable future, because there's no other language that I like nearly as much, or can be nearly as productive in.
So far: complex data visualization, transportation logistics, voting-related nonprofit, medical research, and augmented analytics. I like to explore new domains :)
I switched a few years ago from MBP to ThinkPads running Ubuntu (with Gnome). It's been an overall improvement for sure, and there are very few things I miss (iTerm2 is the big one; there's no Linux terminal emulator that has all the advanced features I loved in iTerm2 like incremental search/highlight/copy. Gnome terminal with tmux is...acceptable). And of course it's much cheaper; on both computers (P51 and X1 Extreme) I paid about 2/3 what I would have paid for a MBP.
The big downside is battery life. On both the ThinkPads I've had, the battery life has been roughly 4-6 hours, despite my attempts to improve it with Powertop and/or TLP, and despite keeping the external graphics card shut down. I find that pretty painful; I like to work outside most of the day when the weather's decent, and now I have to be meticulous about plugging in whenever I go inside for a bit. If it weren't for having it charge up over lunch, there's no way it would make it through my day.
Some folks seem to get better battery life with some ThinkPads running Linux, but I haven't been able to pull it off. In fairness, I do a fair amount of CPU-heavy work -- but I was doing the same kind of work on MBP, and the battery life was much better.
I have the same experience: My T470 always goes at least 10 hours, and the battery estimate shows 16+ from a full charge. My work Macbook might get 5 on a good day?
There are two things I found confusing in the first part of the guide (ie the part up to "Reading the Source"). The first is 'where', which is addressed in another thread on this page. The second is this:
This is a proper list:
(a b c)
and this is not:
(a b . c)
Could someone clarify how to interpret '(a b . c)'? How would it be represented in the non-abbreviated dot notation for pairs? It's not '(a . (b . (c . nil))' -- is it '((a . b) . c)'? The only Lisp I'm fluent in is Clojure, so I'm not used to the dot notation; otherwise this might be obvious.
May not qualify as cheap, but I believe 23andMe will tell you about the genes you've got which control your CYP1A2 levels, and predict your coffee intake accordingly.
Will you point out where it says that? I really did find this paper unusually cryptic about concrete takeaways.
Table 2 suggests that to match the performance of studies 3 and 4 (done by other researchers), which each gave 600 mg of caffeine, they were able to cut the dosage down to 500 mg and 400 mg respectively. But it's not clear to me that they're recommending that as the overall optimum, and that's the only place I'm finding "600" in the paper.
"It's alertness effects go away after repeated use and subsequent tolerance building"
Link to evidence? I don't remember seeing anywhere in the literature that caffeine stops being effective when used daily and long-term, nor does it match my own experience.
