Hacker News

> 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.techspot.com/news/111698-digg-relaunch-fails-two...

Ironically, the top comment (this) is now about AI.

> I think someone should start a community online where AI isnt allowed.

That's lobsters I guess. AI posts got banned there after a 300+ comment discussion, probably the biggest ever on the site.

The exact rule the moderators settled on was "meaningful human authorship" but don't be fooled: a lot of people on lobsters are ideologically opposed to LLMs. Doesn't matter how "meaningfully" the technology was applied. My work was classified as slop simply because AI touched it. People referred to me as an exhibitionist and fetishist when I talked about using AI. Just a heads up for anyone who's thinking of joining.

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

The amazing thing about AI is that you don’t even need AI superfans to shoehorn it into a conversation that doesn’t even touch on AI. Detractors will do it for them.

> a new syntax

How is the syntax new?

It looks like lispy - see the outer parens in the examples given.

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.

> advanced HTTP routing

What do you concretely mean by this? I use https://github.com/joy-framework/joy for all web stuff and can probably get your missing features in within the week.

Julia Evans has a fun blog post using Julia to visualize Gunzip: https://jvns.ca/blog/2013/10/24/day-16-gzip-plus-poetry-equa...

you should totally do a "Janet writes Janet" version

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.

It's a really cool feature but what is a scenario when your average programmer needs such sandboxing?

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

Square brackets are used where elements are the same “kind”, and the first one is not special, e.g.:

(defn f [a b c] …) — a collection of same-kind parameters, the first parameter is not special

(let [a 1 b 2] …) — a collection of bindings, the first binding is not special

The only exception that comes to mind is grouping multiple matching elements in `case`, but it for ergonomics.

Once I got the logic, when which is used, I changed my mind, and ever since I’ve felt it’s beautiful.

You can... just not use square (and curly) brackets. Instead of `[1 2 3]` just write `(array 1 2 3)`. Instead of `(fn [x] (+ 1 x))` just write `(f (x) (+ 1 x))`. They are never necessary.

I'm really happy you liked it! It's still a work in progress.

> 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

Having a shared language of patterns and problems that occur in programming is a good thing. Ridiculing such terminology on the basis of "that group of programmers sure are weird" is pointless and counter productive.

you ever try to explain object oriented programming languages and their benefits to the "average person on the street"?

Average programmer too /j

Frankly, though, I think lispy community has benefited from being smaller. For example, even though the now ancient Design Patterns already warned programmers to prefer composition over inheritance, the OO programmers still created 15 levels deep hierarchies.

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

Referential transparency is a funny name for a very powerful feature which helps you understand what the program does better, it's not a deeply abstract thing. Don't let the name scare you.

You could ask "why the funny name"? Well, specialized professionals use specialized jargon, even for "normal stuff". It's unreasonable to expect otherwise. Car mechanics also have weird names for car parts that are absolutely essential for the car and not that hard to understand if they explained them to you.

I have some gentler introductory stuff like: https://janetdocs.org/tutorials

> I've been drawn into the Janet posts that surface every once in a while here on HN, but found the otherwise highly praised "Janet for Mortals", not being for mortals at all.

I'm surprised: the language is very straightfoward, simple, very few rules to remember. It's a Lisp but with a very small surface area.

I mean, compared to other languages, Janet really is easier to lean, so I'm surprised that the book for it is difficult (did not read the book, but familiar-ish with the language. I don't have anything but praise for it, TBH).

Personally I get hung up on the macro syntax being near the beginning, but there is so much valuable stuff past that

> not being for mortals at all.

I had that with Haskell. Although, while Haskell is too hard for me, I actually like its syntax.

Janet seems to be Lisp 2.0, so the syntax is lispy.

I've only used Tcl briefly, mostly for automation which it's great at. But it's a Algol-like imperative language, doesn't have any type of macros and makes everything based on strings (which makes sense for automation) instead of lists, with all the tradeoffs that comes with.

It seems easier to figure out what the similarities are, because I think they're pretty few, they seem to differ more than they are similar.

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.

I use both. They're similar for simple use, but above a certain level of complexity Hy has a lot of Python-isms that bleed through. It really doesn't ever let you forget that underneath all the parentheses you're really writing Python. Janet feels like its own stand-alone language in that respect, where Hy is more like a syntax swap.

I have the impression that Hy's user base is larger, though (not that either one is huge).

I used Hy for a long time, then tried Janet, and ultimately realized that I wanted more batteries included but didn't want Python... So I forked https://github.com/rcarmo/go-joker and am tinkering with it until it does all I want.

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 VSTs), it means it's absolutely a no-go, because hosts can load any number of instances of your plugins and potentially run them in parallel in the same address space, they can't rely on global state like this. Each interpreter has to be separate.

Lua does this right, as does Python (as of 3.12, when they made the GIL local to each interpreter) and I think most of the JavaScript engines. And it's not hard, instead of a global `janet_init()`, just have an opaque pointer bundle all the state, like `janet_init(interpreter)`. If you want a global interpreter, just stick it in a global variable.

[1]: https://janet.guide/embedding-janet/

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.

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.

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.

"small peg tracer"[1] is really helpful for breaking down a PEGs operation

[1] https://github.com/sogaiu/small-peg-tracer

Came here for this comment. Janet would score positively in my mind if the evolutionary dead-end PEG were replaced with a grammar parser that is known to work under all circumstances.

We recently migrated to a standard library version: https://janet-lang.org/1.41.2/spork/api/sh-dsl.html

I have built a markup language with embedded scripting in Janet. I originally tried to use Lua, but found the verbosity extremely frustrating.

Dammit, Janet, I love you!

Actually not all those are ancient customs, and not all that Janet uses is newer.

In the first description of the language LISP, from March 1959 (AIM-008), John McCarthy had used the names "first" and "rest", instead of what later will be called "CAR" and "CDR".

The names of "CAR" and "CDR" appear to have come from the students who worked at the practical implementation of the LISP interpreter on an IBM 704, and unfortunately we have remained stuck with them, like also with other features that were intended only for a temporary use, until being replaced in the "final version" (which was abandoned).

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

All programming languages have horrible syntax (except maybe Forth). Some examples:

Statements are terminated by either a dedicated graphical character, in which case it's easy to forget the character and have a problem, or by a newline (or maybe a different white space character, but I haven't encountered that yet) in which case decent formatting of code may require a dedicated graphical character to indicate that the newline DOESN'T terminate the statement, in which case we have the same problem. Having newline-terminated statements without continuation character would be consistent, but would hamper readability because identifiers would need to be strictly limited in length to keep certain lines from exceeding available screen space (or alternatively readability would suffer from lines only being partially readable).

And that's before getting into the weeds of how mathematical notation is tricky (most people have learned infix notation at maths class in school, so they mightn't appreciate how horrible it is), how different types of brackets (round, square, curly) can have inconsistent semantics, the downsides to the various ways of indicating lexical blocks (brackets, white space, keywords,...), et cetera.

The ideal programming language would probably be one which allows switching between different syntaxes based on what works best for the user (for example, someone could write code in S-expressions, another person could have that code automatically translated into SRFI-119 Wisp expressions and work with it like that, a third person could then have it rendered into something more Lua-like,...). Which is something I think the Racket people are working on, but I may be mistaken.

It's a scripting language, so it's not going to compete with anything compiled or JITed, but it has a pretty efficient threaded bytecode interpreter (that is almost more interesting than the language itself!). It's certainly good enough for most situations where you would reach for a scripting language.

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.

> 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 use Parinfer, which allows me to edit Janet as if it was an indentation-based language.

> How fast is it?

Roughly as fast as puc-rio Lua. It won't blow your socks off, but it's more than respectable.

Out of those renames, I agree with car->first and progn->do. setq is ugly, but I think using def is maybe questionable. lambda I would have just kept the same.

Are you aware of:

https://docs.racket-lang.org/sweet/index.html

What would be a better syntax according to you? I have found Janet’s syntax very pleasant to work with as opposed to JavaScript, Lua or even Python.

can't there theoretically be a language which transpiles to Janet to get all the benefits without additional paranthesis too?

Not sure if such transpilation would have a perf hit though, I hope somebody responds who knows about it more.

I don't deny that syntax matters itself too but there are some ideas of janet like sandboxing and other features which seem to me to be worth implementing in other languages too.

Personally, I would be really interested in a language like lua/wren which can transpile to Janet too.

It was named after the sentient computer system in the TV show "The Good Place"

A humourous clip: https://youtu.be/etJ6RmMPGko?si=W98LdG1jDdUCXsHV

If it was called [Something] Lisp, Lisp enthusiasts would complain that it’s not a lisp because it does not use linked lists as the primary data structure.

I know that Lisp has lots of paranthesis and I don't have enough experience with Lisp at all.

But from the looks of it, Janet has some great ideas like the one that @ramblurr shared here about sandboxing ("Disable feature sets to prevent the interpreter from using certain system resources. Once a feature is disabled, there is no way to re-enable it.")

Lisp from my understanding is incredibly polarizing and many people love it and many people hate it and that's fine, but at a certain point wouldn't it feel repetitive for statement like this and I am unsure of how healthy discussion about programming concepts can be done this way.

There are so many interesting things from lisp-y languages like Janet and Julia is technically lisp-y too and Julia's compilation to GPU is awesome and Nim too which can compile to C/C++/JS!

It's just so many interesting concepts overall in programming that paranthesis don't seem a concern to me as the underlying concept can be translated to something else, like sandboxing feature, transpilation to GPU or multiple targets!

And there are many unique concepts in non-lispy languages like golang (cross-compat, portability with static binaries), elixir (concurrency!) too.

It's just good to see the amount of innovation within programming from all spheres of influence :-D