if those are the reason why you love janet, then you will love tcl because you will be able to do all the same things without drowning in parenthesis and weird syntax.
There are three languages worth learning that expand your mind: Lisp, Forth and Tcl. Despite all exhibiting homoiconicity, they couldn't be more different from one another. (I'd include Rebol but it's as mind-blowing as it's dead technology from a lost timeline)
Why Janet? (2023)
271–280 of 292 posts
Re: Why Janet? (2023)
#272Pretty 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:…
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…
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.
Re: Why Janet? (2023)
#273Re: Why Janet? (2023)
#274Earlier quoted context omitted.
This is a great comparison and I've been wondering about it for a while. Between babashka, janet(i discovered it just now), fennel, guile. Which one would be a better scripting language? Please tell me you experience, and if you are interested, we can work on a small article and benchmark about this.
It's platform-dependent isn't it? Otherwise, the practical differences between Lisp dialects are negligible. For me writing either in Janet or Fennel or Clojure feels almost like writing in the same language. Babashka has replaced bash-scripting for me. I don't hate Bash, but why would I ever choose to use a language that has no true REPL, if I don't have to? bb is pretty much Clojure, which is the greatest choice if…
Re: Why Janet? (2023)
#275Earlier quoted context omitted.
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 J…
Re: Why Janet? (2023)
#276Earlier quoted context omitted.
I know that Lisp has lots of paranthesis and I don't have enough experience with Lisp at all. But from the looks of it, Janet has some great ideas like the one that @ramblurr shared here about sandboxing ("Disable feature sets to prevent the interpreter from using certain system resources. Once a feature is disabled, there is no way to re-enable it.") Lisp from my understanding is incredibly polarizing and many peopl…
> Lisp from my understanding is incredibly polarizing No it's not! It's as "polarizing" as "group theory" or "set theory". Lisp is fucking math - it maps closely to formal mathematical/logical notation. You just can't "hate" math - you can be confused by it, be unfamiliar with it, intimidated by it. But hatred directed at something that is simply precise and consistent says more about the person than the thing. This…
Re: Why Janet? (2023)
#277Earlier quoted context omitted.
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 J…
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 :)
Because of this plethora of standards, most plugin developers (including us, I work at XLN Audio) use the JUCE C++ framework, which provides a uniform interface to all these formats and more. It's available on GitHub under a GPL license if you just want to play with it (it has excellent tutorials and example projects). If you're just curious about development thing, I recommend using Reaper as a host to test in, both because it's essentially free (it's free like WinRAR is free), and it has tons of options for how to run plugins (all in the main process, all in a bridged process, every plugin in a dedicated process, etc.).
Audio plugins are essentially dynamic libraries loaded at runtime, and a common way to run them (used to be universal, but some hosts are changing) is that the dynamic library is just loaded in the main process address space and the host communicates with it by calling functions on it. That means that if a single plugin (out of maybe dozens in a project) crashes, it takes the entire host down. In addition, if you have multiple instances of the same plugin (very common, you might have the same effect on multiple tracks, for instance), all global and thread_local variables are shared between them, which makes global variables a total nightmare, and raises the thread_local problem I mentioned earlier.
Our products use JUCE for the unified interface, but then we have an entirely custom Lua codebase for the GUIs and scripting the products themselves (with lots of connections to the audio engine, which is of course C++). There are very limited languages you can embed this way, because of the requirements I mentioned above. The ones I've looked at which you could possibly do it with is Lua, Python (3.12+), JavaScript and Tcl. I haven't done a lot of testing outside of Lua though, this is just me looking at the embedding APIs. You could also do it with web views, and recent versions of JUCE provides nice ways to do that.
I wouldn't do it with Janet if it uses thread local state this way, but maybe it works. It would definitely work if you spun up dedicated threads for each instance and communicated the events back and forth, but that seems like a bad idea.
Let me know if you have more questions, this is a very weird field of programming that most developers are not exposed to.
Re: Why Janet? (2023)
#278Earlier quoted context omitted.
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?
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 in the 1970s and are entirely keyboard-centric with very primitive UI flows. You can get used to it, but never fix 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. When I inspect a class in LispWorks, I get truly interactive UI elements which themselves map to rich Lisp objects.
Even editors like Lem that fix Emacs' performance issues (another genuine problem), they all make the same mistake of being centered around text-buffers and under-engineered UI frameworks. You can extend them ad infinitum, but if the roots are rotten...
Second Climacs exists, but it's more of a curiosity and a research project than a usable text editor IME (and is also currently tied to X, though that doesn't affect me personally). I hope that changes some day.
Re: Why Janet? (2023)
#279Earlier 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…
It makes me sad that some-mthfka got some but perhaps not enough support and the effort stalled after a few months.
Re: Why Janet? (2023)
#280Earlier quoted context omitted.
> advanced HTTP routing What do you concretely mean by this? I use https://github.com/joy-framework/joy for all web stuff and can probably get your missing features in within the week.
TLS. There are some curl wrappers but last time I checked they did not work