Very entertaining article, just a small remark when people count pages in Common Lisp or C++ standards, they tend to forget that standard library is also part of those pages.
Something like Python. .NET, Java also isn't far from them, when language + standard library + vm reference (if any) land in dead tree form.
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?
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.
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.
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.
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)
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).
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.
Interesting. I frequently write Common Lisp code in org blocks and execute from there, but not Emacs Lisp. And I don't have emacs on my phone so I can't test it. Can you copy a sample org file here?
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.
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.
> 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".
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.