The Many Faces of an Undying Programming Language(jakob.space)
jakob.space
The Many Faces of an Undying Programming Language
http://jakob.space/blog/thoughts-on-lisps.html
50 comments
I've never understood why anyone uses the number of pages of the reference document as an argument. It feels like making fun of the hard work of people put into making the reference. The bulk of the reference probably consists of minor details that can be skipped but can also be extremely helpful when you actually need them. Should we make worse references just to appease some bean counting?
> the hard work of people put into making the reference
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.
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've never understood why anyone uses the number of pages of the reference document as an argument
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 guess that, assuming that all refs have roughly the same information density, it gives a rough idea of the “size” of the language.
This assumption really doesn't hold though if you look at a couple different language standards
If you count the standard library in the size it is just an arbitrary number.
Unless you're using the size of the standard as a rough measure of the complexity of creating a new implementation of the standard. If you need to provide an implementation of the standard library, then that contributes to the amount of effort required.
At least in C++ - after the initial spec, the language was literally _built_ on exploiting those minor details. A lot, if not most, of C++'s magic and its ugliness goes through those weird minor details.
Author, here. The n ≈ 163 pages figure I give for R6RS includes the standard library and description of formal semantics.
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'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.
> when language + standard library + vm reference (if any) land in dead tree form.
I find that comment quite funny, considering that the Java specifications came out in dead tree form already for Java 1.0. :-)
I find that comment quite funny, considering that the Java specifications came out in dead tree form already for Java 1.0. :-)
> Emacs Lisp, or Elisp, is generally hated
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.
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.
I read this, and then went and read the article, and was expecting it to be hating on Elisp, but in fact the article defends it; FWIW, Elisp is generally hated, and that is one of the first (unfortunate) things I think of when I hear it come up in a conversation, so given that this author does not seem to agree I don't see anything wrong with this statement.
Elisp is popular, but not likely through any strength of the language. Emacs' rich history of people writing crazy extensions is just so compelling it can't be avoided.
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.
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.
Yes, it's not ideal because of its lack of tail call optimisation, but as a Vim user I'm kind of envious now and then when I try to write a custom function myself.
Then again afaik Vim doesn't throw errors when you have a bracket imbalance in comments(!), so that's nice.
Then again afaik Vim doesn't throw errors when you have a bracket imbalance in comments(!), so that's nice.
> errors ... bracket imbalance in comments
Not sure where this is coming from. Elisp doesn't error on anything in comments.
Not sure where this is coming from. Elisp doesn't error on anything in comments.
I think it was due to org-mode, which has its share of bugs and glitches. Either way Emacs refused to evaluate a function because I had a commented out line with a closing parentheses in it, and would only accept it after I deleted that line.
If you can reproduce it it would be worth submitting a bug report. Comments like:
(defun foo ()
;; old code)
new code)
I just checked, it doesn't happen in an actual elisp buffer, but every time in a standard .org file. It'll always throw a 'Lisp error: (scan-error "Unbalanced parentheses")'.
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.
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 went down this rabbit hole last year: https://taoofmac.com/space/blog/2019/06/20/2310
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.
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.
> Clojure's license makes it a complete non starter for me, sorry. Live free or die.
Can someone ELI5 this? Why is Clojure's license problematic?
Can someone ELI5 this? Why is Clojure's license problematic?
Not GPL-compatible:
https://www.reddit.com/r/lisp/comments/hupqhn/the_many_faces...
https://www.reddit.com/r/lisp/comments/hupqhn/the_many_faces...
I am by no means an expert on things to do with licensing but Clojure is under Eclipse so IIRC if you distribute your code onto the user's machine they have a right to the source.
This can make on-prem solutions for a product slightly hairy.
Please feel free to correct me if this is inaccurate
This can make on-prem solutions for a product slightly hairy.
Please feel free to correct me if this is inaccurate
> This can make on-prem solutions for a product slightly hairy.
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.
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.
> This isn’t GPL compatible, though, because GPL does “infect” linked modules too.
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".
https://www.gnu.org/licenses/license-list.html#EPL
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".
https://www.gnu.org/licenses/license-list.html#EPL
The problem with the EPL is that if your software is a derivative work of EPL licensed software, the EPL applies your software, including the obligation to provide access to the source of your software to the entities to which it is distributed. Determining if a work is a derivative work in software is far from straightforward. The EPL FAQ for instance points out that this might be an issue when using software that generates code.
That cannot be the problem that the author of the submitted article has with the EPL, because the GPL is the same way.
No, I agree. I was pointing out a general challenge with the EPL that people tend to overlook. In the Clojure environment many use EPL for Clojure libraries, many without realising that it might, depending on your intentions, be an issue.
This is the reason why the Classpath exception exists for GPL. Perhaps EPL would also consider adding one?
Given the amount of surviving GPL software that still has some meaning, basically Linux kernel and GCC are the ones left, that reasoning won't hold for long.
Actually, that's a good point I hadn't thought of. The world has moved on from GPL to more free alternatives.
I wouldn't call the missing upstream improvements to LLVM and BSD from Sony, or Apple, thanks license, a more free alternative, but I digress.
More free in the sense that you, the person making a derivative work or distributing the licensed software, have more freedom in what you can do. It’s not more free to your users unless you decide to license it to them under a similar license.
The original authors not receiving your changes doesn’t seem to me to affect their freedom, even if it kinda sucks.
The original authors not receiving your changes doesn’t seem to me to affect their freedom, even if it kinda sucks.
Not that I care that much as I am mostly a commercial software user/dev, but as the world returns to the days of shareware and public domain, those that drove the carts back there will find out what "freedom" means.
Had Linux nor GCC happened, and we would all still being enjoying commercial UNIXes.
Had Linux nor GCC happened, and we would all still being enjoying commercial UNIXes.
I'm not arguing against GPL and friends, I'm simply pointing out that less restriction = more freedom for the initial user in the sense that they have freedom to do more things and that this freedom does not transfer downstream. I'm also saying that not contributing back upstream is orthogonal to freedom.
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.
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.
That restriction is why people get to enjoy the Linux kernel and GCC today.
See where the MIT freedom has taken the BSDs, and what they have gotten out of it.
See where the MIT freedom has taken the BSDs, and what they have gotten out of it.
Again, I was only pointing out the differences in freedom, not making a judgement about which one is better... different people have different opinions on this one, after all.
MacOS is BSD after all, I dunno what to say.
macOS has parts of BSD, most of them never contributed back.
I suggest reading a bit about macOS internals and which of those parts you actually find on any BSD variant.
I suggest reading a bit about macOS internals and which of those parts you actually find on any BSD variant.
I think the kind of licensing you’re referring to is usually called permissive licensing [1]
[1] https://en.wikipedia.org/wiki/Permissive_software_license
[1] https://en.wikipedia.org/wiki/Permissive_software_license
I am merely stating that less restrictions = more freedom (ie more choices of what you can do) to the initial user. I'm also pointing out that this freedom of choices does not translate to downstream users since the previous user is free to choose to restrict it. GPL has less freedom (by virtue of adding restrictions on what can be done), but it does this to make sure all users have equal freedom. Some people value the higher freedom more, other people value the equality more.
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.
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.
More free as in enhancing the privileges of the elite programmers who control the software at the expense of mere people who think they own and control their own devices.
You mean, less free alternatives.
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.
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 clarify what any of this has to do with freedom provided by the license itself?
Could you also clarify whether the first example is relating to company code or personal code?
Could you also clarify whether the first example is relating to company code or personal code?
About that "write-ppm" example. Using PPM type 3 will increase the size of pixel data by 2-4 times. Use type 6.
"Clojure's license makes it a complete non starter for me, sorry. Live free or die."
I don't think you understand what the word "free" means.
I don't think you understand what the word "free" means.
If you are interested in game development and lisp, may I suggest having a look at https://github.com/carp-lang/Carp ?
It's "A statically typed lisp, without a GC, for real-time applications.", the Gitter is quite friendly as well.
Something like Python. .NET, Java also isn't far from them, when language + standard library + vm reference (if any) land in dead tree form.