5 ms·

I am a happy though very new Janet user. I started migrating my existing workflow optimization scripts (e.g. Git wrappers) to--and writing new ones--in Janet as

I am a happy though very new Janet user. I started migrating my existing workflow optimization scripts (e.g. Git wrappers) to--and writing new ones--in Janet as of a few months ago. I used to use Perl but I switched to Janet as it is a much simpler language and VM, and being a Lisp is ~infinitely extensible. Janet has os/ and file/ packages, as well as a PEG system which mostly stand in for the best features of Perl. Some low-level POSIX-specific operations (like daemonizing and forking) aren't practical but I can just use C for those. I am also using it to teach my son very simple programming. He can't type well yet, so the terseness of the language helps (there are cryptic symbols but he likes learning their names and how to type them). Its REPL and functional style I feel help a lot too.

jhgb 5y ago
Have you perchance tried Gerbil as well?
- matvore 5y ago
  I did not hear of it before. Glancing at the website, it looks rather appealing (simple language, C-friendly FFI) but I don't see anything about using Gerbil in the shebang line for scripting purposes? I may give it a closer look sometime.
harryvederci 5y ago
I've played with the idea of converting my bash path scripts to Janet, but haven't had the time yet. Have you experienced any downsides of using it for your optimization scripts?
- matvore 5y ago
  I would say that if you're interested, go for it. My complaints about Janet are not too big. I feel like there are many ways to do some things, and they are all basically the same. Most of this excessive flexibility is inherited from Clojure. 1. It's never clear whether I need `cond` or can get by with `case` until I've waffled around a bit 2. I don't know whether to choose `if`, `and`, or `when`, for conditionals, because there are many times when all three would work. Also, if the condition expression is trivially negated (e.g. change '=' to '!=') then even `or` would work, making 4 choices. 3. It's hard to choose between `->` vs. manually-nested expressions. EDIT: formatting
  - actuallyalys 5y ago
    I'm pretty experienced with Clojure and here are my takes on those: 1. The Janet docs suggest `cond` as a replacement for if-if-else-else chains in other languages and `case` for `switch`-`case` blocks. That's a pretty good rule, although maybe you've already encountered that explanation? My main rule of thumb is that if the important value is "enum-y", representing a particular kind of thing or state, try `case`. If not, use `cond`. Neither Janet nor Clojure have enums (although you might be able to hack them in through macros or interop), so keywords usually serve that role. 2. I would prefer `when` to `if` because it's usually clearer what's going on. I usually don't use `and` in place of `if`. The trivial negation problem is an issue in basically any programming language that has `and`, `or`, and `not`, but it does add more options. Whether to use `and` or the equivalent `or`, I think your first instinct is often best. 3. I tend to favor threading macros (`->` and `->>`) when something is three or more functions nested and manually nested expressions for the rest. For a total beginner, I would actually suggest forgetting about the more specialized options until you're comfortable. In other words, just use `cond`, `if`, and manual nesting. (Obviously still use `and` within the branches of `cond` or `if`.)
    - matvore 5y ago
      Thanks for the tips. I will try to keep these in mind so I can stop thinking so much about trivialities. When I was using Java in my day job, I toyed with Clojure a bit and it was a pleasure. My favorite features were protocols and multi-arity functions.
    - saikyun 5y ago
      This is solid advice. :)
Karrot_Kream 5y ago
> Janet has os/ and file/ packages, as well as a PEG system which mostly stand in for the best features of Perl. Some low-level POSIX-specific operations (like daemonizing and forking) aren't practical but I can just use C for those. The README briefly mention the C API. How easy is it to use it, and how easy is it to "lift" results from the C API into Janet? (e.g. wrapping an fd from the POSIX API into a file object)
- matvore 5y ago
  Good question :) I actually haven't had a good excuse to use the C API yet. When I need C I just code the entire tool in C, or use IPC.
  - cjohnson318 5y ago
    Dumb question: Is IPC Inter-Process Communication? Or is it an unrelated tool?
    - matvore 5y ago
      > Is IPC Inter-Process Communication? Or is it an unrelated tool? The former. Piping with the shell, or C subprocess hosted by the Janet script, or vice-versa.
- saikyun 5y ago
  It's easy to treat any C struct as an abstract object in Janet, then have functions that do specific things (e.g. write to the file, read from it, etc). You have to write some manual code, but it's generally not too bad.
petre 5y ago
I've also played with it but it's still feels like a toy language? Not particulary fast and also the messages are not particulary useful when you make syntax errors. Some aspects of it are nice though. If you come from imperative programming background, it's easier to write code in Janet compared to Scheme. Easier to use than Racket, but then again Racket has lots of features and libraries: PEG, regexps, pattern matching, you name it. So I feel like my time is better invested learning Racket instead?
- matvore 5y ago
  I wasn't looking for something fast, as I'm happy to write some code in C anyway for something performance-sensitive, and most of the stuff I was going to write in Janet would be for interactive use. I was more interested in having a simple VM and a language that wasn't piling on new features every release like mainstream blub languages. I also wanted a language that gave a straightforward mental model without an opinionated philosophy that tried to protect me from mutability and other real-world things (hence I didn't really want to go with Haskell and ~purely functional languages). FWIW I also think the syntax errors in Janet are somewhat hard to grok. > So I feel like my time is better invested learning Racket instead? I think it depends. If you want a language you can always rely on for 99% of use cases, something that covers many bases makes sense. For me, I wanted more of a fill-in-the-gaps language where neither C nor /bin/sh scripting make sense (e.g. stuff I may run on Windows or something heavy in string-handling).

jhgb 5y ago

Have you perchance tried Gerbil as well?

matvore 5y ago
I did not hear of it before. Glancing at the website, it looks rather appealing (simple language, C-friendly FFI) but I don't see anything about using Gerbil in the shebang line for scripting purposes? I may give it a closer look sometime.

harryvederci 5y ago

I've played with the idea of converting my bash path scripts to Janet, but haven't had the time yet. Have you experienced any downsides of using it for your optimization scripts?

matvore 5y ago
I would say that if you're interested, go for it. My complaints about Janet are not too big. I feel like there are many ways to do some things, and they are all basically the same. Most of this excessive flexibility is inherited from Clojure. 1. It's never clear whether I need `cond` or can get by with `case` until I've waffled around a bit 2. I don't know whether to choose `if`, `and`, or `when`, for conditionals, because there are many times when all three would work. Also, if the condition expression is trivially negated (e.g. change '=' to '!=') then even `or` would work, making 4 choices. 3. It's hard to choose between `->` vs. manually-nested expressions. EDIT: formatting
- actuallyalys 5y ago
  I'm pretty experienced with Clojure and here are my takes on those: 1. The Janet docs suggest `cond` as a replacement for if-if-else-else chains in other languages and `case` for `switch`-`case` blocks. That's a pretty good rule, although maybe you've already encountered that explanation? My main rule of thumb is that if the important value is "enum-y", representing a particular kind of thing or state, try `case`. If not, use `cond`. Neither Janet nor Clojure have enums (although you might be able to hack them in through macros or interop), so keywords usually serve that role. 2. I would prefer `when` to `if` because it's usually clearer what's going on. I usually don't use `and` in place of `if`. The trivial negation problem is an issue in basically any programming language that has `and`, `or`, and `not`, but it does add more options. Whether to use `and` or the equivalent `or`, I think your first instinct is often best. 3. I tend to favor threading macros (`->` and `->>`) when something is three or more functions nested and manually nested expressions for the rest. For a total beginner, I would actually suggest forgetting about the more specialized options until you're comfortable. In other words, just use `cond`, `if`, and manual nesting. (Obviously still use `and` within the branches of `cond` or `if`.)
  - matvore 5y ago
    Thanks for the tips. I will try to keep these in mind so I can stop thinking so much about trivialities. When I was using Java in my day job, I toyed with Clojure a bit and it was a pleasure. My favorite features were protocols and multi-arity functions.
  - saikyun 5y ago
    This is solid advice. :)

Karrot_Kream 5y ago

> Janet has os/ and file/ packages, as well as a PEG system which mostly stand in for the best features of Perl. Some low-level POSIX-specific operations (like daemonizing and forking) aren't practical but I can just use C for those. The README briefly mention the C API. How easy is it to use it, and how easy is it to "lift" results from the C API into Janet? (e.g. wrapping an fd from the POSIX API into a file object)

matvore 5y ago
Good question :) I actually haven't had a good excuse to use the C API yet. When I need C I just code the entire tool in C, or use IPC.
- cjohnson318 5y ago
  Dumb question: Is IPC Inter-Process Communication? Or is it an unrelated tool?
  - matvore 5y ago
    > Is IPC Inter-Process Communication? Or is it an unrelated tool? The former. Piping with the shell, or C subprocess hosted by the Janet script, or vice-versa.
saikyun 5y ago
It's easy to treat any C struct as an abstract object in Janet, then have functions that do specific things (e.g. write to the file, read from it, etc). You have to write some manual code, but it's generally not too bad.

petre 5y ago

I've also played with it but it's still feels like a toy language? Not particulary fast and also the messages are not particulary useful when you make syntax errors. Some aspects of it are nice though. If you come from imperative programming background, it's easier to write code in Janet compared to Scheme. Easier to use than Racket, but then again Racket has lots of features and libraries: PEG, regexps, pattern matching, you name it. So I feel like my time is better invested learning Racket instead?

matvore 5y ago
I wasn't looking for something fast, as I'm happy to write some code in C anyway for something performance-sensitive, and most of the stuff I was going to write in Janet would be for interactive use. I was more interested in having a simple VM and a language that wasn't piling on new features every release like mainstream blub languages. I also wanted a language that gave a straightforward mental model without an opinionated philosophy that tried to protect me from mutability and other real-world things (hence I didn't really want to go with Haskell and ~purely functional languages). FWIW I also think the syntax errors in Janet are somewhat hard to grok. > So I feel like my time is better invested learning Racket instead? I think it depends. If you want a language you can always rely on for 99% of use cases, something that covers many bases makes sense. For me, I wanted more of a fill-in-the-gaps language where neither C nor /bin/sh scripting make sense (e.g. stuff I may run on Windows or something heavy in string-handling).