Live data from Hacker News

Why Janet? (2023)

ianthehenry.com

151–160 of 292 posts

Re: Why Janet? (2023)

#151
post #114
post #40

Earlier quoted context omitted.

The non-commutavity is a feature, not a bug. It allows you to have clearly defined parsing for grammars that would traditionally be considered ambiguous.

But that’s not how humans writing code generally think about ambiguous expressions. You can see that by how few precedence rules programmers tend to internalize, and often prefer extra parentheses to make sure that the parser interprets it the way they mean.

I am not talking about operator precedence, that’s a separate thing. Consider the parsing of math expressions, where juxtaposition of terms denotes multiplication unless it can be interpreted as something else. So f(x+2) is function application, whereas 3(x+2) is multiplication. With a PEG, you just write a standard expression grammar with an additional choice at the end for the implicit multiplication. With a conventional parser, this is much more difficult – you have to explicitly list all the different ways that terms could be next to each other without meaning something else.

Re: Why Janet? (2023)

#152
post #105
post #87

Earlier quoted context omitted.

You don’t program in Lisp, do you? I used to be confused by the smug Lisp weenies. Now I am one. And the difficult thing I’ve found over the years is that Lisp is sort of unexplainable. You either “get it” or you don’t. Yes, it has macros, but macros are a bit overrated. I’ve been programming in Lisp for decades and I rarely write macros. I think the thing that is difficult to convey is how powerful Lisp’s core execu…

There are reasons why not that many programmers “get it”, and it’s not because the others are uninformed. It’s a matter of valuing different things.

Hmm, that'd be weird, how do you know you "value something different" if you haven't "got it"? You'd need to "get it" first, then you can understand if you value something different or not, otherwise how would you know?

Re: Why Janet? (2023)

#153
post #4

> But by allowing you to unquote literal functions, Janet makes it possible to write macros that are completely referentially transparent. These lisp guys really get excited over very abstract things. If you say this to an average person on the street they will probably try to run away.

> very abstract things A C macro with literals that lacks referential transparency: #define MULTIPLY(x, y) x * y int result = MULTIPLY(2 + 3, 4); // 14 Not knowing what something means does not make it bad, which is what I'm assuming you meant given how you phrased your sentence. Having a shared language of patterns and problems that occur in programming is a good thing. Ridiculing such terminology on the basis of "t…

Thank you for the lesson. Very productive of you and on point.

Now if you relaxed just a little bit - the world would be much nicer place.

Re: Why Janet? (2023)

#154
post #65
post #3

This post is refreshing - smells of the pre AI discussions on the internet. A new language, a new syntax, heavy debate with people who have spent years writing code. I think someone should start a community online where AI isnt allowed.

> a community online where AI isnt allowed. This is something I think about a lot, especially how one could pull it off without tearing down anonymity online. Having some sort of "proof of humanity" is a hard problem to solve.

[deleted]

Re: Why Janet? (2023)

#155
post #87

Earlier quoted context omitted.

I don't see why Lisp's history would necessarily imply the family is worth learning in 2026. What (other than macros) do lisps offer that other modern languages don't?

You don’t program in Lisp, do you? I used to be confused by the smug Lisp weenies. Now I am one. And the difficult thing I’ve found over the years is that Lisp is sort of unexplainable. You either “get it” or you don’t. Yes, it has macros, but macros are a bit overrated. I’ve been programming in Lisp for decades and I rarely write macros. I think the thing that is difficult to convey is how powerful Lisp’s core execu…

> You don’t program in Lisp, do you?

Not anymore. I started with Racket and went through the Little Schemer. I did Clojure for a while. I even used Babashka to write all my scripts, then later rewrote them in other languages.

I gave it a good try. Maybe it wasn't enough to properly "get it"?

Re: Why Janet? (2023)

#156

There is also fennel, earlier language originally by same developer, that is similar, but compiles to, and is fully implemented in, Lua. No standard library of its own so missing many nice things like the parser library from janet, but it is good for writing scripts for things that embed Lua. https://fennel-lang.org/

Fennel really is great, and a great way to get into the clojure family. My biggest gripe with it is that debugging is the typical transpilation bed of needles. The bridge between Fennel and the Lua VM is super fragile, and it just doesn't have half the quality of the Janet debugger and REPL. It's a real shame, because Fennel is way more portable, and thanks to LuaJIT is capable of breaking SBCL's jaw, which is absolu…

Is fennel clojure-ish? I’m vaguely aware of it being a lisp, but I didn’t know it was clojure-ey. Pretty neat sounding!

Re: Why Janet? (2023)

#157
post #8

> Instead of regular expressions, Janet’s text wrangling is based around parsing expression grammars. Parsing expression grammars are simpler, more powerful, and more predictable than regular expressions. I would dispute that this is the case. In PEGs, alternatives are not commutative, unlike in regular expressions. This can lead to quite frustrating debugging. While a valid choice, the advantage over REs is overstat…

I'd argue they are not commutive in regexes either, at least as implemented in practice. Implemented regexes favor the leftmost alternative even when both sides of the alternative match. This matters in cases like: capturing groups, and backtracking implementations. There absolutely are cases where one ordering of alternatives could yield catastrophic backtracking for some input, while the other will avoid it completely.

I personally don't like this at all. This means that regex engines that try to generate optimized matching code for an expression can end up generating suboptimal code if you don't want alternative order to matter, since the engine needs to keep that invariant, except in the case when it can prove that the alternatives won't overlap, and a later one can be checked in constant time. If both are true, it is legal to reorder them to do the constant time check before the big complicated wildcard-filled alternative.

But personally, I have never written a regex where I actively cared about the alternative evaluation order. I've used some other people made where order is important but never written one myself.

I'd love to be able to tell the engine "feel free to swap the evaluation order of my alternatives while optimizing", but few if any such engines offer that as a feature.

Now I get that PEGs have commutivity problems are that are different from regexes', which make the issue worse, but that doesn't mean regexes do things right either.

Re: Why Janet? (2023)

#158
post #144

Does embedding Janet still lean on global state?

My first question too, and I checked out the linked book [1], and sure seems like it! There's global functions like `janet_init()` and `janet_loop()` all over the place. A language shouldn't advertise itself as "embeddable" if it does this. It means you can't have multiple interpreters, you can't use it on multiple threads, etc. GNU Guile does this too, and it's a baffling decision! For my field (audio plugins like V…

Janet global state is thread local;[1] janet_init() is called once per thread.

[1] official docs: https://janet-lang.org/capi/embedding.html

Re: Why Janet? (2023)

#159
post #87

Earlier quoted context omitted.

You don’t program in Lisp, do you? I used to be confused by the smug Lisp weenies. Now I am one. And the difficult thing I’ve found over the years is that Lisp is sort of unexplainable. You either “get it” or you don’t. Yes, it has macros, but macros are a bit overrated. I’ve been programming in Lisp for decades and I rarely write macros. I think the thing that is difficult to convey is how powerful Lisp’s core execu…

> You don’t program in Lisp, do you? Not anymore. I started with Racket and went through the Little Schemer. I did Clojure for a while. I even used Babashka to write all my scripts, then later rewrote them in other languages. I gave it a good try. Maybe it wasn't enough to properly "get it"?

Aw man I love babashka. I will say the lack of static types in clojure is pretty brutal for me. Especially when combined with the obtuse error messages. But I still love babashka and the whole REPL driven world.

What did you end up rewriting your bb scripts in?

Re: Why Janet? (2023)

#160
post #87

Earlier quoted context omitted.

You don’t program in Lisp, do you? I used to be confused by the smug Lisp weenies. Now I am one. And the difficult thing I’ve found over the years is that Lisp is sort of unexplainable. You either “get it” or you don’t. Yes, it has macros, but macros are a bit overrated. I’ve been programming in Lisp for decades and I rarely write macros. I think the thing that is difficult to convey is how powerful Lisp’s core execu…

> You don’t program in Lisp, do you? Not anymore. I started with Racket and went through the Little Schemer. I did Clojure for a while. I even used Babashka to write all my scripts, then later rewrote them in other languages. I gave it a good try. Maybe it wasn't enough to properly "get it"?

That's a very reasonable try. Your statements are not unfounded. If I may ask, what's your daily driver now and why do you favor it over Lisps?
Post reply on HN