Note that Paul did not say that Arc will be open-sourced this Winter, just that he hopes it will. That's a big difference. So much of a difference that this headline seems Reddit-ready.
I meant I was planning to, unless there's some disaster. I'm working on it now. Anyone have any preference for licenses? BSD? Or should I not have asked that...
From what I've seen, projects that go GPL tend to be more community-focused, and seem to more readily gather a contributor community around them. I think contributors tend to like the idea of their contribution being free in perpetuity.
MIT-licensed projects, OTOH, tend to be mostly worked-on by their creator (again, FWICT). That is, there are fewer individuals willing to contribute code to a project which could simply be scooped up and put into some company's closed-source product. I get the impression that MIT-licensed projects are always looking to be popular, and feel entitled to be so, since users can basically do whatever they want with the code.
A lot of careful thought by lawyers, the community, and the FSF has gone into the most current GPL. I'd suggest that it's worth considering.
I think there's a rule that when you create a new language you also have to create a new open source compatible license. I look forward to releasing code under The Arc License.
Well, it is a hard question. And the best person to answer it are you. I like simple licenses (BSD[1], MIT[2]...), but only if you don't mind people making closed version of it.
Being Arc a language, I think you would like to remain the head of its development, so maybe the Artistic License [3][4]would be right. Like Perl does.
It's far more complicated than the simple ones, but it would make easier to differentiate between the Vanilla Arc and the Straciatella Arc.
For the GPL[5], I think it is better suited for programs than for languages.
Seconded. If you really want a 100-year language, then your chief concern is getting it widely-adopted, and a permissive license like MIT is just the ticket.
I'm not so sure that liberal licensing leads to popularity. One obvious counter-example of your supposition is GNU/Linux vs. BSD.
Incidentally, the last thing the FSF is worried about is popularity, yet look at how popular GCC, Emacs, bash, and other GPL'd software is.
Licensing your software with a very liberal license may help make your software more popular with some large companies who are in a position to take advantage of it (and I suspect timing is important here as well), but I'm not so sure it makes your software popular with the developer community.
It's certainly complicated, and depends on several factors.
One thing that's important for languages like Tcl is that they can be embedded within other projects, and for that reason a liberal license was very important. Of course, it's certainly not the only thing you need. The GPL is probably ok for "finished product" sorts of things that you don't need to link against to utilize it.
I prefer zlib or boost licenses which make a distinction for binaries. You don't have to attach the license for binary-only applications which makes it more suited in some cases (like embedded development).
I second zlib. It's slightly more restrictive than MIT, but in a very sensible way. I don't think preventing modified sources from masquerading as the original Arc, or maintaining author attribution will impede adoption overly much.
I prefer GPL over BSD strictly for the reason that if someone makes a modified version of Arc publicly available, then we all get to see (and maybe use) the modifications.
Mysql's license is all about trying to make money from Mysql. My guess is that pg would prefer wider adoption to trying to make money. At least, initially.
If someone publishes a bug fix, or finds a cleaner way of doing something, I'd like to be able to incorporate it without being accused of having stolen their IP. That's the main thing.
BSD license allows you to re-use fixes of others (assuming they also release their fix under BSD), but it does not compel them them to reveal their fix if they distribute only a binary.
GPLv2 requires modified public distributions to also be under GPLv2, so you could both see the fix/change and use it (in the sense that you won't be infringing on copyright).
GPLv3 adds patent protection, so someone adding a fix/change that they have also patented explicitly grants a license for that patent.
I think GPLv3 is the most comprehensive way to keep fixes/changes of others available for reuse.
Don't forget that if you use the GPLv3 you won't be able to distribute your software with the OLPC, since it has anti-theft measures which put signed code at an advantage to unsigned.
If I recall correctly, the Apache license has some kind of clause to the effect that all contributors automatically grant you all the same rights available under the license, meaning that by contributing, they acknowledge the license and give you permission to make use of their contribution. There is also some anti-patent stuff.
Public domain is not enforcable in some countries. You can't give up your copyright as author for example in germany. So a license defining the rights of the users will work better.
There is no such thing as public domain for software. If you simply give your software away, it's still your copyrighted work...just without a license for other people to use it.
I'd like to be able to embed it in apps. Any license that allows that is OK by me.
Some ideas I've got floating around are to use it for scripting (instead of, say, LUA or XSLT) and for config files (instead of XML) in existing apps. Also, lisp seems fantastically placed for HTML generation, so if I embed it in an IIS or Apache site, then great!
The license should cover patents. If a company adds to the code using patented algorithms, they could perhaps block further development since nobody could use the code? I'm not a lawyer, so perhaps it's not a problem anyway.
pg: It should be Affero GPL. You won't overthrow Java et al anyway, but if Arc is as good as we all anticipate, choosing AGPL may really help the free software.
Er... yes you did. A Reddit worthy headline would have been "Paul Graham Exposed! Fundamentalist Christian plans to finish an arc before 'Judgement Day'"
Feature Request: Why not have the "new" comments in a thread visually distinct from the "old" ones?
When there's a big thread like that I'd like to check the new comments but I can't be bothered to read again the 64 comments I read earlier to find the 8 new ones.
You could dual-license Arc, like Gambit Scheme does. I believe Gambit uses Apache 2.0 and LGPL 2.1. I hope that the open-sourcing of the language won't cause it to become too stable and end its evolution, like what happened with Java. I think languages should have a breaking-reverse-compatibility release scheduled every five years.
I guess this announcement puts an end to my plan to read everything PG has written about Arc and then write my own implementation.
I have a Lisp success story. I wrote a decompiler in C++, building cruft on top of cruft, until it became too unwieldy (c.70,000 lines), so I rewrote it from the ground up in Lisp. Now it's 20,000 lines, far more elegant, and works a heck of a lot better.
However, I did experience a certain amount of burnout on this - I haven't written anything nearly as extensive since (eg, no more than 1000 lines of Lisp).
Well, that just complicates my "language to learn this year" decision.
Last year was Common Lisp. I was planning on doing Python this year. Then recently Scala has been looking very interesting, with the functional/static thing with not bad performance and access to the whole Java stack (I program Java at my job).
Now Arc might be a possibility. At this rate, it will be December and I'll still be trying to decide.
I think you're right. I already found a task for Python to do, spent a couple weeks (off and on) refining it, and at the end I seemed to have used all of the prominent features of Python somewhere in that script. At the end of that, I had this vague feeling that I now "knew" Python and wasn't sure what was left to learn.
So, you are confirming my vague feeling and I can now move on to Scala and decide whether or not to switch to Arc once it emerges. :)
Since you're feeling cocky, have a look at the Zope/Plone source. You'll almost certainly realize you don't know Python (and possibly that you don't actually want to).
There is a difference between a language and its common idioms. "Generator expressions" is a good phrase to test how much people know. For example: http://norvig.com/sudoku.html
Python can definitely fit in your head, as far as the language. Reading lots of code is a good way to learn the idioms.
I wasn't actually referring to the usual Python idioms, but if you're unfamiliar with Zope/Plone, you can be forgiven for not knowing that. The Zope developers (and to a lesser degree Plone) don't actually seem to like Python, and so they've reinvented many common language features and libraries. Partly this is historical...the Python that Zope was originally written in didn't have most of those features or the standard library that exists today. It's one of the problems of developing a large codebase in a language that is still in rapid flux and doesn't mind throwing out backward compatibility (my Perl code written before Zope existed still runs on modern Perl, while practically none of my Python code from 1.5 through 2.2 runs today unmodified).
But, regardless of the very sound reasons for it to be the way it is, it's a very intimidating codebase, and a really good case study in the "reinvent everything" mindset. (It's quite powerful, and I've worked with several of the guys who built it, as I did contract work for Zope Corp for a few years, and I have the utmost respect for their talent and intellect. They're some of the smartest developers I've ever met. But it's not quite like anything else I've ever seen when it comes to having a learning cliff, even with some pre-existing Python knowledge.)
Yes, C is another good example. The language is fairly small, and it's not terribly difficult to learn the language itself and write your own programs. But to be able to look at an arbitrary piece of C code and understand all of the implications is another matter entirely.
This is true of any language to some degree, although some are worse than others, and if the code was purposefully written in some non-traditional way it can be even harder.
I knew about list comprehensions, but generator expressions add some new tricks. And I also now have a clearer idea of what constraint propagation means.
this year a particular language surprised me: Lua. i'm not a polymath of programming languages, but in my experience Lua is the most powerful non-lisp language (in terms of abstractive power). it's scripted, functional, dynamically typed, supports closures, asymmetric coroutines, has a heterogeneous data structure, and gives you access to the 'compiler'. it's something like a heavily improved and simplified javascript
pg has said in an earlier post that he likes designing his own custom languages to fit a particular need. I'm interested to hear what the tagline for Arc will be.
