dokyun

Or another Organization plot...

Have you looked at it? It's an abomination. The point of SICP isn't Scheme or the syntax of Scheme, but what it represents. Whoever made the Javascript rewrite didn't understand that. You can't write a metacircular interpreter in Javascript, because Javascript is not homoiconic.

SICP isn't a book about Lisp, however it uses some of Lisp's unique properties to demonstrate important concepts that other languages can't easily replicate. A book that's meant to be similar to SICP that doesn't use Scheme or Lisp would not be anything like SICP, or at least not teach the same things. Haskell and ML are in my experience much harder to understand than Scheme, so I'm wondering what your difficulty is?

These aren't S-expressions...

As programs that utilize AI continue to become more prevalent, the concern for their freedom is going to become very important. It might require a new license, like a new version or variant of the GPL. In any case I believe the FSF is going to continue to campaign for the ethical freedom of these new classes of software, even if it requires new insight into what it means for them to be free, as they have done before. The FSF is also a much larger and more vocal organization than OSI is, even without the latter's corporate monarc--I mean, monetizers.

This is why I'd wait for the FSF to deliver their statement before taking anything OSI comes out with seriously.

WTFPL is a fine license. It's even FSF approved.

The group that claimed to be responsible for the first hack was said to be Russian-based, anti-U.S., pro-Palestine, and their reasoning for the attack was because of IA's violation of copyright....

I think you should draw your own more informed conclusions, but it smells a lot like feds to me.

It depends a lot on the problem, but I tend to visualize the /processes/ of the programs that I am working on, rather than the code itself: for example, if I'm writing a function that parses a string, I try to imagine it going over the string, finding the positions of individual characters and capturing substrings between them. If I'm working with asynchronous or network code, I try to visualize how the processes (or hosts) should be working at different times, and how they might send messages to each other.

I find it very necessary and useful a lot of the time to draw diagrams, or even just written notes on the problem I am dealing with. A lot of my mental visualizations are very clear, but it is difficult to retain several at a time.

And like someone else in this thread shared, I often have to get away from the problem and do something else for my mind to garbage-collect itself and have enough room to clearly think up new angles. For me only a matter of even a few minutes away from the computer helps a lot.

There's more 'cognitive overhead' to making CADADR etc. a macro that expands to the above when CAR and CDR don't work that way, since then its implementation isn't consistent with what it's meant to be. If you made it a macro with a different name then you have two slightly different versions of CADADR and every other accessor, which is even more overhead. Apparently this idiom happened often enough that it was deemed desirable to simply make it the default behaviour. Accommodating common idioms is a pattern of "the right thing" design, from which Lisp is heavily derived, and if you're not a Lisp programmer then keeping this philosophy in mind is a good way to not have misconceptions about the design of the system.

However, thinking in terms of 'cognitive overhead' for a very minor design choice is very silly. I don't suffer any 'cognitive overhead' from having CAR and CDR work on NIL when I write Common Lisp because I'm used to it, but I do suffer 'cognitive overhead' when they don't in Scheme, which is the 'alternate world with a different design'. I am incredulous to the idea that one is actually superior to the other, and suppose that it is simply a matter of preference.

It would be considered "the right thing" to do something that's so common you probably want it without asking. I don't think CADR would check for NIL since it's meant to be equivalent to (car (cdr x)), so if you wanted a safe list operation you would have to check it like this: (I'll use CADADR because it makes the issue more apparent)

  (and (car x)
       (cadr x)
       (cadar x)
       (cadadr x))

You would have to write this every time you want to see if there's a really CADADR, whereas if CAR and CDR can return NIL then you can just write (cadadr x) and CADADR can still be defined as (car (cdr (car (cdr x)))) and have the desired behaviour.

I don't believe so, standardly. Guile scheme added the value `#nil' which is equivalent to NIL and distinct from #f and the empty list, but this was done in order to support Emacs Lisp.

I recall reading that in early versions of Maclisp, taking the CAR or CDR of NIL worked differently: Taking its CAR would signal an error as you would expect, however taking its CDR would return the symbol plist of NIL, as internally the operation of CDR on the location of a symbol would access its plist, and that's how it was commonly done before there was a specific form for it (and it actually still worked that way into Lisp Machine Lisp, provided you took the CDR of the locative of a symbol).

Apparently the behaviour of the CAR and CDR of NIL being NIL was from Interlisp, and it wasn't until the designers of Maclisp and Interlisp met to exchange ideas that they decided to adopt that behaviour (it was also ostensibly one of the very few things they actually ended up agreeing on). The reason they chose it was because they figured operations like CADR and such would be more correct if they simply returned NIL if that part of the list didn't exist rather than returning an error, otherwise you had to check each cons of the list every time. (If somebody can find the source for this, please link it!)

> You seemed to imply there wasn't any reason for limiting extensions if you trust the author.

That may be implied but the precedent is not important. The bigger consequent point I am trying to make is that there is no good reason for limiting extensions at all, and my reasoning for that will follow.

> you can easily be sabotaged by the most trusted color theme author.

Okay. Let's say that we solved the hypothetical issue of colour theme authors sabotaging their themes by requiring color themes to use a format that can't evaluate arbitrary code, only dictate UI options.

Now what about all of the other packages that aren't color themes, that do more useful things and require greater breadth of functionality? I am not trying to separate things into functional and non-functional, as it is futile to do so--there are an infinite number of separations between the degrees of utility packages have, and once you have "solved" the issue of their insecurity by restricting one class of them, there are always more. And every time you do this you only degrade the freedom and extensibility of the entire system; you do not gain anything by it, you only lose.

This phenomena can be explained because it's really an application of Gödel's Incompleteness Theorem. For any program running on any computer, it will always be possible to induce conditions that the program was never designed to handle. Thus it is my belief that the entire field of computer security is really a joke, and anyone who sacrifices freedom for safety ultimately ends up with neither.

In practical terms a bit of security is useful, however Emacs is not the kind of program that benefits from it. It is not useful to waste time reasoning about which methods of security should be applied to a text editor. If you were using Emacs to run an air traffic control system then this type of thinking might make sense, but not as a reasonable or common case.

Read my other reply in this tree.

> You update all your emacs packages automatically without any code review. Then you start getting emails from your companies security team asking why you uploaded sensitive projects to a 3rd party.

If you do not trust the author or maintainers of a random program and refuse to review any code updates before installing it, then you are a moron.

I think if there is a concern that people would upload malicious packages, then there would be a level of trust put into the repositories that accept and offer them to review submissions before accepting them. This is still imperfect, but it shifts some responsibility off of you.

> Wouldn't it make more sense to restirct color themes to color and font related tasks? Why should a color theme be allowed to scrape sensitive code from your disk and upload it to a 3rd party without your consent?

Why SHOULDN'T a color theme be allowed to scrape code from your disk? Maybe the color theme is sophisticated enough to want to do that, or talk to some network. Something like a seasonal color theme that responds to the local weather might have a lot of hack value; and that is precisely the point you are missing. Emacs is not about restricting what you can and can't do, because the designers of Emacs understand that restricting what the user is allowed to do ultimately hinders freedom and creativity. It is one of the very few platforms left that's still like that, and I believe it should stay that way. If people want to use an editor that's very safe and tells them what to do rather than vice versa, then they should probably consider VS Code, or something like it which DOES upload your data to a third party without your consent, because it is smarter and knows better than you what you should be doing with your computer.

The biggest security nightmare that web browsers have to deal with is that they are always continuously running random JavaScript. Emacs' browser doesn't handle JS, which is a good thing for a simple browser. Emacs doesn't share this problem in that the Elisp that you run is all chosen by you, and it's always free and never obfuscated.

I don't really see how the XZ backdoor is relevant to this conversation, since these types of exploits are the fear of server operators, and generally not people who run user programs like Emacs on their desktop. A rogue Elisp function could delete all of the files in your home directory if it wanted to, but people don't really complain about that because being able to delete files is a desirable function.

If you ask me, Emacs is a program where user freedom is and should be the ultimate goal. Adding security features that the user has to jump around 'for his own good' and only really serve as idiot nets are dubiously effective and only hinder this freedom. If someone wants to install a package from a source other than the official archives, then the trust is placed in him to actually look at the source code he's received. Even if you install an official package you should still look at the code, as it's quite useful to know what's going on inside it when you want to configure it or add functionality. The vast majority of packages I use are a single file and tend to not take up more than a few screens, so they are easily understandable.

> - Implement better sandboxing and security measures for extensions.

Why, pray tell, should this be of any concern at all? Sandboxing is used when the host is concerned about running programs that he doesn't trust. There is no reason that an Emacs package would require security measures around it, unless it were knowingly potentially malware. The only reality in which I could see this is if people were using proprietary Emacs extensions, in which case I would entirely understand it, because then people would be willingly running malware inside their editor. Perhaps this the stance VS Code users like to take towards extensions?

It really is not poorly addressed, as it's a reasonable solution to the issue which also brings about it's own benefits. If you have your system configured such that the Emacs server starts up when you log in, by the time you actually start Emacs it will long have already loaded completely. If you actually use your Emacs for several things throughout the day, including but not limited to reading and editing text and documents, then it is likely you will have it always running during that time with several files open, and will find it useful to be using Emacs in the same state it was in the last time you opened it.

As an aside, having it running in the background was actually the way the original EMACS that ran on ITS was intended to be used: When you C-x C-c out of it, it does not kill the program, it simply puts it in the background, and the next time you invoke EMACS it brings it back up. This is similar in effect to hitting C-z, then using 'fg' to bring it up again, but this only really works in a terminal. The Emacs server achieves the intended effect better, especially on a graphical display.

That the video is entirely monochrome while also extremely fluid and intricate makes for an interesting duality when applying it to a technical problem, and that it's also a very pleasing and impressive work of art in of itself, I would think gives it many of the qualities that demosceners in particular appreciate.

> If a commercial company wants to ship a product without reinventing all the wheels, they are going to use code with permissive licenses, and skip projects with GPL license or similar in a heartbeat.

Did you know that there's no rule against commercializing or selling free software? The only reason that companies skip projects with copyleft licenses that's relevant in this discussion is because they intend to incorporate them into proprietary software, and this is because they are, by some deeply corporatistic scruple, incapable of conceiving of the idea of delivering free software (even if 90% of the heavy lifting in their services is done by free programs).

> You could even argue quite the contrary -- when you make your project GPL/AGPL etc, and if it is big/impactful enough, people will inevitably create alternative projects with permissive licenses that tried to match the feature set, and it is you that is the cause of all this "waste of time". Not necessarily a good argument, but there is some truth there.

Yes, it's not a good argument. The truth there is that if I develop a free program or library under (L)GPL or similar then I have made that thing free. If people want to write an alternative for technical reasons, then that's neither here nor there, but if people want to write an alternative because they don't like the license, then that's their own time they are wasting, because they would have no other reason to do it other than wanting to incorporate it into nonfree software.

There's a whole handful of permissively-licensed, feature-matched alternatives to GNU Readline that I suspect only exist due to political aversions to its license. It saddens me that these people would rather waste time treading over the same paths others have just to increase the potential for nonfree software, rather than using that time to write free and useful things.

> That's an interesting counter-take and it makes me wonder if Rust isn't a third thing... not the clean sparse MIT approach but also not the wild YOLO slop of C and Unix. Something correct but also complex and pragmatic.

I had supposed this in a previous thread, and I agree it is another thing entirely, however whether Rust is 'correct' or 'pragmatic', I think is a matter of contention.

> (1) Worse is free -- the "worse" stuff tended to be less encumbered by patents and closed source / copyrights. This is particularly true after GNU, BSD, and Linux. Free stuff is viral. It spreads fast and overtakes everything else.

At the time it seems that the "worse" stuff was actually more encumbered--GNU started to exist as a consequence of Unix both becoming an industry standard and solidifying the position of nonfree software in industry, and it didn't get that way by being free--they simply licensed it away en masse to universities. The free software movement was born out of the MIT hacker ethic of sharing software freely (GNU brought the design philosophy of MIT to Unix systems, and largely stands opposed to the "worse is better" approach. It originally sought to replace parts of Unix with superior alternatives, such as Info over man pages). BSD didn't become free until much, much later, at which point Linux had already become relevant.

> (2) Programmers like to show off, and "worse" provides more opportunities to revel in complexity and cleverness.

I think maybe C or C++ lets you show off by hacking around the compiler to do certain things that look impressive like preprocessor hacks or obfuscated code, but I think many would agree that this kind of style isn't "correct": languages like Go were developed as a consequence of this in order to suck any and all fun you might get out of hacking C, in order to force you to write more "correct" programs. Lisp, on the contrary doesn't tell you what a correct or incorrect program is, and gives you every facility to write programs that are infinitely complex and clever.

To me, Rust looks like the result of trying to break the rules of industry languages, by trying to incorporate things like real macros and type systems into something that resembles a real-world language. But it's biggest flaw to me is that it doesn't break enough of them, rather it makes more in the process.

....so why is it so slow to generate code?

Rust is not the MIT approach, because an important aspect of that approach is that it's conceptually simple. Rust is a leviathan of complexity both in interface and implementation. Common Lisp is an MIT approach language, and approaches the same problems like memory and type safety by doing "the right thing" by default and offering more advanced options like type annotations and optimization levels in a "take it or leave it" manner. Rust will force you to program the way the compiler wants in the name of safety, while Common Lisp will allow you to program safely and freely, and decide which parts are important. An observation of this idea is that Rust compilers are terribly huge and slow because they use static type-tetris for everything, while Common Lisp compilers are very fast because they do most type-checking at runtime.

No, the explanation is that it's hilarious.

I think he's hilarious, and at a time where a lot of programming pundits only pretend to be subversive and shameless, I welcome Xah's unflitered presentation of his opinions. He often makes a lot of good points, and I tend to find his stances on things thought-provoking even if I disagree with him.

It doesn't look like Xah was really trolling here, most of his responses are pretty polite. And he seems to indicate at this point in time he wasn't really familiar with lisp, so I'd venture to guess he wasn't nearly as prominent as he later became.

My point is that for people who wish to experience a Lisp Machine system for what it is, and explore its unique concepts, they have free systems they could be looking to rather than a dead proprietary one.

Yes, and the Medley Interlisp revival project seems to have become very successful.

Another thing is, that despite Genera having been gone from the real world for over 30 years, it is still nonfree, and most of the interesting software that ran on it hasn't been publically archived either. That has made it essentially worthless to most people who would otherwise be interested in it. On the contrary, the MIT Lisp Machine system from which Genera was derived is completely free, as well as the LMI system which was another derivative. And there are a small handful of enthusiasts who continue to use, share and improve them.