Why Janet?
55 points
37 minutes ago
| 8 comments
| ianthehenry.com
| HN
krinne
13 minutes ago
[-]
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.
reply
soomtong
6 minutes ago
[-]
It’s been a few months, but I built a tool by Janet lang to communicate with an LLM via HTTP. Of course, I probably had Claude Code write it for me. It turned out better than I expected.

I was really impressed by how small the executable file was. I’d only ever done web development with Node.js up until then.

reply
uka
10 minutes ago
[-]
> 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.

reply
bryanrasmussen
8 minutes ago
[-]
you ever try to explain object oriented programming languages and their benefits to the "average person on the street"?
reply
rambrrest
5 minutes ago
[-]
somehow i also never got the idea around these languages like lisp. I remember i studied them in school - but i quickly forgot and never got around to relearning it.
reply
lindig
9 minutes ago
[-]
> 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 overstated.

reply
defrost
5 minutes ago
[-]
Previously (April 2023) | 140 comments: https://news.ycombinator.com/item?id=35539255
reply
skeledrew
10 minutes ago
[-]
This got me thinking of Hy. I wonder how syntactically close they are; there might be an exploitable Python -> Hy -> Janet path here.

[0] https://hylang.org/

reply
6LLvveMx2koXfwn
6 minutes ago
[-]
Maybe needs a (2023) in the title?
reply
gspr
10 minutes ago
[-]
The embeddability sounds very appealing. Does anyone have experience with using this somewhere one might traditionally reach for Lua?
reply
IshKebab
24 minutes ago
[-]
Pretty compelling, especially "Janet does not adhere to the ancient customs. CAR is called first. PROGN is called do. LAMBDA is fn, and SETQ is def." - a sign of good sense for sure!

How fast is it?

Also my main objection to Lisps is still the horrible bracket syntax. Yes it's unambiguous and easy to parse, but it's HORRIBLE to read and edit. I wish this project had been a success (or something similar to it): https://readable.sourceforge.io/

Also I don't think static typing is really optional for me at this point.

reply
graemep
6 minutes ago
[-]
Syntax is not that important to me. I prefer Python style indentation, but its really not that important - its just something to get used to for me.

Is static typing that important for a scripting language? From the intro to the book:

> And to be clear, I’m not going to try to convince you to bet your next startup on Janet, or even to use it in any sort of production setting. But I think it’s an excellent language for exploratory programming, scripting, and fun side projects.

reply
setopt
10 minutes ago
[-]
> Pretty compelling, especially "Janet does not adhere to the ancient customs. CAR is called first. PROGN is called do. LAMBDA is fn, and SETQ is def." - a sign of good sense for sure!

Just FYI, many of these are also done in Scheme and its derivative Racket. They kept lambda (but even Python did that), but progn -> begin, setq -> set!, car -> first, and so on.

> Also my main objection to Lisps is still the horrible bracket syntax. Yes it's unambiguous and easy to parse, but it's HORRIBLE to read and edit.

I have pretty mixed feelings at this point. I don’t mind it for normal programming, but when I do numerical programming (physics models, etc.) you often get extremely long and verbose expressions that are IMO difficult to parse compared to the math-like infix operator notation used in other languages.

reply
aeonik
4 minutes ago
[-]
I'm starting to prefer the s expression syntax when dealing with tree structures like json.

I wonder if we were raised on tree based algebra if math would be easier to do, or harder.

Like, solve for x.

   (= (+ (* 2 x) 3) 11)
   (= (* 2 x) (- 11 3))
   (= (* 2 x) 8)
   (= x (/ 8 2))
   (= x 4)
Though this isn't too bad.

    (= (+ (pow x 2)
          (pow y 2))
       (pow r 2))
reply