"Except as otherwise specifically permitted in this Agreement, you may not: [...] (h) publish any results of benchmark tests run on the Software to a third party without Licensor’s prior written consent"
So we know that it's slow as crap, which is especially problematic given the author's claims of suitability for embedded development, and the author also thinks that nobody's going to notice. (What's next, an NDA to get the proposed license?) There's not a big enough cup to hold all the nope.
Honestly, it might even be the fastest language ever, but if the license prohibits something as basic as sharing benchmarks there is something quite fishy and dystopic.
Would this be likely to hold up in court at all? It seems like this kind of thing would fall under the purview of defamation law, and benchmarks are essentially "just facts" so about as safe as you can get. I imagine they'd have to show that you maliciously construed the benchmark itself or something to make any case stick.
Sure, but licences are not free to obligate anything at all. A lincense cannot legally obligate otherwise illegal behaviour, for example. It just wouldn't hold up in court. My question is about how far licenses can circumscribe non-illegal behaviour.
There are clear pathological cases that probably wouldn't hold up in court either. What if a software contract says that you must turn over your first born child? I image that the software company would have to provide some very good reasons for including such a clause.
A lot of commercial embedded compilers have similar licenses. Even ones that e.g. have certified and published EEMBC benchmarks, so it's not so much of a red-flag as you might think.
* I see many claims of "cross-platform", but not a lot of substance to back it up. The FAQ is odd as well - it makes many claims that are simply not true.
* Given that you chose to keep the source closed, what guarantees will I have that your language will continue to be supported if the company collapses?
* What are you offering in a paid language that isn't already provided by an open alternative?
* What is the state of the standard library or library ecosystem? Will I end up writing my own dependencies?
did you google the name before deciding on it? The term "8th" already has a well-established association that you might not want attached to your company:
> 8th lets you choose, and offers strong protection if needed. ... The build tool compress your program code and all its required bits and pieces into a ZIP-format blob which is unpacked, compiled and run on the device when needed. It is difficult to modify the ZIP-data without corrupting the deployment package.
Also, unless they're doing something interesting, zips really aren't hard to modify. See also: Android APKs, also just fancy zip files, also easy to modify (though, granted, you have to re-sign the result).
I wonder how much money they would be willing to bet on their big claims of security. Somehow I don't imagine it would last long in the hands of a dedicated individual.
At the risk of sounding negative may I ask, why would I even use a platform with really shady testimonials ( https://8th-dev.com/kudos.html ) and something that might have no future?
>The main reason 8th is not GPL licensed is that I (Ron) have strong philosophical objections to being forced to give away my intellectual property. I disagree with the very tenet that "code should be free" in the GPL sense. Instead, I am of the opinion that you are free to have access to the 8th source code if you are willing to pay for that privilege. If not, not.
>A secondary reason we do not follow the "open source" idea is that, frankly, over the many years we have used open-source projects, we have been struck by the simple fact that a great many of those projects are maintained only to the extent the author decides to do so. Thus for example, the venerable "gcc" compiler has severe bugs which were reported many years ago, but which will probably never be fixed. This, despite the fact that the code for it is available and anyone could fix it at will. Nobody has, probably nobody will -- because the gcc code is extraordinarily difficult to grok. So the "many eyes" argument for open-source and GPL is not overly convincing to me.
> Thus for example, the venerable "gcc" compiler has severe bugs which were reported many years ago, but which will probably never be fixed. This, despite the fact that the code for it is available and anyone could fix it at will. Nobody has, probably nobody will -- because the gcc code is extraordinarily difficult to grok. So the "many eyes" argument for open-source and GPL is not overly convincing to me.
It looks like this really just identifies that "hard problems are hard", ignores any actual benefits, and incorrectly projects that onto a "license problem". Anyone is free to license how they like, but this isn't a strong argument for that.
> A secondary reason we do not follow the "open source" idea is that, frankly, over the many years we have used open-source projects, we have been struck by the simple fact that a great many of those projects are maintained only to the extent the author decides to do so
I'm sure this company will be maintained only to the extent the company can stay alive.
on one hand, yes, I support their right to do whatever they want with their product. on the other hand, as a user I am not willing to invest any time or attention in a closed source language.
also, having seen that philosophy essentially kill qi/shen, I am sceptical of it as a general approach. might work for some niches like game dev.
Indeed. Programming languages are a buyer's market. Sure, you can feel free to do whatever you want with your own language - just don't expect people to take it seriously.
yes, but there seems to be a certain window of opportunity for new language where they have enough mindshare for lots of early adopters to check them out, and if there are any barriers to adoption at that point the crowd tends to move on to the next new thing. sadly, fixing things later doesn't seem to work, though I wish it would. I can immediately think of shen, rebol and D as languages that have not done nearly as well as one might expect based purely on what they offered to PL enthusiasts, and I am sure there are lots more.
Poplog - a hydra of Common Lisp, Standard ML, Prolog, and POP-11. Late 1980's, early 1990's, it seemed like it could change the world. With dreams of riches, it was kept closed source and commercial. It made a few million... and is dead and forgotten. Gotta wonder what the world might be like now, if they'd chosen glory over riches.
> strong philosophical objections to being forced to give away my intellectual property
Non-sequitar. If you used the GPL, you'd be doing so voluntarily, so you wouldn't be being "forced" to do anything.
> a great many of those projects are maintained only to the extent the author decides to do so
An issue that is even more pronounced with closed source software, where _all_ such projects are maintained only to the extent the author decides to do so.
Every programming language I've ever used has been open source. I have fixed small issues myself, and I know that I or someone else could fork them if the current maintainers quit.
Whether developers have the right to the source is debatable. But personally, I wouldn't stake the life of my projects on a language (or database) whose life depends on one entity and their business model. And it seems to me that others feel the same way, and that the trends are toward OSS - .NET went open source, Oracle is giving way to PostgreSQL, Azure now supports Linux, etc.
I have a different objection to Open Source, that companies can profit from its use without paying its developers a penny, and usually do. My preferred licence is Shared Source: you get the source, and it's free
(as in beer) for non-commercial use, and can be bought for commercial use.
"He developed the well respected Reva Forth, used by hobbyists around the world. "
Reva Forth always seemed nice but I could never get it working on anything other than Windows.
As such, I have little faith that "8th" will place any value on portability either, e.g., that it will be ported to BSD, Plan 9 or other RPi-compatible OS.
Meanwhile, there are plenty of more portable, open source Forths to choose from.
Some HN commenters are questioning the peculiar security claims.
The author discloses that 8th depends on a number of third party libraries. Would this mean that each of those third parties would also have to make similar security claims to 8th?
For example, 8th uses an HTML5 parsing library from Google called gumbo-parser.
"Non-goals:
Security. Gumbo was initially designed for a product that worked with trusted input files only. We're working to harden this and make sure that it behaves as expected even on malicious input, but for now, Gumbo should only be run on trusted input or within a sandbox. Gumbo underwent a number of security fixes and passed Google's security review as of version 0.9.1."
C# was close sourced for many years. It's who backs up the language, the tooling, the standard out of the box libraries, and documentation that makes a big difference in deciding the lifespan of a language. Then speed, stability etc (not in that order)
Yes, but it was also owned by MS, a big company. I think closed source language is a terrible business model, especially considering that this model managed to kill several well-known programming languages (Smalltalk, Common Lisp).
Smalltalk was never owned by a single company since the first public release in 1980. Common Lisp was born in cooperation between Symbolics, Texas Instruments, Xerox, CMU and was never owned by a single company either. Neither of them exclusively had closed-source implementations.
It was closed for the first year, then went "open" but with AGPL therefor you cannot make non-opensource software with it if it has any users beyond yourself.
It is a clear case of the license hampering the adoption of an otherwise good idea (JSX is so commonplace now, Opa had it already in 2010). But you are right, the actual close source era of Opa was very short.
sure, for a closed-source language that you have to pay for, you need to have a very high confidence in the source. for a closed-source closed-specification language, it seems quite a tall ask, imo. it would have to be something really amazing.
i would wager that c# standardizing it's specifications (over ten years ago) and having an open-source implementation (mono) was a big deal, and moving toward rosalyn was certainly a strategic move.
Whether or not 'Delphi/Object Pascal' includes the largely compatible Lazarus + LCL + Free Pascal combo is a very big question here. Just 'Delphi' would be clearer, FPC refers to itself as an 'Open source compiler for Pascal and Object Pascal' : https://www.freepascal.org/
Because of FPC, arguably, if you use Delphi you're not exactly stuck in the unlikely event that it dies since in the worst case there is Free Pascal to move to, LCL and Lazarus (although I have no idea how it compares to modern late 2010s era Delphi and RAD Studio but it's at least something). Delphi also has a more or less proven track record, costs a lot, is pretty much enterprise tier item and has a multi million company behind it.
I'd argue Object Pascal is not a closed language but a language that has few implementations, one major open one (FPC) and one major closed one (Delphi) and that the situation is even better than C# vs. Mono was, since Mono had a murky legal/patent situation (or maybe it was FUD, I'm not too into C#) and the situation was basically 'closed language with a closed implementation that happens to have an open implementation' while FPC and Delphi are more like brothers with Delphi not 'owning' the concept of Object Pascal in itself nor any patents that could threaten it in any way AFAIK.
Dyalog APL is an extremely interesting environment and implementation, with very good downloadable technical documentation, I suppose it might go for some lisps too.
"Except as otherwise specifically permitted in this Agreement, you may not: [...] (h) publish any results of benchmark tests run on the Software to a third party without Licensor’s prior written consent"
So we know that it's slow as crap, which is especially problematic given the author's claims of suitability for embedded development, and the author also thinks that nobody's going to notice. (What's next, an NDA to get the proposed license?) There's not a big enough cup to hold all the nope.