unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Attila Lendvai <attila@lendvai.name>
To: Csepp <raingloom@riseup.net>
Cc: Pjotr Prins <pjotr.public12@thebird.nl>,
	Felix Lechner <felix.lechner@lease-up.com>,
	Robby Zambito <contact@robbyzambito.me>,
	Sarthak Shah <shahsarthakw@gmail.com>,
	guix-devel@gnu.org
Subject: Re: A Forum for Guix Users
Date: Mon, 17 Jul 2023 17:41:33 +0000	[thread overview]
Message-ID: <k3heLWSnUov3I0Aynr3zVkMpArRRjOe2gZaFcghqL4c33lhyTbsEqSZ19xx3PiqgispMzOgSJI8KxMWbamBE2TbCsccPKViJoqYUOCCSZUg=@lendvai.name> (raw)
In-Reply-To: <871qh7tnn1.fsf@riseup.net>

> Like I've mentioned on fedi before, advocates of Lispy languages tend to
> talk a lot about what's possible with the language, but the truth is
> that the actual tooling that matters simply isn't very good, and having
> an S-expression based syntax doesn't magically make writing the kinds of
> refactoring tools that Java developers have been enjoying for 10+ years
> significantly easier.
> For that we need good static analysis, and unbounded dynamism and too
> much syntax magic makes that more difficult.
> At the very least I want to be able to rename variables across the whole
> project and jump to definitions reliably.


i came to Common Lisp from that world, and i don't miss those tools one bit.

those refactoring tools in the java world feel so useful exactly because of the linguistic inability to formally express abstractions in the language. when lisp is used properly (which includes discipline while naming abstractions!) then one doesn't miss those tools.

a related quote that captures this sentiment:

“[Design] Patterns mean "I have run out of language."”
	— Rich Hickey

but i agree that there's plenty of room for improvement in the lisp tooling, even for just Guile + Geiser to catch up with CL + Slime.

and i also agree that the learning curve is way too steep with Emacs + lisp tools. ultiamtely, i think it's worth it, but it does require quite some determination and frustration tolerance.


> ps.: As far as I can tell, the Lisps with good IDEs are image based, not
> source based, that's why they have an easier time doing metaprogramming,
> because the runtime helps a lot. But an image based system is not
> exactly in line with Guix's goal of reproducibility.


all lisps are image based in the sense that they are a VM once the source has been loaded... no? but, unfortunately, all (non-obsolete) lisps use flat text files to represent the source code. java tools turn that flat text source code into a graph and work on the graph, and does this text-graph-text conversion transparently for the user.

but it's only possible to do this conversion in languages that have a relatively little degree of freedom... which translates to less freedom to express abstractions... which in turn translates to a greater need for refactoring tools.

again, i most agree with you. what i wanted to express is that there's much more to this topic.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“It's surprising how many persons go through life without ever recognizing that their feelings toward other people are largely determined by their feelings toward themselves, and if you're not comfortable within yourself, you can't be comfortable with others.”
	— Sydney J. Harris



  reply	other threads:[~2023-07-17 17:53 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-13 13:52 A Forum for Guix Users Sarthak Shah
2023-07-13 14:05 ` Robby Zambito
2023-07-13 15:21   ` Csepp
2023-07-14 11:31     ` Msavoritias
2023-07-15 13:43       ` Attila Lendvai
2023-07-15 21:00         ` MSavoritias
2023-07-16  5:55           ` Julien Lepiller
2023-07-15  2:45     ` kiasoc5
2023-07-15 13:59       ` Attila Lendvai
2023-07-15 13:14     ` Tobias Geerinckx-Rice
2023-07-14 21:10   ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2023-07-15 13:27     ` Attila Lendvai
2023-07-16 10:33     ` Pjotr Prins
2023-07-16 23:30       ` Csepp
2023-07-17 17:41         ` Attila Lendvai [this message]
2023-07-17  7:37       ` Ricardo Wurmus
2023-07-17  8:17         ` MSavoritias
2023-07-17 20:29           ` Csepp
2023-07-13 14:40 ` Andrea Rossi
2023-07-13 22:38 ` vidak
2023-07-17  7:58   ` Etienne B. Roesch
2023-08-19 12:47     ` Simon Tournier
2023-07-18  1:52 ` Wilko Meyer
2023-07-18 16:39   ` Nguyễn Gia Phong via Development of GNU Guix and the GNU System distribution.
2023-07-18 21:12     ` Ricardo Wurmus
2023-08-19 11:54 ` Simon Tournier
  -- strict thread matches above, loose matches on Subject: below --
2023-07-14 20:19 Andy Tai
2023-07-14 21:17 ` Sarthak Shah
2023-07-14 21:26   ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2023-07-14 22:12     ` Wojtek Kosior via Development of GNU Guix and the GNU System distribution.
2023-07-14 23:50   ` Nguyễn Gia Phong via Development of GNU Guix and the GNU System distribution.
2023-07-21 13:30   ` 宋文武
2023-07-18 11:45 Distopico
2023-07-21  8:37 ` Etienne B. Roesch
2023-07-23 16:17 ` Ahmed Khanzada
2023-07-24  2:41   ` Csepp
2023-08-19 10:59 ` Simon Tournier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='k3heLWSnUov3I0Aynr3zVkMpArRRjOe2gZaFcghqL4c33lhyTbsEqSZ19xx3PiqgispMzOgSJI8KxMWbamBE2TbCsccPKViJoqYUOCCSZUg=@lendvai.name' \
    --to=attila@lendvai.name \
    --cc=contact@robbyzambito.me \
    --cc=felix.lechner@lease-up.com \
    --cc=guix-devel@gnu.org \
    --cc=pjotr.public12@thebird.nl \
    --cc=raingloom@riseup.net \
    --cc=shahsarthakw@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).