I understand the general job market, but what about lisp prevents you from pursuing personal ventures with it?
I understand the general job market, but what about lisp prevents you from pursuing personal ventures with it?
Yeah Clojure is like the monkey’s paw of Lisp weenies. It adds many modern day niceties that are lacking in standard Scheme or Common Lisp, but also changes enough things to make it feel very un-lispy. I go back and forth as to whether or not I even consider it Lisp (Richard Stallman doesn’t).
But I do know that I’d rather write Clojure than any other non-lisp language.
I’d also recommend people try ABCL, which is Common Lisp on the JVM , or Parenscript which is Common Lisp that compiles to Javascript.
Lisp
It solves so many problems new languages have been invented to try and solve, while being simultaneously simpler than most
emacs org-mode publish
https://orgmode.org/worg/org-tutorials/org-publish-html-tutorial.html
emacs org-mode meets all of these criteria
I’ll never understand why we don’t just use s-expressions.
I think I said something a bit stronger than what I meant. I’m not averse to sharing my thoughts on posts, I’ve just never held it against a post if the OP happens to not provide some comment containing their thoughts on it.
I do see what you’re saying about not knowing what something is, and not wanting to spend ~1 hour on it to find out. Though I still don’t think that’s what downvoting is for (unless you have positive evidence that it’s spam).
Mainly I disagree with “I’ll downvote it to make room for the posts that are definitely good”. That’s just very much not my philosophy and not one I ever took to be a majority view. Downvoting for me means the content is not good/appropriate/whatever. It’s a sign of negativity, and being not definitely good != being bad.
I appreciate you being the 1/8 to actually state their reason!
Everything seemed pretty self-explanatory to me in a community like this since:
Also I wholehartedly disagree with downvoting something as spam when you have no idea what it is. And why do you need me to tell you what “we’re” doing here? It’s not for me to say whether this is a thread for roasting the game or praising it or anything else. I’m not sure I could even think of a more clear, straightforward title (and it’s simply the video title).
I also don’t feel it’s my obligation to share my thoughts on something I post. As OP I prefer for people to think for themselves and form their own opinion about the content.
I had the same thought lol
Yeah is there some specific reason that I’m missing? I’ve never posted something like this before anywhere on lemmy.
Metroidvanias of knowledge a la Outer Wilds
Have you heard something recent? I feel Signal has been saying that for years now.
I don’t care about XMPP as a protocol versus some other messaging protocol much, but I care a fair bit about the wdespread adoption of federated XMPP
I don’t quite understand what this means, could you elaborate?
if this service using this protocol becomes very popular, will the service seek to eliminate the open role of the protocol
That is a valid concern, though the point of the article is to try and convince people why it won’t happen like it did with Google or might with Meta for structural reasons (rather than “oh but we’re different” reasons).
The main difference I see with Snikket vs Google Talk is that Snikket is not only libre client software, but libre server software as well. The point of Snikket is that individual people host it themselves, not that the Snikket devs run a bunch of Snikket servers which require their Snikket client for connection and just so happen to use xmpp to power it. Really all Snikket is (right now) is a prosody server with some pre-configurations and easy install, as well as an android/ios app which are general xmpp clients that are designed to work well when connected with Snikket servers.
Now it could still go south in a similar way to Google Talk, in that maybe a bunch of people start running Snikket servers and using Snikket clients, and then the Snikket devs start wall gardening the implementation. That would be bad, but the users (both server runners and client users) would be in a much stronger position to pivot away from those decisions.
I think it’s at least an interesting idea (hence why I posted it) for the reasons the author mentions: striking a balance between trustless freedom and interface stability/agility.
That sounds roughly correct, though I don’t see the connection with the article? Unless you’re saying that “products” (like Signal) will always exist, which is probably true but is orthogonal to whether or not other models will succeed.
As for email, I think posteo does a pretty good job, but you’re right options are few and far between. But self hosting email is just as viable as ever? Perhaps less so since e.g. gmail will instantly flag your incoming mail as spam if you’re sending it from randomsite.tld, but honestly that issue hasn’t gotten that bad (yet). Yes, whenever there’s a protocol like email or xmpp, companies will create gmails and signals and turn them into walled gardens, but that doesn’t spoil the protocol for everyone else. It just causes frustration that companies build closed products on top of open technologies, but not much to be done about that.
You can mount any directory you want as the “home” directory of a given container with distrobox, it just defaults to using your home directory.
Thanks for the response! Flathub is a fantastic project so glad to hear about your contributions. Your videos have been helpful for me as introductions to Silvelblue ideas and statuses.
I don’t have much to say about the term “cloud native” personally, it doesn’t seem too important. I think myself and others react against it because cloud tech is mostly used by businesses and “server people” to deliver products (sometimes at the cost of user freedom), and so has either a non or negative connotation in the FOSS linux desktop space. But names are names, and accuracy matters most. I don’t think etiher “cloud native” or “immutable” are really all that helpful as technical terms though, maybe something else should be used (image based, atomic, container centric, ?).
I’m not sure I understand “distros already have htop.” Distros already have everything packaged for flatpak, yet they were packaged for flatpak. The real question is why do flatpaks exist at all if you can just run programs in containers, OR why do containers exist at all if you can just run programs as flatpaks (assuming everything we wanted were available as a flatpak). That is: what are the technical / UX reasons to choose flatpak over containers and vice versa?
Podmansh looks very cool! That’s definitely the direction I’d like to see these sorts of projects moving in. The #1 issue I have at the moment with this OS model is customization/tinkering/hackability. I want to have the niceties of atomic updates and reproducible builds, and containers on their own are great. But not if it takes away my ability to make my system fit my needs. I have no interest in using a macbook.
The future of these technologies looks bright, and they are clearly functional today, but I’m not sure any of them meet my needs yet as someone who likes to have a great deal of control and understanding of my system.
Yeah rollbacks are probably the best part of immutable OS’s, but of almost equal importance is reproducible system configuration, which imo only Nix and Guix do well. Neither snapshots nor Silverblue really manage that yet.
I actually recently switched (back) from Guix to Void for similar reasons.
I already knew lisp and functional programming so actually found Guix configuration via Guile a joy syntactically, so that wasn’t much of an issue. It really was just more complexity and overhead than I needed in my day to day system.
Even after having a good grasp on configuration semantics, I still find hacking away on things simpler on Void. I also feel like the whole system is transparent and at my fingertips, which I didn’t as much with Guix due to the abstraction layer.
It also was a bit slower and more resource intensive (though that’s true for all but Alpine when comparing against Void).
edit: I do feel norawibb’s point, the slippery mutability of Void is something I am a lot less comfortable with than I used to be. Apparently Guix has spoiled me.
Common Lisp “solves” most language-level problems by providing metaprogramming capabilities via lisp-style macros. (Almost) any language feature you would want can be implemented with lisp macros, and many such features already have been. So you don’t have to worry whether or not lisp has “for i in…” loops, or pattern matching, or generics, or virtually anything else, because if it doesn’t, you can write it! Plus if it’s really a good feature somebody has probably already made a library for it (if it’s not already part of the standard).
One of the most extensive examples of this is Coalton, which is an ML-style statically typed EDSL for Common Lisp.
There are metaprogramming features in a few other languages: template haskell, C pre-processors, even macros in Rust or Julia. But these all fall very short of lisp-style macros because those languages are not (truly) homoiconic, which makes the macros awkward to write and integrate into the language. This kind of metaprogramming is rarely employed, and when it is only for heavy duty tasks, and even then is generally discouraged as a last resort/special circumstance. But lisp macros are very easy to write because it’s the same as writing any other piece of lisp code. This results in macros being used often for smaller lightweight abstractions in the same way you write a small function.
The other big pro of lisp is image based development. But that’s not so much solving a problem in other languages as it is simply a feature that they don’t (and pretty much can’t) have.
And all of this is done in a language with less syntactic and semantic primitives than almost any other language, including the other “simple” ones like Python, Ruby, Elixir, etc.