>> 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.
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.
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 you.
>> Also why not setup an IRC channel?
I'm not much of an IRC guy myself, but a channel can definitely be made.
I won't be present most of the time, since I've got work & college to worry about, but an IRC channel can be made.
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 simplicity at the library/API level.
Lux is more oriented towards that.
Portability
I code in Clojure and love the fact that I can work both on the JVM and on JavaScript. However, Clojure's current approach to portability lacks in several ways. I've seen other languages that compile to other platforms (like Scala & Haskell) and they all seem to have limited approaches.
I've come up with a new idea for how to approach the subject that should yield highly portable code that will be trivially reusable.
I've yet to add it to the compiler but it's gonna come in one of the upcoming releases.
Speed
Right now the code generated isn't being optimized in any way (it's v0.1 after all), but I've come with several ideas to make it fast and by the time I'm done, it will be faster than Clojure, and maybe Scala (I'm not sure about Scala, since I'm not a Scala dev and don't know how fast it is).
My goal with Lux is to get it as close to Java's speed as I possibly can.
Extensibility
Lux will allow people to access the compiler state in order to get useful information for macros. There is already a macro (using) that takes advantage of the typing information in the compiler to open up structs ala SML's open.
The pattern-matching macro is also open to extensibility and you can craft your own custom syntax to do crazy things with it.
The prelude (lux.lux) already comes with 2 such pattern-matching extensions.
From what I've seen about Shen, it seems like the idea is to write some kind of layer on top of the host language on which Shen is run, kind of like an interpreter, though not quite.
Or at least that's the feeling I've got from watching a talk on Shen.
Lux, on the other hand, will be compiled directly to the target platforms. There will be a degree of separation (mostly because portability is a #1 concern for me and I don't wan't host semantics to compromise it), but Lux is meant to compile down to host code (bytecode, in the case of the JVM).
Also, the type-system is more like Haskell's, whereas Shen has it's own way of doing it (sequent-calculus).
platz >> Describing Canonicity as a problem that that needs 'hacks' to work around seems a little disingenuous.
If by "canonicity" you mean having 1 canonical instance of a type-class per type and by "hack" you mean using records as structs/modules, then I think you're not really appreciating the coolness of Lux's approach.
Not only is Lux's approach simpler (just use records vs having to implement a complete type-class subsystem), but it's based on ideas that have existed for years in the ML world.
ML's signatures & structures are not canonical, and yet all you hear is the ML guys praising their system, without a drop of envy for type-classes.
Also, by having everything be based on records instead of ML's system, I get extra benefits and the language becomes much simpler.
Plus, using macros & the type-data in the compiler state, I've already conceived how a macro could be made that does code-transformations that make it seem as if you had globally-scoped type classes, as in Haskell.