Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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 wrote a tiny multimethod library for Janet: https://github.com/staab/janet-multimethod

The stack traces have so far been really clean and helpful.


> stuff I'd like to see [...] Pattern matching support

It looks like it does have a match macro, and it does destructuring and _: https://janet-lang.org/api/index.html#match


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."


Hilarious, but true!


From the examples:

# A simple fizz buzz example

(loop [i :range [1 101] :let [fizz (zero? (% i 3)) buzz (zero? (% i 5))]] (print (cond (and fizz buzz) "fizzbuzz" fizz "fizz" buzz "buzz" i)))

Is this not lisp?


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".


Clojure isn't a Lisp, and really screws up some of the concepts.


Can someone explain why this comment was downvoted?


[flagged]


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.


Likely for bashing CL (however lightly). People get tetchy.


See some previous HN threads on Common Lisp.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: