Welp... he hates JavaScript because of things he thinks he knows about JavaScript even though he's stating he knows nothing about JavaScript. Then he continues to ramble on about how browsers run JavaScript.
Someone so influential, and who sets the ethical standards for free software, should really do their homework.
I don't get why he didn't just say, "we won't support other languages because that's our vision for this software" and had to go into a bunch of unrelated bullshit. That's why no one listens to RMS's good ideas, because he talks about stupid, unrelated bullshit all the time. This talk was supposed to be about the future of Emacs, but the first part of it was dedicated to ranting about web JS?
He didn't state any technical reasons, or even related ethical reasons, why JS is bad for Emacs. RMS ranted on unrelated subject matter: that JS is used for "evil" in the web browser world. Why does that taint JS as a language in any way?
You quote the word “evil”, but RMS did not use that word.
If you actually listen to (or read) what he said, he explains it quite well:
“Emacs is supposed to defend your freedom. It's supposed to help you to defend your freedom, and lead you to defend your freedom, which means it shouldn't lead you to throw your freedom away as soon as you visit a site that tries to send you a non-free program to run straight off of that other machine. So it's important not to lead users to do computing this way.”
I.e. if Emacs were to run JavaScript, people would use Emacs as a web browser, which would make Emacs help users run various privacy-invading JavaScript software.
So it's important to RMS that our software protect us from using it in the way we want if that way is going to harm us according to his personal ethics and morals? Seems sketchy to me. RMS might want to consider retiring and letting his past work define him, as he seems to be thinking and saying some dumb shit lately, IMO.
I don't know why I care what he thinks so much, I don't even use Emacs. I just bristle at his dumb moral reasoning behind what should be as simple as, "we want to focus on things other than JS support, and we also want lisp to be the primary language interface, according to our vision". His whole argument here is just moral and ethical grandstanding.
> His whole argument here is just moral and ethical grandstanding.
I don’t think it is a moral or ethical question. The more freedoms you give away to companies with significant market power, the worse off you are in an economic sense.
See Microsoft’s takeover of open-source .NET libraries and VS Code extensions, the Intel Management Engine, the glued in batteries in Apple devices, Google’s efforts to make alternative OSs harder to run on Android devices and ChromeBooks which in their factory form are built to track you, Toyota’s subscription model to keep your remote key fob functional, Mercedes’ subscription model for acceleration, and so on.
You buy hardware, you use (and often buy) software, and they are more and more locked down so you don’t truly own them and are more and more designed to force you to pay more of your money.
Ah, so you didn't listen to the first half of the video, in which he said, that JS would be a less beautiful and less powerful language than elisp and that it would split their focus? OK! But keep the claims about what he said or did not say comming.
Presumably because of emacs-ng [1], from the page " additive native layer over emacs, bringing features like Deno's Javascript and Async I/O environment, Mozilla's Webrender,".
Oh I don't know. Back in school when asked to write a response to an essay, if I focused on the distraction and not the main point, things didn't go well.
I didn't say it was good to focus on it, just that obviously people are going to.
If someone wants to communicate a particular point, it's wise for them to eliminate the rabbit trails and distractions from what they say. It's especially distracting to the programmer-type if the side point is badly argued.
Human nature is, alas, fairly predictable in the large.
Technically, nothing. But in practice, if Emacs ran JavaScript, people would overwhelmingly use Emacs to browse the web, which would involve the normal step of running the scads of non-free JavaScript code which is present on seemingly every web page. RMS is not aiming to simply have a technical excuse to claim that something is not his fault, he wants people to actually get into a better situation than they are now in. Therefore, it would result in a practically bad result if Emacs were to be used in this way.
> [00:03:46.280] However, the language that we above all shouldn't support is JavaScript. That's not because of the language itself. I don't know the JavaScript language, I've heard people say it's rather clumsy and not well designed
Even people who like JS think it's clumsy and not well designed. I love the asynchronous-by-default nature of JS and I certainly don't hate the language as a whole, but it can be a weird mess. Consider type coercion, the way Date doesn't store timezones, the legacy implementation of parseInt() that tried to detect the radix, etc. From a lisp perspective it has many of the usual problems of C descendants, too.
He also had to go out of his way to make sure that “improve emacs ergonomics” is conflated with “change everything we’ve ever done to be VS Code”. Which has been the standard refrain any time the topic of improving onboarding for new people comes up.
The guy is walking hyperbole, I will never understand why so many people idolize him.
> He also had to go out of his way to make sure that “improve emacs ergonomics” is conflated with “change everything we’ve ever done to be VS Code”.
Not sure how you get that from:
> Lots of people come to Emacs familiar with VS Code, and they say, "Please make Emacs more like VS Code. Change everything that you did in the 1980s and 90s to be like that other thing." That wouldn't be feasible even if we wanted to. Our goal is not to be... not resembling VS Code. Any resemblance is coincidental.
It is probably the “change everything that you did in the 1980s and 90s to be like that other thing”.
He wasn’t quoting someone, he was being hyperbolic. Hyperbole that says “if you don’t like it exactly like I made it than you’re unreasonable and your demands doubly so”.
> The guy is walking hyperbole, I will never understand why so many people idolize him.
People admire those who put their morals before personal gain, which is exactly what RMS has done. With his intelligence and academic pedigree, he easily could have made gobs of money doing things he considered unethical, but instead he's devoted his life to protecting what he sees as an important aspect of human freedom. Even if you don't like him or agree with his views, the commitment he has to human human is admirable.
He won a million dollar McArthur grant and promptly purchased properly in Massachusetts with a chunk of it, and was been the owner of record for many years. It has escalated in value as you'd expect.
It's not terribly hard to find the details, but dropping them directly on HN seems rather counter to the general stance on doxxing people with things like "the address of a house they own".
I don’t find anything admirable about RMS. He is caustic to people in mailing lists, defended a colleague accused of participating in sex trafficking by stating that the victim must have presented as “entirely willing”, has referred to child sexual abuse as “voluntary pedophilia”, and has a long, long history of accusations of sexual harassment against him.
All of which makes arguments about his superior morality pretty dubious to me.
Sigh, this again. I expect better from HN than getting mad at things based on blind keyword matching.
> must have presented as “entirely willing”
Everyone insists on interpreting this as "Stallman thinks she was entirely willing", which is obviously not what he said in at least two ways:
First, he said it was possible, not that she "must have", and advocated for not drawing conclusions without full information.
Second, "presented herself as entirely willing" is different from "actually was entirely willing", considering we're talking about a woman who was being coerced into things. Nobody's seriously claiming the latter, but the former is a different statement, one that leaves open the possibility for Minsky to simply not have thought of the alternative at the time.
> has referred to child sexual abuse as “voluntary pedophilia”
I read it as an "I, personally, would not be bothered by this, and it hadn't occurred to me that anyone would be traumatized by it" thing, which would be consistent with his obviously-some-kind-of-neurodivergent mind.
> First, he said it was possible, not that she "must have", and advocated for not drawing conclusions without full information.
He didn’t say that it was “possible”, he said it was the “most plausible explanation”. Those statements are not the same because one implies a certainty of truth. He defended this heavily in a 20-something page long email thread.
> I read it as an "I, personally, would not be bothered by this, and it hadn't occurred to me that anyone would be traumatized by it" thing, which would be consistent with his obviously-some-kind-of-neurodivergent mind.
You’re right, he eventually relented and said we probably shouldn’t be doing this. If this were the only questionable thing he had done and he later said “you know what, I was wrong” then I would be much more willing to give him some leeway here. However, that just isn’t the case. His entire academic career has been riddled with inappropriate behavior and misguided statements.
Stallman tried to defend his accused-rapist colleague by asserting that we need to be “scientific” and look at facts. I agree, and the fact is that RMS has a long-standing pattern of behavior that trends towards immoral, misogynistic, and hateful. Scientifically, you can’t cherry pick the one time he doubled back and admitted he was wrong and ignore the overall trend.
If you personally choose to ignore all of this and worship at the cult of personality here, that’s fine. You do you, I’m obviously not going to convince you that zealotry is wrong. But asserting that he’s some paragon of virtue for his humanitarian fight for the freedoms of software is just laughable.
> He didn’t say that it was “possible”, he said it was the “most plausible explanation”.
You're right, I had misremembered. This is still not the same thing as "must have", but it is much scloser.
I still have trouble seeing this as problematic, because it's still explicitly referring to "presented herself as willing" and not "was actually willing".
> If you personally choose to ignore all of this and worship at the cult of personality here, that’s fine. You do you, I’m obviously not going to convince you that zealotry is wrong.
This is another example of you reading a lot into what someone wrote that they did not say. I wish people would stop doing that.
I think he takes the free software thing well past the point of counterproductivity.
Separately from that, yes, he's said some other things that are not socially accepted, many for good reasons. I didn't even respond to the last paragraph of your comment, because I have no counterargument to it. This does not mean he is automatically wrong about everything.
I simply empathize with him in some specific cases, because I also live in a world that's actively hostile to me in many of the same ways. I just wound up with more social skills and less executive function than he did. This is very different from agreeing with everything he says. People are complicated.
He was having an entirely understandable emotional reaction to the idea that his beloved mentor might have raped someone, and leapt to Minsky's defense.
What he did, though, was not "be scientific and look at facts," it was knee-jerk defending of someone he loved and respected, in the guise of being hyper-rational.
idolize may be too strong. in my case i just see a dude who started a big project long ago with lots of good bits in it, which is worth a bit of respect
"That's not because of the language itself. I don't know the JavaScript language, I've heard people say it's rather clumsy and not well designed, but I don't know this. In any case, it's not what my views are based on."
He's pretty clear in the, what, 2 minutes tops?, that he spends on the topic.
The complaints here mostly seem to be "I don't like RMS so I'm going to overstate some complaints about what I've decided he said instead of what he actually said."
His complaint about JavaScript doesn’t really make sense on several levels.
(1) Things websites do that he doesn’t like aren’t all done by JavaScript. Some of the most insidious tracking on the web is done with script-free methods like tracking pixels, link decoration parameters, redirect bounces, etc.
(2) his comments about the horror of downloading and running programs betray a lack of understanding of the security model of the web.
(2) His logic amounts to: “a language is used in a programming environment where some bad things sometimes happen. Therefore don’t use the language for anything else.” This is childish purity based non-logic. Should we also avoid HTTP? CSS? I hear a lot of browsers are implemented in combos of C, C++, and Rust. Should we avoid all those too?
His primary concern is user control. JS typically puts others in control by nature of its distribution and widespread use. Opting out or taming it is becoming increasingly impractical.
I don't think RMS is much of a fan of non-JS tracking either.
> The problem comes not from the language JavaScript, but from the fact that browsers, by default, will pull in JavaScript code that gets sent to them and run it to do anything at all. Emacs is supposed to defend your freedom. It's supposed to help you to defend your freedom, and lead you to defend your freedom, which means it shouldn't lead you to throw your freedom away as soon as you visit a site that tries to send you a non-free program to run straight off of that other machine. So it's important not to lead users to do computing this way.
I don't know how this is related to extending Emacs with JavaScript, but it's more or less correct about how JavaScript works in the browser (modulo "anything at all" being "anything at all in the browser sandbox"). If you only want to run free software, you necessarily must disable JS in your browser.
That's not a language issue, but a platform (i.e. browser) issue. It's entirely possible to enable JS and not have this as the default.
In Emacs, you can install any package that will then do most/all the evil that JS can. In principle, you should be very careful about the packages you install.
That's what he said, more or less: "The problem comes not from the language JavaScript, but from the fact that browsers, by default, ..."
I think it's the cultural issues he's getting at. Minified or otherwise obfuscated elisp packages would rightly be viewed with suspicion. Unauditable JS is the norm, right?
He had devoted a part of the talk about browsers too, starting with:
> But one thing I think we really shouldn't have is the equivalent of a modern web browser.
I think people are focusing on the Javascript part alone too much, when he made it clear numerous times that he is talking about the browser model, not javascript language itself.
but... if he doesn't want the equivalent of a modern browser, then downloading and executing JS isn't really an issue, and thus the whole JS=BAD because you download it and execute it goes out the window.
I don't get it. Like, i don't care if we can write emacs stuff in JS or not, but i don't see how it's any more dangerous than Lisp.
I agree, his reasoning is strange: JS is used in other contexts to compromise user control. We want user control. Thus we will avoid Javascript in this context.
I mean he is only saying JS=BAD in the context of downloading and executing obfuscated non-free javascript. The scenario where JS isn't downloaded and executed (e.g. outside browser) isn't even being what's talked about here much less being also lumped into the BAD group, so it's weird that people here are making this about JS at all, when it's clearly not.
I don't understand the argument that Javascript isn't free. Every library I'm aware of is MIT or otherwise FOSS licensed, and (at least before Node.js and NPM came along) it isn't owned or licensed by a specific corporation. It's probably the most free programming language ever created.
It's RMS, so I know he's going to throw the baby out with the bathwater on this, then throw out the bathtub, then disassemble the plumbing, brick up the bathroom and never bathe again on principle, but Javascript has probably served as a greater benefit for FOSS culture than any other language. Certainly more so than lisp. Making it out to be an implicitly evil language seems... out of touch?
quick edit: I know the argument about privacy invading javascript software, but software can be free and still invade your privacy. That's got nothing to do with the language.
Just to explain, the non-free code JavaScript code he is referring to is the inline JavaScript code on individual web pages (which in turn often uses the large MIT-licensed libraries).
The JS mess has brought us megabyte huge blobs of minified JS that does who knows what, slowing down getting information to a crawl compared to what could be. Not all JS is like that, but a lot of people are actively participating in creating that mess.
I'm not a fan of RMS, but as you noted, his blurb in the talk wasn't "Javascript the language is not free", or even "Javascript the ecosystem is not free", it's about the privacy invading factor of JS in a modern web browser. Since, as you said, software can be free and still invade your privacy.
He just doesn't want this GNU project to include support for a language whose primary purpose seems to be invading privacy -- even if it has a lot of great secondary purposes and a good open source ecosystem. Given that the GNU/FSF projects are all about advocacy in the area of software freedom and privacy, it seems like a reasonable perspective to have. Yeah, RMS definitely takes things to an extreme, but I don't see the "JS is implicitly evil" thing you're calling out, just refusing to appear to endorse or support something that goes against his principles.
And of course ironically enough those very principles mean he (should be...) perfectly happy with the emacs-ng fork, since that's part of the freedom he's advocating for.
> “b) we don't need JS to invade your privacy on the web... Does he browse without images turned on too?”
He doesn’t really browse the web at all:
“””How I use the Internet
I am careful in how I connect to the internet.
Specifically, I refuse to connect through portals that would require me to identify myself, or to run any nontrivial nonfree Javascript code. I use LibreJS to prevent nonfree Javascript code from running.
I am careful in how I use the Internet.
I generally do not connect to web sites from my own machine, aside from a few sites I have some special relationship with. I usually fetch web pages from other sites by sending mail to a program (see https://git.savannah.gnu.org/git/womb/hacks.git) that fetches them, much like wget, and then mails them back to me. Then I look at them using a web browser, unless it is easy to see the text in the HTML page directly. I usually try lynx first, then a graphical browser if the page needs it.
I occasionally also browse unrelated sites using IceCat via Tor. Except for rare cases, I do not identify myself to them. I think that plus Tor plus LibreJS is enough to prevent my browsing from being associated with me.
“””
The JavaScript on a typical web site is most definitely not free. Someone wholesale copied the Crunchyroll player code into a Kodi plugin and got a (legitimate) DMCA takedown notice.
On smaller sites there is no license, on commercial sites it's usually "all rights reserved"
It's too late to update, but most commercial sites no longer have an explicit "all rights reserve" message, presumably because minifiers remove the comments. However, in many jurisdictions (including the US) such a notice is optional anyways.
Emacs Lisp (and its data model) is quite different from what programmers are traditionally used to. We typically write software that runs completely unattended for years at a time. We communicate with unknown servers and APIs that change randomly for no reason. Everything that can go wrong, will go wrong, multiple times an hour. Thus, a programming language designed for that environment has to have error handling front and center, it's really all you're doing! Taking that to the extreme, code that refuses to compile because you didn't handle every possible eventuality is actually wonderful for making software that stands a chance of not being the ops team's (you these days) worst nightmare.
Emacs is not like that, however. The user of the code is likely a programmer, and the main data structure is the buffer of text that they're looking at. It's the one time in the world that you can just throw an exception and let the user handle it. They can just adjust the "memory" by typing stuff and trying the command again. Having written a lot of Emacs Lisp (and a fair amount of Javascript), I don't even know how you could make a nice API in Javascript that let you quickly put together quick editor tools, the fundamental design of the language just makes it more difficult than necessary. (You'll see this in the long tail of Emacs packages that the newer editors simply don't have. It's so easy to get started, and to finish!)
I'm honestly surprised that anyone has managed to write a text editor in a programming language other than Emacs Lisp. It's just such an impedance mismatch, it must be pain upon pain constantly.
RMS is right in the sense that users can't really inspect the code they get from websites. That is more of a webpack and browser issue than anything else. Emacs has great tools for inspecting the code you're going to run or are running (it's a keystroke away at all times), but I think you could build that for any language. And to be fair, I'm sure many Emacs users package-install stuff that they never look at, or even care that Emacs is free.
True, the rant kind of goes in the direction "I hate the web, and the web uses Javascript", which is kind of an irrelevant factoid. It's a very short rant, though, so maybe we shouldn't be reading into it this deeply.
If browsers ran lisp and the ecosystem was as advanced as that of elisp, then one could macro away some of the challenges of the modern web. If one liked to do so, they could opt to allow the execution of only GNU-compatible lisp code, and if people didn’t like losing one of their freedoms by a particular code segment, somebody else could modify the offending code and propagate it to a different part of the free web. Emacs is almost there. If there was a critical mass one could experiment a bit, but the vulnerabilities during the experimentation phase would likely kill such a project.
Emacs had (or still has) a web browser. The problem is that companies (starting with Netscape) took control of browser development, adding tons of both useful and useless features, with the goal of controlling the development of the web. Emacs and other projects cannot compete with that.
I agree. I see a minor glimpse of hope with people using mastodon for communication, and basic clients running within Emacs; perhaps eventually one could also have a personal server running (or at least controlled) within Emacs. Once the extensions are in Lisp, new types of opportunities open up. Maybe one day blog posts could be using org mode natively and allow for local/interactive elisp or other babel-language execution. Maybe an extension of crdt within Emacs is all that’s needed for interactive shared documents by multiple users. The web could be interesting in new ways, just like the multiplayer online games of the eighties.
I think his point is that browsers don’t run Lisp.
The culture of (Emacs) Lisp keeps inspectability front and center. You can look up the source code for every function with C-h f and every keybinding with C-h k. But if Emacs supported JavaScript, the culture of JS, including code obfuscation, would probably come with it too. Or that’s the way that I interpret it.
The great thing about open source is that you can just ignore RMS's opinions and write whatever you want. The great thing about Emacs is that it's easy to extend, you don't even have to fork it.
In fact, Steve Yegge has already written an EMCA-262 interpreter in Emacs Lisp, and given it the unfortunate name "Ejacs".
This has been the main thing RMS has wanted in Emacs since the late 90s or so. But I think not many Emacs users want it, nor many other Emacs developers. I think this is one of several cases where RMS is fixated on fighting the last war - in this case, vs. MS Word. But in the meantime, the importance of WYSIWYG document preparation as a main thing people use their computers for has greatly declined.
I don’t think it’s that odd. It’s just that probably you, like many others, see Emacs as a programming editor / IDE, while RMS sees the much broader applicability of this software.
Nowadays if you want WYSIWYG you don’t even own the data anymore, it’s a Microsoft or Google editor as a SaaS in the browser. So Emacs covering this use case too would be extremely powerful and coherent from the software freedom angle.
On one hand, I'm aware that most of what he's saying is wildly divorced from the vast majority of tech reality.
That being said: I never want him to stop or change. I still find his ideas and notions incredibly valuable and extremely good sticking points to always consider seriously, even if (perhaps ESPECIALLY IF) there's not much of chance one could actually practice them.
I've learned to listen to him before I judge strongly.
At first, a while ago, I thought he was quite eccentric and maybe similar to those wearing tin foil hats. But over time, I've learned to see that he is right about a number of things and I start to agree that we should have more control over our freedom when it comes to software and computing.
If we don't take an active approach in protecting our freedom, it will get removed before we ever knew we had that.
It has already been in many areas. I have worked with computers for almost 30 years now, and the kind of things that we need to endure nowadays because of a company's decision is truly absurd. We have entire devices that are closed using cryptographic methods controlled by the company that sold it. In the very near future, we won't be able to program a single line of code for most devices without having our identity strictly controlled by companies and governments. It is a dystopian future for computing.
I was thinking about RMS during the "spat" between Elon and Apple. Neither one of them have our interests at heart. Big platforms are bad in a lot of ways.
Stallman is a good example of the old "a stopped clock is right twice a day" thing. More interestingly to me, a stopped clock is precisely right in a way that a running clock never will be, for those two moments. But it isn't usefully right. A clock that is off by half a minute is useful all day for most applications. A stopped clock is useful only, maybe, for calibration but even then you have to wait half a day to get the chance.
Stallman is precisely right in a few very specific ways, but it's almost impossible to apply that precision to any real world problems we face. We can calibrate against it, and there's some value in that. But not that much I find.
I find that RMS predictions become true eventually (unfortunately). Just read something he said around 20-30 years ago (to have the benefit of hindsight).
Most people don't own a computer where they could install software freely (mobile). Personal data is collected in huge volumes.
All I want for Emacs is support for proportional fonts. I don’t care if it’s a major hack, and I don’t want rich text or WYSIWYG. Just proportional fonts.
Since it is not mentioned in the title or any of the comments (yet), thought it would be useful to say that this talk is by Richard Stallman and is from 2 days ago.
> [...] starting around two decades ago, there was an explosion in the complexity of browsers as companies wanted to have more and more control over exactly what would appear on a user's screen. So they invented lots of features to control that, features where the user couldn't really customize how something would actually appear because the whole point was that the company could control that. And JavaScript was sort of the ultimate level of "the company controls everything." Because of this, going beyond the simple level of web page formatting features in Emacs is basically heading down a path that leads to subjugation. It's a path that we need to stay away from. It's a path to an unjust world of computing that you can easily see around you. Web browsers nowadays are designed to display ads that you may not want to see. They're designed for DRM. They're designed for companies to snoop on you in unobvious ways. And all of that we should protect ourselves from, protect our users from.
Users already have a lot of control over what sort of content they view on the web. They can choose not to navigate to websites they don't trust. They can choose not to run javascript. They can disable css. They can set the font size they want. They can modify the contents of the webpage in a multitude of ways. Perhaps web browsers should have more granular controls and easier ways for users to override the browser's default behavior of rendering things like they're asked to, but then wouldn't that be an argument for Emacs having its own web browser?
Stallman's argument simply doesn't make sense. If I make my own website, I should be able to control what's on it. It's a user's prerogative to ignore all those things or modify it on their end to make it more usable for them. Is it user-hostile for me to, say, require javascript for my site to function? Maybe, but that's still entirely my prerogative as the person making the website. There's no obligation for me to make a website for everyone and there's no obligation from anyone to use my website.
A person should be able to navigate to websites safely and navigate away safely since there's no way of knowing what the contents of a webpage are before navigating to it, but that's about it.
> They can choose not to navigate to websites they don't trust. They can choose not to run javascript. They can disable css.
How do you settle on (dis)trust about a website? Just as you do with a person, there are 4 ways:
* reputation (meaning someone else already visited it and had to pay with bad experience)
* your own experience (meaning you already visited and were victim of the website)
* intuition (very poor driver, full of biases)
* homogeneity: a checklist of norms and conventions (can easily be gamed)
So in any case, it's either very uncertain or relies on others to throw themselves over the cliff so you can benefit from their experience.
So no, you cannot simply choose to not navigate websites you don't trust. It's just blind navigation and that's what most people, uninformed as they are, do.
> So in any case, it's either very uncertain or relies on others to throw themselves over the cliff so you can benefit from their experience.
Every human advancement has basically been a result of benefiting from other's experiences or insight. Sometimes you make your own individual contributions to human knowledge but you mostly don't.
> So no, you cannot simply choose to not navigate websites you don't trust. It's just blind navigation and that's what most people, uninformed as they are, do.
Sure you can. All the reasons you mentioned above are totally legitimate ways of establishing trust with a website. You absolutely can only visit websites that others have vetted, if you're someone so paranoid about webpages. Some people are pioneers and some are not.
You cannot avoid blind trust. Society as a whole hinges on the notion that people's behavior en masse is predictable and generally not destructive. How do you know, for example, that the groceries you just bought are not poisoned? You can't. You can regulate things but regulations cannot be perfectly enforced.
So yes, you absolutely can just choose not to navigate to websites you don't trust.
If it were trivial for anyone to disable unwanted behaviour in browsers, you wouldn’t see so much EU legislation being passed, forcing websites to make useless disclaimers.
On the one hand, browsers have a long history of breaking security principles. On the other, the web has been the most vibrant platform for enhancing user experience; the same commercial interests that RMS criticises have caused the world economy to flourish like nothing else.
If Emacs had somehow become the most popular VM in the world, I’m sure we’d see a lot more skepticism of it.
I do think browsers are more secure than Emacs today, because of the pressure of popularity.
But the criticism of the web being captured by commercial interests applies just as much: you are not ultimately safe from the government when you roam the web, because the technology is largely controlled by few actors.
You know that wasn't the point. If there wasn't as much investment in browsers and web tech, and as much money-making potential to motivate those investments, do you think the technology would be where it is?
The amount of bullshit jobs available is positively correlated with how well everyone is doing. I’m not sure how that impacts science negatively. There are lots of sciency startups on the internet.
> Perhaps web browsers should have more granular controls and easier ways for users to override the browser's default behavior of rendering things like they're asked to
Yes, I think that it would be good, but still the specifications and implementations of WWW are bad and tend to be trying to make the company to control everything, like they say.
Web browsers could be designed much better, although to compensate for bad specifications requires some messy details. (One thing that might help is for client software to use ARIA hints. They seem to want to use them for blind users, but I think they can help improve it for everyone.)
Instead, they make them worse, trying to hide stuff from end users, trying to believe they know better than the end users, etc. This makes things difficult to control, e.g. you cannot make non-tunneling proxies for HTTPS and therefore you need to take extra energy just to decrypt and reencrypt the communications, and the WebExtensions is rather limited, and you cannot usually make browser extensions in C, and the way that some things are core vs extensions makes many things difficult to change. And then, they will add spyware and stuff, and other inefficient stuff.
A web browser designed only for advanced users, who are assumed to know what they are doing, would be a good thing to have. (And, if you do not understand something, then read the documentation; programs must have good documentation, and unfortunately many do not, and that is what makes them difficult to understand.)
> but then wouldn't that be an argument for Emacs having its own web browser?
Maybe; they can see if a better one can be made. It shouldn't be a built-in feature of Emacs, but it could be a file included with it, and maybe it might help. Variants of Chromium isn't the way to make a better one, so it must be made differently.
> If I make my own website, I should be able to control what's on it.
Yes, but you shouldn't need to add all sorts of stuff just to concede to W3C's demand, to use Unicode, badly made HTML, etc (even if other file formats would be better, trying to serve them properly just makes a mess).
You can use just plain HTML, but it has many problems, and CSS/JavaScripts just makes even more problems.
Even if you can, it does not necessarily mean, that it is a good idea.
> Is it user-hostile for me to, say, require javascript for my site to function?
It depends on the site. For documents, it shouldn't. For some types of games, it might make sense to require JavaScripts, but it should be possible to view the documentation (and the link to the documentation) even without it.
- Be able to interact with anything else on the system, that can be interacted by C codes, including external programs
- More control, than using JavaScripts
A web browser designed only for advanced users, who are assumed to know what they are doing, would be a good thing to have. (And, if you do not understand something, then read the documentation; programs must have good documentation, and unfortunately many do not, and that is what makes them difficult to understand.)
I disagree, although even if there is a C interface, it can still be made to work with many other programming languages too, so if you prefer Rust (or Python, etc) instead, then you can use Rust and you do not have to use C. Either way, it allows native code will full system capabilities, which an end user might want in a browser extension.
(JavaScript-based browser extensions are still useful to make simple things without writing as much code, and also useful when you want to distribute portable sandboxed code for browser extensions, but for many other uses, C will be better.)
(It is true the C programming language has some problems, but so do all programming languages.)
But compare this "it's my website, I can be hostile to users with special needs if I want to" to the real world. In the real world many countries such as the US and the UK make having your shop accessible to people in wheelchairs a law. So you need to have ramps, or whatever to do this. We don't expect people in wheelchairs to carry the burden of this by requiring them to cart around their own ramps that they can place over stairs.
I strongly believe in accessibility technologies and accessibility on the web but I also don't think any individual should be required to make their webpage accessible. Regulatory barriers ensure that only those with sufficient resources are allowed to have a presence in that space. The current approach, which are guidelines (like WCAG) that most corporations and governments take seriously is a much better approach.
> The current approach, which are guidelines (like WCAG) that most corporations and governments take seriously is a much better approach.
It was only this year I even heard someone in industry talk about WCAG and their manager treated it veey low priority.
I'd wager most views that espouse "accessibility should be guidelines, not regulations" would 180 as soon as the person holding that view was affected by even the smallest vision disability and lack of WCAG compliance on a site they frequent.
> I'd wager most views that espouse "accessibility should be guidelines, not regulations" would 180 as soon as the person holding that view was affected by even the smallest vision disability and lack of WCAG compliance on a site they frequent.
It's not from a lack of empathy and I think that framing the argument that way is emotionally manipulative. There is a cost associated with making things accessible. If that weren't the case we wouldn't have guidelines like WCAG that teach people how to make things accessible. It's not entirely intuitive so it must be learned which is an added cost. For the government that's very obviously going to be necessary. In the US it's mandated by law that federal agencies' services must be accessible.
That's the scope that I'm comfortable with. The government is for the people so that naturally extends to all of its citizens, not just the able-bodied. Private companies don't have any such obligation to serve every person and individuals definitely don't. Guidelines are the right balance. You don't infringe on people's freedom of expression and you get iterative improvements on specifications that make it easier for people building accessibility tech to be on the same page.
> Users already have a lot of control over what sort of content they view on the web.
This is true, but if you want to use most websites, you have to give up a lot of this control in order to have any sort of reasonable experience (reasonable for most people that is, not a reader of Hacker News).
I believe though the authors of the websites should have control on how the contents are displayed, it's still more convenient if the raw contents or the contents following a specific standard of delivery is provided. And that's what I did for my website, by providing markdown source via git and web.
You actually got RMS's point: There's no obligation for you to make a website for everyone, but you could provide more convenience and compatibility by not _only_ making a website which needs javascript enabled. It shouldn't be assumed that everyone favors javascript and likes to execute javascript code from everywhere.
One may argue that would be easy to be scraped by bots. That's another issue.
> Is it user-hostile for me to, say, require javascript for my site to function? Maybe, but that's still entirely my prerogative as the person making the website
but that is exactly what he is talking about - ie the culture of user hostility (and also code obfuscation) in js front end development
I don't know about you, but most of the web applications online don't work without JS. Coupled with the fact that more and more applications are being moved online, I find that hard to say that users can simply turn JS off.
It's still a choice. I know this might be hard for people to believe, but there's still a lot of people that live their lives without internet and they can still do all the things necessary to live their life.
If you want to use a web application, then yeah, you probably need to allow the web browser to run JS because it enables those things to exist.
I disagree. This has been eroded in a continual and unstoppable way.
It's annoying because years and years ago my view of computing was very very positive.
I would have viewed something like web assembly as better and faster! Now I view it primarily as a way of obscuring what happens on your computer. We can see that web pages load and run fast enough -- it is just that most do not because they load the maximum number of advertisements and trackers that the delay will bear.
I find it interesting because I think a lot about computing on your own terms.
This is the norm: Vendor-locked hardware, operating systems that manipulate you into making choices that benefit others than you, software updates that remove functionality or render devices useless, access to multimedia that is revoked, services shutting down to make devices bound to them useless unless hacked.
And I think I seek problems when I insist on running Linux on known hardware. But I avoid. so. much. by doing do.
> Namely, it's [javascript] been adopted as a way for a network server to send a program to your machine without your even noticing, so that this program, written by you don't know who, will run on your computer and do you don't know what.
Is there any practical difference between running obfuscated Javascript or compiled WebAassembly and running an closed source binary blob?
Sandboxing and a limited api. As much as we love to hate on JavaScript for forcing the will of the company on the user, there are a lot of things you intentionally cannot do with it. Even something as simple as playing a sound without user interaction.
I think WebAssembly requires explicitly linking which functions you will use, and does not have as complicated objects as JavaScript, so handling sandboxing will be simpler. It also is presumably might be able run more efficiently than a JavaScript code. (I think WebAssembly has some problems too, but there are some advantages.)
Am I the only one who thinks it's entirely obvious that JS is a bad idea for emacs? The beauty of emacs is that it's all in lisp. All of it, except a small C core which is mostly just the elisp implementation. If you don't like lisp, why on earth would you use emacs? There's an absolute fuckton of editors out there that support Javascript.
I don't even care what RMS' argument was, I think he's pretty out of touch most of the time. But putting Javascript in Emacs is just a stupid idea that would completely ruin it eventually. Let Emacs be Emacs and Vscode be Vscode.
Agree. The beauty of lisp dev is that it’s a REPL that maintains state. You can edit the editor while editing. without restarting Write a defun and evaluate and it’s there. All the state persists. Most JS involves restarting the whole app on script change. I don’t use MS VS code because I can’t stand MS (if you know their history … you understand) Maybe they have the same feature now. Don’t know. The WYSIWYG editors are all web based. Maybe make a open source cloud hosted office suite? Google and MS should not have the only offering there.
There are a lot of people who want to do everything in Javascript. Frankly I don't get why people want to do that. And Lisp is not that hard to learn anyway.
You can learn lisp in half an hour. The hard part of emacs isn’t “lisp” it’s learning the libraries, just like it is in any other ecosystem. This difficulty would by present if everything was JS.
I believe that you are right about trasferrability. About difficulty, it depends. If you start from C, Java or PHP then JS is easier than Lisp, at least until you get into the async stuff. If you start from vanilla Python, JS is more complicated so Lisp is not so much further away.
If you start from scratch, they are both equally difficult.
Yes, I agree with this. My statement was based on most programmers learning a C-style language first. If you have experience in a functional language then lisp will be much easier to learn.
The things I learned from Common Lisp help me quite a bit in day-to-day JavaScript and Ruby development. The important transferable skills in programming are almost all language-independent, IMO.
It's the only programming language they know, since they grew out of being a "webmaster" but haven't learned properly about stacks of abstraction in computing.
The classic phenomenon of junior engineers that have become decent at programming but unexperienced enough that they want to rewrite everything, thinking they can surely do better.
Now this is endemic in the JS world, especially because it is more ubiquitous than the previous beginner language, PHP.
Let me be frank: ELisp is a terrible programming language. I have a number of Emacs packages (in ELisp) and Sublime Text packages (in Python), and the development effort difference between the two is not even funny.
That said, Emacs relies rather heavily on unique features such as dynamic binding, advice, and autoloads. These are more or less impossible to replicate in modern languages, so I don't think there's a reasonable path to rewriting major parts of Emacs in, say, Javascript.
But we should look at what Lua did for Neovim. There has been an explosion of development effort now that Neovim finally added a reasonable programming interface. A similar thing could happen in Emacs.
> But we should look at what Lua did for Neovim. There has been an explosion of development effort now that Neovim finally added a reasonable programming interface.
It is very much debatable whether Lua is the "reasonable programming interface" causing the activity in Neovim. Vimscript has many flaws, one of them being that it doesn't look like other programming languages, but it does its specialized job pretty well. It is slow, but efforts are made in that area. Lua is well designed but it certainly has its shortcomings too, and many argue (me included) that programming in Lua is not that pleasant. The Lua bindings have been available in Vim for quite some time, but they never were popular, for some reasons.
Anyway, it is not directly related to your point, but I think that example is not that compelling.
Lua is a really good lure. You add it to a project and a bunch of people go "oh neat, I've heard a lot of good things about lua, I'll do this idea I've had in lua."
And then the realities of working in lua accrete over months, but then they're in too deep. What are they gonna do, learn elisp? Admit defeat and switch back to VS code?
Personally, I'm using Haxe with its Lua backend. While wrapping Lua APIs is a pain, and some dynamic patterns are hard to represent directly, Haxe provides a lot of the things that Lua lacks: a gradual static type system, more familiar JS-based syntax, syntactic sugar for lambdas, sane handling of `this` in methods, control over inlining, immutable variables, generics, null safety, powerful hygienic macros, somewhat usable standard library, extension functions (Kotlin/Scala3 like), partial function application, hash and array comprehensions, functional operators on collections, limited operator overloading via abstracts, built-in LSP server, and a lot more.
I do this in the context of scripting my window manager, and plan to try this with Nginx/OpenRESTY. I feel like pairing LuaJIT runtime with Haxe compilation creates incredibly powerful combination. Lua provides coroutines, tail call elimination including corecursive functions, lightweight and fast JITed VM, a package manager (luarocks), bindings to important C libraries, FFI, reflection (everything is a table anyway), and more. The integration between Haxe and Lua is not yet seamless, and Lua compiler backend is one of the least developed, but even in this state I'm very happy with the combination of compile-time and run-time features I get.
Ha interesting, I didn't really expect a serious answer but very cool. I looked into haxe a while back when I was gearing up for a significantly complex project targeting lua 5.1.
I ended not using it mostly because of unfamiliarity and it felt like it would add a fair bit of complexity. Didn't want to pick up a whole new ecosystem for that project.
I ended up using fennel, which solves most of my practical problems with lua without really making anything harder. Doesn't help with the package ecosystem or build process but I ended up just taking that compromise.
Don't regret it, still use fennel anywhere I'm forced to use lua, including hammerspoon and mud client scripting. I think if I was going to work heavily in lua long-term I'd go back and invest in haxe for it.
Why do you think so? My main gripe is the lack of namespaces and proper modules, but there are many languages in Top 10 on TIOBE that share this problem. The only other problem is a clunky, decades old standard library. Lack of consensus around async processing is less important, but also irritating.
Other than that, Elisp improved tremendously in the last 5 years, and it keeps improving with every release. The stdlib is getting some long overdue cleanups and sensible convenience modules are added regularly. The language features of other languages are being readily incorporated in the form of macros. The live environment along with "self documenting" code makes for a rapid dev feedback, and tools like built-in Edebug and 3rd party packages like Paredit and EROS make editing Elisp code more pleasant than most other languages.
Obviously, Elisp has many problems, it's not ideal, but it's nowhere near "terrible" in my opinion. At least not anymore.
I agree with you! It's not really that bad. The two biggest problems for me are the lack of namespaces/modules like you said, and the default dynamic scope (with the ability to enable lexical scoping).
They're both basically just ergonomic issues at this point, with prefixing names and always setting lexical scoping being cultural norms.
Really? (Didn't have the time to listen to the talk.) I'd like to know if it was somehow measured, ie. how much of the Elisp code is still not adjusted to use lexical scoping and how much of such code would break by switching to lexical scoping. You can still opt-in to dynamic scoping by using defvar (and it's been a standard practice since forever), so the only scenario where old code would break would be where a called function accesses local variables from the calling function, like you would do in TCL with upvalue. I suspect that's a pretty small percentage of all the Elisp code in the wild; plus, this would be caught by the byte compiler, without the need to run the offending code. In any case: the change of the default is welcome, though not very important, as we've all already got used to putting `lexical-binding: t` at the top of every Elisp file :)
Yes! Prefixing names as a way of emulating namespaces generally works well enough. We could get modules support the same way JS used to have them, ie. as hashes of closures. Or we could use something like the `nameless` package, which rewrites the code to add a prefix to definitions automatically. Yet nobody seems to be doing either: it's just too much of a pain with too small a gain. The situation would be different if we got first-class module support in the language, but if we're going to only emulate it anyway, then namespacing with prefixes is just the easiest way to do it that is still "good enough". Still, Racket-like modules would be great to have, can't deny that :-)
Not everyone likes Emacs Lisp, but I think there are two main arguments - one is speed, and the other is familiarity.
Now that Emacs Lisp actually has native compilation, the speed issue is less of a problem, but it's a plain fact that a lot more people can do things with Javascript than Lisp.
I think usually if you have an application you'd prefer to reuse a programming language rather than having a language specific to the application. I think that was the main motivation for the failed port to Scheme.
I love emacs and don't live Elisp at all. I can use it, if pushed, but don't love it for sure.
Do i prefer JS? Probably not. But to me the draw of emacs is nothing to do with Elisp. It is instead everything to do with customisation, one-editor-many-languages, and the ability to do absolutely everything from a keyboard-based, low-clutter GUI.
Part of it is of course that good people made plugins in Elisp and maybe you'd argue that without it they wouldn't come to be, but I'm not sure.
> But to me the draw of emacs is nothing to do with Elisp. It is instead everything to do with customisation
I keep hearing this argument but it is contradictory: the reason why Emacs is so customizable it is because it is written in a Lisp, a very versatile metaprogramming language.
You simply cannot have the flexibility of Emacs in anything less malleable than a Lisp. You'd have a regular editor with plugins.
I know many will want to prove me wrong, but where is the non-Lisp Emacs killer yet? VSCode is a great editor, but it's nowhere as flexible.
A problem with jumping over to the current popular language is that JavaScript will eventually fade in relevance, as all programming languages do. At that point Emacs would be saddled with two niche languages, and the advantage of using what is popular will be lost. Emacs is the “editor of a lifetime” and I expect it to be around for another 40 years. Best not make decisions based on what the current trends are.
I was thinking that applications like operating systems reveal the language they are written in as they are extended and there is too much c++ in texmacs to port it over to emacs which appears to be written in c. I can’t really comment on guile without researching it but the low level ideas are between scheme and lisp are incompatible with the lisp language, and I think he mentioned that when he said ‘non-Lispy language would be a mistake’.
I do not use Emacs, although I can still comment, about the specific things they mentioned.
They are right it does not have to be VS Code; if you like that, then you can use VS Code. However, if you want specific features, then that is a different thing, and will have to be considered specifically.
If you want JavaScript in Emacs, it could be an external extension, maybe; it probably should not be included by default. However, if the model is different enough from Lisp then it might be hard to fit; nevertheless, such an extension might help if you need to run JavaScript codes designed for other editors that do use JavaScripts, without having to rewrite them (polyfills will be possible, if necessary). Lisp alone probably isn't ideal though, and you should be allowed to write extensions in C as well (I don't know if this is already possible; maybe it is).
WYSIWYG editing should have "reveal-codes" function also; without such thing, WYSIWYG isn't very good.
One thing I think would want to have in text editor is capability of non-Unicode text encodings which don't convert to/from Unicode. You just should not expect that everything is conversion in one unified character set; it does not really work.
No disrespect to Stallman, but it's hard for me to understand what problem he's trying to solve here. Various unofficial packages have made Emacs usable to me in my work as a software engineer, which combined with Emacs's unparalleled text editing capabilities and keyboard shortcuts make it a powerful tool indeed. Without many of those unofficial packages, I would be forced to use VS Code or some alternative.
In my observation, Emacs has been moving in the right direction, addressing outdated aspects and sources of lagging performance, and adding essential features like LSP support natively. I hope that Emacs contributors and maintainers can keep this focus.
189 comments
[ 3.3 ms ] story [ 213 ms ] threadSomeone so influential, and who sets the ethical standards for free software, should really do their homework.
If you actually listen to (or read) what he said, he explains it quite well:
“Emacs is supposed to defend your freedom. It's supposed to help you to defend your freedom, and lead you to defend your freedom, which means it shouldn't lead you to throw your freedom away as soon as you visit a site that tries to send you a non-free program to run straight off of that other machine. So it's important not to lead users to do computing this way.”
I.e. if Emacs were to run JavaScript, people would use Emacs as a web browser, which would make Emacs help users run various privacy-invading JavaScript software.
I don't know why I care what he thinks so much, I don't even use Emacs. I just bristle at his dumb moral reasoning behind what should be as simple as, "we want to focus on things other than JS support, and we also want lisp to be the primary language interface, according to our vision". His whole argument here is just moral and ethical grandstanding.
I don’t think it is a moral or ethical question. The more freedoms you give away to companies with significant market power, the worse off you are in an economic sense.
See Microsoft’s takeover of open-source .NET libraries and VS Code extensions, the Intel Management Engine, the glued in batteries in Apple devices, Google’s efforts to make alternative OSs harder to run on Android devices and ChromeBooks which in their factory form are built to track you, Toyota’s subscription model to keep your remote key fob functional, Mercedes’ subscription model for acceleration, and so on.
You buy hardware, you use (and often buy) software, and they are more and more locked down so you don’t truly own them and are more and more designed to force you to pay more of your money.
[1] https://github.com/emacs-ng/emacs-ng
Of course people are focused on it.
If someone wants to communicate a particular point, it's wise for them to eliminate the rabbit trails and distractions from what they say. It's especially distracting to the programmer-type if the side point is badly argued.
Human nature is, alas, fairly predictable in the large.
His sources are not wrong, though: it is clumsy and not well designed.
The guy is walking hyperbole, I will never understand why so many people idolize him.
Not sure how you get that from:
> Lots of people come to Emacs familiar with VS Code, and they say, "Please make Emacs more like VS Code. Change everything that you did in the 1980s and 90s to be like that other thing." That wouldn't be feasible even if we wanted to. Our goal is not to be... not resembling VS Code. Any resemblance is coincidental.
He wasn’t quoting someone, he was being hyperbolic. Hyperbole that says “if you don’t like it exactly like I made it than you’re unreasonable and your demands doubly so”.
People admire those who put their morals before personal gain, which is exactly what RMS has done. With his intelligence and academic pedigree, he easily could have made gobs of money doing things he considered unethical, but instead he's devoted his life to protecting what he sees as an important aspect of human freedom. Even if you don't like him or agree with his views, the commitment he has to human human is admirable.
He's a millionaire who has people provide him with travel and personal assistants. I am not sure what you think he's given up.
It's not terribly hard to find the details, but dropping them directly on HN seems rather counter to the general stance on doxxing people with things like "the address of a house they own".
All of which makes arguments about his superior morality pretty dubious to me.
> must have presented as “entirely willing”
Everyone insists on interpreting this as "Stallman thinks she was entirely willing", which is obviously not what he said in at least two ways:
First, he said it was possible, not that she "must have", and advocated for not drawing conclusions without full information.
Second, "presented herself as entirely willing" is different from "actually was entirely willing", considering we're talking about a woman who was being coerced into things. Nobody's seriously claiming the latter, but the former is a different statement, one that leaves open the possibility for Minsky to simply not have thought of the alternative at the time.
> has referred to child sexual abuse as “voluntary pedophilia”
That one was less defensible, but he did later change his mind: https://stallman.org/archives/2019-sep-dec.html#14_September...
I read it as an "I, personally, would not be bothered by this, and it hadn't occurred to me that anyone would be traumatized by it" thing, which would be consistent with his obviously-some-kind-of-neurodivergent mind.
He didn’t say that it was “possible”, he said it was the “most plausible explanation”. Those statements are not the same because one implies a certainty of truth. He defended this heavily in a 20-something page long email thread.
> I read it as an "I, personally, would not be bothered by this, and it hadn't occurred to me that anyone would be traumatized by it" thing, which would be consistent with his obviously-some-kind-of-neurodivergent mind.
You’re right, he eventually relented and said we probably shouldn’t be doing this. If this were the only questionable thing he had done and he later said “you know what, I was wrong” then I would be much more willing to give him some leeway here. However, that just isn’t the case. His entire academic career has been riddled with inappropriate behavior and misguided statements.
Stallman tried to defend his accused-rapist colleague by asserting that we need to be “scientific” and look at facts. I agree, and the fact is that RMS has a long-standing pattern of behavior that trends towards immoral, misogynistic, and hateful. Scientifically, you can’t cherry pick the one time he doubled back and admitted he was wrong and ignore the overall trend.
If you personally choose to ignore all of this and worship at the cult of personality here, that’s fine. You do you, I’m obviously not going to convince you that zealotry is wrong. But asserting that he’s some paragon of virtue for his humanitarian fight for the freedoms of software is just laughable.
You're right, I had misremembered. This is still not the same thing as "must have", but it is much scloser.
I still have trouble seeing this as problematic, because it's still explicitly referring to "presented herself as willing" and not "was actually willing".
> If you personally choose to ignore all of this and worship at the cult of personality here, that’s fine. You do you, I’m obviously not going to convince you that zealotry is wrong.
This is another example of you reading a lot into what someone wrote that they did not say. I wish people would stop doing that.
I think he takes the free software thing well past the point of counterproductivity.
Separately from that, yes, he's said some other things that are not socially accepted, many for good reasons. I didn't even respond to the last paragraph of your comment, because I have no counterargument to it. This does not mean he is automatically wrong about everything.
I simply empathize with him in some specific cases, because I also live in a world that's actively hostile to me in many of the same ways. I just wound up with more social skills and less executive function than he did. This is very different from agreeing with everything he says. People are complicated.
Unspeakable!
He was having an entirely understandable emotional reaction to the idea that his beloved mentor might have raped someone, and leapt to Minsky's defense.
What he did, though, was not "be scientific and look at facts," it was knee-jerk defending of someone he loved and respected, in the guise of being hyper-rational.
• https://stallmansupport.org/debunking-false-accusations-agai...
• https://sterling-archermedes.github.io/
He's pretty clear in the, what, 2 minutes tops?, that he spends on the topic.
The complaints here mostly seem to be "I don't like RMS so I'm going to overstate some complaints about what I've decided he said instead of what he actually said."
It's wild.
(1) Things websites do that he doesn’t like aren’t all done by JavaScript. Some of the most insidious tracking on the web is done with script-free methods like tracking pixels, link decoration parameters, redirect bounces, etc.
(2) his comments about the horror of downloading and running programs betray a lack of understanding of the security model of the web.
(2) His logic amounts to: “a language is used in a programming environment where some bad things sometimes happen. Therefore don’t use the language for anything else.” This is childish purity based non-logic. Should we also avoid HTTP? CSS? I hear a lot of browsers are implemented in combos of C, C++, and Rust. Should we avoid all those too?
I don't think RMS is much of a fan of non-JS tracking either.
I don't know how this is related to extending Emacs with JavaScript, but it's more or less correct about how JavaScript works in the browser (modulo "anything at all" being "anything at all in the browser sandbox"). If you only want to run free software, you necessarily must disable JS in your browser.
In Emacs, you can install any package that will then do most/all the evil that JS can. In principle, you should be very careful about the packages you install.
I think it's the cultural issues he's getting at. Minified or otherwise obfuscated elisp packages would rightly be viewed with suspicion. Unauditable JS is the norm, right?
> But one thing I think we really shouldn't have is the equivalent of a modern web browser.
I think people are focusing on the Javascript part alone too much, when he made it clear numerous times that he is talking about the browser model, not javascript language itself.
I don't get it. Like, i don't care if we can write emacs stuff in JS or not, but i don't see how it's any more dangerous than Lisp.
It's RMS, so I know he's going to throw the baby out with the bathwater on this, then throw out the bathtub, then disassemble the plumbing, brick up the bathroom and never bathe again on principle, but Javascript has probably served as a greater benefit for FOSS culture than any other language. Certainly more so than lisp. Making it out to be an implicitly evil language seems... out of touch?
quick edit: I know the argument about privacy invading javascript software, but software can be free and still invade your privacy. That's got nothing to do with the language.
He just doesn't want this GNU project to include support for a language whose primary purpose seems to be invading privacy -- even if it has a lot of great secondary purposes and a good open source ecosystem. Given that the GNU/FSF projects are all about advocacy in the area of software freedom and privacy, it seems like a reasonable perspective to have. Yeah, RMS definitely takes things to an extreme, but I don't see the "JS is implicitly evil" thing you're calling out, just refusing to appear to endorse or support something that goes against his principles.
And of course ironically enough those very principles mean he (should be...) perfectly happy with the emacs-ng fork, since that's part of the freedom he's advocating for.
a) that's not its primary use by a long shot. The VAST majority of JS written has nothing to do with tracking / privacy stuff.
b) we don't need JS to invade your privacy on the web... Does he browse without images turned on too?!
(and i recognize you're just explaining his position not arguing against JS)
He doesn’t really browse the web at all:
“””How I use the Internet
I am careful in how I connect to the internet.
Specifically, I refuse to connect through portals that would require me to identify myself, or to run any nontrivial nonfree Javascript code. I use LibreJS to prevent nonfree Javascript code from running.
I am careful in how I use the Internet.
I generally do not connect to web sites from my own machine, aside from a few sites I have some special relationship with. I usually fetch web pages from other sites by sending mail to a program (see https://git.savannah.gnu.org/git/womb/hacks.git) that fetches them, much like wget, and then mails them back to me. Then I look at them using a web browser, unless it is easy to see the text in the HTML page directly. I usually try lynx first, then a graphical browser if the page needs it.
I occasionally also browse unrelated sites using IceCat via Tor. Except for rare cases, I do not identify myself to them. I think that plus Tor plus LibreJS is enough to prevent my browsing from being associated with me. “””
https://stallman.org/stallman-computing.html
On smaller sites there is no license, on commercial sites it's usually "all rights reserved"
Emacs Lisp (and its data model) is quite different from what programmers are traditionally used to. We typically write software that runs completely unattended for years at a time. We communicate with unknown servers and APIs that change randomly for no reason. Everything that can go wrong, will go wrong, multiple times an hour. Thus, a programming language designed for that environment has to have error handling front and center, it's really all you're doing! Taking that to the extreme, code that refuses to compile because you didn't handle every possible eventuality is actually wonderful for making software that stands a chance of not being the ops team's (you these days) worst nightmare.
Emacs is not like that, however. The user of the code is likely a programmer, and the main data structure is the buffer of text that they're looking at. It's the one time in the world that you can just throw an exception and let the user handle it. They can just adjust the "memory" by typing stuff and trying the command again. Having written a lot of Emacs Lisp (and a fair amount of Javascript), I don't even know how you could make a nice API in Javascript that let you quickly put together quick editor tools, the fundamental design of the language just makes it more difficult than necessary. (You'll see this in the long tail of Emacs packages that the newer editors simply don't have. It's so easy to get started, and to finish!)
I'm honestly surprised that anyone has managed to write a text editor in a programming language other than Emacs Lisp. It's just such an impedance mismatch, it must be pain upon pain constantly.
RMS is right in the sense that users can't really inspect the code they get from websites. That is more of a webpack and browser issue than anything else. Emacs has great tools for inspecting the code you're going to run or are running (it's a keystroke away at all times), but I think you could build that for any language. And to be fair, I'm sure many Emacs users package-install stuff that they never look at, or even care that Emacs is free.
The culture of (Emacs) Lisp keeps inspectability front and center. You can look up the source code for every function with C-h f and every keybinding with C-h k. But if Emacs supported JavaScript, the culture of JS, including code obfuscation, would probably come with it too. Or that’s the way that I interpret it.
In fact, Steve Yegge has already written an EMCA-262 interpreter in Emacs Lisp, and given it the unfortunate name "Ejacs".
https://www.youtube.com/watch?v=D1sXuHnf_lo
I'm actually thinking of adding some kind of Pie menu to Ejacs, perhaps a Cream Pie menu would be appropriate
https://www.urbandictionary.com/define.php?term=finger%20pie
https://www.quora.com/In-the-Beatles-song-Penny-Lane-what-do...
Eight Jizzabytes And Constantly Swapping
Would emacs developer builds some form a GUI toolkit or would it be built inside the existing concept of text buffers?
Seems odd and a bit unfocused, and seems like a big wasted engineering effort for when something like LibreOffice exists.
https://www.gnu.org/software/emacs/tour/
I imagine that he simply wants this used to enable Emacs to be able to edit rich text in a WYSIWYG style.
Like does it include headers, fonts, etc
No, it hasn't.
In developer circles, yes, slightly, because of Git, Markdown, etc.
For regular folks (90%+ of folks out there), not at all.
A doctor or biologist or quartermaster aren't about to write Markdown any day soon.
Edit: url
Nowadays if you want WYSIWYG you don’t even own the data anymore, it’s a Microsoft or Google editor as a SaaS in the browser. So Emacs covering this use case too would be extremely powerful and coherent from the software freedom angle.
Edit: seems like it's this https://pad.emacsconf.org/2022-rms but it's not complete (yet?)
That being said: I never want him to stop or change. I still find his ideas and notions incredibly valuable and extremely good sticking points to always consider seriously, even if (perhaps ESPECIALLY IF) there's not much of chance one could actually practice them.
I've learned to listen to him before I judge strongly.
You may want to read the rest of his opinions on his site on the topic as well.
I have absolutely no idea why I was downvoted and flagged for pointing to a thread it links to his views on child sex and rape.
If we don't take an active approach in protecting our freedom, it will get removed before we ever knew we had that.
Not while there are users like myself who will try to continue using software that is free (as in libre), as much as I possibly can.
Education and communication is key.
Stallman is precisely right in a few very specific ways, but it's almost impossible to apply that precision to any real world problems we face. We can calibrate against it, and there's some value in that. But not that much I find.
Most people don't own a computer where they could install software freely (mobile). Personal data is collected in huge volumes.
> [...] starting around two decades ago, there was an explosion in the complexity of browsers as companies wanted to have more and more control over exactly what would appear on a user's screen. So they invented lots of features to control that, features where the user couldn't really customize how something would actually appear because the whole point was that the company could control that. And JavaScript was sort of the ultimate level of "the company controls everything." Because of this, going beyond the simple level of web page formatting features in Emacs is basically heading down a path that leads to subjugation. It's a path that we need to stay away from. It's a path to an unjust world of computing that you can easily see around you. Web browsers nowadays are designed to display ads that you may not want to see. They're designed for DRM. They're designed for companies to snoop on you in unobvious ways. And all of that we should protect ourselves from, protect our users from.
Stallman's argument simply doesn't make sense. If I make my own website, I should be able to control what's on it. It's a user's prerogative to ignore all those things or modify it on their end to make it more usable for them. Is it user-hostile for me to, say, require javascript for my site to function? Maybe, but that's still entirely my prerogative as the person making the website. There's no obligation for me to make a website for everyone and there's no obligation from anyone to use my website.
A person should be able to navigate to websites safely and navigate away safely since there's no way of knowing what the contents of a webpage are before navigating to it, but that's about it.
How do you settle on (dis)trust about a website? Just as you do with a person, there are 4 ways:
* reputation (meaning someone else already visited it and had to pay with bad experience)
* your own experience (meaning you already visited and were victim of the website)
* intuition (very poor driver, full of biases)
* homogeneity: a checklist of norms and conventions (can easily be gamed)
So in any case, it's either very uncertain or relies on others to throw themselves over the cliff so you can benefit from their experience.
So no, you cannot simply choose to not navigate websites you don't trust. It's just blind navigation and that's what most people, uninformed as they are, do.
Every human advancement has basically been a result of benefiting from other's experiences or insight. Sometimes you make your own individual contributions to human knowledge but you mostly don't.
> So no, you cannot simply choose to not navigate websites you don't trust. It's just blind navigation and that's what most people, uninformed as they are, do.
Sure you can. All the reasons you mentioned above are totally legitimate ways of establishing trust with a website. You absolutely can only visit websites that others have vetted, if you're someone so paranoid about webpages. Some people are pioneers and some are not.
You cannot avoid blind trust. Society as a whole hinges on the notion that people's behavior en masse is predictable and generally not destructive. How do you know, for example, that the groceries you just bought are not poisoned? You can't. You can regulate things but regulations cannot be perfectly enforced.
So yes, you absolutely can just choose not to navigate to websites you don't trust.
Trust is also a leap of faith, when that's all you have. I had put that in the "intuition" category of my first comment.
On the one hand, browsers have a long history of breaking security principles. On the other, the web has been the most vibrant platform for enhancing user experience; the same commercial interests that RMS criticises have caused the world economy to flourish like nothing else.
If Emacs had somehow become the most popular VM in the world, I’m sure we’d see a lot more skepticism of it.
I do think browsers are more secure than Emacs today, because of the pressure of popularity.
But the criticism of the web being captured by commercial interests applies just as much: you are not ultimately safe from the government when you roam the web, because the technology is largely controlled by few actors.
GDPR is not forcing them to do that.
That is companies futile attempts at continuing exactly the same abuse they have been doing the past decade.
And they won't get away with just disclaimers for long:
even Google has now decided to implement direct, easy and fast opt out instead of the previous tactic of making it as hard as possible.
Source: I see a new, simple and easy to answer dialog every time Google ask me.
> The amount of bullshit jobs available is positively correlated with how well everyone is doing.
Why to throw arguments you are never able to prove?
Yes, I think that it would be good, but still the specifications and implementations of WWW are bad and tend to be trying to make the company to control everything, like they say.
Web browsers could be designed much better, although to compensate for bad specifications requires some messy details. (One thing that might help is for client software to use ARIA hints. They seem to want to use them for blind users, but I think they can help improve it for everyone.)
Instead, they make them worse, trying to hide stuff from end users, trying to believe they know better than the end users, etc. This makes things difficult to control, e.g. you cannot make non-tunneling proxies for HTTPS and therefore you need to take extra energy just to decrypt and reencrypt the communications, and the WebExtensions is rather limited, and you cannot usually make browser extensions in C, and the way that some things are core vs extensions makes many things difficult to change. And then, they will add spyware and stuff, and other inefficient stuff.
A web browser designed only for advanced users, who are assumed to know what they are doing, would be a good thing to have. (And, if you do not understand something, then read the documentation; programs must have good documentation, and unfortunately many do not, and that is what makes them difficult to understand.)
> but then wouldn't that be an argument for Emacs having its own web browser?
Maybe; they can see if a better one can be made. It shouldn't be a built-in feature of Emacs, but it could be a file included with it, and maybe it might help. Variants of Chromium isn't the way to make a better one, so it must be made differently.
> If I make my own website, I should be able to control what's on it.
Yes, but you shouldn't need to add all sorts of stuff just to concede to W3C's demand, to use Unicode, badly made HTML, etc (even if other file formats would be better, trying to serve them properly just makes a mess).
You can use just plain HTML, but it has many problems, and CSS/JavaScripts just makes even more problems.
Even if you can, it does not necessarily mean, that it is a good idea.
> Is it user-hostile for me to, say, require javascript for my site to function?
It depends on the site. For documents, it shouldn't. For some types of games, it might make sense to require JavaScripts, but it should be possible to view the documentation (and the link to the documentation) even without it.
Why in the heavens name... would you want to do that?
- More efficient codes
- Be able to interact with anything else on the system, that can be interacted by C codes, including external programs
- More control, than using JavaScripts
A web browser designed only for advanced users, who are assumed to know what they are doing, would be a good thing to have. (And, if you do not understand something, then read the documentation; programs must have good documentation, and unfortunately many do not, and that is what makes them difficult to understand.)
(JavaScript-based browser extensions are still useful to make simple things without writing as much code, and also useful when you want to distribute portable sandboxed code for browser extensions, but for many other uses, C will be better.)
(It is true the C programming language has some problems, but so do all programming languages.)
It was only this year I even heard someone in industry talk about WCAG and their manager treated it veey low priority.
I'd wager most views that espouse "accessibility should be guidelines, not regulations" would 180 as soon as the person holding that view was affected by even the smallest vision disability and lack of WCAG compliance on a site they frequent.
It's not from a lack of empathy and I think that framing the argument that way is emotionally manipulative. There is a cost associated with making things accessible. If that weren't the case we wouldn't have guidelines like WCAG that teach people how to make things accessible. It's not entirely intuitive so it must be learned which is an added cost. For the government that's very obviously going to be necessary. In the US it's mandated by law that federal agencies' services must be accessible.
That's the scope that I'm comfortable with. The government is for the people so that naturally extends to all of its citizens, not just the able-bodied. Private companies don't have any such obligation to serve every person and individuals definitely don't. Guidelines are the right balance. You don't infringe on people's freedom of expression and you get iterative improvements on specifications that make it easier for people building accessibility tech to be on the same page.
This is true, but if you want to use most websites, you have to give up a lot of this control in order to have any sort of reasonable experience (reasonable for most people that is, not a reader of Hacker News).
You actually got RMS's point: There's no obligation for you to make a website for everyone, but you could provide more convenience and compatibility by not _only_ making a website which needs javascript enabled. It shouldn't be assumed that everyone favors javascript and likes to execute javascript code from everywhere.
One may argue that would be easy to be scraped by bots. That's another issue.
but that is exactly what he is talking about - ie the culture of user hostility (and also code obfuscation) in js front end development
Have you done that on "modern" websites?
Most users turn off js, notice their favorite site broke, and conclude "if I disable js it breaks the sites I care about".
If you want to use a web application, then yeah, you probably need to allow the web browser to run JS because it enables those things to exist.
It's annoying because years and years ago my view of computing was very very positive.
I would have viewed something like web assembly as better and faster! Now I view it primarily as a way of obscuring what happens on your computer. We can see that web pages load and run fast enough -- it is just that most do not because they load the maximum number of advertisements and trackers that the delay will bear.
This is the norm: Vendor-locked hardware, operating systems that manipulate you into making choices that benefit others than you, software updates that remove functionality or render devices useless, access to multimedia that is revoked, services shutting down to make devices bound to them useless unless hacked.
And I think I seek problems when I insist on running Linux on known hardware. But I avoid. so. much. by doing do.
Is there any practical difference between running obfuscated Javascript or compiled WebAassembly and running an closed source binary blob?
I don't even care what RMS' argument was, I think he's pretty out of touch most of the time. But putting Javascript in Emacs is just a stupid idea that would completely ruin it eventually. Let Emacs be Emacs and Vscode be Vscode.
Javascript tends to ruin everything eventually.
Lisp is much, much harder to learn than JS is. Aside from that JS is a very transferrable skill, but Lisp is not.
> I speak from my experience in college (~3-4 years ago) where, every year, 60% of the class dropped out of an AI class taught in common lisp because they couldn't understand it: https://catalog.harding.edu/preview_course_nopop.php?catoid=...
JS is much easier to become bad at quickly, which is not a bad thing.
Lisp is an ever-expanding paradigm, but you can learn it at a steady pace like JS.
JS is directly transferrable to similar-syntax languages, yes.
But Lisp provides insight into techniques that will expand your knowledge and understanding of all programming languages.
Does JS have a music video like this? (The Land of Lisp)
https://www.youtube.com/watch?v=HM1Zb3xmvMc
https://www.youtube.com/watch?v=jxi0ETwDvws ("Bug in the Javascript", not music video but video of musician performing vocal and harmonica parts of song)
https://github.com/Wilfred/tree-sitter-elisp/blob/main/gramm... (approx. 200 lines)
and here is the grammar of JavaScript:
https://github.com/tree-sitter/tree-sitter-javascript/blob/m... (approx. 1200 lines)
JavaScript evolved into a language of similar complexity as Perl 5 (the corresponding tree sitter syntax table counts almost 2000 lines, currently).
Now this is endemic in the JS world, especially because it is more ubiquitous than the previous beginner language, PHP.
They don't want to have another, so they change the world around them so that Javascript can be used for anything.
That said, Emacs relies rather heavily on unique features such as dynamic binding, advice, and autoloads. These are more or less impossible to replicate in modern languages, so I don't think there's a reasonable path to rewriting major parts of Emacs in, say, Javascript.
But we should look at what Lua did for Neovim. There has been an explosion of development effort now that Neovim finally added a reasonable programming interface. A similar thing could happen in Emacs.
It is very much debatable whether Lua is the "reasonable programming interface" causing the activity in Neovim. Vimscript has many flaws, one of them being that it doesn't look like other programming languages, but it does its specialized job pretty well. It is slow, but efforts are made in that area. Lua is well designed but it certainly has its shortcomings too, and many argue (me included) that programming in Lua is not that pleasant. The Lua bindings have been available in Vim for quite some time, but they never were popular, for some reasons.
Anyway, it is not directly related to your point, but I think that example is not that compelling.
And then the realities of working in lua accrete over months, but then they're in too deep. What are they gonna do, learn elisp? Admit defeat and switch back to VS code?
Personally, I'm using Haxe with its Lua backend. While wrapping Lua APIs is a pain, and some dynamic patterns are hard to represent directly, Haxe provides a lot of the things that Lua lacks: a gradual static type system, more familiar JS-based syntax, syntactic sugar for lambdas, sane handling of `this` in methods, control over inlining, immutable variables, generics, null safety, powerful hygienic macros, somewhat usable standard library, extension functions (Kotlin/Scala3 like), partial function application, hash and array comprehensions, functional operators on collections, limited operator overloading via abstracts, built-in LSP server, and a lot more.
I do this in the context of scripting my window manager, and plan to try this with Nginx/OpenRESTY. I feel like pairing LuaJIT runtime with Haxe compilation creates incredibly powerful combination. Lua provides coroutines, tail call elimination including corecursive functions, lightweight and fast JITed VM, a package manager (luarocks), bindings to important C libraries, FFI, reflection (everything is a table anyway), and more. The integration between Haxe and Lua is not yet seamless, and Lua compiler backend is one of the least developed, but even in this state I'm very happy with the combination of compile-time and run-time features I get.
I ended not using it mostly because of unfamiliarity and it felt like it would add a fair bit of complexity. Didn't want to pick up a whole new ecosystem for that project.
I ended up using fennel, which solves most of my practical problems with lua without really making anything harder. Doesn't help with the package ecosystem or build process but I ended up just taking that compromise.
Don't regret it, still use fennel anywhere I'm forced to use lua, including hammerspoon and mud client scripting. I think if I was going to work heavily in lua long-term I'd go back and invest in haxe for it.
Why do you think so? My main gripe is the lack of namespaces and proper modules, but there are many languages in Top 10 on TIOBE that share this problem. The only other problem is a clunky, decades old standard library. Lack of consensus around async processing is less important, but also irritating.
Other than that, Elisp improved tremendously in the last 5 years, and it keeps improving with every release. The stdlib is getting some long overdue cleanups and sensible convenience modules are added regularly. The language features of other languages are being readily incorporated in the form of macros. The live environment along with "self documenting" code makes for a rapid dev feedback, and tools like built-in Edebug and 3rd party packages like Paredit and EROS make editing Elisp code more pleasant than most other languages.
Obviously, Elisp has many problems, it's not ideal, but it's nowhere near "terrible" in my opinion. At least not anymore.
They're both basically just ergonomic issues at this point, with prefixing names and always setting lexical scoping being cultural norms.
Yes! Prefixing names as a way of emulating namespaces generally works well enough. We could get modules support the same way JS used to have them, ie. as hashes of closures. Or we could use something like the `nameless` package, which rewrites the code to add a prefix to definitions automatically. Yet nobody seems to be doing either: it's just too much of a pain with too small a gain. The situation would be different if we got first-class module support in the language, but if we're going to only emulate it anyway, then namespacing with prefixes is just the easiest way to do it that is still "good enough". Still, Racket-like modules would be great to have, can't deny that :-)
Now that Emacs Lisp actually has native compilation, the speed issue is less of a problem, but it's a plain fact that a lot more people can do things with Javascript than Lisp.
I think usually if you have an application you'd prefer to reuse a programming language rather than having a language specific to the application. I think that was the main motivation for the failed port to Scheme.
Do i prefer JS? Probably not. But to me the draw of emacs is nothing to do with Elisp. It is instead everything to do with customisation, one-editor-many-languages, and the ability to do absolutely everything from a keyboard-based, low-clutter GUI.
Part of it is of course that good people made plugins in Elisp and maybe you'd argue that without it they wouldn't come to be, but I'm not sure.
I keep hearing this argument but it is contradictory: the reason why Emacs is so customizable it is because it is written in a Lisp, a very versatile metaprogramming language.
You simply cannot have the flexibility of Emacs in anything less malleable than a Lisp. You'd have a regular editor with plugins.
I know many will want to prove me wrong, but where is the non-Lisp Emacs killer yet? VSCode is a great editor, but it's nowhere as flexible.
If I could write plugins in Python, within the Emacs environment, I would (i believe it is sort of doable but quite wonky).
That, and the R5/R6/R7 debacle has alienated many from scheme.
Emacs' core isn't known to be the best codebase in existence, but it is battle hardened and hard to replicate.
They are right it does not have to be VS Code; if you like that, then you can use VS Code. However, if you want specific features, then that is a different thing, and will have to be considered specifically.
If you want JavaScript in Emacs, it could be an external extension, maybe; it probably should not be included by default. However, if the model is different enough from Lisp then it might be hard to fit; nevertheless, such an extension might help if you need to run JavaScript codes designed for other editors that do use JavaScripts, without having to rewrite them (polyfills will be possible, if necessary). Lisp alone probably isn't ideal though, and you should be allowed to write extensions in C as well (I don't know if this is already possible; maybe it is).
WYSIWYG editing should have "reveal-codes" function also; without such thing, WYSIWYG isn't very good.
One thing I think would want to have in text editor is capability of non-Unicode text encodings which don't convert to/from Unicode. You just should not expect that everything is conversion in one unified character set; it does not really work.
In my observation, Emacs has been moving in the right direction, addressing outdated aspects and sources of lagging performance, and adding essential features like LSP support natively. I hope that Emacs contributors and maintainers can keep this focus.