Learn Shen
shenlanguage.org
shenlanguage.org
http://www.shenlanguage.org/license.html
Unfortunately this is something I have to mention every time Shen is mentioned, because I'm irate that, in spite of my interest in it, that both it (and its predecessor Qi) insist on doing something so strange with no apparent legitimate purpose (some kind of bogeyman of fragmentation killing the project).
It not being "free software" is pretty debatable imo. Maybe not free with a capitol f, but free enough as an academic language.
Constructing derivatives of other languages is a pretty common thing for PL academics to do.
I would advise anyone to stay far, far away from that sort of licensing.
It seems impossible to combine most software components with it if you were trying to build something on top of Shen (as an example).
Why is it strange to want to avoid dilution and confusion of your product? People can use it, modify it for improved performance, add libraries to it, include graphics and other files as necessary, and even charge money for what they've done with it. Pretty much the only thing you can't do with it is modify it significantly and re-release it as your own personal brand of Shen (whether renamed, or not).
It looks like a lot of work went into it, and they're basically gifting it to the community to use and profit from.
A more open license would be great, sure. But they have a legitimate position here, and they make a reasonable point. It may be myopic in some people's opinion, that's a matter of debate, but I don't see how it can be considered to be absurd.
[1] "Hence the production of derivative non-conforming programs from our source, whether called Shen, Shin, Shine or Shoo, is barred by the license. To give up on this is to give up on the motivation for Shen.
We are therefore not open source. Generally, the diversity and freedom to fork which was lauded as a strength of open source, has turned into the major weakness of Linux. This OS has been burdened by multiple forks, multiple distros, multiple apps for doing the same thing to the point where essentially the same work has been redone over and over again by different groups. The resultant wastage of effort has been huge and the result has been lack of cross platform usability, a lack of uniformity in the user interface, a reliance on complex dependencies and too often, software that reflects the scattering of human resources by displaying broken functionality. Even Linux fans are seeing this. This in turn has given Linux a bad name. We want to avoid all that."
> "Why are you guys so fork paranoid? Do you want everyone to vote for the same political party, too?" -- Theo de Raadt
A witty saying proves nothing, but it might be a good starting point for a discussion. To me, it isn't strange that an author wants to avoid dilution and confusion of their work, we all feel this way at one point or another when producing software.
But, when I pick a community and a language to express myself, I consider several potential future issues. Such as, will this language be around in five years? Will I be able to port it to a platform that few people find to be important/interesting enough? Will I be allowed to experiment with the fundamentals? Will I be allowed to disagree with the original author on how things are done? With a license like this, worries starts to pop up into my head. Since to me software isn't handed down from above, it is an ecosystem of which I am an active a part of.
If the authors don't trust someone else to do what they do better, or different for another purpose. Why should I trust them?
To me free software either has no price or has no licensing restrictions at all.
What is free software?
When the word "free" is hijacked for political agenda we slip a little closer to the Orwellian dystopia.
Who decides whether a language I come up with is a port/version/mod of Shen? How much of Shen's features can I include without crossing that threshold? Does that threshold move if I can point to other non-Shen languages as the source of those ideas?
Not all languages have to have the same license. It's open source, since the source is available, and it's free, since you don't have to pay to use it. If you mean that it's not "free" by FSF definition, then just say "it's not Free (tm) FSF(c)".
Not all language implementations have to be open source, and conversely, I don't have to invest my infrastructure in all language implementations, especially ones that choose to hobble their fitness in the form of a dubious and paranoid license, which I think is chosen based on reasoning that may have only been defensible (not even 'good') in 1985 or 1990.
The comparison to "Linux" (by which they mean, distributions, I presume, instead of the kernel, which is definitely a monolithic development effort) is as laughable as worrying about "what if thirty people write TLS libraries in Shen!?" The problem ostensibly addressed by the license is not solved, and so it is nothing more than an albatross.
It's a pity, because the ideas in Shen deserve a better chance than that.
The license makes the work $free and the only requirement is that if anybody changes it, that it continue to work. Otherwise I can do as I want. Perfectly fair.
Also they seem pretty successful in building a whole series of portable cross-platform versions which compared to the crud I've seen under Linux is a very good start.
"It's a pity, because the ideas in Shen deserve a better chance than that."
I think Shen deserves a better analysis than yours.
Your concept of being unfettered tells you that you should have the right to park your tank on somebody else's lawn. Doesn't it hit you that your goal of being unfettered to foobar something you don't understand (and nor do I actually, but I'm humble enough to admit I'm unqualified to hack the Shen kernel) might actually interfere with what the people on that project are trying to achieve? So the end result is that you end up being so fettered by your own attitudes you can't even get to understand what is being gifted for free (in the good old fashioned Anglo-Saxon use of the word). You remain perpetually stuck with yur sense of self-entitlement.
That is what I call a psychological problem.
I can't justify a reason to absorb that much risk over the lifetime of maintaining programs written in the Shen language, running on the Shenlanguage.org implementation, which is presumed to be the best. The relatively new implementation is hard enough to swallow, but understandably completely necessary and unavoidable. Considering the typically interested audience of advanced static typing include staid system programmers looking for an edge in correctness in systems that take a long time to build and last a long time afterwards, that's a pretty weighty consideration. It is from this viewpoint I evaluate my dependencies.
So, sorry. I don't think my analysis -- which is something you seem to sneer at -- is without a justified dimension. To be fair, I sneer at the licensing in turn, so all is even.
Hopefully, the authors might understand why so many people may be so hesitant to invest in their platform, doing all the hard work of writing, debugging, and maintaining ports and libraries on such a foundation, as they seem so inclined to ask people to do. Even if the existing authors did all that themselves, proposal of new investment in the platform in organizations at arm's length from Lambda Associates would raise some eyebrows. I could see enormous organizations (like the US DoD or Boeing) being interested.
I'd compare Lambda Associates (the Shen author umbrella organization) as a less entrenched Adacore as things stand.
Given that I don't feel they solve their purported problem anyway (divergent language implementations are not so much a fragmenting force as multiple libraries with inadequate resources doing the same-ish thing, a problem virtually un-treatable by any policy or license) I'd really hope they'll one day see fit to just not be strange with respect to licensing, and change their mind. The observation of another poster -- that this may ironically increase fragmentation, because someone fascinated with the ideas in the language but not the bizarre license -- may be inclined to make something kind-of-not-quite-like Shen rather than contributing to the existing artifact.
BTW if you're going to use words like 'laughable' and 'paranoid', don't complain at people who question your posts as sneering at you.
I can work with this implementation, sell my stuff on it, learn from it, its less restrictive than GPL. You apparently cannot do that because your mindset stops you.
And as regards libraries; the library AFAIK is under BSD. The kernel is under license and the page explains why.
"The analogy that we would like people to carry with them is that of a spinning wheel. The freedom of the wheel to spin depends on there being a fixed hub which at its theoretical geometrical centre point shows zero motion. Our adherence to standards and discipline as system programmers allows you, the applications programmer, to be confident of basing your work on ours."
Is this problem really solved by the license? The example given (Linux distributions) is not a good parallel to a language implementation. As per earlier, this is more like worrying if people will come up with thirty ways to implement TLS -- something they are still free to do. Fragmentation analogous to that cited is not curbed in any way, from what I can see.
The other side of the coin: is the problem a problem? Do similar but incompatible implementations really typically come from a common base? From what I can see, this is Not A Problem -- usually such subtleties are from complete reimplementations and under-specification or just flat out bugs. So why worry about this?
The final concern that I have left unstated, but other posters have also probed at is "if a group of people have the determination to change Shen's semantics and wish to distribute it and maintain it, and people wish to use that, should they be denied? Why should anyone trust the original designing committee over the course of many years, with their only recourse being to start from scratch?"
It's hard to understand what the authors of Shen want to get out of the whole thing, but I'm not only perturbed by their choice of aesthetics in this area, but the apparent fact that the problems ostensibly treated seem very much untreated. It is this latter fact -- that the stated concerns seem to have resulted in a non sequitur decisions -- that leaves me even more confused and disappointed.
I'll finish this concluding: of course the authors are free to do as they will, but I can't read the soundness in their line of reasoning and am simultaneously disappointed by the result, and I'm sorry I've let that disappointment make me snide.
"Do similar but incompatible implementations really typically come from a common base?"
In this instance without the license the answer would certainly be 'yes'. Forking from the existing sources would be the obvious and easy route.
"If a group of people have the determination to change Shen's semantics and wish to distribute it and maintain it, and people wish to use that, should they be denied? Why should anyone trust the original designing committee over the course of many years, with their only recourse being to start from scratch?"
Well that's a tough one. According to Stallman the answer is 'yes' because the originator has no special rights over his work. On the other hand Stallman's idea of freedom is freedom to agree with Stallman. I prefer BSD.
If we imagine that this group know what they are doing then the answer might be 'yes'. However you cannot write this proviso into a license, so you have to allow the half-assed changes along with the good ones and you're back to a free for all.
Pragmatically what I think is that the Shen group are very good; they are the only ones with the expertise and they have a good track record of delivery. The Shen spec looks good. I've read Tarver's book on Qi and from what I can see the whole semantics of the language is mixed in with a bunch of proofs in math'l logic that I for one wouldn't want to mess with. If they drop the ball, we should step in, but If you did have a case for changing the spec, my money would be that the best thing to do is to approach the group and put forward your case.
I'll say one thing for Tarver and what he does; it sure is different. Fifteen years on, with billions of free hours, open source has failed to deliver a popular Linux desktop. Maybe we should start being a little open minded about methodologies and licenses before jumping on people's heads. The important thing is to deliver.
If it's a great language, but the current implementation is toxic (as it seems to be), you'll get people writing their own implementations of it, which will inevitably differ, and the lack of a common base will make divergence even more likely. With forks, at least you usually have the option of porting changes between the forks with a smallish amount of effort; with separate implementations, this sort of thing becomes much harder.
Systems like this are usually used as theorem-proving systems, not actual production languages. I think Qi was intended to be a practical language that allowed arbitrary proofs about the properties of its programs.
I have not been able to find any reference to this in a quick perusal of Shen's documentation.
union types (data T = mkTA A | mkTB B) <-> logical disjunction (A ∨ B)
product types (data T = mkT A B) <-> logical conjunction (A ∧ B)
function types (type T = A -> B) <-> logical implication (A → B)
the unit type (()) <-> true (⊤)
bottom (⊥) <-> false (⊥)
Inference on richer type systems, e.g., systems that support dependent types (types built up from expressions about the values they represent) is in general undecidable, which is why some dependently typed languages (e.g., Coq) have type systems that are not Turing equivalent—the language designers have consciously pared down parts of the type system in order to guarantee that type-checking terminates.
0. This is the Curry-Howard correspondence: http://en.wikipedia.org/wiki/Curry–Howard_correspondence#Cor...
Dependent types correspond to first-order logic in the Curry-Howard interpretation. I don't know much of anything about Shen, so I can't comment further on it specifically.
By the way, limited dependent types can also be implemented in Haskell through type-level programming. The paper that introduced this idea [0] is a good read, and doing some type-level programming is a great way to get to grips with the ins and outs of Haskell's type system. If you're interested in type-level hackery, also be sure to read the HList paper [1].
0. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.22.2...
http://www.cs.uu.nl/education/scripties/pdf.php?SID=INF/SCR-...
There's also typed racket, which i don't know anything, it's been mentioned to me as "theorems for free"
There's some talk about the motivation here: http://www.shenlanguage.org/motivation.html.
I'll admit that, having studied Haskell before Lisp, I really, really like pattern matching. But I don't think this would be enough for me to pick up Shen; I'd probably go with Clojure if I wanted a Lisp.
A quick google for 'Shen' proves as much.
As opposed to searching for 'Go', Ruby', 'C' or 'Python'? Don't worry, if it becomes at leas a bit popular, Google will learn how to search for it.