Lisp is very cool. But one thing I do not like is that the syntax style `(fun a b c)` loses out to the less-symmetric "OO" style `a.fun(b, c)` when it comes to IDE auto-completion. And for me the IDE help is important to provide a smooth developer experience and minimize wasted brain energy. I'd like to find a way to make the editing and auto-completion work better. I think the way IDEs (and maybe our brains) work is: "here is a thing X, now what can I do to/with it?". That translates to typing in your editor: "X.[cursor here]", and then the IDE lets you see and search the things you can "do" with X. But if, in Lisp, you write "([cursor here]", you are immediately confronted with: "what is the signature of that function again?", but the IDE has nothing to go on. Maybe there is different style of editing, where we could type the arguments, and then trigger the auto-complete.
In Clojure, this is merely (a/fun b c) or (. a fun b c) depending on whether a is a namespace or an object. Autocomplete works wonderfully. I would strongly urge you to try a coding session using Cursive so you can objectively refactor your obsolete LISP opinions.
I don't know about other lisps, but Clojure has namespaces and that's good enough for me. So you can type "(foobar/" and get a list of functions in the foobar namespace.
Janet kind of has this too: if you import a module with (import foo), all the imported bindings will be prefixed with foo/. Also, this can be avoided by writing (use foo) instead.
Haskell sort of has this. You type (_ a b c) and the compiler tells you which methods would make sense there based on all three variables (so in a sense it is even more useful.)
Do you mean you run a build and it tells you in the error message? Or is there an IDE/editor where you could hit a key-combo with the cursor on that line, or near the `_`, and it would show a popup of possibilities for auto-completion?
I think this is more familiarity bias and the presence of an enforced type system than a necessity of auto-complete. In the same way that `a.` auto-completes to methods of `a`, `(fun ` could auto-complete to a list of in-scope variables that satisfy `fun`'s type signature. A lot of lisp is untyped though, even in variants that have support for it.
I also think there's some familiarity bias to the OO style. I don't find it particularly natural, though that's subjective. I often know what I want to do, and have to find the object that has the method. E.g. I know I want to read a particular header, but is it on Request, or on Request.Headers, or are headers passed in as a separate object? It feels cleaner to do something like `(get-header "SOME-HEADER" ` and have the IDE tell me I need to pass in `(get 'headers request)` or similar.
What do you do if 'a.<tab>' doesn't work because it's not 'a.fun(b, c)' but 'b.fun(a, c)' or 'c.fun(a, b)'?
Also think of autocompletion for 'var x = new' to 'var x = new ByteArenaFactory()', the way you get from nothing to 'ByteArenaFactory' is the same way you get from nothing to '(fun a b c)'.
Ah neat! In Guile I use threading/pipelining all the time with a small macro:
(define-syntax ->
(syntax-rules ()
;; first expression is left unchanged
[(-> expr) expr]
;; take from the back, wrap other calls
[(-> expr* ... (op args* ...))
(op args* ... (-> expr* ...))]
;; make parens unnecessary in trivial case of no further arguments
[(-> expr* ... op)
(op (-> expr* ...))]))
Janet already having this ... Reading many good things about Janet in this discussion.
You mentioned autocompletion a few times and that is something available via LSPs (janet specifically has one that has this) or through the editor (e.g. emacs can use swank for common lisp). It's no different for any other language integration.
I think that threading macros is different to method chaining (at least to my understanding), method chaining works on the object returned, and threading macros can work on raw data or objects.
When I see languages like this, I always wonder, how far the ecosystem is. I have used GNU Guile a lot and there are quite a few libraries for it, so that one can do almost anything. Web things are coming, but maybe not as fully there yet, as one might like. Racket also has lots of libraries. And even a standard library web framework.
So lets say I want to start my next web project in Janet. I already know Scheme and can probably quite easily just start writing another lisp, assuming it has TCO and I can do things mostly like I would in Scheme, except maybe for having to use funcall (which is annoying, but OK). Does Janet have libraries, that enable web projects? Like a web server and SXML or something like that? Or does it have things like a JSON parser? All these little things one would like to have, to not have to develop the basics first, before getting to the actual project.
And what about data structures? Are there functional data structures available? In GNU Guile I have at least the unmaintained guile-pfds. Hopefully, I will one day understand enough about functional data structures to build more or to maybe even maintain that library. But learning resources are scarce. It is already difficult to find a functional version of an AVL tree! Lots and lots of places merely teach non-persistent, non-functional versions of these data structures, and it is not trivial to translate them, might impact performance in ways that are not necessary, if one had great knowledge about how to make these data structures.
And also reproducibility! With GNU Guile I have what I need on Guix, which is great! With other languages, I might need to rely on older package managing approaches, that do not have reproducibility/determinism as the a high goal on their agenda, or might even lack the ability to create lock files/files with checksums. I don't want to go back to non-reproducible.
I am also eyeing statically typed variants like Carp. Same questions arise. Some seem really great and I would probably enjoy using them a lot. Would be a pity to then discover, that the ecosystem is just not there, and one has to create all the basic tools one needs oneself. Sometimes that can be fun, but it can also be exhausting and one never gets around to ones actual project.
Janet has ~10 web frameworks (half SSG, half dynamic) and many web servers. Joy [0] is the most fully featured stack approach, which Janetdocs [1] runs on. But everything you mention is in the std lib. Here's a certbot in 10 lines only using the extended std lib (called spork): https://codeberg.org/veqq/janetdocs/src/branch/master/ssl-fe... `json/decode` automatically maps json to native data structures. There's a package manager included, which builds all code I've found so far, reproducibly.
As for DS, only arrays, there are maps, arrays and strings, all mutable or immutable. I don't think there's any intention to ever implement functional data structures, but they could "easily" be a library.
I see that there is a package manager "jpm" and I looked at the docs, but I couldn't see anything relating to how to create a lock file or how it makes sure, that every time I install dependencies, I get the exact same versions (not just version numbers).
Maintenance isn't a breaking issue, at the moment. No one's stepped up to fork them and accept PRs, because they work as is. I'm personally working on this, though and expect a lot of progress in the next months - but this won't impact day to day coding, because they work already.
Here's a implementation of some persistent DS: https://github.com/ianthehenry/jimmy It's incomplete, primarily serving as a c++ interop example, though.
That looks cool. I scrolled through the readme though and it only lists vectors, maps, and sets. That's not actually that much, but it is quite foundational. Maybe one could build others on top of that. But then the question arises, whether that implementation is performant.
Janet uses a bytecode VM that's faster than many dynamic languages but won't match SBCL's native compilation performance; it has optional type annotations for documentation but not for optimization.
> My favorite feature of Janet, though, is something that sounds really dumb when I say it out loud: you can actually distribute Janet programs to other people. You can compile Janet programs into statically-linked native binaries and give them to people who have never even heard of Janet before. And they can run them without having to install any gems or set up any virtual environments or download any runtimes or anything else like that.
They're not super tiny, though. A hello world I just did is about 727K.
No, gp is correct, the 'real executables' are a VM image with the interpreter baked in. The only native code in the binary is the interpreter. Janet code does not compile to machine code.
I understand your point, but by similar logic I can argue any language is interpreted because nothing compiles down to microcode. The point is you don't need janet-specific external dependencies in the environment. I don't differentiate between this and an inefficient compiler.
> I can argue any language is interpreted because nothing compiles down to microcode
Not every processor architecture uses microcode, so this doesn't hold up.
> The point is you don't need janet-specific external dependencies in the environment
Sure.
> I don't differentiate between this and an inefficient compiler
A compiler is the general term here, but the target is not. Targeting the native architecture for a CPU vs targeting a bytecode VM are quite different and have pretty important implications for performance, portability, memory usage, etc.
I think the distinction (from the OP’s perspective) is that it’s “just an app” to the end user.
When I download the Slack desktop app, I might know it’s running on electron because I’m a programmer. But I didn’t have to download and install nodejs or anything else. As far as I’m concerned it’s a completely self contained application.
The end user needn’t download and install Janet or even know that Janet exists.
That can obviously be done with any interpreted language, but Janet makes it really simple out of the box.
It's a lightweight embeddable interpreter and runtime, similar to Lua. Dynamically and strongly typed, but no native compilation. Easy to call C libraries, or embed into C projects. In my testing, it's roughly twice as fast as Python for similar tasks. You can "compile" a project by embedding scripts and resources with the runtime into a bundled executable.
Yeah, I see Janet as "what Guile intended itself to be", though it is quite a bit smaller (in some ways that's a postive). I find the choices it made to be more pragmatic and it's far more accessible in non-linux environments since Guile tied itself closely to guix.
CL is like the C++ of the Lisp world. It's standardized, multiparadigm, has a ton of functionality, fast, and built with large codebases in mind. It's also got a lot of cruft and because the standard is old it lacks certain things people expect, like networking and threads. Implementations usually provide these and compatibility libraries do a decent job of smoothing over implementation differences. Choose CL if you have a team, a large project, and you need speed.
Scheme was written for educational purposes. It's very minimal, and implementations aren't very compatible for anything outside the spec and the SRFIs (specs for optional functionality). I'd you choose a major implementation like Guile or Chicken however, there are tons of libraries available and it's very usable for small and medium-sized projects. It isn't known for its speed. Choose Scheme if you think like a computer scientist.
I've never used the others enough to comment, although I did enjoy playing around with Clojure since it's a functional language. I'd do more with it if it wasn't tied to Java and JavaScript. I keep telling myself to learn some Racket, but I never have the time.
Personally, I do most of my Lisp work in elisp, since my regular job isn't Lisp-based but I need to mangle text a lot. elisp is from the same tradition as CL so it's pretty similar.
Is there anything that is janet-unique? I just did a cursory glance, and most of it seems like a scheme with slightly different syntax and a more "modern" standard library.
Why should I switch from my scheme of choice (guile) to Janet?
It's not a Scheme at all! It doesn't have cons cells after all. It's a Clojure-like (maps everywhere, collection api, immutable data structures) with 1mb executable and [servers](http://janetdocs.org/) running under 10mb of ram.
Fibers are very interesting, even used for error handling. I've not wrapped my head around PEGs yet.
That makes sense. I have always thought about what I would do if I could make a "modern scheme". A lot would be taken from clojure but definitely not everything. Cons cells would stay, but the star of the show would be immutable vectors based on rrb trees or maybe finger trees (efficient concatenation, insertion in the middle etc), HAMTs , concurrentML (like guile-fibers) and a nice looping facility (like my own goof-loop[1]) and restricted mutation. Syntax-case and syntax-parse from racket. An extensible pattern matcher (like the one found in racket).
I would also make strings immutable, maybe like Guile's cow-strings, maybe blobs-with-cursors.
Definitely just copy Guile's delimited continuations.
I think I would just ignore most of r7rs, since I don't think it improves things for the progrmmer.
I am no fan of racket's for loops. It is frustrating, because it fells like an almost-goosd looping facility.
I do use racket, but for scripts I prefer guile. Guile-fibers is a lot neater than the racket parallelism situation, for example. And I can usually find the code responsible for what IAM trying to achieve in the implementation. I never became friends with racket. I remember trying to fix a bug, but I never found what I was looking for.
Getting superficially familiar with the guile codebase takes about an hour.
Then again, I am a classical musician and not a programmer.
Racket's for loops declare in their name what they're intended to return (if anything). Personally that's way more readable and preferable to, say, Common Lisp loop or iterate where you have to hunt through the body for clues. Plus it's easy to create new ones when desired.
I don't see fibers in the guile manual, just heavy weight threads. Is that a third party library? (The lack of a package manager to easily install such things is an issue with most Schemes; only chicken and chibi have anything like Racket's)
It does not use mutation, and should produce just as efficient code as the racket loops. It is also extensible (and easily portable to racket!). It is written almost exclusively in syntax-rules.
Yep peg.el[1] is now built-into Emacs since 30.1 (which is how I came to know of it, but actually the library seems much older) and it makes certain things much simpler and faster to do than before (once you figure out its quirks).
Although I'm a recovering sexp addict I must confess that I fail to see what makes the cons cell so important to those purer in their faith?
To me the homoiconity of Lisp is mainly about code-as-data, the exact nature of the data doesn't matter to me that much as long as it's a first class citizen and enclosed in nicely balanced parenthesis (though sadly here Janet seems to have fallen to the temptations of the curly braces, and thus, is indeed heresy).
I have an emacs function that opens up the page to its examples use on the web, which can be useful directly from emacs itself.
I'd also like to be able to open up each example up on to the playground with the docs above it. (Currently you can just open the example in the playground) no docs right above it.
I did see a json file containing all site data at one point, I did think about using this as a data source for an llm to 'janet' correctly (because at the moment, they do not). This could be displayed/noted more prominently.
I did most of the 2023 Advent of Code using Janet and it was a great experience. I forced myself to use PEGs as much as possible, even when it was overkill, and I really began to like those for the readability and ease compared to other parsers/regexps that I have used.
I like that it is a small language without dependencies. Have it installed everywhere, including in termux on my phone. Good for scripting.
Used to daydream about a native Clojure and Janet is close enough to that. Does not have everything, but the cost in size and dependencies is so much lower. It is simpler and easier and runs well even on a RPi Zero.
I would tend to use Janet for scripts, especially ones that need to talk to the outside world because of its fast startup and batteries included standard library (particularly for messing with JSON, making HTTPS requests, parsing with PEGs, storing data in maps), while I would use guile for larger projects where things like modularity, performance, or metaprogramming were more important to me.
That being said, these days I use Clojure for both (I use babashka to run scripts: https://babashka.org/)
I don't know enough about guile, but janet was pretty easy to develop for .
Its binaries are quite small, could wrap and embed raylib and a few small c libraries with no hassle. This makes distribution much easier.
For my simple 2d game jaylib (raylib) code.
ls -laoh build/app
-rwxr-xr-x 1 worthless 2.8M 27 Jul 17:28 build/app
otool -L ./build/app
./build/app:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1356.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 24.0.0)
/System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 706.41.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 2674.3.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 4034.0.0)
/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1951.0.4)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1226.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 4034.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
I believe those are pretty standard to have on most OSX machines, the situation is similar for my Linux system.
The LLM's really can't deal with janet though, they seem to think its clojure and screw up a lot of things.
Feed your LLMs the documentation and example code (perhaps the whole stdlib if it fits). Tell your LLM that it is not Clojure nor Scheme, it is a different language. I have worked with more niche languages than Janet with Claude before this way, successfully.
One big difference is you can compile Janet programs down to executables without any additional dependencies or runtimes. It makes distribution extremely nice. The ffi is also much easier.
If you are happy with Guile, I guess Janet is not worth switching (it is faster, though). It is absolutely and explicitly not Scheme, though. More like natively compiled and script-optimized Clojure.
Janet is awesome but pretty please, work on the tooling. There's very little in the way of working and debugging interactively with the REPL from any IDE that I know of and last time I tried (on Emacs) there was barely a dedicated mode to work with it.
I've also added Janet support to nvim-paredit [0] and use a combination of that, conjure [1], and nvim-parinfer to get a really slick editing experience in neovim.
Looks great, I like the clean syntax and in particular the defn is pretty.
I lost interest before I got to implementing proper functions, so mine only has variables that can be executed, if you're interested, it's here http://dusted.dk/pages/slispRepl/ but it's a mess, and only interpreted.
It is unfortunate that there doesn't seem to be a GUI library --- if there was one _and_ if one could easily compile to a stand-alone program for distribution, this would be very interesting to me.
For bonus points, compiling to a stand-alone JavaScript wrapped in HTML would be awesome if it could be hosted on a Github page.
For a GUI in a limited sense you can use TIC-80 with its built-in Janet support. It can export to stand-alone binaries too, but I did not try that (and I mostly used TIC-80 with Fennel, not Janet).
Obviously I understand most of the time someone wants to make a GUI they are not thinking about something like TIC-80. I agree a more complete GUI library would be nice.
But if nothing else it may be worth mentioning that TIC-80 is a fun and easy way to install and try Janet. Even the Android version comes with Janet and a built-in code editor. Just run "new janet" in the TIC-80 console and then press F1 (on Android TIC-80 by default uses its own virtual keyboard that has all the keys it needs) to open the code editor.
Problem with the Android version is how ... to access the files it saves (or exports to). They seem to end up in the app-specific data directory that no other app can read on newer versions of Android.
Given your criterion for what a "fortunate" language would be, what language includes a GUI library, compiles to a stand-alone program for distribution, as well as "Javascript wrapped in HTML"?
Just so I'm clear, you then feel compelled to openly and publicly label every literally programming language as "unfortunate" because it doesn't live up to what LiveCode aspired to be?
An opinion that flatly and individually labels every extant thing the same has no signal to it. I'm not sure what to make of your original post other than you're expressing displeasure at the universe for not handing you what you wanted and that you believe that expression should be injected into arbitrary discussion.
Should have phrased it as something along the lines of:
>This would be very interesting to me if it had support for a GUI library, and if it were then possible to compile to a stand-alone application which could be easily distributed.
Lisp is very cool. But one thing I do not like is that the syntax style `(fun a b c)` loses out to the less-symmetric "OO" style `a.fun(b, c)` when it comes to IDE auto-completion. And for me the IDE help is important to provide a smooth developer experience and minimize wasted brain energy. I'd like to find a way to make the editing and auto-completion work better. I think the way IDEs (and maybe our brains) work is: "here is a thing X, now what can I do to/with it?". That translates to typing in your editor: "X.[cursor here]", and then the IDE lets you see and search the things you can "do" with X. But if, in Lisp, you write "([cursor here]", you are immediately confronted with: "what is the signature of that function again?", but the IDE has nothing to go on. Maybe there is different style of editing, where we could type the arguments, and then trigger the auto-complete.
In Clojure, this is merely (a/fun b c) or (. a fun b c) depending on whether a is a namespace or an object. Autocomplete works wonderfully. I would strongly urge you to try a coding session using Cursive so you can objectively refactor your obsolete LISP opinions.
I don't know about other lisps, but Clojure has namespaces and that's good enough for me. So you can type "(foobar/" and get a list of functions in the foobar namespace.
Janet kind of has this too: if you import a module with (import foo), all the imported bindings will be prefixed with foo/. Also, this can be avoided by writing (use foo) instead.
Common Lisp also has namespaces, you can type '(asdf:' and get the functions ASDF provides.
Haskell sort of has this. You type (_ a b c) and the compiler tells you which methods would make sense there based on all three variables (so in a sense it is even more useful.)
Do you mean you run a build and it tells you in the error message? Or is there an IDE/editor where you could hit a key-combo with the cursor on that line, or near the `_`, and it would show a popup of possibilities for auto-completion?
Yes. Both are alternatives.
I think this is more familiarity bias and the presence of an enforced type system than a necessity of auto-complete. In the same way that `a.` auto-completes to methods of `a`, `(fun ` could auto-complete to a list of in-scope variables that satisfy `fun`'s type signature. A lot of lisp is untyped though, even in variants that have support for it.
I also think there's some familiarity bias to the OO style. I don't find it particularly natural, though that's subjective. I often know what I want to do, and have to find the object that has the method. E.g. I know I want to read a particular header, but is it on Request, or on Request.Headers, or are headers passed in as a separate object? It feels cleaner to do something like `(get-header "SOME-HEADER" ` and have the IDE tell me I need to pass in `(get 'headers request)` or similar.
Odin's language server calls it "fake methods".
https://odin-lang.org
https://github.com/DanielGavin/ols
What do you do if 'a.<tab>' doesn't work because it's not 'a.fun(b, c)' but 'b.fun(a, c)' or 'c.fun(a, b)'?
Also think of autocompletion for 'var x = new' to 'var x = new ByteArenaFactory()', the way you get from nothing to 'ByteArenaFactory' is the same way you get from nothing to '(fun a b c)'.
Janet, like some other lisps, has the arrow macro, which allows you to write in the “OO” style.
Ah neat! In Guile I use threading/pipelining all the time with a small macro:
Janet already having this ... Reading many good things about Janet in this discussion.Something like this combined with some IDE smarts to offer up the possibilities for `fun` after I type `(-> a` ... that could be very cool.
You mentioned autocompletion a few times and that is something available via LSPs (janet specifically has one that has this) or through the editor (e.g. emacs can use swank for common lisp). It's no different for any other language integration.
I think that threading macros is different to method chaining (at least to my understanding), method chaining works on the object returned, and threading macros can work on raw data or objects.
When I see languages like this, I always wonder, how far the ecosystem is. I have used GNU Guile a lot and there are quite a few libraries for it, so that one can do almost anything. Web things are coming, but maybe not as fully there yet, as one might like. Racket also has lots of libraries. And even a standard library web framework.
So lets say I want to start my next web project in Janet. I already know Scheme and can probably quite easily just start writing another lisp, assuming it has TCO and I can do things mostly like I would in Scheme, except maybe for having to use funcall (which is annoying, but OK). Does Janet have libraries, that enable web projects? Like a web server and SXML or something like that? Or does it have things like a JSON parser? All these little things one would like to have, to not have to develop the basics first, before getting to the actual project.
And what about data structures? Are there functional data structures available? In GNU Guile I have at least the unmaintained guile-pfds. Hopefully, I will one day understand enough about functional data structures to build more or to maybe even maintain that library. But learning resources are scarce. It is already difficult to find a functional version of an AVL tree! Lots and lots of places merely teach non-persistent, non-functional versions of these data structures, and it is not trivial to translate them, might impact performance in ways that are not necessary, if one had great knowledge about how to make these data structures.
And also reproducibility! With GNU Guile I have what I need on Guix, which is great! With other languages, I might need to rely on older package managing approaches, that do not have reproducibility/determinism as the a high goal on their agenda, or might even lack the ability to create lock files/files with checksums. I don't want to go back to non-reproducible.
I am also eyeing statically typed variants like Carp. Same questions arise. Some seem really great and I would probably enjoy using them a lot. Would be a pity to then discover, that the ecosystem is just not there, and one has to create all the basic tools one needs oneself. Sometimes that can be fun, but it can also be exhausting and one never gets around to ones actual project.
Janet has ~10 web frameworks (half SSG, half dynamic) and many web servers. Joy [0] is the most fully featured stack approach, which Janetdocs [1] runs on. But everything you mention is in the std lib. Here's a certbot in 10 lines only using the extended std lib (called spork): https://codeberg.org/veqq/janetdocs/src/branch/master/ssl-fe... `json/decode` automatically maps json to native data structures. There's a package manager included, which builds all code I've found so far, reproducibly.
As for DS, only arrays, there are maps, arrays and strings, all mutable or immutable. I don't think there's any intention to ever implement functional data structures, but they could "easily" be a library.
- [0] https://github.com/joy-framework/joy - [1] http://janetdocs.org/
I see that there is a package manager "jpm" and I looked at the docs, but I couldn't see anything relating to how to create a lock file or how it makes sure, that every time I install dependencies, I get the exact same versions (not just version numbers).
Are any of them maintained? I see that the last commit for Joy was 2 years ago.
Maintenance isn't a breaking issue, at the moment. No one's stepped up to fork them and accept PRs, because they work as is. I'm personally working on this, though and expect a lot of progress in the next months - but this won't impact day to day coding, because they work already.
Here's a implementation of some persistent DS: https://github.com/ianthehenry/jimmy It's incomplete, primarily serving as a c++ interop example, though.
That looks cool. I scrolled through the readme though and it only lists vectors, maps, and sets. That's not actually that much, but it is quite foundational. Maybe one could build others on top of that. But then the question arises, whether that implementation is performant.
Also see https://janet.guide/ for a good introductory book to Janet.
This is the first time I'm seeing the book. The author is solid! He has just the right sense of humour for a programming book.
He works at Jane Street and was recently on their podcast§. An interesting chap, for sure!
§https://signalsandthreads.com/building-tools-for-traders/
Previous discussions:
https://news.ycombinator.com/item?id=23164614
https://news.ycombinator.com/item?id=34843306
https://news.ycombinator.com/item?id=28255116
https://news.ycombinator.com/item?id=28850861
Does it have a native compiler and/or types? Basically, can it get in the ballpark of SBCL's performance?
It'd be nice to have something cleaner than Common Lisp, and a much smaller image size. If it has decent performance too, I'm sold.
Janet uses a bytecode VM that's faster than many dynamic languages but won't match SBCL's native compilation performance; it has optional type annotations for documentation but not for optimization.
Janet does compile to standalone executables with jpm
Just keep in mind that these executables are the Janet bytecode interpreter bundled with your bytecode, not “real” native executables.
No, they are actually real executables without the need of an external runtime. You can get images also if you like. See quickbin in the jpm man page.
> Create a standalone, statically linked executable from a Janet source file that contains a main function.
and discussion here
https://janet.guide/
> My favorite feature of Janet, though, is something that sounds really dumb when I say it out loud: you can actually distribute Janet programs to other people. You can compile Janet programs into statically-linked native binaries and give them to people who have never even heard of Janet before. And they can run them without having to install any gems or set up any virtual environments or download any runtimes or anything else like that.
They're not super tiny, though. A hello world I just did is about 727K.
No, gp is correct, the 'real executables' are a VM image with the interpreter baked in. The only native code in the binary is the interpreter. Janet code does not compile to machine code.
I understand your point, but by similar logic I can argue any language is interpreted because nothing compiles down to microcode. The point is you don't need janet-specific external dependencies in the environment. I don't differentiate between this and an inefficient compiler.
> I can argue any language is interpreted because nothing compiles down to microcode
Not every processor architecture uses microcode, so this doesn't hold up.
> The point is you don't need janet-specific external dependencies in the environment
Sure.
> I don't differentiate between this and an inefficient compiler
A compiler is the general term here, but the target is not. Targeting the native architecture for a CPU vs targeting a bytecode VM are quite different and have pretty important implications for performance, portability, memory usage, etc.
The distinction matters because the resulting executable is not (significantly) faster than running the program as a script.
I think the distinction (from the OP’s perspective) is that it’s “just an app” to the end user.
When I download the Slack desktop app, I might know it’s running on electron because I’m a programmer. But I didn’t have to download and install nodejs or anything else. As far as I’m concerned it’s a completely self contained application.
The end user needn’t download and install Janet or even know that Janet exists.
That can obviously be done with any interpreted language, but Janet makes it really simple out of the box.
From the book you linked:
> But in order to produce native code, jpm actually:
> 1. Compiles your Janet source code into an “image.”
> 2. Embeds the contents of that image into a .c file that also links in the Janet runtime and interpreter.
> 3. Compiles that .c file using your system’s C compiler.
https://janet.guide/compilation-and-imagination/
Tangentially, image-based development is possible, reloading images into the REPL for more interesting workflows: https://alexalejandre.com/notes/exploring-janet/#image-based... but it's a WIP.
So after all those steps, it is actually compiled native code that you run?
Yes, but the code portion of the executable is really the Janet interpreter, while your code lives in the data segment and is not in the native form.
It's a lightweight embeddable interpreter and runtime, similar to Lua. Dynamically and strongly typed, but no native compilation. Easy to call C libraries, or embed into C projects. In my testing, it's roughly twice as fast as Python for similar tasks. You can "compile" a project by embedding scripts and resources with the runtime into a bundled executable.
This is not a replacement for Common Lisp. It is in the same niche as Guile (but quite faster).
Yeah, I see Janet as "what Guile intended itself to be", though it is quite a bit smaller (in some ways that's a postive). I find the choices it made to be more pragmatic and it's far more accessible in non-linux environments since Guile tied itself closely to guix.
Current Guile it's much faster.
Is there some kind of decision tree for "which lisp should i use?". CL, Scheme, Racket, Clojure, Janet... Elisp at least is clear :)
CL is like the C++ of the Lisp world. It's standardized, multiparadigm, has a ton of functionality, fast, and built with large codebases in mind. It's also got a lot of cruft and because the standard is old it lacks certain things people expect, like networking and threads. Implementations usually provide these and compatibility libraries do a decent job of smoothing over implementation differences. Choose CL if you have a team, a large project, and you need speed.
Scheme was written for educational purposes. It's very minimal, and implementations aren't very compatible for anything outside the spec and the SRFIs (specs for optional functionality). I'd you choose a major implementation like Guile or Chicken however, there are tons of libraries available and it's very usable for small and medium-sized projects. It isn't known for its speed. Choose Scheme if you think like a computer scientist.
I've never used the others enough to comment, although I did enjoy playing around with Clojure since it's a functional language. I'd do more with it if it wasn't tied to Java and JavaScript. I keep telling myself to learn some Racket, but I never have the time.
Personally, I do most of my Lisp work in elisp, since my regular job isn't Lisp-based but I need to mangle text a lot. elisp is from the same tradition as CL so it's pretty similar.
Typical, asked for a tree and returns a flat list...
Cons cell surely...
CL for performance and 'Lispiness'.
Scheme if you really enjoy recursion.
Clojure if you need the JVM and/or employment (this is me).
Racket if you drink the DSL kool aid.
Fennel (same author as Janet) for Lispy Lua.
Janet for Lispy C.
Is there anything that is janet-unique? I just did a cursory glance, and most of it seems like a scheme with slightly different syntax and a more "modern" standard library.
Why should I switch from my scheme of choice (guile) to Janet?
It's not a Scheme at all! It doesn't have cons cells after all. It's a Clojure-like (maps everywhere, collection api, immutable data structures) with 1mb executable and [servers](http://janetdocs.org/) running under 10mb of ram.
Fibers are very interesting, even used for error handling. I've not wrapped my head around PEGs yet.
That makes sense. I have always thought about what I would do if I could make a "modern scheme". A lot would be taken from clojure but definitely not everything. Cons cells would stay, but the star of the show would be immutable vectors based on rrb trees or maybe finger trees (efficient concatenation, insertion in the middle etc), HAMTs , concurrentML (like guile-fibers) and a nice looping facility (like my own goof-loop[1]) and restricted mutation. Syntax-case and syntax-parse from racket. An extensible pattern matcher (like the one found in racket).
I would also make strings immutable, maybe like Guile's cow-strings, maybe blobs-with-cursors.
Definitely just copy Guile's delimited continuations.
I think I would just ignore most of r7rs, since I don't think it improves things for the progrmmer.
[1] https://rikspucko.koketteriet.se/bjoli/goof-loop
Racket has almost all of that.
I am no fan of racket's for loops. It is frustrating, because it fells like an almost-goosd looping facility.
I do use racket, but for scripts I prefer guile. Guile-fibers is a lot neater than the racket parallelism situation, for example. And I can usually find the code responsible for what IAM trying to achieve in the implementation. I never became friends with racket. I remember trying to fix a bug, but I never found what I was looking for.
Getting superficially familiar with the guile codebase takes about an hour.
Then again, I am a classical musician and not a programmer.
Racket's for loops declare in their name what they're intended to return (if anything). Personally that's way more readable and preferable to, say, Common Lisp loop or iterate where you have to hunt through the body for clues. Plus it's easy to create new ones when desired.
I don't see fibers in the guile manual, just heavy weight threads. Is that a third party library? (The lack of a package manager to easily install such things is an issue with most Schemes; only chicken and chibi have anything like Racket's)
I wrote this, which I find more usable than racket's loops: https://rikspucko.koketteriet.se/bjoli/goof-loop
It does not use mutation, and should produce just as efficient code as the racket loops. It is also extensible (and easily portable to racket!). It is written almost exclusively in syntax-rules.
Guile fibers can be found here: https://codeberg.org/fibers/fibers
PEGs (even outside Janet) are amazing and what I reach for all the time :) definitely one of those tools that’s worth learning!
Yep peg.el[1] is now built-into Emacs since 30.1 (which is how I came to know of it, but actually the library seems much older) and it makes certain things much simpler and faster to do than before (once you figure out its quirks).
[1] https://github.com/emacs-mirror/emacs/blob/master/lisp/progm...
> PEGs (even outside Janet) are amazing […] worth learning!
Actually, the opposite is the case. https://news.ycombinator.com/item?id=32316375
HN readers, don't fall into this trap and waste your time.
Ah yes, I, the non-python programmer, find PEGs useful and good because of checks notes Guido, somehow? What a ridiculous comment.
If a language lacks cons can it truly be held to be a lisp or has heresy taken over?
Although I'm a recovering sexp addict I must confess that I fail to see what makes the cons cell so important to those purer in their faith?
To me the homoiconity of Lisp is mainly about code-as-data, the exact nature of the data doesn't matter to me that much as long as it's a first class citizen and enclosed in nicely balanced parenthesis (though sadly here Janet seems to have fallen to the temptations of the curly braces, and thus, is indeed heresy).
I chuckled at "recovering sexp addict". What possible risk is there in over-indulging in sexp?! I simply don't see it.
Speaking of unconventional lisps, I enjoyed this recently:
https://github.com/vygr/ChrysaLisp/blob/master/docs/lisp/lis...
from Chris Hinsley, author of the (very) cool Chrysalisp operating system. Same author who wrote this in 1995:
http://www.uruk.org/emu/Taos.html
I am a heretic, but I agree that it seems the power of code as data can exist outside a linked list.
I will not give up my curly braces or square brackets.
It's got Lots of Indented Silly Parentheses.
Thank you for janetdocs.org , I hated having the missing functions from janetdocs.com
Do you have any suggestions or things to improve on? I'd like to know how others use it!
I have an emacs function that opens up the page to its examples use on the web, which can be useful directly from emacs itself.
I'd also like to be able to open up each example up on to the playground with the docs above it. (Currently you can just open the example in the playground) no docs right above it.
I did see a json file containing all site data at one point, I did think about using this as a data source for an llm to 'janet' correctly (because at the moment, they do not). This could be displayed/noted more prominently.
None of these are 'must have', just nice to have.
I did most of the 2023 Advent of Code using Janet and it was a great experience. I forced myself to use PEGs as much as possible, even when it was overkill, and I really began to like those for the readability and ease compared to other parsers/regexps that I have used.
I like that it is a small language without dependencies. Have it installed everywhere, including in termux on my phone. Good for scripting.
Used to daydream about a native Clojure and Janet is close enough to that. Does not have everything, but the cost in size and dependencies is so much lower. It is simpler and easier and runs well even on a RPi Zero.
A native clojure? have you seen jank?
https://jank-lang.org/
Yeah I am eagerly awaiting it, but it is not ready yet, so for now Janet is the best substitute.
I would tend to use Janet for scripts, especially ones that need to talk to the outside world because of its fast startup and batteries included standard library (particularly for messing with JSON, making HTTPS requests, parsing with PEGs, storing data in maps), while I would use guile for larger projects where things like modularity, performance, or metaprogramming were more important to me.
That being said, these days I use Clojure for both (I use babashka to run scripts: https://babashka.org/)
I don't know enough about guile, but janet was pretty easy to develop for .
Its binaries are quite small, could wrap and embed raylib and a few small c libraries with no hassle. This makes distribution much easier.
For my simple 2d game jaylib (raylib) code.
I believe those are pretty standard to have on most OSX machines, the situation is similar for my Linux system.The LLM's really can't deal with janet though, they seem to think its clojure and screw up a lot of things.
Feed your LLMs the documentation and example code (perhaps the whole stdlib if it fits). Tell your LLM that it is not Clojure nor Scheme, it is a different language. I have worked with more niche languages than Janet with Claude before this way, successfully.
One big difference is you can compile Janet programs down to executables without any additional dependencies or runtimes. It makes distribution extremely nice. The ffi is also much easier.
One thing I really like about Janet, compared to Scheme, is that it’s one language instead of a family of similar but incompatible languages.
If you are happy with Guile, I guess Janet is not worth switching (it is faster, though). It is absolutely and explicitly not Scheme, though. More like natively compiled and script-optimized Clojure.
Janet is awesome but pretty please, work on the tooling. There's very little in the way of working and debugging interactively with the REPL from any IDE that I know of and last time I tried (on Emacs) there was barely a dedicated mode to work with it.
Since other people mentioned there's been work there, here is my Emacs config now:
Also, a fix for treesit auto to not ask for the grammar every time:Janet is also supported by conjure in neovim
https://github.com/Olical/conjure
The LSP for it works reasonably well.
I've also added Janet support to nvim-paredit [0] and use a combination of that, conjure [1], and nvim-parinfer to get a really slick editing experience in neovim.
[0]: https://github.com/julienvincent/nvim-paredit
[1]: https://github.com/julienvincent/nvim-paredit
[2]: https://github.com/olical/conjure
Oops, I really messed up those links:
[0]: https://github.com/julienvincent/nvim-paredit
[1]: https://github.com/olical/conjure
[2]: https://github.com/gpanders/nvim-parinfer
Have you tried contributing any tools?
I use janet ts mode in emacs and Ajsc netrepl integration, for at least a while now.
You should try again.
I've been trying to use ajrepl but as mentioned in the README, there's a lot of cruft that gets output. How do you setup ajsc?
In Emacs
In the janet itself: If you have tight main loop, make sure you have something like: To allow the netrepl server to take time.Start janet (usually i do it via jpm)
Then m-x ajsc and localhost:9365This should be default.
If you dont start it in debug mode, you can't redefine functions as they are running.
I have an example using it for live web stuff here: https://github.com/wmealing/janet-joy-live
Looks great, I like the clean syntax and in particular the defn is pretty.
I lost interest before I got to implementing proper functions, so mine only has variables that can be executed, if you're interested, it's here http://dusted.dk/pages/slispRepl/ but it's a mess, and only interpreted.
The first code example on that page claims to solve "the 3SUM problem".
According to [1], "the 3SUM problem asks if a given set of n real numbers contains three elements that sum to zero."
It's not clear to me what problem the Janet code solves but it's clearly not that 3SUM problem.
On the example input of
it outputs For what it's worth, here's some Common Lisp code that does solve the 3SUM problem in O(n^2). [1] https://en.wikipedia.org/wiki/3SUMIt outputs the indices corresponding to the solution. E.g.
If you want a one line code, in J, for the 42 solutions:
Or the 8 solutions in a 2x12 matrix:I can't handle the line noise :(
Are there any known commercial use cases?
I do not see how it handles async await
You should take a look at fibers
https://janet-lang.org/1.9.1/docs/fibers/index.html
It is unfortunate that there doesn't seem to be a GUI library --- if there was one _and_ if one could easily compile to a stand-alone program for distribution, this would be very interesting to me.
For bonus points, compiling to a stand-alone JavaScript wrapped in HTML would be awesome if it could be hosted on a Github page.
For a GUI in a limited sense you can use TIC-80 with its built-in Janet support. It can export to stand-alone binaries too, but I did not try that (and I mostly used TIC-80 with Fennel, not Janet).
Obviously I understand most of the time someone wants to make a GUI they are not thinking about something like TIC-80. I agree a more complete GUI library would be nice.
But if nothing else it may be worth mentioning that TIC-80 is a fun and easy way to install and try Janet. Even the Android version comes with Janet and a built-in code editor. Just run "new janet" in the TIC-80 console and then press F1 (on Android TIC-80 by default uses its own virtual keyboard that has all the keys it needs) to open the code editor.
Problem with the Android version is how ... to access the files it saves (or exports to). They seem to end up in the app-specific data directory that no other app can read on newer versions of Android.
Given your criterion for what a "fortunate" language would be, what language includes a GUI library, compiles to a stand-alone program for distribution, as well as "Javascript wrapped in HTML"?
Lil has a GUI "system" in the form of Decker, which can export programs as standalone single-file HTML documents: http://beyondloom.com/tools/trylil.html
It doesn't exist as an opensource option anymore (since Livecode did their rugpull) AFAICT, it's something I've been looking for since then.
Similarly, they were supposed to offer "compile to HTML5", but it never really worked for me.
Just so I'm clear, you then feel compelled to openly and publicly label every literally programming language as "unfortunate" because it doesn't live up to what LiveCode aspired to be?
An opinion that flatly and individually labels every extant thing the same has no signal to it. I'm not sure what to make of your original post other than you're expressing displeasure at the universe for not handing you what you wanted and that you believe that expression should be injected into arbitrary discussion.
I will agree that the word choice was poor.
Should have phrased it as something along the lines of:
>This would be very interesting to me if it had support for a GUI library, and if it were then possible to compile to a stand-alone application which could be easily distributed.
https://github.com/janet-lang/jaylib
See my example above, that has embedded raylib.