Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Lux Programming Language

github.com

Post reply on HN
Print view View original

41–50 of 52 posts

Re: The Lux Programming Language

#41

Post by afshin »

unfunco wrote: post #40
eduardoejp wrote: post #38

Earlier quoted context omitted.

I am not much of a licenses buff, so I just went with EPL because it sounded reasonable. Anything that looks like *GPL will be avoided because of its virality. How is EPL incompatible with GPL and what licenses are friendly to it? Apache License v2? (That's another one I was considering)

You're avoiding a license because it's popular?

I think by "virality" what was meant was that GPL libraries "infect" non-GPL because the larger work must also be released as GPL. For programming languages, though, this should not be an issue, unless somebody is bundling the whole interpreter/compiler with their app.

Re: The Lux Programming Language

#42

Post by eduardoejp »

afshin wrote: post #41
unfunco wrote: post #40

Earlier quoted context omitted.

You're avoiding a license because it's popular?

I think by "virality" what was meant was that GPL libraries "infect" non-GPL because the larger work must also be released as GPL. For programming languages, though, this should not be an issue, unless somebody is bundling the whole interpreter/compiler with their app.

In the future, I plan to rewrite the Lux compiler in Lux itself, and one of the reasons is to allow people to embed it and use it's API.

That way, if someone wants to create an online Lux REPL for people to try Lux, it won't be hard for them to do so.

Re: The Lux Programming Language

#43

Post by goldfeld »

eduardoejp wrote: post #42
afshin wrote: post #41

Earlier quoted context omitted.

I think by "virality" what was meant was that GPL libraries "infect" non-GPL because the larger work must also be released as GPL. For programming languages, though, this should not be an issue, unless somebody is bundling the whole interpreter/compiler with their app.

In the future, I plan to rewrite the Lux compiler in Lux itself, and one of the reasons is to allow people to embed it and use it's API. That way, if someone wants to create an online Lux REPL for people to try Lux, it won't be hard for them to do so.

The GPL allows you to modify the source and provide a service on a public server without having to share your modifications.*

But I understand if you prefer a more permissíve license. Lots of people go with MIT License, it's very short, permissive and compatible with the GPL. Apache v2 is also compatible.

See here about EPL being incompatible: https://www.fsf.org/blogs/licensing/using-the-gpl-for-eclips...

Last time I tried understanding the key subtleties of the EPL I came out empty handed, but it would seem it's more viral than the permissive licenses above, bit less so than the GPL.

* That's why the AGPL exists, so someone working on a Lux REPL would only have to show the code for his online Lux modifications if Lux was AGPL.

Re: The Lux Programming Language

#44

Post by c3d »

jonnybgood wrote: post #21
eduardoejp wrote: post #19

Earlier quoted context omitted.

Simplicity My ideal of simplicity is more like Haskell's than Clojure's. Clojure strives to be easy-to-use, but in the process, both the language and standard library have evolved a lot of convoluted and often redundant code (you can take a look at the definition of map to get an idea: https://github.com/clojure/clojure/blob/028af0e0b271aa558ea4... ) Haskell, on the other hand, is a very simple language that seeks si…

It sounds like you want Frege, no? https://github.com/Frege/frege

Never tell the creator of a language "It sounds like you want X". Creating a language is done a) for fun, b) just because, c) as a personal development plan, d) to explore, e) to become master of the universe. None of these is achieved by merely using language X, whatever the value of X is.

Re: The Lux Programming Language

#45

Post by chadzawistowski »

tormeh wrote: post #36
chadzawistowski wrote: post #12

Earlier quoted context omitted.

Mark Tarver originally wrote Qi, which exclusively ran on top of Common Lisp. Qi was refactored as Shen, which is implemented on a small core and is thus very portable. IIRC Mark only maintains the Common Lisp implementations, and the rest were implemented by the community.

How can something, no matter how small core it has, be very portable from CL to Haskell?

Shen doesn't execute directly, it's compiled to K-lambda, a very small, simple, lisp-as-bytecode. K-lambda is very portable, and wherever K-lambda can run, so can Shen.

Details here: http://www.lambdassociates.org/blog/klambda.htm

Re: The Lux Programming Language

#46

Post by zak_mc_kracken »

unfunco wrote: post #40
eduardoejp wrote: post #38

Earlier quoted context omitted.

I am not much of a licenses buff, so I just went with EPL because it sounded reasonable. Anything that looks like *GPL will be avoided because of its virality. How is EPL incompatible with GPL and what licenses are friendly to it? Apache License v2? (That's another one I was considering)

You're avoiding a license because it's popular?

He meant 'viral' as a negative.

The GPL is pretty much banned across the entire industry because of the fact that it forces accompanying software to be open sourced as well, which is a deal breaker for most companies.

Re: The Lux Programming Language

#47

Post by dragonwriter »

zak_mc_kracken wrote: post #46
unfunco wrote: post #40

Earlier quoted context omitted.

You're avoiding a license because it's popular?

He meant 'viral' as a negative. The GPL is pretty much banned across the entire industry because of the fact that it forces accompanying software to be open sourced as well, which is a deal breaker for most companies.

> The GPL is pretty much banned across the entire industry because of the fact that it forces accompanying software to be open sourced as well

The GPL explicitly doesn't require accompanying software to be released under any particular license. (See, e.g., GPLv3 Sec. 5, ending with "Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.")

Re: The Lux Programming Language

#48

Post by dragonwriter »

afshin wrote: post #41
unfunco wrote: post #40

Earlier quoted context omitted.

You're avoiding a license because it's popular?

I think by "virality" what was meant was that GPL libraries "infect" non-GPL because the larger work must also be released as GPL. For programming languages, though, this should not be an issue, unless somebody is bundling the whole interpreter/compiler with their app.

> I think by "virality" what was meant was that GPL libraries "infect" non-GPL because the larger work must also be released as GPL. For programming languages, though, this should not be an issue, unless somebody is bundling the whole interpreter/compiler with their app.

For programming languages that include a prelude or standard library on which most actual programs will rely on in whole or in part, it may be problematic (and, of course, its especially problematic for languages where substantial parts of the interpreter/compiler itself is part of that standard library, as is the case of any language which implements a general purpose eval.)

Re: The Lux Programming Language

#49

Post by adamwk »

eduardoejp wrote: post #37
Expez wrote: post #32

You'd do well to stick with existing syntax conventions. People care about this stuff and introducing changes just because you can seems like a bad idea if you want your language to get wide adoption. So I'd like to see ; be restored as the comment character, to match every other lisp ever written, and you should probably use / for namespacing like in Clojure. The use of / for namespacing is already a well establishe…

Your concerns are well founded but what's going on is this. Import paths will be using / for the separation of the path, so you'll be writing things like: (import foo/bar/bar #as baz) I haven't added imports yet, but they're coming for v0.2 Regarding ; as comments and not namespacing, I chose it mostly because: a) Using / for namespacing leaves the / function in a weird position. b) I originally wanted to use : for n…

Syntax is always a prime candidate for bicycle shedding so they'll always be brought up but uncommon syntax is jarring at first.

One problem I see is how overloaded the `#` character is right now. I think one problem that Scala is stuck with is how many things for which `_` is used.

Re: The Lux Programming Language

#50

Post by yellowapple »

cheepin wrote: post #27
tormeh wrote: post #5

Earlier quoted context omitted.

"runs under CLisp, SBCL, Clojure, Scheme, Ruby, Python, the JVM, Haskell and Javascript" Wow, someone really likes writing compilers...

Interesting to see how many of these overlap. For example: Lux->Clojure->JVM Lux->Ruby->JVM Lux->Haskell->Javascript Any more that I missed?

Hypothetically: Lua->Clojure->Javascript (since Javascript is supposedly one of Clojure's compilation targets, in the form of ClojureScript).
Post reply on HN