Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Janet? (2023)

ianthehenry.com

Post reply on HN
Print view View original

261–270 of 292 posts

Re: Why Janet? (2023)

#261

Post by xigoi »

bmn__ wrote: post #247
xigoi wrote: post #216

Earlier quoted context omitted.

Under what circumstances does PEG not work?

Many. I don't have enough room on HN to show a representative sample of the shortcomings. Read the relevant literature or converse with an LLM to learn more. Typical example, ported from https://news.ycombinator.com/item?id=16600224 >: (pp (peg/match '(capture '{ :main (* :B) :B (+ (* :A "x" "y") :C) :A (+ true (* "x" "z")) :C (+ (* :C "w") "v")}) "xzxy")) This almost trivial grammar works without any problem in know…

Of course this grammar does not work; you violated the two rules of writing PEGs:

• do not use left-recursive rules;

• put alternatives in such an order that none can be a prefix of a subsequent one.

These may seem limiting, but can always be fixed by a simple local change. In contrast, transforming a PEG into a conventional grammar often requires complex, wide-scoped changes. I’ve had the Tree-sitter compiler “shit itself” many times at grammars that PEG accepted with no problem, and had to introduce several ugly hacks to work around the problem of Tree-sitter not allowing ambiguous grammars.

Re: Why Janet? (2023)

#262

Post by radiator »

totalperspectiv wrote: post #256
radiator wrote: post #238

Earlier quoted context omitted.

Relevant issue #1457 VM instrumentation for third-party tools https://github.com/LuaJIT/LuaJIT/issues/1457 was opened by Mike Pall as recently as three weeks ago. I gather that some features will be added to 2.1 but others only to 3.0.

I thought he stopped working on LuaJIT? Is it back in active development?

Well, looking at the commits, he has been regularly contributing for the last ten years at least. I don't know if he had stopped for a while.

Re: Why Janet? (2023)

#263

Post by kscarlet »

ux266478 wrote: post #180
JHonaker wrote: post #135

Earlier quoted context omitted.

> capable of breaking SBCL's jaw What exactly do you mean by this? Speed? Portability? Ease of use?

What I mean by that is that it's in the same weightclass of speed, depending on the problem being tackled. In the case where data's shape is mutable, SBCL will scream ahead thanks to CLOS. You can cheat LuaJIT with dynamically-defined C-structures via abuse of the FFI lib instead of native tables, but it's not as nice as CLOS nor is it very safe. In the case that the shape of data is changed extremely frequently? CLO…

Can you tell a bit more about what is missing from Emacs SLIME when compared to LispWorks?

Re: Why Janet? (2023)

#264

Post by klez »

andrewflnr wrote: post #255
CobrastanJorji wrote: post #250

Earlier quoted context omitted.

It can't just be money. It also has to remove any notion of score or ranking. There should be NO incentive to artificially increase anything. Look at Advent of Code. Free site, fun community, but it had a leaderboard. The moment AI was advanced enough, it began dominating the leaderboard. The solution: kill the leaderboard. Sure, you can still solve all the problems with AI and get yourself full points, but you're no…

Maybe. That's a bit of a different problem: similar mechanic, but much weaker forces with some different pros and cons. Maximizing imaginary internet points is qualitatively different from maximizing actual power in the form of money. I think there's still room to experiment with aligning the incentives on things like karma for community-driven moderation.

If moderation is the problem maybe only allow downvoting? Of course that may bring to the surface a different set of problems (no solution is without drawbacks), but it removes the "numbers go up" incentives.

Re: Why Janet? (2023)

#265

Post by OskarS »

petee wrote: post #228
OskarS wrote: post #204

Earlier quoted context omitted.

So you can't execute a Janet script on a different thread than it was created on? Still not good: if you're making audio plugins, you don't control the threads which your program runs on. It's just not good enough, IMHO.

Not sure exactly what you're getting at, you mean transfer mid-execution to another thread? You can load and run a script on any thread you can load janet on, and you can coordinate across threads if need be. To clarify, janet_init just sets up the VM I'd also go take a look at the actual docs and code, I'm not sure I know the exact answer, but assumptions won't help Edit: there was someone on the Zulip that mentione…

The UI for audio plugins generally work in an event driven manner: you get events like mouseMove, keyDown, repaint, etc. from your host. In response to those events, you run your script to figure out what you need to do. You have no control over which thread calls these things, it can be the GUI thread that runs all of them, it can be run on background threads in parallel, etc. Different hosts do it differently. If Janet using thread-local state, this just doesn't work: the state for one instance is completely different from another, and there's even no guarantee they're running the same scripts.

Consider the most famous embedded language, JavaScript in browsers: you can have any number of tabs open at the same time, and if the JavaScript interpreters for each of those used a bunch of thread-local storage, it would place huge restrictions on how the browsers could schedule and parallelize the callbacks for the JavaScript in those tabs.

The only way I can see this working is if you spin up a thread for each instance, and when these events come in, you wake up those threads, send over the event information, block until the interpreter thread finishes. But that's both inefficient and a real architectural hassle.

All I want is an object that's like `janet_interpreter *interpreter = janet_make_interpreter();` and then you pass that to the functions instead of doing all these magic things with global variables and thread local state. That's it.

Re: Why Janet? (2023)

#266

Post by maleldil »

chamomeal wrote: post #159
maleldil wrote: post #155

Earlier quoted context omitted.

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

Python, Go, or Rust, depending on the complexity. Python (with strict typing) for the simplest ones, or those where startup time wasn't a concern, Go for the medium-complexity ones that I could do with only the standard library, and Rust for everything else. Besides lisps in general still feeling alien to me, I also really like static types.

Re: Why Janet? (2023)

#267

Post by maleldil »

drob518 wrote: post #160
maleldil wrote: post #155

Earlier quoted context omitted.

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

Python (with types), Go or Rust, depending on the complexity. I really missed static types in Clojure. I think no Lisp does static typing well. I guess there's Coalton, but it's too niche.

Re: Why Janet? (2023)

#268

Post by maleldil »

evdubs wrote: post #179
maleldil wrote: post #81

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?

S-expressions. Defining data in JSON or XML is way worse than S-expressions.

I agree that S-expressions for defining data are pretty nice, but you don't need to actually use a Lisp to use them. You can just use them like you would XML.

Re: Why Janet? (2023)

#270

Post by bmn__ »

xigoi wrote: post #261
bmn__ wrote: post #247

Earlier quoted context omitted.

Many. I don't have enough room on HN to show a representative sample of the shortcomings. Read the relevant literature or converse with an LLM to learn more. Typical example, ported from https://news.ycombinator.com/item?id=16600224 >: (pp (peg/match '(capture '{ :main (* :B) :B (+ (* :A "x" "y") :C) :A (+ true (* "x" "z")) :C (+ (* :C "w") "v")}) "xzxy")) This almost trivial grammar works without any problem in know…

Of course this grammar does not work; you violated the two rules of writing PEGs: • do not use left-recursive rules; • put alternatives in such an order that none can be a prefix of a subsequent one. These may seem limiting, but can always be fixed by a simple local change. In contrast, transforming a PEG into a conventional grammar often requires complex, wide-scoped changes. I’ve had the Tree-sitter compiler “shit…

> Of course this grammar does not work [in PEG]

That's the critique, yes. If I put this grammar into a known good parser, it just works. I have to repeat this to hammer the point home.

A user should not have to waste time to find work-arounds for the undocumented limitations. Since there are many more limitations than just the one example I showed, you should realise that there is not much value explaining the particular limitations to me; all the limitations and the required work-around steps should rather go into the Janet documentation so that all users can see them and make use of them. But that's still a crappy developer experience, I would rather see Janet simply adopt a parser that is free of this kind of limitations.

> can always be fixed by a simple local change

I sceptical of that. I claim once the grammar is of the size required to model real-world problems, say about dozens of production rules, fixes become complex, wide-scoped. In the spirit of HN curiosity, I am willing to cooperate with you by conducting an experiment that is designed to change my mind. I would show a grammar that is of the type which is in common use everywhere, and you would apply the fixes to make it work in Janet/PEG, and then we examine whether the changes are always simple and local. Are you willing?

> [PEG grammar in Tree-sitter]

That reads rather bizarre to me because you describe the opposite direction. I have not had that train of thought because in all of my experience and those of the people I know it has always been the case that one receives a grammar that is of the type which is in common use everywhere. And when we try to express it in PEG, it does not work at all, no one knows what to do to make it work, experts who might help cannot be found, and the solution (after wasting a lot of time) is to either give up or try a different parser.

As an aside, I have not examined Tree-sitter yet, and its documentation does not tell me the information I need, so I cannot put it into the category of known good parsers.

Post reply on HN