![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://programming.dev/pictrs/image/8140dda6-9512-4297-ac17-d303638c90a6.png)
we had a plenty of more deterministic tools for parsing human readable text to machine-readable long before llms
I am working on fedi software that is hoping to allow Kodi, Plex and Popcorn Time get rid of IMDb/TMDB dependency. Dm me if you’re skilled in SvelteKit and/or Go, especially the Fiber framework, or machine learning with Rust and willing to contribute.
we had a plenty of more deterministic tools for parsing human readable text to machine-readable long before llms
fr the system is in such a deep terminal crisis that talking to people in their 20s feels like talking to pensioners since in countries like the US or UK the life expectancy is declining due to not being able to afford healthy food, stressful and precarious work, mental health crisis and addictions, worsening healthcare, climate change, moldy cramped housing, proliferation of larger and thus more dangerous cars, new zoonoses etc. etc.
typescript is a linter
wonder when Rust will saturate it’s niche as a C/C++ replacement, I’d guess 3-6 years would be when we might start to see some stabilization.
I only use vscodium for things that are not that well supported by neovim, in my case it’s only Scala basically, but I guess I’m just to lazy to properly configure metals. I use Sway as my desktop and I don’t want to go into configuring DPI just for vscodium or switch to gnome to not ruin my vision even further when using it. This is what I like about terminal-based editors - the whole Ui scales with a single key combination. Speaking of which I also consider the combinations provided by many Neovim “distributions” (and my workflow ;p) way more ergonomic than emacs-y finger gymnastics of vscode and the likes, since I just hit the space twice and type a command alias without moving my fingers from where they should be on the keyboard instead of memorizing gazillion combinations working little by little towards giving me a carpal tunnel.
if you want even more frictionless experience and save a few megs of ram check out wezterm, it does a pretty good job of integrating multiplexing into terminal. also it’s very extensible as it’s configurable with lua.
on a side note, I had some stability issues with vscode-neovim where it’d crash it in worst cases.
yeah sysctl > regedit
'tis a meme… ;)
the real question is whether you use git
variants. Which is another way of not making arch (and Gentoo) certainly not free as in free beer, especially if you live in Europe and need to deal with those outrageous energy prices. btw imo one should be suspicious of projects with long tagged release cadence since it’s usually a sign of technical debt and the need to look for alternatives.
The X server has to be the biggest program I’ve ever seen that doesn’t do anything for you.
Ken Thompson
I see Wayland’s flaws but X is such a bloated piece of hardly maintainable spaghetti code that it is sadly beyond saving or prospects for anything in terms of significant improvement
well in this particular case it’s initramfs’ fault for not designing for all-or-nothing atomicity (a operation either completes fully or not at all). which you can work around with a terminal multiplexer where a session can be re-attached later in such cases btw.
well in my experience it was opensuse tumbleweed or Manjaro that were significantly less stable, but perhaps my perception is a little bit skewed since I use artix and it’s certainly not too rarely just the bloated, tightly coupled nature of shitstemd that causes some of arch’s issues.
Cool to see that after Cotowali was sadly abandoned due to lack of funding. Please, fund the FOSS projects you use!
Still don’t get why Go simultaneously picked this and introduced defer
Still shame they didn’t pick it for desktop and we had to wait years for a quality alternative client like Flare.
deleted by creator
>no GUIX, Parabola or Gentoo on a DRMed SaaSS platform
fitting
I mean, libraries access is good. But lack of tail call optimization support is not something you’d want in a functional programming language runtime. Luckily here Clojure somehow manages to fare better than Scala.
Clojure. Although it’s currently the most popular lisp but the ecosystem is not super lively and sometimes you need to rely on Java interop. This also severely limits the platform flexibility, if more things were written in pure Clojure or targeting BEAM or CLR it’d be nice. But luckily at least unless a library you use doesn’t rely on Java interop, the language is designed in a way that really reduces the bit rot.
Fun thing about it is that despite the S-expressions which you love to appreciate - I mean, it usually looks better than })
at the end of a Promise
/ closure in js or super deep nesting which you’d easily resolve using a thread last macro in Clojure. Therefore I’m also really excited that the pipe operator is finally coming to JS soon. Just add colored delimiters to your IDE. The virtual lack of syntax makes it quite easy to pick up.
With lisp semantics and minimal syntax that resemble the lambda calculus very closely, dynamic typing is rarely an issue (you can still specify types optionally), not to mention that pure functions are super easy to reliably test. Also, many things like DOM, nested data structures, b-trees (to a degree) or ASTs are actually structured like an S-expression tree, making Clojure good for such applications. All of this allows for clean code that does not feel like an assortment of free functions but is usually very loosely coupled yet everything seems to fit really neatly together like a coherent tree.
In general LISPs, as the name implies, are a superb tool for studying algorithms and DS in a way that allows you to focus on the problem itself more than the implementation, unlike in imperative languages where going into every little step in what feels like almost operating at individual CPU instructions at times can feel overwhelming and confuse the hell out of you.
Realizing the open-closed principle with Clojure comes pretty naturally since you’d more likely use function composition or write new transformations than modify the existing functionality.
Since functions are the primary unit of abstraction, dependency inversion is also trivial to adhere to.
Also protocols, which are somewhat more powerful than interfaces in some OO languages. They offer multi-method dynamic dispatch, retroactive polymorphism (extending types defined outside the current codebase), are independent from class hierarchy and are generally somewhat more succinct as virtually everything in that language.
First-class support for STM and immutability also make it good for concurrency like most functional PLs and make it a bit more intuitive than the actor model of Elixir/Akka.
Some Clojure frameworks do as well in certain benchmarks as those written in Rust.
Also compared to some other lisp dialects, the “primary” data structure is not a singly-linked list.
It’s goto data representation format, EDN is also a really nice thing.
And you have a REPL and get to choose what should be compiled AOT and what JIT. It’s most popular build tool, Leiningen is quite neat and in my experience has been a little bit faster in terms of dependency retrieval than Mix used by Elixir.
It can also transpile to js or dart. It generally is a quite flexible and extensible language where the said extensibility does not really make you feel the levels of inconsistency comparable only with PHP a couple years ago before they’ve decided to get it’s shit together as much as possible as can be the case with Haskell codebases that rely on a large number of language extensions.
And lastly, first-class documentation support but that should be a standard (looking at you JS and everything that still uses Doxygen)
Tbh Clojure’s greatest Achilles’ foot is the baggage of JVM with it’s lengthy stack traces, startup time, lack of tail call optimization, different paradigm and backwards compatibility issues. So if the question was which runtime you wish was more popular, I’d pick BEAM. But in it’s current state, whilst BEAM is more suited for functional programming, Clojerl doesn’t allow you to do much more than the standard library since many libraries wrap java, like web frameworks for example.
But on the other hand, JVM integration might make it easier for teams using Java or Scala to adopt Clojure.
Also it might not do the best job of handling bugs gracefully. This is good in the sense of giving you those almost Rust-like levels of strictness but without the lengthy compilation time but if you are looking for a way to move fast and tolerate some breakage, Elixir could be a better pick.
Also currying is not automatic and you have to use partial
or macros.
But speaking of macros, they are almost as neat as in Rust and much more intuitive than in C or Scala.
Good that you’ve enjoyed it. But a fundamentally wrong thing about systemd is that it is actively harming the best thing about Linux – freedom. Some programs won’t work on a non-systemd distro because how tightly coupled and vendor non-agnostic anything that becomes dependent on might become at times. Of course it’s not as bad as glib(loat)c, but still if something can be done without any degradation of functionality via standard POSIX facilities, WHY either incur additional maintenance overhead for non-systemd implementations or punish people for their computing choices if there’s no one to maintain it?
In Clojure,
->
is used for inserting the piped argument at the head position in the arguments of whatever it is passed to, while->>
is used for inserting it at the tail. This approach is great for working with immutable data in a series of approachable transformations, which I believe is one reason why so many Domain-Specific Languages for generative programming are written in that language, aside from its interactive REPL. Additionally, there is no need to worry about excessive copying, as this is generally well optimized.This can be particularly useful with HoneySQL, which is more of a DSL for SQL rather than a typical ORM tool. For example: