lispegistus

3 tahun yang laludiscuss

Having an instance with a x million users is impossible to moderate. Instances have been blocked for not being able to moderate low thousands of users due to incompetent/unresponsive mods. Having a poorly moderated instance federate with yours is seen as a threat to your users and a proactive admin would not allow federation. Also most admins are aware of EEE tactics and we all know we cannot expect anything even remotely resembling ethical behavior from big corporate instances, they are a threat to the network by default.

lispegistus

3 tahun yang laludiscuss

What part of Common Lisp would you consider old cruft and what value would removing it bring to the language that would offset the value we have from having one of the most stable language definitions still in use? I can think of a few dusty parts of the language that are rarely used today but it's perfectly safe to ignore.

Lisp has a good all purpose library ecosystem, it's just informal rather than baked into the language, and I haven't had any significant issues with quicklisp since it came out however many years ago. Writing portable common lisp is not at all difficult and there is no problem like with say Scheme of one library needing a specific compiler. And libraries tend to have a long shelf-life too. How much of Python's standard library is old cruft with better alternative packages available now for example? Didn't they have to prune a bunch of stuff in the python2->3 transition? There is considerable risk in including standard libraries in a standard, and the risk is that those libraries will end up being outdated eventually. You want to add more potential for more old cruft to be in Lisp and then pruned again? Why? Just use quicklisp or one of it's alternatives that are cropping up.

Lisp is not Go, it's an agreement between many different parties about what lisp is, it's not a codebase under the defacto control of one organization, or even an informal group or "community". This is extremely valuable and recent events around Go show why, I am extremely glad that I never payed much attention to Go because honestly I cannot trust it's governance model, but a specification that hasn't been and won't be updated in decades I can trust completely, and if one implementation betrays that trust, I can always move to one of the many alternatives listed in the OP.

sidenote:

> I think every programmer that tries common lisp eventually comes to the same conclusion

if this refers to "Lisp needs more backing from the heavyweights", then OH GODS PLEASE NOOO! I want to write code that will run in a year without modification and won't have some corporation put spyware in my compiler while trying to convince me it's for my own good and have my IDE slurp my code to train some LLM to make it easier to pile even more pointless unmaintainable code upon the world. The "heavyweights" have shown themselves very poor stewards of the discipline of computing indeed.

lispegistus

3 tahun yang laludiscuss

The reason VS Code is not the spiritual successor to Emacs is because Emacs is an attempt to preserve and further develop the legacy of the lisp machine. While VSCode is an attempt to capture as much of the developer editor market as possible. The old joke about Emacs being a great operating system but having a lackluster editor? It's actually literally true. A spiritual successor to Emacs will not be a text editor, it will be a software environment that continues and further develops the principles the lisp machine operating systems were build on, it will just happen to edit text on top of everything else it does.

On a different note, while I concede that VSCode is "good enough" at most text editing, and might even be excellent at some things, I could absolutely never use it because I have an insane grudge against Microsoft as the supreme enemy of Free Software. That's another thing an Emacs spiritual successor will have to be, not in any way shape or form associated with the devil of the church of GNU.

lispegistus

3 tahun yang laludiscuss

Setting aside the question if on by default telemetry is unethical in general, I personally think it is, my point in this comment is that in the context of open source it is impossible for it to be because:

The whole point of open source is the security of the rights and freedoms of the users, and in case of a conflict with the convenience of the developers, the user rights take priority EVERY TIME. If you're not ok with this, you should not write open source software. If nobody opts in to your telemetry scheme if it were the default to choose, too bad, you're just gonna have to live with it and respect user choice no matter how inconvenient or how much better the alternative would be for everyone. If you fail to grasp this very basic thing you will be better served working on proprietary products instead. OSS is not a product you own, it's a shared resource you are in charge of stewarding and the ethical burden is much higher because of that. I checked, Go uses a permissive license, Google is more than welcome to run a proprietary fork with telemetry built in. Keep that out of open source.

comments