There is also fennel, earlier language originally by same developer, that is similar, but compiles to, and is fully implemented in, Lua. No standard library of its own so missing many nice things like the parser library from janet, but it is good for writing scripts for things that embed Lua.
This post is refreshing - smells of the pre AI discussions on the internet. A new language, a new syntax, heavy debate with people who have spent years writing code. I think someone should start a community online where AI isnt allowed.
> I think someone should start a community online where AI isnt allowed.
In case you haven't followed the saga, the latest[1] digg.com relaunch failed because they couldn't deal with the bot onslaught [2]. Whoever finds a reliable way to keep AI out of an online community first is likely to become a very rich person.
[1] Second-to-last, actually, seeing as there seems to be a new homepage right now.
> In case you haven't followed the saga, the latest[1] digg.com relaunch failed because they couldn't deal with the bot onslaught [2]
Given that they wrote their goodbye post using LLMs and gave up after such a short amount of time, I don't take that at face value the same way I don't believe AI layoffs
Perhaps requiring webauthn credential for any post/comment with a whitelist of permitted webauthn hardware devices which must have touch/interaction enabled.
I'd have to read the FIDO specs, however the only place I've seen webauthn hardware pinning in the wild is with Azure AD/Entra which is ostensibly based on token GUID. If this is the only enforcement mechanism available, it's spoofable.
FIDO tokens are designed to able (if authorized by the software, your web browser typically offers a pop-up where you can decline this) to prove their membership of a batch of tokens, but not their individual identity.
The Entra feature you thinking of lets somebody say "Only things which can prove they're in this list work". This could make sense if you, as their employer, issue every employee a custom DoodadCorp Doodad FIDO key and so you don't want somebody's Yubikey or off-brand generic device to work. It's stupid and you shouldn't do it in other scenarios, but your "this is how we detect humans" idea is arguably a scenario where that could make sense.
[Edited to add: This feature is called "Attestation"]
Isn’t the solution high-quality identity verification? There are piles of digital identity companies out there. They make money selling to banks for KYC compliance. Heck, there are background check as a service companies designed to add trust to gig economy platforms.
I used to think that a small payment could accomplish the same thing, but X selling blue check marks proved that doesn’t help much. Well, at least it’s a much weaker signal than the previous curated version.
The challenge is any barrier to entry high enough to discourage motivated spammers is also high enough to discourage casual users. That disrupts the network effects you’ve traditionally needed to bootstrap a social website.
If I was trying to get a new social site off the ground right now, I would try:
1) secure a good brand from the pre-AI era. Twitter, Digg, Friendster, MySpace. Something that motivates a first look.
2) Require third party identity verification on sign up, configured so the social site is never the custodian of PII, though require enough demographics to support high-value advertising later. Verification is free to the user, ideally provide multiple verification options- one US and one EU at minimum.
3) Target a few core communities and invest. Find the people who moderate historically great subreddits, were active in twitter communities during the good years, etc. get them in your platform. Maybe even pay them.
That should be enough to tell you if it’s going to work or not.
This is something I think about a lot, especially how one could pull it off without tearing down anonymity online. Having some sort of "proof of humanity" is a hard problem to solve.
Heh, every time you show a average developer lisp for the first time the reaction is the same. Little do they know conditionals, GC, REPLs, macros and more comes from the syntax and language dreamed up in the 50s/60s.
I don't see why Lisp's history would necessarily imply the family is worth learning in 2026. What (other than macros) do lisps offer that other modern languages don't?
You don’t program in Lisp, do you? I used to be confused by the smug Lisp weenies. Now I am one. And the difficult thing I’ve found over the years is that Lisp is sort of unexplainable. You either “get it” or you don’t. Yes, it has macros, but macros are a bit overrated. I’ve been programming in Lisp for decades and I rarely write macros. I think the thing that is difficult to convey is how powerful Lisp’s core execution environment is while at the same time being just a page of code that a CS undergraduate can understand. Literally everything else is a library. And those libraries can create syntax, generate code on the fly, and do many other powerful things. But most people won’t “get it” until they take the plunge. I didn’t. Until I did. And now, I don’t feel a need to defend Lisp at all. It won’t go away. You can’t kill it. The folks that “get it” will always have it, and those that don’t “get it” will reach for their Blub language again and again. Such is the way of the world.
The amazing thing about AI is that you don’t even need AI superfans to shoehorn it into a conversation that doesn’t even touch on AI. Detractors will do it for them.
It’s been a few months, but I built a tool by Janet lang to communicate with an LLM via HTTP. Of course, I probably had Claude Code write it for me. It turned out better than I expected.
I was really impressed by how small the executable file was. I’d only ever done web development with Node.js up until then.
At first I said "what" out loud, since SETQ doesn't create bindings, it only updates them then I read the doc (https://janet-lang.org/docs/bindings.html) and the author is indeed wrong ("bindings created with def are immutable"). He probably meant "SETQ is set".
I really want to like Janet, as it seems to be the sweet spot between Guile, Tcl and CL (minus the speed/maturity of SBCL) but I have a visceral reaction to square brackets (so vectors) being used in lambdas and control flow operators. Same as Clojure, I simply can't get over it. Maybe I will with enough effort?
Also, what's the current LSP/SLIME status? Really important these days.
A C macro with literals that lacks referential transparency:
#define MULTIPLY(x, y) x * y
int result = MULTIPLY(2 + 3, 4); // 14
Not knowing what something means does not make it bad, which is what I'm assuming you meant given how you phrased your sentence.
Having a shared language of patterns and problems that occur in programming is a good thing. Ridiculing such terminology on the basis of "that group of programmers sure are weird" is pointless and counter productive.
Pretty straight-forward, as the world as we perceive it is made of objects with attributes, interacting with each other via their methods. OOP easily fits the brain of the average person in the street.
somehow i also never got the idea around these languages like lisp. I remember i studied them in school - but i quickly forgot and never got around to relearning it.
It took me probably 5 years of writing Clojure before it clicked. Once you get used to structural editing and repl driven development, it’s really hard to go back to syntactic languages.
It’s kind of like in treesitter style editing, where you can “swap these two arguments,” “select this function,” “wrap this in a try block” with a single keyboard command… but way more standardized and granular. Plus with the ability to execute anything you highlight
All that and then you realize you can store code as data (since it’s just a data structure) and run data as code.
I think most programmers don’t realize how arbitrary the difference is between code and data until they get used to using LISP.
Spot on. For me, it clicked with Common Lisp, 15 years after I graduated from university. Now, Clojure is my daily driver. And it’s extremely difficult to explain to people. I’ve gotten to the point where I don’t even try. You’re right about all the things you mentioned. Once you discover structural editing, everything else seems primitive, on the level of cavemen playing with rocks. But it’s not just one feature that makes Lisp better. It’s all of it which interrelates and creates a powerful synergy (I hate that word, but in this case it’s appropriate) that just isn’t matched by anything else. There are other languages that have a similar vibe, notably Forth and Prolog, but they are often misunderstood, too. Honestly, that’s my real test of whether someone is a senior programmer: do they understand and at least have an appreciation for these languages, even if they don’t program in them everyday.
The idea is that instead of having to learn tens of different syntactic constructs with subtle and often arbitrary differences, you just have parentheses and use them to build everything.
This is such a undervalued benefit, once you've learned s-expressions, you can basically learn a bunch of languages without having to learn completely new syntax. It'll be slightly different, with different idioms and names, but a hell of a lot easier than doing the same across every "It's like C but 50% of the syntax is different actually" language out there, which is most of them.
Is the syntax really the stumbling block for most languages? Would Rust's lifetimes or Swift's isolation rules be easier if they used more parens? Are the scoping rule differences between Emacs Lisp and Scheme easier to comprehend because the syntax is similar?
Yes, a commonly occurring stumbling block for me is trying to use one language's syntax while actually programming in another, especially when it comes to all the Algol/C-like language, I probably mix things on a daily basis.
The concepts would be easier to grok up front if they just used normal function calls instead of "And now for this special syntax that only exists for this particular feature" which just adds more things to remember, instead of just the concepts themselves.
Yes it is, because as soon as programmers step out of the most basic language level (which is kinda similar in most mainstream languages) there's a bunch of wildly different concepts, with wildly different ways of writing them. Writing them in isolation might be manageable, but it's combining them effectively that gets hairy very quickly, unless one is very experienced in said language. But then, translating that to OTHER languages becomes a bar that is too high!
Probably depends on whom you are asking. For me the essence is (1) having functions or procedures as the basic building blocks, not classes. (2) Having all the utility and higher order functions you need to deal with the functions and procedures first idea. (3) Having a very powerful syntax, that allows great semantic editing and is never ambiguous. Oh and can actually be extended in useful ways, without having to wait for a committee to decide upon "the one syntax to rule them all".
Frankly, though, I think lispy community has benefited from being smaller. For example, even though the now ancient Design Patterns already warned programmers to prefer composition over inheritance, the OO programmers still created 15 levels deep hierarchies.
> These lisp guys really get excited over very abstract things. If you say this to an average person on the street they will probably try to run away.
Referential transparency is a funny name for a very powerful feature which helps you understand what the program does better, it's not a deeply abstract thing. Don't let the name scare you.
You could ask "why the funny name"? Well, specialized professionals use specialized jargon, even for "normal stuff". It's unreasonable to expect otherwise. Car mechanics also have weird names for car parts that are absolutely essential for the car and not that hard to understand if they explained them to you.
> Instead of regular expressions, Janet’s text wrangling is based around parsing expression grammars. Parsing expression grammars are simpler, more powerful, and more predictable than regular expressions.
I would dispute that this is the case. In PEGs, alternatives are not commutative, unlike in regular expressions. This can lead to quite frustrating debugging. While a valid choice, the advantage over REs is overstated.
The non-commutavity is a feature, not a bug. It allows you to have clearly defined parsing for grammars that would traditionally be considered ambiguous.
PEGs are just soooo much easier to read than regexes for anything more complex than a few words or single line matching. REs are a hammer that tempts people to see everything as a nail, but once one progresses beyond that phase one usually wants as few REs as possible.
Came here for this comment. Janet would score positively in my mind if the evolutionary dead-end PEG were replaced with a grammar parser that is known to work under all circumstances.
I've been drawn into the Janet posts that surface every once in a while here on HN, but found the otherwise highly praised "Janet for Mortals", not being for mortals at all.
> I've been drawn into the Janet posts that surface every once in a while here on HN, but found the otherwise highly praised "Janet for Mortals", not being for mortals at all.
I'm surprised: the language is very straightfoward, simple, very few rules to remember. It's a Lisp but with a very small surface area.
I mean, compared to other languages, Janet really is easier to lean, so I'm surprised that the book for it is difficult (did not read the book, but familiar-ish with the language. I don't have anything but praise for it, TBH).
Seems some of the listed advantages for Janet would also apply for tcl (small/simple, easy to learn, embeddable, usable as a shell, great for domain specific languages). It would be interesting, to me at least, to see a fan of Janet compare the two.
I've only used Tcl briefly, mostly for automation which it's great at. But it's a Algol-like imperative language, doesn't have any type of macros and makes everything based on strings (which makes sense for automation) instead of lists, with all the tradeoffs that comes with.
It seems easier to figure out what the similarities are, because I think they're pretty few, they seem to differ more than they are similar.
Thought this might be about JANET, the rationale for which I have never really understood. The wikipedia article on it is not very explanatory: https://en.wikipedia.org/wiki/JANET
janet has replaced sh, python, awk, etc. for me, for system scripts over a certain length! it has a very fast startup time (on my system, 1.4ms via hyperfine vs. 1ms for dash) for scripts (not compiled executables), and its sh-dsl module allows typing shell commands very elegantly, like ($ cmda w x | cmdb y z). the ability to load an image to debug is a big help, too. i've started using it very recently but it's probably one of my favorite languages now, and the only other lisp i've used is mit scheme for sicp.
I used Hy for a long time, then tried Janet, and ultimately realized that I wanted more batteries included but didn't want Python... So I forked https://github.com/rcarmo/go-joker and am tinkering with it until it does all I want.
Janet is ALMOST an incredible tool...but what I want is a very clear bifurcation between the standard library's stateful mutating procedures, and stateless value-returning functions. I ran into that wall hard trying to make something non-trivial.
It also turns out that the mix is due to the standard library leaning on raw C loop iterations underneath whenever it can. Which is great! But it confuses the library's interface paradigms.
Pretty compelling, especially "Janet does not adhere to the ancient customs. CAR is called first. PROGN is called do. LAMBDA is fn, and SETQ is def." - a sign of good sense for sure!
How fast is it?
Also my main objection to Lisps is still the horrible bracket syntax. Yes it's unambiguous and easy to parse, but it's HORRIBLE to read and edit. I wish this project had been a success (or something similar to it): https://readable.sourceforge.io/
Also I don't think static typing is really optional for me at this point.
> Pretty compelling, especially "Janet does not adhere to the ancient customs. CAR is called first. PROGN is called do. LAMBDA is fn, and SETQ is def." - a sign of good sense for sure!
Just FYI, many of these are also done in Scheme and its derivative Racket. They kept lambda (but even Python did that), but progn -> begin, setq -> set!, car -> first, and so on.
> 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 have pretty mixed feelings at this point. I don’t mind it for normal programming, but when I do numerical programming (physics models, etc.) you often get extremely long and verbose expressions that are IMO difficult to parse compared to the math-like infix operator notation used in other languages.
I definitely prefer s-exps over both xml and json myself too!
Interesting question. Much of the difficulty does stem from mentally translating back and forth between conventional notation and s-exps too, since you can’t really avoid the standard notation when reading and writing math and physics papers. And current-day math and physics notation has been optimized to some extent for the infix notation; perhaps one would have invented more expressive higher-order functions or macros to denote s-exp math if that was what everyone used for centuries.
I think also a lot of my objections could be worked around if one simply had a "math" macro that evaluates infix math notation as a DSL, similarly to how the CL "loop" macro does a DSL for iteration.
Actually not all those are ancient customs, and not all that Janet uses is newer.
In the first description of the language LISP, from March 1959 (AIM-008), John McCarthy had used the names "first" and "rest", instead of what later will be called "CAR" and "CDR".
The names of "CAR" and "CDR" appear to have come from the students who worked at the practical implementation of the LISP interpreter on an IBM 704, and unfortunately we have remained stuck with them, like also with other features that were intended only for a temporary use, until being replaced in the "final version" (which was abandoned).
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 for exploratory programming, scripting, and fun side projects.
Yeah I mean I guess if you have to use that syntax, it's nice to have a better editor for it. But IMO the existence of that tool clearly demonstrates that the syntax is pretty bad.
All C-derived languages (e.g. Java and Rust) have a bad syntax, with tons of superfluous parentheses and many other superfluous tokens, like semicolons or commas.
This normally matters very little, because a good editor will always insert a complete template whenever you type something like "if", "for", "while" etc.
Most programmers are blind to the syntax defects with which they are accustomed and they notice only the syntax defects with which they are unfamiliar.
I would prefer a language with a good syntax, but unfortunately which programming languages have survived in widespread use has a poor correlation with the technical qualities of a language and especially a really negligible correlation with how good its syntax was.
Out of those renames, I agree with car->first and progn->do. setq is ugly, but I think using def is maybe questionable. lambda I would have just kept the same.
If it was called [Something] Lisp, Lisp enthusiasts would complain that it’s not a lisp because it does not use linked lists as the primary data structure.
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 people love it and many people hate it and that's fine, but at a certain point wouldn't it feel repetitive for statement like this and I am unsure of how healthy discussion about programming concepts can be done this way.
There are so many interesting things from lisp-y languages like Janet and Julia is technically lisp-y too and Julia's compilation to GPU is awesome and Nim too which can compile to C/C++/JS!
It's just so many interesting concepts overall in programming that paranthesis don't seem a concern to me as the underlying concept can be translated to something else, like sandboxing feature, transpilation to GPU or multiple targets!
And there are many unique concepts in non-lispy languages like golang (cross-compat, portability with static binaries), elixir (concurrency!) too.
It's just good to see the amount of innovation within programming from all spheres of influence :-D
While I do not like the excess of parentheses of LISP and similar languages, their syntax is very consistent and predictable. Moreover, while LISP has an excess of parentheses, it omits a greater number of commas that are required in many other programming languages.
I am much more annoyed by the random syntax inconsistencies of most popular programming languages, which are either caused by original language design mistakes, or, more frequently, by the late addition of some features that were not planned in the original language, so they had to be squeezed in with the help of various ugly workarounds.
While during the last years I have not used much LISP like languages, there have been times when I used them a lot, for several years, in scripting applications, e.g. the LISP variant of old AutoCAD, the Scheme-like scripting language of the Cadence EDA applications, or the scsh Scheme dialect that is usable for replacing UNIX shell scripts.
In all cases, these languages allowed a greater productivity associated with rarer bugs than the more popular scripting languages, like Python, Perl, TCL, bash.
While aesthetically I might prefer the look of a Python program, for solving a practical production problem I would prefer to write scripts in one of the LISP derivatives. Obviously, the productivity in various programming languages depends a lot on individual preferences and previous experiences.
It should be noted by all those who believe that the LISP-derived languages have too many parentheses, that the C programming language and all languages with syntax derived from it, like Java or Rust, have a great excess of parentheses in comparison with the older languages that had better designed syntaxes, e.g. ALGOL 68 or IBM PL/I.
For example, compare
for (i = 1; i <= 100; i += 5) { ... }
with
for i from 1 to 100 by 5 do ... od
or
if ( ... ) { ... } else { ... }
with
if ... then ... else ... fi
The first example has 12 syntactic tokens instead of the minimum required, which is 6.
The second example has 8 syntactic tokens instead of the minimum required, which is 4.
If I cannot have a decent programming language with a minimum number of parentheses, I would rather have a programming language where all the places that need parentheses are predictable, like in LISP, instead of having a language like C and its derivatives, which require parentheses in random places, for no good reason at all.
Would be nice if some kind of "scripting" language
be as fast as a compiled language, but without
ruining the syntax. Just about 99% of the languages
that are shown, have a horrible syntax. Syntax is not
everything, but most language designers don't understand
that syntax also matters. So tons of horrible languages
emerge. Nobody will use those languages, so 99% of them
will die off quickly.
can't there theoretically be a language which transpiles to Janet to get all the benefits without additional paranthesis too?
Not sure if such transpilation would have a perf hit though, I hope somebody responds who knows about it more.
I don't deny that syntax matters itself too but there are some ideas of janet like sandboxing and other features which seem to me to be worth implementing in other languages too.
Personally, I would be really interested in a language like lua/wren which can transpile to Janet too.
https://fennel-lang.org/
In case you haven't followed the saga, the latest[1] digg.com relaunch failed because they couldn't deal with the bot onslaught [2]. Whoever finds a reliable way to keep AI out of an online community first is likely to become a very rich person.
[1] Second-to-last, actually, seeing as there seems to be a new homepage right now.
[2] https://www.techspot.com/news/111698-digg-relaunch-fails-two...
I believe it’s the opposite: You have to pay competent human moderators. Like here on HN.
Plus "AI" is a spectrum, with "the AI fixed a typo for me" at one end, and "the AI writes my posts for me" at the other.
Given that they wrote their goodbye post using LLMs and gave up after such a short amount of time, I don't take that at face value the same way I don't believe AI layoffs
I'd have to read the FIDO specs, however the only place I've seen webauthn hardware pinning in the wild is with Azure AD/Entra which is ostensibly based on token GUID. If this is the only enforcement mechanism available, it's spoofable.
The Entra feature you thinking of lets somebody say "Only things which can prove they're in this list work". This could make sense if you, as their employer, issue every employee a custom DoodadCorp Doodad FIDO key and so you don't want somebody's Yubikey or off-brand generic device to work. It's stupid and you shouldn't do it in other scenarios, but your "this is how we detect humans" idea is arguably a scenario where that could make sense.
[Edited to add: This feature is called "Attestation"]
I used to think that a small payment could accomplish the same thing, but X selling blue check marks proved that doesn’t help much. Well, at least it’s a much weaker signal than the previous curated version.
The challenge is any barrier to entry high enough to discourage motivated spammers is also high enough to discourage casual users. That disrupts the network effects you’ve traditionally needed to bootstrap a social website.
If I was trying to get a new social site off the ground right now, I would try:
1) secure a good brand from the pre-AI era. Twitter, Digg, Friendster, MySpace. Something that motivates a first look.
2) Require third party identity verification on sign up, configured so the social site is never the custodian of PII, though require enough demographics to support high-value advertising later. Verification is free to the user, ideally provide multiple verification options- one US and one EU at minimum.
3) Target a few core communities and invest. Find the people who moderate historically great subreddits, were active in twitter communities during the good years, etc. get them in your platform. Maybe even pay them.
That should be enough to tell you if it’s going to work or not.
does seem like more things will have to go this way though
This is something I think about a lot, especially how one could pull it off without tearing down anonymity online. Having some sort of "proof of humanity" is a hard problem to solve.
How is the syntax new?
It looks like lispy - see the outer parens in the examples given.
I was really impressed by how small the executable file was. I’d only ever done web development with Node.js up until then.
shout out to one modern feature: sandbox
"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."
https://janet-lang.org/api/misc.html#sandbox
At first I said "what" out loud, since SETQ doesn't create bindings, it only updates them then I read the doc (https://janet-lang.org/docs/bindings.html) and the author is indeed wrong ("bindings created with def are immutable"). He probably meant "SETQ is set".
I really want to like Janet, as it seems to be the sweet spot between Guile, Tcl and CL (minus the speed/maturity of SBCL) but I have a visceral reaction to square brackets (so vectors) being used in lambdas and control flow operators. Same as Clojure, I simply can't get over it. Maybe I will with enough effort?
Also, what's the current LSP/SLIME status? Really important these days.
When round brackets are used, the first element in the list defines how the rest of the list is interpreted, for example:
(func a b c) — run a function with its parameters
(macro x y z) — expand a macro with its parameters
([p q r] …) — “bare” function body that starts with a vector of parameters, and executable forms follow.
Square brackets are used where elements are the same “kind”, and the first one is not special, e.g.:
(defn f [a b c] …) — a collection of same-kind parameters, the first parameter is not special
(let [a 1 b 2] …) — a collection of bindings, the first binding is not special
The only exception that comes to mind is grouping multiple matching elements in `case`, but it for ergonomics.
Once I got the logic, when which is used, I changed my mind, and ever since I’ve felt it’s beautiful.
These lisp guys really get excited over very abstract things. If you say this to an average person on the street they will probably try to run away.
A C macro with literals that lacks referential transparency:
Not knowing what something means does not make it bad, which is what I'm assuming you meant given how you phrased your sentence.Having a shared language of patterns and problems that occur in programming is a good thing. Ridiculing such terminology on the basis of "that group of programmers sure are weird" is pointless and counter productive.
It’s kind of like in treesitter style editing, where you can “swap these two arguments,” “select this function,” “wrap this in a try block” with a single keyboard command… but way more standardized and granular. Plus with the ability to execute anything you highlight
All that and then you realize you can store code as data (since it’s just a data structure) and run data as code.
I think most programmers don’t realize how arbitrary the difference is between code and data until they get used to using LISP.
The concepts would be easier to grok up front if they just used normal function calls instead of "And now for this special syntax that only exists for this particular feature" which just adds more things to remember, instead of just the concepts themselves.
Frankly, though, I think lispy community has benefited from being smaller. For example, even though the now ancient Design Patterns already warned programmers to prefer composition over inheritance, the OO programmers still created 15 levels deep hierarchies.
Referential transparency is a funny name for a very powerful feature which helps you understand what the program does better, it's not a deeply abstract thing. Don't let the name scare you.
You could ask "why the funny name"? Well, specialized professionals use specialized jargon, even for "normal stuff". It's unreasonable to expect otherwise. Car mechanics also have weird names for car parts that are absolutely essential for the car and not that hard to understand if they explained them to you.
I would dispute that this is the case. In PEGs, alternatives are not commutative, unlike in regular expressions. This can lead to quite frustrating debugging. While a valid choice, the advantage over REs is overstated.
[1] https://github.com/sogaiu/small-peg-tracer
I'm surprised: the language is very straightfoward, simple, very few rules to remember. It's a Lisp but with a very small surface area.
I mean, compared to other languages, Janet really is easier to lean, so I'm surprised that the book for it is difficult (did not read the book, but familiar-ish with the language. I don't have anything but praise for it, TBH).
I had that with Haskell. Although, while Haskell is too hard for me, I actually like its syntax.
Janet seems to be Lisp 2.0, so the syntax is lispy.
https://janetdocs.org/tutorials
https://janet.guide/ (the author's one)
It seems easier to figure out what the similarities are, because I think they're pretty few, they seem to differ more than they are similar.
https://bauble.studio
https://toodle.studio
Those two fascinating art tools got me very excited about Janet a while back.
[0] https://hylang.org/
It also turns out that the mix is due to the standard library leaning on raw C loop iterations underneath whenever it can. Which is great! But it confuses the library's interface paradigms.
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://readable.sourceforge.io/
Also I don't think static typing is really optional for me at this point.
Just FYI, many of these are also done in Scheme and its derivative Racket. They kept lambda (but even Python did that), but progn -> begin, setq -> set!, car -> first, and so on.
> 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 have pretty mixed feelings at this point. I don’t mind it for normal programming, but when I do numerical programming (physics models, etc.) you often get extremely long and verbose expressions that are IMO difficult to parse compared to the math-like infix operator notation used in other languages.
I wonder if we were raised on tree based algebra if math would be easier to do, or harder.
Like, solve for x.
Though this isn't too bad.Interesting question. Much of the difficulty does stem from mentally translating back and forth between conventional notation and s-exps too, since you can’t really avoid the standard notation when reading and writing math and physics papers. And current-day math and physics notation has been optimized to some extent for the infix notation; perhaps one would have invented more expressive higher-order functions or macros to denote s-exp math if that was what everyone used for centuries.
Perhaps this exists already somewhere?
In the first description of the language LISP, from March 1959 (AIM-008), John McCarthy had used the names "first" and "rest", instead of what later will be called "CAR" and "CDR".
The names of "CAR" and "CDR" appear to have come from the students who worked at the practical implementation of the LISP interpreter on an IBM 704, and unfortunately we have remained stuck with them, like also with other features that were intended only for a temporary use, until being replaced in the "final version" (which was abandoned).
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 for exploratory programming, scripting, and fun side projects.
I use Parinfer, which allows me to edit Janet as if it was an indentation-based language.
This normally matters very little, because a good editor will always insert a complete template whenever you type something like "if", "for", "while" etc.
Most programmers are blind to the syntax defects with which they are accustomed and they notice only the syntax defects with which they are unfamiliar.
I would prefer a language with a good syntax, but unfortunately which programming languages have survived in widespread use has a poor correlation with the technical qualities of a language and especially a really negligible correlation with how good its syntax was.
https://docs.racket-lang.org/sweet/index.html
A humourous clip: https://youtu.be/etJ6RmMPGko?si=W98LdG1jDdUCXsHV
> Why is it called "Janet"? Janet is named after the almost omniscient and friendly artificial being in The Good Place
https://github.com/janet-lang/janet#why-is-it-called-janet
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 people love it and many people hate it and that's fine, but at a certain point wouldn't it feel repetitive for statement like this and I am unsure of how healthy discussion about programming concepts can be done this way.
There are so many interesting things from lisp-y languages like Janet and Julia is technically lisp-y too and Julia's compilation to GPU is awesome and Nim too which can compile to C/C++/JS!
It's just so many interesting concepts overall in programming that paranthesis don't seem a concern to me as the underlying concept can be translated to something else, like sandboxing feature, transpilation to GPU or multiple targets!
And there are many unique concepts in non-lispy languages like golang (cross-compat, portability with static binaries), elixir (concurrency!) too.
It's just good to see the amount of innovation within programming from all spheres of influence :-D
I am much more annoyed by the random syntax inconsistencies of most popular programming languages, which are either caused by original language design mistakes, or, more frequently, by the late addition of some features that were not planned in the original language, so they had to be squeezed in with the help of various ugly workarounds.
While during the last years I have not used much LISP like languages, there have been times when I used them a lot, for several years, in scripting applications, e.g. the LISP variant of old AutoCAD, the Scheme-like scripting language of the Cadence EDA applications, or the scsh Scheme dialect that is usable for replacing UNIX shell scripts.
In all cases, these languages allowed a greater productivity associated with rarer bugs than the more popular scripting languages, like Python, Perl, TCL, bash.
While aesthetically I might prefer the look of a Python program, for solving a practical production problem I would prefer to write scripts in one of the LISP derivatives. Obviously, the productivity in various programming languages depends a lot on individual preferences and previous experiences.
It should be noted by all those who believe that the LISP-derived languages have too many parentheses, that the C programming language and all languages with syntax derived from it, like Java or Rust, have a great excess of parentheses in comparison with the older languages that had better designed syntaxes, e.g. ALGOL 68 or IBM PL/I.
For example, compare
with or with The first example has 12 syntactic tokens instead of the minimum required, which is 6.The second example has 8 syntactic tokens instead of the minimum required, which is 4.
If I cannot have a decent programming language with a minimum number of parentheses, I would rather have a programming language where all the places that need parentheses are predictable, like in LISP, instead of having a language like C and its derivatives, which require parentheses in random places, for no good reason at all.
Although, this here is a good idea:
"pass values from compile-time to run-time"
Would be nice if some kind of "scripting" language be as fast as a compiled language, but without ruining the syntax. Just about 99% of the languages that are shown, have a horrible syntax. Syntax is not everything, but most language designers don't understand that syntax also matters. So tons of horrible languages emerge. Nobody will use those languages, so 99% of them will die off quickly.
Not sure if such transpilation would have a perf hit though, I hope somebody responds who knows about it more.
I don't deny that syntax matters itself too but there are some ideas of janet like sandboxing and other features which seem to me to be worth implementing in other languages too.
Personally, I would be really interested in a language like lua/wren which can transpile to Janet too.