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

281–290 of 292 posts

Re: Why Janet? (2023)

#281

Post by kscarlet »

ux266478 wrote: post #278
kscarlet wrote: post #263

Earlier quoted context omitted.

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

A small but illustrative example: given a live running clisp program, I can click on a UI element to inspect both the live object and the underlying code in the IDE. I can even copy and paste UI elements! Emacs is text-centric, LispWorks is clisp-centric with a real GUI designed for computers with a keyboard and mouse. There's a whole MVC system! Wow! GNU Emacs, Lem, etc. are all very nice editors, but they're stuck…

> A small but illustrative example: given a live running clisp program, I can click on a UI element to inspect both the live object and the underlying code in the IDE. I can even copy and paste UI elements!

I agree GUI is awkward in Emacs/SLIME. I think the reason is there isn't a standardized GUI framework across the Lisp world. Otherwise people can make SLIME support it.

> If I wanted to use slime-fancy to inspect a class, what I get is a dead list of raw text that I have to awkwardly interact with.

This part I do not agree. Nowadays "text" in Emacs/SLIME is far from "raw text", there's button that respond to hover, with right click context menu, and can be copy and pasted. I recall some small quirks (like objects in inspector are not presentations) but the only reason they aren't fixed (yet) is nobody get bothered enough. There's rarely any fundamental limitation. After all, it wouldn't be fare to call LispWorks UI "dead pixels".

BTW I once wrote yet another over ambitious project https://github.com/neomacs-project/neomacs > but it doesn't go anywhere either. People do not care enough, Emacs is good enough.

Re: Why Janet? (2023)

#282

Post by petee »

OskarS wrote: post #277
petee wrote: post #275

Earlier quoted context omitted.

Is there any particular plugin system you're referring to? I'm interested to learn more, out of curiosity. Janet's code is pretty easy to read, so you've got me learning about the vm now :)

Sure! The main formats are VST3 (from Steinberg, the most popular format), AU (from Apple, supported by most macOS hosts, and Logic only uses AU), AAX (for Avid Pro Tools) and CLAP (an open source variant, that's the best of all of them but is having trouble getting market share). Then there is also "Standalone", which is when you just run your plugin as a standalone app. Because of this plethora of standards, most p…

Awesome thank you, I appreciate that

Re: Why Janet? (2023)

#283

Post by nrclark »

xigoi wrote: post #215
nrclark wrote: post #211

Earlier quoted context omitted.

Something I'd observe here: without expressing an opinion about PEGs vs regexes, I'd note that regexes are much more widely used. They're also completely sufficient for an awful lot of text processing tasks. PCRE regexes would be a great inclusion to the stdlib, and would probably be popular.

> PCRE regexes would be a great inclusion to the stdlib Why? Anything that can be done with a regex can also be done with a PEG, and the PEG will be much more readable.

PEGs are a great replacement for a complicated regex, and can express a lot of things that are hard to do with a regex. But they're also more verbose, and fewer developers are familiar with their usage. PCRE regex is kind of the lingua franca of text-matching, and making it available would be helpful for newcomers imo.

Re: Why Janet? (2023)

#284

Post by veqq »

setopt wrote: post #99
aeonik wrote: post #15

Earlier quoted context omitted.

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

I definitely prefer s-exps over both xml and json myself too! Interesting question. Much of the difficulty does stem from mentally translating back and forth between conventional notation and s-exps too, since you can’t really avoid the standard notation when reading and writing math and physics papers. And current-day math and physics notation has been optimized to some extent for the infix notation; perhaps one wou…

> perhaps one would have invented more expressive higher-order functions or macros to denote s-exp math if that was what everyone used for centuries.

Have you ever looked into APL? It was made as a better notation for math over a decade before computers emerged.

Re: Why Janet? (2023)

#285

Post by veqq »

xigoi wrote: post #45
IshKebab wrote: post #2

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:…

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

> Parinfer

Have you explored Paredit? Structural editing turns the parentheses into a huge plus so navigating feels like flying.

Re: Why Janet? (2023)

#286

Post by veqq »

xigoi wrote: post #220
bjourne wrote: post #123

Damn it, Janet. No proper namespaces. Hard pass.

What do you mean? When you import a module in Janet, it adds a namespace prefix to all symbols. What more do you want?

It would be really cool to declare multiple modules in the same file, somehow. Also, the Janet community's generally against the word namespace, saying we don't have them. (I don't fully grok why not.)

Re: Why Janet? (2023)

#287

Post by bjourne »

xigoi wrote: post #220
bjourne wrote: post #123

Damn it, Janet. No proper namespaces. Hard pass.

What do you mean? When you import a module in Janet, it adds a namespace prefix to all symbols. What more do you want?

Namespaces as first class objects. Janet namespaces symbols by renaming them. It's not the same thing.

Re: Why Janet? (2023)

#288

Post by Capricorn2481 »

IshKebab wrote: post #272
graemep wrote: post #12

Earlier quoted context omitted.

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 fo…

> Is static typing that important for a scripting language? Yes. Firstly, static types are useful for even tiny programs, like 100 lines. Secondly is "scripting language" really a thing? There's nothing fundamentally different about a "scripting language" to a non-scripting language. Look at Javascript - that even has "script" in the name! - but clearly Typescript is an enormous improvement on it.

> Look at Javascript - that even has "script" in the name!

Look at Java, it has nothing to do with coffee!

My understanding is a script does two things 1) It can be interpreted. Even if it has some kind of JIT or bytecode step, it can be run as soon as file changes are made. 2) It's one or several informally wired together files for small tasks. A small task meaning you could patch it live without being worried about breaking something, because you can keep it all in your head. It's a narrower definition of a "program."

At that level of programming, terseness becomes an asset rather than a liability, and that's why "scripting languages" tend to be dogged on in larger programs.

Re: Why Janet? (2023)

#289

Post by xigoi »

bmn__ wrote: post #270
xigoi wrote: post #261

Earlier quoted context omitted.

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 partic…

I accept your challenge, assuming you mean a grammar with a real use case and not an artificially constructed pathological example. You can contact me at [my username] at disroot dot org. I could also send you a stripped-down version of one of the grammars I spent time translating from PEG to Tree-sitter. FYI, according to its website, Tree-sitter uses GLR parsing.

Re: Why Janet? (2023)

#290

Post by ianthehenry »

bjourne wrote: post #287
xigoi wrote: post #220

Earlier quoted context omitted.

What do you mean? When you import a module in Janet, it adds a namespace prefix to all symbols. What more do you want?

Namespaces as first class objects. Janet namespaces symbols by renaming them. It's not the same thing.

The `import` macro extends the current environment with prefixed symbols from another environment. But the environment is a first-class object that you can hold and manipulate and use in arbitrary ways — `require` is the lower level primitive that `import` is built on.
Post reply on HN