The Many Faces of an Undying Programming Language
jakob.space
jakob.space
Something like Python. .NET, Java also isn't far from them, when language + standard library + vm reference (if any) land in dead tree form.
In my 1990 edition of Steele's Common Lisp, The Language, even the index is a work of love.
[Example spoiler] After the entry for Michelangelo (turtle), who is mentioned on page 440, the page numbers for Michelangelo (artist) are 1475-1564.
I guess that, assuming that all refs have roughly the same information density, it gives a rough idea of the “size” of the language.
I'd like to clarify that I didn't mean to imply that larger standards are worse. Quite the opposite, actually. That's why I enjoy R6RS. As shakow pointed out, it's a means of giving a rough estimate of size. Common Lisp has much more than Scheme in terms of what's included.
I find that comment quite funny, considering that the Java specifications came out in dead tree form already for Java 1.0. :-)
That seems unnecessary; of all the options above, it might be the one seeing the /most/ active development, and (given that "Guile-macs" isn't happening anytime soon) will continue to be in active development for a long time to come.
There isn't really an argument for why a text editor needs its own different brand of lisp vs. using Common Lisp with a dedicated library for the Emacs interpretation of how text works. It only ended up this way from inertia. But it is nevertheless extremely telling that the only major implementation of Elisp is Emacs.
Then again afaik Vim doesn't throw errors when you have a bracket imbalance in comments(!), so that's nice.
Not sure where this is coming from. Elisp doesn't error on anything in comments.
(defun foo ()
;; old code)
new code)
Should just get discarded when parsing/running the lisp code. There was a lot of code like that in my old .emacs file back when I was learning how I wanted it to behave but didn't want to delete old configurations (before I got into the git everything habit, especially).You might rightly say that evaluating lisp code directly in an org-mode code block might not be the best idea, I just don't expect it to mostly work but mess up the syntax depending on comments.
I fared a bit better with Gerbil, enough to build multi-arch Docker images for it: https://github.com/insightfulsystems/ubuntu-gerbil
These days I mess around with Janet a bit, and quite like Fennel, but lack the time to do substantial bits of code in either.
Can someone ELI5 this? Why is Clojure's license problematic?
https://www.reddit.com/r/lisp/comments/hupqhn/the_many_faces...
This can make on-prem solutions for a product slightly hairy.
Please feel free to correct me if this is inaccurate
EPL has the restriction that if you distribute binaries, you have to make the source available (you must state in your license where to obtain it). It seems that listing your dependencies libraries and linking to their websites (which I think is good practice anyway even with less restrictive licenses) would be enough, as long as you didn’t modify them.
EPL allows linked modules to be distributed under whatever license you want, so in a commercial product doesn’t apply to your closed source code or any libraries that choose not to be distributed under EPL.
So for on prem distribution, you just need to include a license file that lists all of your EPL (or other licenses that require the license to be included like MIT) with a link to where to get the code. Your own code is unaffected.
This isn’t GPL compatible, though, because GPL does “infect” linked modules too.
However IANAL.
I don't think that's the reason. The BSD license is GPL compatible, without infecting anything.
EPL being GPL incompatible means that EPL-licensed pieces cannot be combined with GPL ones for whatever reason. The FSF claims that it is because of its "weak copyleft and choice of law clause".
The original authors not receiving your changes doesn’t seem to me to affect their freedom, even if it kinda sucks.
Had Linux nor GCC happened, and we would all still being enjoying commercial UNIXes.
I'm not sure why this is contentious: GPL adds a restriction that, eg, MIT does not -- that you must contribute back. MIT lets you choose if you want to or not, therefore it provides you more freedom. Sure, GPL adds this restriction to ensure that all users have an equal level of freedom. I am not making a value judgement here at all, nor am I saying that MIT (or whatever) is better than GPL as different people have different preferences, priorities or opinions.
See where the MIT freedom has taken the BSDs, and what they have gotten out of it.
I suggest reading a bit about macOS internals and which of those parts you actually find on any BSD variant.
[1] https://en.wikipedia.org/wiki/Permissive_software_license
Separately, I was pointing out that contributing back upstream is a beneficial and nice thing to do, but is orthogonal to freedom. If anything, forcing it means there is less since the person loses the freedom to choose whether they wish to or not. I'm not judging which is better either, just pointing out the differences. Sometimes less freedom for the individual is better for the whole (to ensure equal freedom for all, or so changes are contributed back), we see it in society too: we give up personal freedom for the benefit of society as a whole.
I am all but forced by my employers to write non-GPL code - even when I'm allowed to write permissive-license open-source software.
But beyond that, circumstances also pressure me into making software I write on my own available with a permissive license, to reach wider adoption by people writing commercial code. I occasionally have pangs of conscience about doing that, and wonder whether I shouldn't have just taken the "hit" of sticking to the more worthy license.
Could you also clarify whether the first example is relating to company code or personal code?
I don't think you understand what the word "free" means.