Live data from Hacker News

Why Janet? (2023)

ianthehenry.com

111–120 of 292 posts

Re: Why Janet? (2023)

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

> I think someone should start a community online where AI isnt allowed. In case you haven't followed the saga, the latest[1] digg.com relaunch failed because they couldn't deal with the bot onslaught [2]. Whoever finds a reliable way to keep AI out of an online community first is likely to become a very rich person. [1] Second-to-last, actually, seeing as there seems to be a new homepage right now. [2] https://www.t…

Blizzard's Real ID system would fix all of this. It was ahead of it's time /s

Re: Why Janet? (2023)

#112
post #32

Seems some of the listed advantages for Janet would also apply for tcl (small/simple, easy to learn, embeddable, usable as a shell, great for domain specific languages). It would be interesting, to me at least, to see a fan of Janet compare the two.

Janet is faster, but lacks anything like tk. It's probably also quicker to learn, as you don't get into complex evaluation structure until you start messing around with quasiquotes, while tcl requires you to understand mixing 3 different layers of evaluation right off the bat. tcl's vm imo is easier to understand as well.

tcl if you want a UI, janet if you want an embedded scripting language.

Re: Why Janet? (2023)

#113

> SETQ is def At first I said "what" out loud, since SETQ doesn't create bindings, it only updates them then I read the doc ( https://janet-lang.org/docs/bindings.html ) and the author is indeed wrong ("bindings created with def are immutable"). He probably meant "SETQ is set". I really want to like Janet, as it seems to be the sweet spot between Guile, Tcl and CL (minus the speed/maturity of SBCL) but I have a visce…

Square brackets’ use is very consistent and rather logical in how they are used in Clojure’s syntax. When round brackets are used, the first element in the list defines how the rest of the list is interpreted, for example: (func a b c) — run a function with its parameters (macro x y z) — expand a macro with its parameters ([p q r] …) — “bare” function body that starts with a vector of parameters, and executable forms…

Thanks a lot, that's a very interesting way of seeing it.

Re: Why Janet? (2023)

#114
post #40
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…

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.

Re: Why Janet? (2023)

#115
post #75

Earlier quoted context omitted.

> I think someone should start a community online where AI isnt allowed. In case you haven't followed the saga, the latest[1] digg.com relaunch failed because they couldn't deal with the bot onslaught [2]. Whoever finds a reliable way to keep AI out of an online community first is likely to become a very rich person. [1] Second-to-last, actually, seeing as there seems to be a new homepage right now. [2] https://www.t…

We've already got models that can handle it - eg web of trust. We don't want to use them. Plus "AI" is a spectrum, with "the AI fixed a typo for me" at one end, and "the AI writes my posts for me" at the other.

Web of trust has been a miserable failure because of the GPG's horrible UX and high entry barrier. It's dead, Jim.

Re: Why Janet? (2023)

#116
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…

PEGs are just soooo much easier to read than regexes for anything more complex than a few words or single line matching. REs are a hammer that tempts people to see everything as a nail, but once one progresses beyond that phase one usually wants as few REs as possible.

That’s mostly an artifact of concise regex syntax I believe. When you write regular expressions in an ABNF-like form, they become much more intelligible.

Re: Why Janet? (2023)

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

[deleted]

Re: Why Janet? (2023)

#119

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 absolutely fucking insane. But the transpilation experience just completely kneecaps it imo. There are workarounds you can do, but even if you mess around with implementing a debug.setinfo you still run into less-than-fun edge cases like with match-blocks.

I think there's a lot of value in forking LuaJIT2 and reworking the debugging and error structures within to make it more suitable for language transparency. Doing so would make languages like Fennel much more attractive.

Post reply on HN