What I'd like to see in Emacs
emacsconf.org
emacsconf.org
> [...] 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.
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.
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=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 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.
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.
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.
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.
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.
Is there any practical difference between running obfuscated Javascript or compiled WebAassembly and running an closed source binary blob?
Edit: seems like it's this https://pad.emacsconf.org/2022-rms but it's not complete (yet?)
Someone 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.
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...
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. “””
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".
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