What are the goals of the Janet project?

[MikeBeller]

Janet is a really terrific language. I think it hits a really great sweet-spot of simplicity and expressiveness. Like the smallness of Lua with the expressiveness of Python. The C amalgamation (only 30k lines) is like a superpower for embedding. And the community is exceptionally helpful and friendly. But is there a community goal? (or an individual one in the mind of @bakpakin?).

My assumption was the goal is "adoption", or perhaps "adoption while not losing your identity" (i.e. stay small, stay embeddable, etc.) But that is just my assumption. If adoption is the main goal though, it may be worth discussing what would cause Janet to become more widely adopted. Getting a language above the noise today is very non trivial. I feel like you pretty much need an "adoption hook" and some focus.

Thoughts?

Mike

[bakpakin]

NOTE: If you are a frequent user of Janet, please let me know what things you would like to see in Janet.

---

While adoption is always nice, Janet is not a commercial endeavor and my main goal is "to make a useful lisp-like programming language for scripting and extending C applications". The hope is that if the software is good, users will come. To that end, I think the core language is mostly there, and adding more functionality is encroaching on "bloat". However, we are not there yet and there is room to improve.

However, wider adoption does make Janet more useful (more people adding code, more insight, more manpower, etc.), so "adoption" is just one factor that make Janet better software (and perhaps a better community).

To improve adoption and also make Janet more useful as software, I think there are a few very important issues.

• Improved API documentation - the current documentation is sparse on how to use Janet from C, which is supposedly a main purpose of Janet. Networking docs and ev/* docs are also mostly missing (this falls mostly on me).
  There are efforts like https://janetdocs.com for doing community source documentation as well, which are a great
  way to have users contribute to Janet.
• A spec - See Official language spec? #542
• Libraries and package manager - there is jpm and a central package listing - https://github.com/janet-lang/pkgs.git, but it is not automatically updated and is therefor out of date. Since it is not automatically curated and I have been busy with other things, it would be great if someone would like to curate libraries for adding there. Since my hope is the Janet language itself is becoming more stable and getting closer to "completion", more effort should be redirected to creating and maintaining Janet libraries and tools.
• Formal organization - for Janet to really grow, it could be desirable to form a more formal organization. But there are downsides to maintaining such a thing, and many software projects function fine as distributed, informal, 1 person + contributors projects.

For my individual goals with Janet, I have many :). When possible, I like to use Janet as a spring board for any programming needs of mine where CPU performance is not an issue. It definitely takes a bit of ego to decide things in other programming languages are not good and re-implement them "better", but that is exactly what many programming languages do.

[pepe]

I am volunteering for the package curator role. I will try to specify what It would actually mean and start another discussion on the topic.

[uvtc]

Edit: Ooof. Sorry. Removed comment. Interested to hear what you have to say on the subject, @pepe .

[bakpakin]

I am volunteering for the package curator role. I will try to specify what It would actually mean and start another discussion on the topic.

@pepe Thanks for the offer! I've sent you an invite to the Janet organization and I will give you access to the pkgs repo so you can currate/update the repo.

Hopefully we can get more packages there, and maybe even add some more meta data to the package listing! There is a whole lot of useful data we could put there that would enable things like package search, etc.

[pepe]

Thank you very much. Today is a little bit too late, but tomorrow is a free day for me, and I start that discussion. I feel there is a lot of opinions in the community.

Repository wise I will start with the basic stuff, as proposed in janet-lang/pkgs#19 and standard admin work.

The curation could easily turn into censorship and thus must be well thought out. But after we decide about the rules, there could be a retrospective on what we already have there.

[pepe]

@bakpakin may I ask to add permission to my user for the pkgs repo, please?

[ahungry]

I'd like better cross-compilation (mingw build on GNU/Linux to make Windows .exe) support built into JPM, so I don't have to hack around it with things such as this (https://github.com/ahungry/ahungry-janet/blob/master/Wakefile32 and https://github.com/ahungry/ahungry-janet/blob/master/Wakefile).

On the subject of jpm, I think the project.janet are a bit wild at the moment, as they execute arbitrary janet code during the build process vs being declarative lists of things that jpm needs to process (files, flags, etc.).

This is good for flexibility, but also means everyone has a different ad-hoc solution to solving the same things (GNU/Linux custom build steps vs Windows custom build steps etc.), environment based setup things, dynamic package flag checks etc.

Maybe both my wants would be achievable if we could have a generic project.janet for common build steps, and then architecture/OS specific project.linux.janet, project.windows.janet, project.ming.janet, project.osx.janet files which would activate when being built on that target? (it may also make it more clear what OS is and is not supported by various janet packages/libraries).

[bakpakin]

mingw support would certainly be useful and I see no reason why we couldn't. There maybe some needs to change preprocessor directives and add a new Makefile.

As for making project.janet less adhoc, the fact that project.janet is a script is sort of built-in to jpm and unlikely to change.

Making jpm load platform specific project.janet files as well as a main one seems interesting, and it's not exactly hard to add to an existing project.janet

(-> (string "project." (os/which) ".janet") slurp eval-string)

[etanol]

I'd like better cross-compilation (mingw build on GNU/Linux to make Windows .exe) support built into JPM, so I don't have to hack around it with things such as this (https://github.com/ahungry/ahungry-janet/blob/master/Wakefile32 and https://github.com/ahungry/ahungry-janet/blob/master/Wakefile).

You may want to tinker with Zig's Clang distribution that comes with very nice cross-compilation support out of the box.

[ahungry]

I recently tried out nim (well, back in the winter) - it comes with it as a built in output flag - I was pretty impressed.

[uvtc]

Thank you for Janet. I really appreciate its small size, simplicity, taste, practicality, docs, GPL-compatible license, and also how much you include the community.

A few comments:

• I'm interested in using Janet for standalone apps (including GUI programs) on GNU/Linux, so I hope that goals oriented towards embeddability don't conflict with Janet also being good for standalone programs.

• I'd like for Janet to go out of its way to help me catch my own mistakes.

• I don't mind if Janet has to break backward compatibility on occasion.

[yumaikas]

I'm very, very much a newcomer, to Janet.

Like bakpakin, I'd like to be able to use Janet for anything where CPU use isn't a concern, up to and including running it instead of JS in the browser, or developing GUIs or cross platform TUIs in it.

I would also like to see the various edges of it tested more thoroughly, but that's probably mostly down to more total lines of Janet being written in more contexts.

I have enjoyed the community quite a bit, y'all have been very helpful

[yumaikas]

On the "use Janet in more places" angle, I think having more Janet packages will help there as well.

[pepe]

I do not miss anything in the language itself. If we say to freeze the feature set, I won't object. Especially as adding new functionality is so easy with the module loaders, run-context and other tools.

I am very interested in the Spec because it will on one side lead to examining the design and putting struts around it. Also, many newcomers with higher experience level will appreciate it.

Documentation could get better, especially in some more advanced topics. But I think there is more work in tutorials, FAQs and other rather free forms.

In the "broad the audience" I am on the same boat, people will come if the language is good.

The biggest work lay in the ecosystem: libraries, packages, and free form documentation mentioned above.

Anyway, I love the sentence: "everything Janet is fair game". For me, it is the motto of the language.

[bakpakin]

Appreciate the feature-freeze sentiment, as I don't want Janet to dissolve into design-by-committee and get a massive core library. That would also make a spec harder to write.

That said, writing a formal spec for a language is not something I have much experience with, but I would expect it would be mostly taking the current website and annotating what behavior is required - For example: https://schemers.org/Documents/Standards/R5RS/HTML/ there is some similarity between this and Janet's website, although Scheme R5RS is obviously much more verbose and, well, specification-like. I wonder if it would be acceptable to just add a section to Janet's website that more or less follows a similar organization of the scheme standard.

Practically, a CTS (Conformance Test Suite) is also very useful - a second Janet implementation would be able to check if it follows the spec by running the test suite - Janet's existing test suite is a good starting place for this but is not well organized for this use.

[pepe]

Ad Spec I think the section on the website + CTS is all that is needed, at least for now. And even with this in mind, I wouldn't rush it.

[subsetpark]

I definitely came to Janet (and continue to look to it) as a language suitable for small command line applications (though I hesitate to say ‘scripting’ because I like being able to compile and distribute those applications).

If I were asked what I want to see out of it, it’s less along the lines of new features and more along the lines of making existing abstractions maximally composable. For instance, the work currently going into make threads and ev behave nicely together.

Other examples are the standard ways, or lack thereof, for extending behavior. We have some one-off examples of ad-hoc extension of methods like :close and :compare. But it’s not productive yet, to the extent that if I know how to extend tables for comparison, I can infer how to extend tables for, say, iteration, or string/format, et cetera.

[MikeBeller]

Hey -- subsetpark. I am with you on this idea of being able to hook certain operations. (I authored the commit of polymorphic comparison to the core.) I actually think one solution is to allow another type of "Abstract type" in Janet. Currently you can only write abstract types in C. But if you had one where the other abstract methods (:next, :marshal, etc.) were forwarded to the prototype of a table @{:_next (fn...) :_marshal..} maybe that would get you all that you need. For example you could write a new datastructure in Janet that would be automatically supported by the sequence combinators like map, loop :in, etc. This concept could actually be developed with no changes to the core by creating a module (e.g janet-abstract). I've been thinking about doing that.

[bakpakin]

@MikeBeller I don't see any issues with that for most methods. I have mentioned this a few times in gitter chat - This is basically JavaScript's Proxy.

However, we shouldn't allow people to override hash and = for custom types, as it would let them break invariants for internal hash tables (and crash Janet) if they decide to "go off the rails".

Or we could allow it, and just trust the programmer to program reasonable hash and = functions, with the idea that if those things did break, behavior as table keys would be undefined. (I'm not sure Janet would actually crash or do anything at the C-level, but it would certainly be weird).

[bakpakin]

Another goal of Janet thus-far has been to make it as hard as possible to segfault Janet (without using native extensions), which is why I bring up the issue.

[MikeBeller]

@bakpakin 110% with you on not wanting to let Janet code segfault Janet! Abstract types have: gc, gcmark, get, put, marshal, unmarshal, tostring, compare, hash, next, call methods. If I wrote a module (say 'janet-abstract') which allowed you to 'bless' a table with a prototype as being a new abstract type, I can see benefit in "hooking" get, put, marshal, unmarshal, tostring, compare, next, and call. Definitely NOT gc or gcmark, and probably don't care about hash. But compare -- that could potentially be valuable as a hook. Are you suggesting it would crash janet if someone screwed up their compare implementation? (or would it just cause hash tables to do inconsistent things?) The former is unacceptable, but the latter could be a subject of a warning in the module "if you mess up compare your object will not work correctly as the key of a table or struct".

[subsetpark]

@bakpakin thanks for your thoughts on this. I think the caution against being able to disrupt intuitions about the behavior of the runtime is absolutely crucial. And I will temper my own discussion of polymorphism, extending types, etc with the caution that there is a HUGE difference between user-defined types and being able to ‘reach into’ the behavior of the standard or core library. To go to the two languages I know best, for instance: whereas Python (and other everything-is-an-object languages like Ruby) allows for pervasive monkey patching and redefinition of global objects, Elixir has user-defined compile time records in the form of structs, and fully productive extension of behavior for structs via protocols, but the semantics of the underlying Elixir/Erlang terms are absolutely immutable.

I vastly prefer the latter approach. It’s invaluable, as a user of a programming system, to know that the underlying data types that I use will not have been changed from under me. What’s interesting - and also relevant to Janet, I’d say - is that both Python and Erlang/Elixir have really rich runtimes and late-binding semantics, so the difference here isn’t really that one is interpreted or runtime-oriented while the other is compiled. In fact Erlang is the most observable and introspectable runtime I know, which provides nice evidence that you can privilege that kind of behavior (as I think it’s fair to say that Janet, as a Lisp that exposes things like root-env, leans towards) while still having really rigorous and predictable semantics for the primitive terms.

[wrq]

I've been interested in writing something like this for a little while now.

There's a fairly wide array of major benefits that Janet offers, I guess I'll make a list.

• Successful Innovation in Lisp(s)
• Cross-platform, including Windows (!)
• Standalone, NOT hosted (!!)

Successful Innovation in Lisp(s)

As I'm sure the majority of us know, Lisp has a rich and beautiful history, with many twists and turns along the way. Many would agree that Clojure and its successes have marked a sort of milestone in the ideals of Lisp, as it's reached a level of commercial popularity that demands attention from other PL and PLT communities.

As we've seen over the past few years, there are now little lisps and clojurelikes popping up all over the place. I'm really happy that Janet takes so much from Clojure's ideals, and continue to iterate on these ideas in a way that seems fresh and confident. ev is a great example, I'm really quite excited to see what the future holds for Janet's stdlib. Maybe a core.logic clone someday? Who knows!

Cross-platform, including Windows (!)

Pretty self-explanatory, but I think being cross-platform is a HUGE benefit for any programming language. Especially Windows, because it accounts for a large portion of casual users who might not necessarily be running some hacker-y ArchLinux whatever, and they want to learn a little bit about Lisp programming with Janet. It's important not to send them down some MinGW rabbit hole of bad UX design. I'm delighted Janet can just be installed normally on Windows.

Standalone, NOT hosted (!!)

This is probably the biggest one for me, because it reduces the surface of potentially overwhelming new users with too much information when they go looking for the solution to a simple problem. By having a small language, with a small core, it's so much easier to explain things to newbies. Clojure isn't TERRIBLE about this, but if they're coming to Clojure from zero, there's this weird conversation of like "Oh yeah, there's Java and the JVM, which is this whole container for the universe that our Clojure code exists in, and occasionally the two need to communicate and there's Classes and Factory and ...." That's not very pleasant. Certainly in Janet, there's C, and its ability to talk to Janet, but the user doesn't need to have as much footing there.

Future Wishlist

• Core.logic
• Core.spec
• More newbie-centered projects to jump into. Maybe something like Love2D but for Janet+Jaylib?

Thanks for all the work, @bakpakin. Truly, I believe history will remember you and what Janet is doing for practical programming languages.

[bakpakin]

Cloure spec is an interesting proposition, as is Core.logic. It's not something I plan on working on though, as I have never really used Prolog-like systems. Good candidate for a library, though.

As for "newbie-centered projects", if I understand right, they are a non-goal. I think making projects for the purposes of creating work for newcomers is silly, and ends up creating a lot of small, basically useless projects. Tutorials, on the other hand, are valuable and something that certainly help the community. They are certainly not easy to create, though, and the standard for code needs to be pristine, and are 1 part code and 3 parts writing.

[wrq]

Perhaps I wrote poorly. I meant projects that are appealing and accessible to newbies, not projects for them to work on themselves.

I suppose with Clojure there is plenty of source material to examine at least the structure of good tutorials? I'll look into it.

[subsetpark]

I feel like a lot of the newbie-friendly nature is a matter of community: maintaining a high standard of documentation and quality prose across the ecosystem. Hopefully there’s a point where there are large, robust Janet projects that have lots of surface area for contribution: at that point, what will make them newbie-friendly is that they were built in a milieu that prized communication and put consistent effort into maintaining ticketing systems and lots of explicit explanation.

[bakpakin]

One library I have been working on is https://github.com/janet-lang/spork. My hope is that it can be become the default Janet "contrib" library, where it is a sort of secondary standard library that is maintained and distributed separately from the core.

It's not really there yet, but my hope it would be a good way for newcomers to add useful contributions to code without needing to start from scratch

[yumaikas]

One other concrete goal that I think we should have:

For at least Windows, Linux, and Mac, we could make it so that repositories that are in the janet-lang organization can install with just a "jpm install", where possible. I'll have to look them over more, but I just did the work to get jaylib there.

[zhming0]

I am really keen to get Janet on some simple Web projects.

I understand the performance is a non-goal. But I wonder if it's fair to say that the performance will be roughly the same with Lua (not including LuaJIT in comparison)?

In such case, do you recommend to use Janet on Web development?

[pyrmont]

You mean 1.15.4, right?

[zhming0]

@pyrmont Yes, you are right. Sorry for the typo.

[pyrmont]

@zhming0 Hmmm... Some people on Gitter were seeing numbers closer to yours so I'm probably doing something wrong.

[pyrmont]

Found it >_< My Janet code had a typo. Am now seeing what you're seeing.

[MikeBeller]

Hi @zhming0 and @pyrmont

Sorry for the delay getting back to you on this. There are two issues with your example program that are making it much slower than it might otherwise be:

(1) You are using pos? instead of just saying while (> i 0) -- the problem with pos? is it is part of polymorphic comparison -- which allows for comparing janet numbers with other types of numbers like int/u64 int/s64 and even ints from janet-big package, but is much slower than regular comparison.

(2) Like many other scripting languages (see python for example), it is much less expensive in Janet to use a local variable than a global one. In your code, i is global. It must be looked up in a table on each usage. To make i truly local, put the code in a function (or a do scope but a function is more typical).

So if you use this below code you will find it runs slightly faster than the lua version. (I get .5 seconds for janet vs .6 seconds for lua)

(defn mytest []
  (var i 100000000)
  (while (> i 0)
    (-- i)))

(mytest)

Regards

Mike