• 17 Posts
  • 50 Comments
Joined 1 year ago
cake
Cake day: June 16th, 2023

help-circle
  • mrh@mander.xyztoProgramming@programming.dev...
    link
    fedilink
    English
    arrow-up
    2
    ·
    2 months ago

    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.



  • mrh@mander.xyztoProgramming@programming.dev...
    link
    fedilink
    English
    arrow-up
    6
    ·
    2 months ago

    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.






  • mrh@mander.xyzOPtoLinux@lemmy.mlGuix on the Framework 13 (AMD)
    link
    fedilink
    English
    arrow-up
    6
    arrow-down
    1
    ·
    edit-2
    4 months ago

    Yes GNU Guix is a linux distro.

    The package manager for Guix (also called guix) is also a portable package manager which works on any linux distro, similar to flatpak, nix, homebrew, etc.

    Guix’s claim to fame is that it is a functional distro/package manager, meaning that all changes are atomic, so installing/upgrading/deleting packages never leaves your system in a broken state.

    Not only that, but if you make some change to your system and it breaks for normal reasons (e.g. newest software version has a bug), you can roll back to your previous system state with all your previous packages and their versions, and this roll-back operation is also atomic.

    Guix the distro not only let’s you do package management this way, but also let’s you do declarative system configuration. This means rather than manually rummaging around /etc changing files and hoping nothing breaks, there’s simply a single config file which declares all of your system configuration. From your kernel to users, partitions, system services, and just about anything else, all the configuration is declaratively done in one place with one language (Guile Scheme). Any changes you make to your system this way are also of course atomic and can be rolled back.

    It even comes with a built in system called guix home which lets you bring that same level of declarative, atomic configuration to your user’s home environment, letting you manage user level packages, dotfiles, env variables, and more with a single home configuration file.

    There are other goodies too, such as the ability to spawn one-off shell environments with the guix shell command, dropping you in a shell with all the packages and env variables you declare, keeping your regular user environment clean (very nice for development).

    There’s even more, but at this point if you’re still interested just head over to the site and the docs.






  • If I understand you correctly, this is trivial in emacs:

    (defun insert-text ()
      (interactive)
      (insert "your text here"))
    
    (global-set-key your-keybind-here #'insert-text)
    

    You could make it a format string if it relies on data specific to some file or parameter. You could also make the keybind local to certain modes/files rather than a global keybind if you don’t want to pollute your keybind space.







  • mrh@mander.xyzOPtoUnixporn@lemmy.ml[OC] GNU/LiSP
    link
    fedilink
    English
    arrow-up
    4
    ·
    8 months ago

    Yep! If you’re applying and need a non-trivial number of locations checked/maps generated, you can check out the prgoram here.

    Note that it says you can install it with guix, but it hasn’t actually been merged into master yet, so for now you do need sbcl and the dependencies (etiher via quicklisp or however else you snag them).



  • mrh@mander.xyztoGuix@lemmy.ml***
    link
    fedilink
    English
    arrow-up
    1
    ·
    8 months ago

    Can you share your config? Have you enabled substitutes (see here)?

    You can look at mine here (it’s pretty small): https://codeberg.org/mrh/dotfiles/src/branch/trunk/guix/system-config.scm

    That’s my personal config so you probably don’t wanna copy it verbatim, but it should show you how to do a minimal setup.

    I don’t use gnome, but to have gnome just add (service gnome-desktop-service-type) to the services field, and replace %base-services with %desktop-services. It might complain that you have some duplicates after that last step (since I add e.g. elogind service myself, but %desktop-services already has it), but when it does just do exactly what you’d expect and remove the duplicate service. See here for more info.

    I also have a few things in there from the nonguix channel, including setting up their substitue server, so be aware of that when copying things.

    My config also is setup with an encrypted drive and a swap partition. Again just take the things which make sense and ask about any specific questions you have.

    Also note that you should generally install most packages, like kakoune, at the user level, not the system level.

    Finally I would recommend joining the IRC channel at #guix on libera.chat. It is very active and people there are always answering questions.





  • 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.