Good morning
Morning all.
Morning
Good morning
Morning
madainn mhath 🏴
Morning
How're you doing so far?
• Paradoxically, sleep didn't improve much, although there are confounding factors so no clear verdict in the sleep department yet • Cravings are manageable • Mild headache the first few days, gone now • Calm bowels = win (I have IBS) • Calmer overall, kinda have the feeling it's slightly easier to get "in the zone" Overall, doing better than I expected.
Insomnia / sleep disturbance is very very common when withdrawing from caffeine, for some people it will even take three weeks to normalize or so (but it sounds you might already be over the hardest part)
I guess decaf coffee (for taste) isn't an option for you since it will still trigger IBS
I have the impression that decaf triggers it in a worse way than regular coffee.
Although that might just be an impression, perhaps it is correlated with the time of day when i sometimes grab a decaf (after lunch)
I've heard that too, not sure why that is
love that account
Reminds me of this old reddit thread 🤣 https://web.archive.org/web/20170806233157/https://www.reddit.com/r/AskReddit/comments/cmwov/hey_reddit_what_tattoos_do_you_have/c0tpyls/
yeah, I remember twitter. That looks like a fun account. A diamond in a sea of slurry.
hahahahaha
morning
morning
hello there cool people ! long time no morning
I'd love to have your opinion, for those of you who use JS/TS (or even Cljs with react) what component library has brought you joy ? (especially if you don't love frontend work) I want to suffer as little as possible while buidling a website using TS
Haven’t used it myself but heard good things about https://ui.shadcn.com/
@trost.mario trying to use it with remix but I feel like it's not exactly easy to use... I've only started playing with it so maybe it gets better with time
Morning
morning
Morning!
Morning :)
Do you guys enjoy low level programming? I'm finding myself getting more and more curious about what's happening closer to the metal. Which for me feels weird. In general I think the software industry uses to low-level languages - eg Javascript, Go or Rust when Clojure would work well. I consider Clojure higher level than the others, because it let's you think on a higher level. You can (often mostly) ignore memory, structs and serialization, and instead think about data structures and operations on those data structures. But that "ignoring" no longer works if you want to do high performance numerics or high performance graphics. Which further gets me curious about building fast low-level primitives that can be combined with powerful high-level operations in a REPL. And leaves me curious about how to write the low-level pieces. Use a low level language? Or try to do the low-level work in plain clojure? 🤔
The other thing to bear in mind is that the JVM project Panama will bring much better FFI for C et al. See https://github.com/IGJoshua/coffi for one way how it might be used from Clojure
I would love to do low level programming in clojure, too, e.g. on an ESP32 or Arduino. That wouldn't work with clojure on the JVM for the size of the runtime, but maybe would be an option with jank.
https://ferret-lang.org/#outline-container-sec-2 looks like a fun clojure-inspired low level programming language! Haven't tried it myself but it pops up around here from time to time
There's https://ferret-lang.org/ or https://github.com/mfikes/esprit for example.
But I love to see some of the simplicity of the ArduinoIDE with a nicer language than C/C++ or python.
With Clojure as a language, you can program the backend, the frontend in the browser, scripting with babashka. Data Science is evolving nicely. The missing peace for world domination is low level microcontroller stuff. 😜
I spent years in the early part of my career writing assembler for a wide variety of chipsets: full-screen text editors, database engines, network adapters, and then porting compilers to various architectures. Some chips were fun to work on, some weren't. Increasingly chips stopped being designed for humans to code against and became optimized for programs to code against. I miss some of those older, simpler chips but I wouldn't want to be coding directly against modern x64 stuff:slightly_frowning_face:
Hmm, you’re making me think. Maybe it makes sense to think of “be able to use Clojure or something Clojure-like in memory constrained environments” as one goal, and “simple run time / compile time model” as another, a “simple platform”. I find myself curious about a lot of the decisions the Zig team makes. It ships a C compiler, different C standard libraries, and a build system. And it cross compiles to different architectures. Those decisions help you make Zig code portable, while still having direct access to C resources. — I feel like Clojure is simple in some senses, Zig simple in others. In Clojure, you write functions that operate on data. Simple. You can evaluate new expressions. Simple. That simplicity requires rigor, Rich had to make sure not to put things in the language that didn’t work nicely with the other simple pieces of Clojure. Zig seems to empathize a simple build process and simple build artefacts—without introducing platform limitations relative to C. As Sean touches on, “which platform do you want to be programming against?” appears to be at the core. The JVM is awesome for lots of use cases, but it has its limitations. Babashka and Clojurescript (and perhaps Jank) help alleviate these. Yet, bb, cljs and Jank don’t isolate you from the platform. Babashka still has the GraalVM-provided classes, Clojurescript has JS interop, Jank has C++ interop. Which makes me think of something Thomas Heller (shadow-cljs) said: > Absolutely Java and JavaScript since they will strengthen your understanding of Clojure(Script). Knowing what the JVM is capable of and having the option of dropping down to Java if you really need to do something performance critical is like having a super power. You don’t need to do it often but having the option to do so is great. Same applies to JS. Knowing how and when to leverage the Host is critical IMHO. > > Full thread: https://clojureverse.org/t/let-us-assume-for-the-sake-of-argument-that-learning-clojure-is-not-the-only-worthwile-persuit-in-life/7339/2 — I’m more confused about my opinions now. Good sign, you’re making me think 😄
when programming a microcontroller in clojure you would still have to know the hardware, the GPIO pins and how A/D conversion works, for example. But still you could push the I/O to the edge of the system and program functionally at the core. It's data processing none the less.
Nice, but that's in the way of Clojure world domination. 😜
prescheme> Interesting. I think I may have become allergic to non-lisp languages (without structure editing).
pub export const mat4 = [3][3]f64{ [_]f64{ 1.0, 2.0, 3.0 }, [_]f64{ 4.0, 5.0, 6.0 }, [_]f64{ 7.0, 8.0, 9.0 } };
More stuff is required than in the Clojure version, which in my opinion hurts readability. (Though Clojure vectors and nested Zig arrays aren’t exactly the same)
(def mat4
[[1 2 3]
[4 5 6]
[7 8 9]])
Perhaps a #squint -like Clojure to Zig syntax compiler could have felt better to work with.I’m guessing mat4 would require type annotations to become an array of three arrays in pre-scheme? I’m seeing a function (make-vector length init) in https://3e8.org/pub/scheme/doc/s48-refman.pdf. But that should be possible to generate compile-time, I should think 🤔
Another thing to bear in mind as you dip into low-level programming: it's all about mutation -- registers are all mutable, memory is (mostly) all mutable -- everything is achieved by procedural changes, and any "data structures" you deal with all have to be programmed and managed by your own code. You can't just "depend on a library" at that level because you're down below it all. When I worked at an insurance company ('80s) they used IBM 8100 minicomputers and System/370 mainframes and it was either assembler or COBOL to program those. My team was building a hierarchical database engine for the 8100 series and I created a reusable routine that did recursive tree-walking and could be passed a "procedure" to apply to all the recursive nodes. So it had to do all its own stack management to make that work, and had to be able to dynamically call into other code, constructing parameter lists etc. It was fun for young me but it was also very easy to completely tank the machine (the 8100 didn't have user space so all the illusion of that was constructed down in the code)... after about a week of me tanking our shared dev machine(!) they moved me into the basement and powered up a new 8100 C for me to work on, on my own, until I got things running well enough to integrate back into the shared environment 🙂
I think mat4 can be inferred correctly in HM and be statically initialized
I attended a C64 assembly workshop at http://boosterconf.no one year and had a blast. Yes it’s mutable, but super cool to be working so closely with the machine. It’s a totally different way of programming from what I normally do, I don’t know if I could do it for a living (it feels like you’d end up writing the c std-lib first and then probs a lisp on top of that), but it’s cool from time to time so that you get that understanding of what’s really going on under the hood.
Ah, the 6502 (on which the C64's MOS 6510 was based) was a glorious chip -- such a beautiful architecture and instruction set. I still have an old Programming the 6502 book and every few years I have a run at writing a 6502 emulator in some language or other. I started a version in Clojure at one point but got distracted before I got very far with it...
Late to the party but both fennel and especially common lisps (plural) are worth considering if you want to stay in lisp-land
Fennel/lua can run on esp32 as far as i remember. And CL has various interesting backends like ecl, clasp (not to mention the obvious, sbcl) and also very good ffi