Live data from Hacker News

The Lux Programming Language

github.com

31–40 of 52 posts

Re: The Lux Programming Language

#31
post #28

I feel like there should be a way to re-use algorithms and data structures across programming languages and platforms automatically. Sort of like a CLR/JVM etc. but really a common exchange format that could work across different VMs or systems. A little bit like how math can formally describe diverse systems, except you could automatically process/translate this format.

The problem is that even if two languages each have, say, the Set data type, the implementation of those features and how they interact with the language may be radically different. The closest we have to what you're describing right now probably exists in compile-to-JS languages, where one language's implementation of a particular data type or standard library function can (at least in its compiled form) be used by another language.

That, or maybe something at one layer of abstraction up from LLVM - but I'm no expert.

Re: The Lux Programming Language

#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 established convention, because we do that all the time on the web.

Re: The Lux Programming Language

#33
Why EPL? I use Clojure everyday and I know why it is EPL'd, but I wish it was another license since it's incompatible with the GPL. Couldn't you consider a GPL-friendly license? It sets the tone for the community.

Re: The Lux Programming Language

#34

So if I were to learn a Lisp language for the first time, would Lux be worth my time? Also why not setup an IRC channel? edit: Typo

Lux is still in diapers, but everything should be completed in the next few months. >> So if I were to learn a Lisp language for the first time, would Lux be worth my time? That depends. Do you like sophisticated types ala Haskell? Are you interested in functional programming? Do you want a language that runs on established platforms such as the JVM or Node.js/IO.js? If you answered yes to all of those, Lux welcomes…

>Lux is still in diapers, but everything should be completed in the next few months.

How accurate is that? In the sense that it's something heard from a lot of projects, and then years pass and they're not ready yet or are abandoned.

Is there some tangibles to support this? E.g. "creator had done some other languages in the past succesfully so he knows the timescales involved", "author is paid to work on this full time", etc?

Re: The Lux Programming Language

#35
post #10
post #6

[deleted]

I have to ask: why aren't you using the reply link?

Probably because he doesn't know that while the link doesn't show up immediately on the main thread for new comments, he can visit the comment he wants to reply to itself, and it will have one.

Re: The Lux Programming Language

#36
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...

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?

Re: The Lux Programming Language

#37
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 namespacing, but ended up choosing it for the type-annotating macro, so I settled for ;.

c) ## Was chosen for comments because I get to save on reserved characters. For instance, Clojure reserves an awful lot of characters (, . / ^ # @ ~ ' ` ; : \), whereas Lux only reserves 2 (# ;). So I chose ## to save on characters and because if you squint, ; kinda looks like :

d) Ultimately, there is nothing written in stone and I can change my mind about syntax, but I don't see how rocking the boat a little bit with the syntax will cause much trouble.

Re: The Lux Programming Language

#38

Why EPL? I use Clojure everyday and I know why it is EPL'd, but I wish it was another license since it's incompatible with the GPL. Couldn't you consider a GPL-friendly license? It sets the tone for the community.

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)

Re: The Lux Programming Language

#39
post #34

Earlier quoted context omitted.

Lux is still in diapers, but everything should be completed in the next few months. >> So if I were to learn a Lisp language for the first time, would Lux be worth my time? That depends. Do you like sophisticated types ala Haskell? Are you interested in functional programming? Do you want a language that runs on established platforms such as the JVM or Node.js/IO.js? If you answered yes to all of those, Lux welcomes…

> Lux is still in diapers, but everything should be completed in the next few months. How accurate is that? In the sense that it's something heard from a lot of projects, and then years pass and they're not ready yet or are abandoned. Is there some tangibles to support this? E.g. "creator had done some other languages in the past succesfully so he knows the timescales involved", "author is paid to work on this full t…

>> How accurate is that? In the sense that it's something heard from a lot of projects, and then years pass and they're not ready yet or are abandoned.

Basically, I know how much I've done so far and how much needs to be done, so I can kinda guesstimate how much is necessary.

Taking things this far has taken me 5 and a half months, and the vast majority of the work has already been done.

v0.2 will just expand the standard library (which is a piece of cake), add a few missing features that aren't that hard to implement, and make some improvements to compiler speed.

After that, I'll just be focusing on adding compiler optimizations and porting the compiler to ClojureScript to generate JavaScript.

>> "creator had done some other languages in the past succesfully so he knows the timescales involved"

This is my first language made for public consumption.

>> "author is paid to work on this full time"

I sure as hell would like that, but I'm working part time & going to college. With that said, I've gotten quite far just by extracting time from weekends and working late at night. And since most of the work has been done, I've be surprised if Lux wasn't finished before the end of the year.

I'll also be making sure not to tie myself with other projects as much as I can to be able to dedicate all the time I can to Lux.

Re: The Lux Programming Language

#40

Why EPL? I use Clojure everyday and I know why it is EPL'd, but I wish it was another license since it's incompatible with the GPL. Couldn't you consider a GPL-friendly license? It sets the tone for the community.

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?
Post reply on HN