This looks so awesome! It's got the best parts of a lot of languages. This is what sticks out to me:
- Really simple lisp like scheme, but reminds me of lua (and not bloated like CL)
- Has resumable fibers, no callcc like scheme
- Not missing the lack of lists tbh
- A module system that doesn't feel awkward like CL
- A built-in package manager (unlike CL)
- Good lua and C support
- Threads have a shared-nothing approach with message passing (reminds me of Erlang actors)
- Destructuring
- Good PEG support, encourages it over regex
- (Im)mutable versions of data structures (ie tuples vs arrays, structs vs tables) for maximum flexibility
- Prototypal inheritance
- Docs are clean and easy to read
I'll definitely have to try this out, it looks really cool.
Some stuff I'd like to see:
- Pattern matching support (could be a library I guess)
- Multimethods
- Full numeric tower with arbitrary precision types
- Javascript compilation -- I could see this language being really useful for web and game dev
Does it have good debugging support?
I'm thinking of something like slime, swank, etc. Can I set up emacs and/or vim to work the same way I can use CL with slime + swank?
I'm also wondering about the stack traces -- one of the downsides to CL is sometimes the stack traces are nasty to read
I never thought I'd see a Lisp without lists. Oh wait, I didn't because this isn't a Lisp.
I know naming is hard, but this is getting out of hand. Don't say you're a Lisp when you're clearly not. Say Lisp-inspired. Don't use the term 'modern Lisp', 9/10 it's signaling the wrong thing.
I'm so tired of this whole "xyz lang isn't a REAL lisp". First off, what's your definition of "real lisp", second off, who cares? What point are you trying to make? Is the language somehow less useful because it doesn't meet your arbitrary definition of what it means to be a "real" lisp? I imagine you sitting at home in a smoking jacket with some smug smirk typing this out.
Saying that a language isn't a "real lisp" because it doesn't use cons cells is like saying a map implemented using a red-black tree isn't a "real" map because it doesn't use an array of nodes.
The definition of what is Lisp does not have the moving goalposts you imply.
> Is the language somehow less useful
It may in fact be the most generally useful programming system in the world.
But does it have to be misleadingly named?
Would you make a four-wheeled bicycle and call it a "skateboard"?
> saying a map implemented using a red-black tree isn't a "real" map
Rather, it's like writing a map using an array of nodes, and then calling it "red black tree" and using identifiers like rbtree_t and rbtree_node_t all over the code, complete with a rbtree_lower_bound function that calls bsearch, followed by a linear scan to find the lowest duplicate key. Why? Because all the popular maps use red-black trees and the designer doesn't understand what that actually is, believing it to be a synonym for any ordered map.
Lisp is not abstract, like "map"; it started as the name of a concrete computer program with a reference manual describing specific features. It spawned descendant systems and imitations. Those which are too far from the original concept aren't Lisp, simple as that.
"Lisp" is an implementation word, not an abstraction word.
Lisp is a specific implementation of symbolic and list processing with specific shapes of data structures, names of functions and their semantics, treatment of Boolean conditions, syntax, and everything else.
Another implementation of symbolic processing, no matter how well or how badly it works, is something else.
People who make Algol-like languages understand this.
Wirth made some very similar languages yet prudently gave them different names. The result is that anyone who says that Oberon is Pacal or that Pascal is Modula 2 is promptly and correctly regarded as an idiot.
> Don't use the term 'modern Lisp', 9/10 it's signaling the wrong thing.
I think it's signalling exactly the right thing. We know exactly what to expect when someone claims they've made a "modern Lisp". That phrase has come to mean "something with parentheses that demonstrates that its author doesn't understand Lisp at all."
Lisp comes from LISt Processing, and prefix notation with enclosing parentheses alone doesn't mean processing lists.
With that said, the underlying datastructures don't actually deter from the fact that you can quote and unquote what appear to be lists, and it walks and quacks more or less like a lisp (like clojure, as a sibling pointed out), so I don't actually mind.
In fact, Janet just might be my favorite scripting language, even if I haven't had occasion to use it for anything impressive yet.
I'm not clear on the exact reasons, but I think some people see it as "Python with S-expressions" rather than "Lisp". I think it's because Janet does not use lists implemented with cons cells and historically that's just what Lisp always used. (Janet uses arrays instead.) But by that logic Clojure isn't a Lisp, if has no cons cells...
Another criteria used is homoiconicity.
I think the argument is about if a language satisfies the historical definition of "Lisp" rathen than being a Lisp-inspired language with parens.
A good reason to regard this as "Python with parentheses" is because not only does it use arrays instead of cons cells, but there's no non-mutating `append` function. Instead, Janet has an `array/concat` function that behaves like a Python array's `.append` method, and that's it.
And no, Clojure isn't a Lisp. Perhaps it would be appropriate to say that Janet is "a Clojure".
Category error maybe: CL is a language standard with several very extremely different implementations and a diverse tool landscape. Janet OTOH is a single language&implementation.
- Really simple lisp like scheme, but reminds me of lua (and not bloated like CL)
- Has resumable fibers, no callcc like scheme
- Not missing the lack of lists tbh
- A module system that doesn't feel awkward like CL
- A built-in package manager (unlike CL)
- Good lua and C support
- Threads have a shared-nothing approach with message passing (reminds me of Erlang actors)
- Destructuring
- Good PEG support, encourages it over regex
- (Im)mutable versions of data structures (ie tuples vs arrays, structs vs tables) for maximum flexibility
- Prototypal inheritance
- Docs are clean and easy to read
I'll definitely have to try this out, it looks really cool.
Some stuff I'd like to see:
- Pattern matching support (could be a library I guess)
- Multimethods
- Full numeric tower with arbitrary precision types
- Javascript compilation -- I could see this language being really useful for web and game dev
Does it have good debugging support? I'm thinking of something like slime, swank, etc. Can I set up emacs and/or vim to work the same way I can use CL with slime + swank?
I'm also wondering about the stack traces -- one of the downsides to CL is sometimes the stack traces are nasty to read