[ prog / sol / mona ]

prog


Suckless-like Community for Scheme/Lisp

1 2020-05-16 16:08

There have been a few developer groups like Suckless. 2f30, cat-v or bitreich for example. For the most part, they seem to have been part of a Unix or Plan9 tradition, advocating and setting an example for what the so-called "Unix Philosophy" means.
Does anything like this exist in the Scheme/Lisp space? A group of people developing free-software utilities written in and for Lisp systems?

2 2020-05-16 16:58

I don't think so.

3 2020-05-16 23:05

Does anything like this exist in the Scheme/Lisp space? A group of people developing free-software utilities written in and for Lisp systems?

yes people write emacs plugins

4 2020-05-17 01:15

I remember one huge party in a student dorm. Party in every room, every corridor, you'd just mingle and hop from a small group of people to another. I think I was afraid of missing out on something. I told this girl: "hey Sanja let's find the place with the best atmosphere, the room where people are partying the hardest with the best music and the best alcohol and stay there". She told me "No dumbass! That's not how it works! We are the party! The best place is around us and people come to us, not the other way round". She was blonde and tall. She studied civil engineering. In astrophysics, accretion is the accumulation of particles into a massive object by gravitationally attracting more matter, typically gaseous matter, in an accretion disk. Most astronomical objects, such as galaxies, stars, and planets, are formed by accretion processes.

5 2020-05-17 08:05

>>3

yes people write emacs plugins

That's not really the same, because it's either individuals or a group of people focused on a specific project/package instead of an idea.

6 2020-05-18 15:17

Lispers are lone hackers. There's Cliki, kindof a community.

7 2020-05-19 18:26

>>5 The idea is having one lisp machine (emacs) being able to do almost every computing task you need. The idea of never having to leave Emacs to do anything. People have written music trackers, window managers, web browsers and email clients all for that end goal. It's definitely more tongue and cheek than the computing minimalism movement but it's the only thing I can think of when trying to think of lispers creating software that fits into a larger overall movement.

8 2020-05-19 21:41

>>7
Sure, but you get the difference. That's a "indirect" or "accidental" community, while I was asking for a explicit group of people one can join and collaborate with on explicit projects.

9 2020-05-20 05:54

Suckless is a community where anything mildly difficult to do which also isn't already provided by UNIX or C is "bloat" and should be avoided. Rather than seriously consider why the "UNIX philosophy" falls flat for many different types of programs, they instead attack the category and pretend it doesn't matter. They're mental midgets wearing stilts that don't work.

>>6
This is also a good point, and largely how I operate.

10 2020-05-20 06:00

>>1 >advocating and setting an example for what the so-called "Unix Philosophy" means.Does anything like this exist in the Scheme/Lisp space?

This is very confusing to me, a relative outsider, when the main example in this thread, Emacs, is a GNU project. Most of my encounters with Lisps have been in a unix environment. But I still see Lisp set in opposition to Unix, not just other programming languages, on a regular basis, as if there were this large contingent of hackers running Lisp Machines or working on ITS somewhere.

11 2020-05-20 14:02

>>10

Most of my encounters with Lisps have been in a unix environment. But I still see Lisp set in opposition to Unix, not just other programming languages, on a regular basis, as if there were this large contingent of hackers running Lisp Machines or working on ITS somewhere.

The argumentation here seems flawed. One can for example imagine a dissident who lives in a grim and dystopian society. Would it be reasonable to say that because this individual lives in this society that there is no opposition between the individual and this society? There are several differences between the Lisp approach and the UNIX approach. The first distinction, is on module boundaries. UNIX advocates small program where every program parses input text and serializes output text, while Lisp encourages the creation of interactive systems with modularity on the basis of functions which pass and return native data-structures. Emacs is an example of this despite its increased emphasis on text than some other Lisp applications. Another distinction is the difference between the “New Jersey style” and the “MIT/Stanford style”. Unfortunately, the decentralized development process some projects have taken has pushed many Lisp and UNIX projects alike in a direction which isn't inline with either of these philosophies (including GNU Emacs). This distinction still often remains with the Lone Lisp Hacker and the Lone UNIX Hacker however, and this distinction has dramatic implications. Yet another distinction is the focus of the UNIX hacker on constant time optimisations to the Lisp Hackers focus on complexity analysis. In practice these distinctions manifests as the difference between a hierarchical file-system and a tag based file-system, the difference between a text file and a binary representation of native data-structures which can be saved to disk or over the network, and the difference between an application which is fast in the best case but unusable in the worst, for example. There are many more differences I didn't go into as well, but I'd like to emphasize that it's clearly not the case that every Lisp programmer follows the entirety of the Lisp philosophy just like it's not the case that every UNIX programmer follows the entirety of the UNIX philosophy, and you can of course program Lisp in the style of UNIX.

12 2020-05-20 19:27

>>11

I guess what I'm trying to voice is my confusion over what I hear, which is a real desire for "lisp all the way down" in the community versus what I see, which is surface level lisp (especially wrt Schemes which don't seem to have images and the same ability to update an object and have everything that uses that object update, too that CL does). I mean Mezzano exists and uLisp exists and GUIX exists, and you could make the argument that you have to develop on what your customers are using, but 9front has been putting out regular updates for years. Maybe it's just that all the Lisp Machine IP is not available.

13 2020-05-20 19:30

>>11

Yet another distinction is the focus of the UNIX hacker on constant time optimisations to the Lisp Hackers focus on complexity analysis.

I don't recall ever reading about this noted quality, and yet I'm a Lisp hacker this describes well. I focus on the time and space complexity of my programs, in addition to the more concrete qualities where I can, as opposed to merely testing and measuring my programs on my few machines, and this usually leads to good results; I tend to do this with all of the languages I use, because it seems the most reasonable method. Am I to understand UNIX hackers try to write constant-time operations with fallbacks, which of course has the mentioned disadvantage that these can cascade and cause unacceptable performance? In plenty of instances, I recognize the opportunity to add special cases, but weigh them against the added code complexity and likelihood of triggering them, which usually has me leave the fine general code in place alone.

14 2020-05-20 23:32

>>12

I guess what I'm trying to voice is my confusion over what I hear, which is a real desire for "lisp all the way down" in the community versus what I see, which is surface level lisp.

Well, if I had to guess the biggest part of it is practicality. This of course effects every large project, but there are a few things that make Lisp operating systems less practical than other OS projects. Three that come to my mind are that the community of Lisp programmers is far smaller than that of C programmers, the second being that the Lisp philosophy is opposed to half-baked work, and the third being that the Lisp ideas of the way a computing system should work are so different from the status quo that it is difficult to create something which is capable of accepting foreign applications, and building on existing infrastructure. This is just a guess though.

>>13

Am I to understand UNIX hackers try to write constant-time operations with fallbacks, which of course has the mentioned disadvantage that these can cascade and cause unacceptable performance?

I misspoke, this wasn't what I was trying to say. I was trying to point out that in the most pure form of the UNIX philosophy any sort of optimisation is just seen as complexity and so it's avoided. Rather the domain space is constrained to some subset of the full problem where a naive implementation is suitable. The UNIX hacker works in C and writes naive algorithms so they naturally write algorithms with good constant, but poor big-O performance. Rob Pike for example is known for his rule: “Fancy algorithms are slow when n is small, and n is usually small.”

15 2020-05-20 23:46

>>12

especially wrt Schemes which don't seem to have images

Nitpick: A few Schemes do have images, most notably MIT Scheme (bands) and Scheme 48 (heaps), but they're nowhere near as elaborate as CL's.

16 2020-05-28 23:26

I realize a lot of things have changed in the OS world since the early 90s, but Lisp Machine Lisp is still a thing that already exists as a guide for implementation. uLisp, also exists as a Lisp that will talk to ARM and now RISC-V hardware at a low level. It just seems like if the UNIX-WINDOWS world were that incongenial, there would be at least enough substrate for some talented hackers to grab the Chine ual and see what they could do with, say a Raspberry Pi.

17 2020-06-06 09:44

This was posted in the scsh thread: http://www.ccs.neu.edu/home/shivers/papers/sre.txt

Maybe designing and implementing 100% solutions for Scheme would be a good goal for a community of practice.

18 2020-06-06 17:05

>>17

Maybe designing and implementing 100% solutions for Scheme would be a good goal for a community of practice.

It would be an excellent goal, as mentioned in >>11 this is one of the defining characteristic of the Lisp philosophy. Unfortunately, also as mentioned by >>11 the Lisp philosophy is far weaker than it used to be and seems to only persist in lone hackers currently. Olin Shivers is an example of this and so is Verisimilitudes with programs such as http://verisimilitudes.net/2017-12-31 (M-x shr-render-buffer to render in eww) To have such a virtuous group as these individuals would be extraordinary.

19 2020-06-07 18:01

>>17
Or extending suckless tools with guile...

20 2020-06-07 22:16

>>19
absolute disgust.

21 2020-06-07 22:21

>>19,20
What we've got here is the absolute incompatibility of the two infamously orthogonal approaches to software design.

22 2020-06-07 22:23

>>20
What would be suckless favorite Scheme implementation? TinyScheme? SIOD? S9fES?

23 2020-06-07 22:30 *

>>22
My vote is on S9fES. The author is fond of minimalism for its own sake, much like suckless.

24 2020-06-07 22:33

>>20
In itself, perhaps, but as a starting-point to lure minimalists away from unix dogmatism, it could be interesting. Especially if it would enable various programs to communicate more intelligently with one-another without pipes.
Could this be used for something like that: https://www.gnu.org/software/guile/docs/docs-2.2/guile-ref/Cooperative-REPL-Servers.html

25 2020-06-08 00:12

>>24
Intellectual diversity, single address space, you're hurting me.

26 2020-06-08 06:44 *

Numerical towers? Bloat.
Hygienic macros? Bloat.
Garbage collection? Bloat.

Scheme is considered harmful.

27 2020-06-08 10:11

>>25
I won't stop until I can reprogram dwm in Scheme while it's running or extend dmenu with custom programmed completion.

28 2020-06-08 12:09

>>27

I won't stop until I can reprogram dwm in Scheme while it's running or extend dmenu with custom programmed completion.

In that case enjoy your new project.

29 2020-06-08 13:52 *

>>28
I've used wmii before dwm and I don't miss any of the features, even though I created a lot of custom scripts for wmii taking profit of the 9P filesystem interface. I've configured dwm once, maybe 10 years ago, and haven't felt the need to change anything since then. I use these 3 patches: noborder, pertag and attachbottom. run-recent makes completions smart enough for dmenu and and gives me the ability to launch a command in a terminal (I really don't need that, I just run the command from a terminal)

The fact that dwm isn't configurable while running suits me well, I am not one who change habits easily. My setup is perfect for running xterm in fullscreen. It's like a glorified console, with better Truetype fonts and the ability to launch graphical programs (Gimp, feh, mpv, mupdf, QEMU, Vinagre, Mumble, Palemoon and Chromium would be an exhaustive list)

Customizations of the X11 server are done in .Xdefaults, .Xmodmap and .xbindkeysrc, they're only slightly modified once, when I get a new computer but they could all be redefined and relaunched while X is running. (xbindkeys is configurable in Scheme btw)

I'm sure there are many interesting Window Managers but I don't have the time to try them and I'd have to configure them to reproduce the settings I already have in dwm which would be a total waste of time.

Maybe I lack imagination and an extension language could provide me with features I had never thought of. Embedding Guile is not hard and I'd still be interested to see what you did in case you tackle that project. You could also ditch dwm completely and try that Guile framework for creating WMs: https://github.com/mwitmer/guile-wm

30 2020-06-20 12:57

>>24,27
Far more interesting might be to fork GNOME and replace the Javascript+CSS parts with Guile.

31 2020-06-20 17:17 *

>>30
Also polkit.

32 2020-06-20 20:01

I honestly never understood why JS was picked as the scripting language of GNOME. Surely it can't be only that it was hip to use it outside of web at the time?

33 2020-06-21 06:47

>>32
The only reason I can think of is that it had the best compromise of "there are a lot of developers familiar with it" and "it doesn't require a special runtime, such as the JVM".

34 2020-06-27 19:02

>>30-33
The GNOME Gitlab has a few discussions on JS (e.g. https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/836), but they always seem to be shutdown because those asking them just can't speak like normal people.

35 2020-06-27 20:52 *

>>34
Make a patch and speak their language, the "normal people" language isn't close enough, this is the internet with it's own variety of social rulings. Speaking their own language includes the patch following the same coding standards and philosophy of the project or the closest one, if the former is unavailable. If the philosophy is use atom and the latest web technologies, your efforts are better spent on another project, then say, changing the philosophies of the project.
This is hilarious and obviously either trolling or a theater setup by modern politics. By a specific side due to how these "trolls" are speaking.

We should be using C/C++ for GNOME not javascript. Please bring back C/C++. Or better yet, rewrite it in Rust!
Just benchmark Javascript with C/C++. You'll know the big difference in performance. Javascript is a HYPE! And its slow!
Oh really? This is the profiling I got during the time when Gnome Shell got SLOOOOOOOOOOW. If you see it clearly with your FOUR EYES, those are all Javascript at the top of slooooooooowness.

There's a bunch of stats after the above comment, using https://perf.wiki.kernel.org/ , Proving resource usage. This is what they meant by "point".
And then they caved in, which if this is trolling one should never do, you have just feed them.

Please read and understand https://wiki.gnome.org/Foundation/CodeOfConduct . If you'd like to be active in GNOME Gitlab, please use respectful language in future comments. Thanks for your understanding. Hence I'm locking this issue as even though you might have some point, it won't get discussed due to your choice of tone.

36 2020-07-13 17:00

At this point wouldn't it be easier to use StumpWM? It's a tilling WM written in Common Lisp and can do all things that you mentioned (and more).

37 2020-07-14 08:30 *

>>36

Sorry, I forgot to reference >>27

38 2020-08-15 21:18

Maybe we could have instead a Scheme study group.

39 2020-08-16 04:01

>>1
Unix and Lisp hackers don't mix well, and history shows.

40 2020-08-16 05:19 *

>>39
It's historical misunderstanding. They should get along well. They're all quiche eaters.

41 2020-08-16 09:02

>>39
There's an irony to that, because in practice, all modern Lisp'ers depend on and use *nix or *nix-like systems.
But at the same time, *nix still stands a lot to gain from Lisp/Scheme's lessons.

42 2020-08-16 12:10 *

>>39
I'm doing it anyway.
>>41
This comment describes what I'm doing.

43 2020-08-16 13:06

>>39
What is your OS?

44 2020-08-16 16:53

>>43
What are you trying to prove?

45 2020-08-16 17:14

>>44
I'm not trying to prove anything. I got into programming after the era of Lisp Machines (and Ada and Smalltalk machines, for that matter) was over, but just barely. Now, over 20 years later, I still hear (some) lispers talk as if there are lisp machines and I'm trying to understand it. Is this doing everything in emacs? Is it something else?

46 2020-08-16 17:24

>>45
Not that anon but there are indeed still some real physical lisp machines in working condition and reconstructions.

47 2020-08-16 17:53

>>45 there was never "Ada machines", because Ada was explicitly designed to target a variety of von neumann micro architectures, but there were for example Apl machines.

"lispers" talking like there's lisp machines is mostly a cargo cult, but driven by a genuine desire to escape the growing complexity of modern software. it's also perhaps an attempt to escape a certain kind of lack of control over software world: at any point in the project's life there might appear an activist or a group of activists, who, often through underhanded means, will implement some new and incompatible paradigm, which is supposedly "better", often done in the name of "security" or other such amorphous concepts.

a lisp machine is the same kind of holy grail as suckless stack. the idea is to escape the constantly changing technology landscape into your own little world, where you're in control of everything that's going on. often such attempts are about constructing an intentionally restricted, minimalist environment. so in the case of a unix head such an escape will be into suckless stack, but in the case of a lisper that escape will be into a lisp machine: it might be a "emacs all the time" approach, or it might be "running sbcl for everything". some crazy people actually try and run lisp machines in emulators, etc. i don't actually know anyone who has tried moving full time onto an actual hardware lisp machine, mostly because they are slow, finicky and unruly.

48 2020-08-16 19:21 *

>>47

i don't actually know anyone who has tried moving full time onto an actual hardware lisp machine, mostly because they are slow, finicky and unruly.

Oberon lisp on modern hardware can be fast and ruly but still finicky. I don't know anyone who uses a oberon implementation full time instead of just for fun but there might be a terry out there for oberon. Terry still didn't really main drive templeos.

49 2020-08-16 19:26 *

>>48
The cargo cult won't accept the oberon specifications for self made hardware being a true lisp machine, I forgot.

50 2020-08-16 19:48 *

>>49 this could've been an interesting conversation.

51 2020-08-16 19:50

>>38
The Society for Technological Contrarians et al.

52 2020-08-16 20:32

>>47 I was thinking of the Rational R1000.

But I look at platforms like the OLinuXino and it seems like the perfect place, (if someone wanted to) to start with a bare-metal lisp and work work your way up.

On the other hand, unix (to me) is so much more open than other platforms I've worked on, and more programmer-oriented so it seems confusing to me to see it as the enemy.

But I do get the frustration with computer systems that take up so much more space than they did 20 years ago (and I'm not sure why).

53 2020-08-16 22:03

>>52 yeah, you're right actually! i was writing up a response to 48, which i scrapped because he want all passive aggressive in 49, but in the process i was looking up some details about PERQ's microcode and learned that they also had one for Ada. there must've been more Ada systems out there, but i don't know anything about that.

personally i don't think that unix is the enemy, e.g. outside of autistic projects i use plan9port full time. i do think though that the projects that involve somehow hosting lisp on top of C machine and pretending like it's the real thing are misguided. not because of some purity concerns, but simply because of the mismatch and leaky abstractions. lisp microcode used to to support all kinds of lisp specific functionality: calling conventions, data types (all kinds of ways in which that affects GC for example), etc.

to paraphrase the bible, render onto unix the things that are of unix, and render onto lisp the things that are of lisp.

54 2020-08-16 23:39 *

>>53
Claiming corrections aimed at self and not others are passive aggressive is highly manipulative and fallacious. I'm disappointed, the concepts were important. You can call this comment passive aggressive and feminine if you want though. I was slightly interested in the opinion of oberon's hardware specification and someone more knowledgeable in a lisp machine.

55 2020-08-17 06:11

What's the most feminine Lisp? Is it Scheme?

56 2020-08-17 09:36

>>55

I don't know what the right adjective is, but Autolisp's K&R-ish style makes it stand out from other lisps. And there's lisps that de-paren like Dylan. Or Julia?

57 2022-07-31 10:49

Cat-V is considered harmful - they banned me on IRC for calling them normies and explaining how/why normies are bad for life.

58


VIP:

do not edit these