Rendered at 10:36:03 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
janetacarr 4 days ago [-]
I have my qualms with Janet. Mostly, it's lack of package management versioning and lack of libraries in general (advanced HTTP routing, etc).
I do LOVE that Janet can create binaries with JPM, scripts, and is very portable. I once put the Janet programming language on the Playdate game console as POC.
I actually do enjoy writing Janet, but every time I do people think I created the language (I did not).
It let's you vendor deps and easily install modern Janet bundles without jpm.
Karrot_Kream 4 days ago [-]
If you want server side, as veqq says there's joy which implements its own lightweight http server. If you want a client, it's quite trivial to use the Janet C API to wrap libcurl or any other HTTP client. If you're open to LLM development have the LLM write the wrappers and write your actual logic in Janet.
veqq 4 days ago [-]
> 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.
cptmurphy 4 days ago [-]
TLS. There are some curl wrappers but last time I checked they did not work
cfiggers 4 days ago [-]
There's a few that don't work, but one works phenomenally well— CosmicToast/jurl is incredible (unless you're on Windows—the library as a whole does work on Windows but the build script doesn't have Windows instructions in it, you have to hack that yourself).
Besides the 2 the others shared, Joy does that too.
cod1r 3 days ago [-]
WUT UP YOU FRICKEN H-nvm.
i watch ur streams on twitch lol
1313ed01 4 days ago [-]
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.
Fennel really is great, and a great way to get into the clojure family. My biggest gripe with it is that debugging is the typical transpilation bed of needles. The bridge between Fennel and the Lua VM is super fragile, and it just doesn't have half the quality of the Janet debugger and REPL. It's a real shame, because Fennel is way more portable, and thanks to LuaJIT is capable of breaking SBCL's jaw, which is absolutely fucking insane. But the transpilation experience just completely kneecaps it imo. There are workarounds you can do, but even if you mess around with implementing a debug.setinfo you still run into less-than-fun edge cases like with match-blocks.
I think there's a lot of value in forking LuaJIT2 and reworking the debugging and error structures within to make it more suitable for language transparency. Doing so would make languages like Fennel much more attractive.
I gather that some features will be added to 2.1 but others only to 3.0.
totalperspectiv 3 days ago [-]
I thought he stopped working on LuaJIT? Is it back in active development?
radiator 3 days ago [-]
Well, looking at the commits, he has been regularly contributing for the last ten years at least. I don't know if he had stopped for a while.
JHonaker 4 days ago [-]
> capable of breaking SBCL's jaw
What exactly do you mean by this? Speed? Portability? Ease of use?
ux266478 4 days ago [-]
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? CLOS might actually end up falling behind here. Another area where SBCL will likely win out is when the hotpath is bottlenecked on string operations.
Where I'd say it advances into breaking SBCL's jaw is that the runtime, interpreter, jitter, etc. are all much smaller than SBCL's runtime and compiler. If you're looking for a complete system, I'd say SBCL wins out obviously. You're talking a world-class REPL, debugger, a high quality stdlib, etc. All it's missing is a text editor like LispWorks (emacs and pretty much every other FOSS Lisp editor I've seen is a massive downgrade.) With that in mind, SBCL is not something you embed in an application written in another language. The holy grail is getting something as fast as SBCL, as flexible as SBCL, but as a 50k loc self-contained runtime. LuaJIT is the reigning heavyweight champ there, so having a Lisp-adjacent language like Fennel running atop it is a pretty damn compelling idea.
Interestingly with regards to text editors, Lua doesn't have that problem technically. Lite-XL is dangerously close to being zmacs/LispWorks for Lua. Poetically, just like Lua it's fairly bare bones and requires extension to be a decent IDE. But the underlying structure is absolutely fantastic, being based around a fairly cohesive object model rather than coats of paint over text buffers.
kscarlet 3 days ago [-]
Can you tell a bit more about what is missing from Emacs SLIME when compared to LispWorks?
ux266478 3 days ago [-]
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 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.
It makes me sad that some-mthfka got some but perhaps not enough support and the effort stalled after a few months.
kscarlet 3 days ago [-]
> 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!
I agree GUI is awkward in Emacs/SLIME. I think the reason is there isn't a standardized GUI framework across the Lisp world. Otherwise people can make SLIME support 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.
This part I do not agree. Nowadays "text" in Emacs/SLIME is far from "raw text", there's button that respond to hover, with right click context menu, and can be copy and pasted. I recall some small quirks (like objects in inspector are not presentations) but the only reason they aren't fixed (yet) is nobody get bothered enough. There's rarely any fundamental limitation. After all, it wouldn't be fare to call LispWorks UI "dead pixels".
BTW I once wrote yet another over ambitious project < https://github.com/neomacs-project/neomacs > but it doesn't go anywhere either. People do not care enough, Emacs is good enough.
chamomeal 4 days ago [-]
Is fennel clojure-ish? I’m vaguely aware of it being a lisp, but I didn’t know it was clojure-ey. Pretty neat sounding!
veqq 4 days ago [-]
All new Lisps since ~2010 have been Clojure-y-: https://p.hagelb.org/new-lisps.html (Lone Lisp and LispE are the only exceptions and LispE still has _some_ Clojure features.)
ramblurr 4 days ago [-]
Always nice to see janet getting some attention.
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."
Those two fascinating art tools got me very excited about Janet a while back.
mackeye 4 days ago [-]
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.
iLemming 4 days ago [-]
> janet has replaced sh, python, awk, etc....
babashka did that for me.
yolkedgeek 4 days ago [-]
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.
iLemming 4 days ago [-]
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 you're dealing with data - any data. Clojure is incredibly data-driven, which wins me over Janet. I also reach out to nbb whenever I need to deal with Node. e.g. scraping scripts driven by Playwright.
Janet is great when you need tiny runtime or you're dealing with subprocess-heavy scripts - Janet feels closer to actual shell syntax; or when you have to embed it to C/C++ program.
Fennel is indispensable for any Lua - mpv, Hammerspoon, AwesomeWM and Neovim configs, etc.
veqq 4 days ago [-]
> Clojure is incredibly data-driven, which wins me over Janet.
I'm curious what differences you see? I've been all in on Janet, but barely used Clojure. What more data driven aspects does Clojure have .... offer? My mental model/assumption's always been that Janet's Clojure without JVM and (sadly) not so pure. I don't use any of Janet's C interop facilities. I'd love to know what I'm missing
iLemming 3 days ago [-]
> I'd love to know what I'm missing
afaik, Janet's immutable structs/tuples are flat copies - no structural sharing. Clojure uses HAMTs. So it's truly immutable by default - you'd transform data without intermediate allocations.
In Clojure, the standard library already knows about your data - it has the tools to group, index, validate, serialize, and transform maps/vectors/sets without you reinventing them. In Janet, you have the building blocks but it feels like you're assembling the furniture yourself.
The trade-off is that babashka adds ~200ms to cold start and can be pretty memory hungry, but god, Clojure is so nice to deal with data. For small scripts it may not matter. For processing log files or CSVs with millions of rows, it does.
mackeye 3 days ago [-]
this is good to know :) my use for janet hasn't involved much processing of external data but i'll keep bb in mind when the use case arises. thank you for the information!
yolkedgeek 3 days ago [-]
True. But for things that they all can do, normal scripting (replacing bash/powershell, etc.), creating CLI and TUI apps, I would like to do a comparison of them.
1. which one is more pleasant to write
2. which one has the better echo system and tooling
3. performance benchmarks
4. portability
a-french-anon 4 days ago [-]
> SETQ is def
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.
nlitened 4 days ago [-]
Square brackets’ use is very consistent and rather logical in how they are used in Clojure’s syntax.
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.
aquariusDue 3 days ago [-]
Huh, now it makes more sense for me too. Thank you!
a-french-anon 4 days ago [-]
Thanks a lot, that's a very interesting way of seeing it.
veqq 4 days ago [-]
You can... just not use square (and curly) brackets. Instead of `[1 2 3]` just write `(array 1 2 3)`. Instead of `(fn [x] (+ 1 x))` just write `(f (x) (+ 1 x))`. They are never necessary.
BoingBoomTschak 4 days ago [-]
Huh! So like some Schemes and Racket? Yet I must read them in code that isn't mine, which is a large part of the problem.
xigoi 4 days ago [-]
Not quitek in Scheme, parens and brackets are completely interchangeable.
iLemming 4 days ago [-]
> I have a visceral reaction to square brackets
Once you understand how destructuring works in Clojure, it then becomes obvious what role square-brackets play.
uka 4 days ago [-]
> But by allowing you to unquote literal functions, Janet makes it possible to write macros that are completely referentially transparent.
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.
fredrikholm 4 days ago [-]
> very abstract things
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.
uka 4 days ago [-]
Thank you for the lesson. Very productive of you and on point.
Now if you relaxed just a little bit - the world would be much nicer place.
bryanrasmussen 4 days ago [-]
you ever try to explain object oriented programming languages and their benefits to the "average person on the street"?
rambrrest 4 days ago [-]
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.
barrell 4 days ago [-]
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.
drob518 4 days ago [-]
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.
xigoi 4 days ago [-]
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.
embedding-shape 4 days ago [-]
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.
jurip 4 days ago [-]
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?
embedding-shape 4 days ago [-]
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.
lelanthran 4 days ago [-]
> Would Rust's lifetimes or Swift's isolation rules be easier if they used more parens?
For me, certainly. But it's not a matter of adding parens, it's more removing extra syntax.
bryanrasmussen 3 days ago [-]
well sometimes you get complaints in particular languages that someone has written code like they are a Java programmer, or their code is not rubyish enough, or pythonic enough, and so on.
So often people coming from one linguistic syntactical style express themselves in that style which makes their code in the new language less understandable or maintainable.
dragandj 4 days ago [-]
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!
iLemming 4 days ago [-]
[dead]
layer8 4 days ago [-]
That just moves the subtle and often arbitrary differences to the functions and macros you use.
xigoi 4 days ago [-]
The kind of subtle difference I’m talking about is that in C, you have to put a semicolon after struct {…} and do {…} while (…), but not after other curly brace constructs. What would be the analogue in Janet?
layer8 4 days ago [-]
The first one is pretty C-specific and for example doesn’t exist in Java. Similarly for the second one, the reason is that `while` is used for two different constructs, which for example isn’t the case in Rust. These are just accidental complexities stemming from unfortunate design decisions in C. Having a richer repertoire of syntactic constructs doesn’t by itself imply such complications.
My point was, replacing n syntactic constructs by n functions or macros doesn’t reduce the cognitive load of having to know how each construct works. To the contrary, one can argue that everything having the same syntactic form makes it more difficult to distinguish different classes of features.
xigoi 4 days ago [-]
> The first one is pretty C-specific and for example doesn’t exist in Java.
It was just an example, most languages have quirks like this. I don’t know about Java, but in Rust you have the turbofish operator, whose necessity stems from using the less-than sign as both an operator and a delimiter.
> My point was, replacing n syntactic constructs by n functions or macros doesn’t reduce the cognitive load of having to know each of them.
The difference is that if you don’t know a function/macro, you can just read its documentation. If you don’t know a syntactic construct, where do you look?
Another advantage is that if you want to create new functionality similar to existing language features, it won’t stick out like a sore thumb. For example, you could create an until loop:
(until (window-should-close)
(draw-screen))
# is equivalent to
(while (not (window-should-close))
(draw-screen))
In Rust, it would have to look completely different from a while loop:
until!(window_should_close(),
draw_screen());
// is equivalent to
while window_should_close() {
draw_screen();
}
zelphirkalt 4 days ago [-]
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".
> studied them in school - but i quickly forgot and never got around
Because industry lied to you, promising "simplicity and riches". The industry didn't just overcomplicate programming. It institutionalized the complication. Why? Because complexity is a moat.
Complex frameworks need certified experts. Certified experts charge more. Companies built around expertise need the complexity to persist. So the complexity gets marketed as sophistication.
They've promised: "Java/C# will get you hired anywhere", but you're hired to write xml (these days yaml). "OOP models the real world", they said. The real world doesn't have abstract factory visitors. "Design patterns make you senior", but you only learned workarounds for language deficiencies. "Learn the framework, get the job". Framework dies, you start over. "Specialization is valuable". you're now hostage to one ecosystem.
A programmer who understands fundamentals is dangerous to this system. The fundamentals:
- a function transforms input to output.
- composition builds complexity from simplicity.
- types describe what's possible.
- effects should be explicit.
And then you realize that Lisp is the skeleton key. All that above is Lisp, or came from Lisp. Every language is either: Lisp with different syntax, or C with different syntax, or arguing between the two.
If you learn Lisp, you don't learn a language. You learn what languages are. You're no longer a consumer of a programming language or two, or a few. You are native speaker in all of them.
skeledrew 4 days ago [-]
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.
iLemming 4 days ago [-]
> the world as we perceive it is made of objects
Of course easier to explain the "strategy pattern" to a florist, instead of saying "imagine a function that takes a function". Who the hell understands functions? Such a mind-bending concept, literally nobody really knows how they work. Einstein famously complained about it. Too bad he didn't know OOP - would've been so much easier. I couldn't grok general and special relativity for so long, thank god I've found Java - it made it so much easier. I don't know what Persian mathematicians been smoking in 12th century to come up with this utterly fucked up idea of a function. And fuck Leibniz as well.
the_af 4 days ago [-]
[dead]
the_af 4 days ago [-]
> 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.
wmedrano 4 days ago [-]
I started writing a Scheme interpreter about a year ago and got pretty far. I dropped it a few months back since I got a new job.
I'm thinking of getting back and am wondering if the niche (and difficult for me to implement) features are worth it. I might be better off skipping dynamic-unwind, maybe even ripping out call/cc, in favor working on the debugability, ecosystem, performance, and package management story.
SoftTalker 4 days ago [-]
> If you say this to an average person on the street they will probably try to run away.
This is the average reaction I get any time I get the "so what do you do" question. I try to stay very vague "I do computer work" or something. Or I'll say "Oh, nothing interesting" and try to change the subject. Any more specific than that and they start looking for the exits.
prerok 4 days ago [-]
Average programmer too /j
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.
iLemming 4 days ago [-]
> over very abstract things.
I beg to differ. There's just isn't "easy and straightforward" path to simplicity. We thought that explaining the world with "objects" was simple and instead of using already existing language, OOP took "objects" (an easy choice) and invented a elaborate taxonomy of "patterns" to work around the limitations of objects. Just look at this mess:
- Strategy Pattern: Interface + multiple classes + dependency injection + factory maybe. Bruh, it's just a function that takes a function.
- Singleton: Private constructor + static instance + thread safety + double-checked locking.
Bruh, it's a fucking value. You define it once. It doesn't change. You're done.
- Observer/Event System: Interface + listener registration + event loop + memory leak when you forget to unsubscribe. Bruh, tis a fucking function applied to a list (or stream).
- Decorator; Wrap a class in another class that implements the same interface. Bruh - it's function composition. You learned this in algebra class before you turned fourteen.
- Command: Encapsulate a method call as an object with execute(), undo(), history queue... It's a function stored in a variable. That's it. That's the pattern.
- Factory: Separate class whose entire job is to call constructors. Come on, it's just a fucking function.
- Template Method: Abstract base class with a method that calls abstract methods subclasses must override. It's a higher-order function.
- Iterator: Interface with hasNext() and next(), mutable state, ConcurrentModificationException. It's fucking map.
The Gang of Four book exists because Java made functions second-class citizens, so programmers spent 20 years building elaborate object scaffolding to simulate... functions. FP didn't solve these problems. It just never had them.
Yet somehow the industry likes to pretend that every programmer knows (or should know) OOP, while keep telling everyone how hard programming is.
Those who found the truth understand that there's a reason why Lisp just refuses to die and it's unlikely it ever will. At 70 years, it is still flourishing.
Jtsummers 4 days ago [-]
> The Gang of Four book exists because Java made functions second-class citizens
Why do people write silly things like this? GoF was published in 1995, the same year Java was first released, and includes neither Java code nor any mention of Java. Java had no influence on that book.
Jtsummers 4 days ago [-]
iLemming, your reply is [dead] and I don't know why. Responding to parts of it:
> Peter Norvig made this argument explicitly in 1998, showing 16 of 23 patterns are "invisible or simpler" in Lisp
The GoF book even mentions this so Norvig's presentation is a useful read, but even the authors of the book knew it was true. It's not like he added a new idea with that bit you quoted, the useful parts of the presentation were which patterns became invisible or simpler and why.
> Let's try not to nitpick on literal wording to avoid engaging with the substance, could we?
I responded to a common, but false, claim. Don't make false claims and I won't call you out for it.
iLemming 4 days ago [-]
You can replace Java there with pretty much any OOP language, where functions are not first-class citizens, and it will still be true. There are no "false claims" here. The main point is valid. We have orchestrated an entire industry around "objects", while much simpler abstractions have already existed. You probably just have not experienced the "true" nature of Lisp, where you can interactively change any behavior of the running program, directly from your editor, without linking, linting, compiling, restarting or even saving the code you type. The process is an enormously joyful experience, it feels like playing a video game. You probably have little idea of what we've lost and what we've gained from the industry heavily tilting towards OOP.
Jtsummers 4 days ago [-]
> There are no "false claims" here.
You wrote:
>> The Gang of Four book exists because Java made functions second-class citizens
That is a false claim. You asserted a causal relationship between Java and the content of the GoF book that does not exist without time travel.
> You probably just have not experienced the "true" nature of Lisp, where you can interactively change any behavior of the running program, directly from your editor, without linking, linting, compiling, restarting or even saving the code you type.
Sure buddy. You know so much about me...
iLemming 4 days ago [-]
[dead]
iLemming 4 days ago [-]
OMG. You got me. I'm so, so sorry you caught me spreading lies about your precious programming language (or your favorite book, I don't know what you're trying to protect more). Thank you from the bottom of my heart for the diligent work of protecting the truth and keeping this place free of disinformation. Please send me a DM with your mailing address and I'll send you a medal, shipping cost included.
> Sure buddy. You know so much about me...
I should have checked your comment history first before making assumptions. Please accept my apologies if I sounded patronizing. Shouldn't be an excuse for my tone, in my defense I could say: "I said 'probably'". Still disagree with you overly correcting me since I firmly believe the overall notion of my original comment is correct. Thus I won't remove my snarky, sarcastic paragraph above.
iLemming 4 days ago [-]
[dead]
soomtong 4 days ago [-]
This document was really helpful when I first met Janet:
I'm really happy you liked it! It's still a work in progress.
wodenokoto 4 days ago [-]
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).
shevy-java 4 days ago [-]
> not being for mortals at all.
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.
petee 4 days ago [-]
Personally I get hung up on the macro syntax being near the beginning, but there is so much valuable stuff past that
0x0203 4 days ago [-]
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.
embedding-shape 4 days ago [-]
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.
nrclark 4 days ago [-]
Tcl is pretty good at functional-programming type stuff, and it can absolutely do anything that you could do with a macro. It isn't Algol-like at all imo, maybe beyond some superficial syntax. It feels a lot more like if LISP and Bash had a baby out of wedlock.
(I've written a lot of Tcl over the years and it'll always have a spot in my heart)
adrian_b 4 days ago [-]
Tcl being based on strings creates the same problems like in bash scripts, i.e. it is too easy to misuse the quotation rules, leading to subtle bugs.
Using for scripting LISP-like languages is much more foolproof, especially for more complex scripts.
packetlost 4 days ago [-]
Ok, but now I want to embed Janet in a TCL program
ux266478 4 days ago [-]
Janet is faster, but lacks anything like tk. It's probably also quicker to learn, as you don't get into complex evaluation structure until you start messing around with quasiquotes, while tcl requires you to understand mixing 3 different layers of evaluation right off the bat. tcl's vm imo is easier to understand as well.
tcl if you want a UI, janet if you want an embedded scripting language.
skeledrew 4 days ago [-]
This got me thinking of Hy. I wonder how syntactically close they are; there might be an exploitable Python -> Hy -> Janet path here.
I use both. They're similar for simple use, but above a certain level of complexity Hy has a lot of Python-isms that bleed through. It really doesn't ever let you forget that underneath all the parentheses you're really writing Python. Janet feels like its own stand-alone language in that respect, where Hy is more like a syntax swap.
I have the impression that Hy's user base is larger, though (not that either one is huge).
rcarmo 4 days ago [-]
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.
1vuio0pswjnm7 4 days ago [-]
The author does not mention that Janet comes with _built-in_ networking
Having tried many tiny interpreters over the years, that's relatively rare IME
gspr 4 days ago [-]
The embeddability sounds very appealing. Does anyone have experience with using this somewhere one might traditionally reach for Lua?
xigoi 4 days ago [-]
I have built a markup language with embedded scripting in Janet. I originally tried to use Lua, but found the verbosity extremely frustrating.
didibus 4 days ago [-]
Wow I never realized Janet was released more than 10 years after Clojure.
Clojure: 2007
Janet: 2019
p1necone 4 days ago [-]
First time I've seen 'wat' used as a noun, I like it.
DSLs. Creating a language that only you know that will double the learning curve for the folks coming after you. It's fine for personal projects, but almost always an anti-pattern.
ifidishshbsba 3 days ago [-]
Dsls are always in the codebase either explicit where it’s made plain or implicit as design patterns and apis
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.
lindig 4 days ago [-]
> 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.
jsmith45 4 days ago [-]
I'd argue they are not commutive in regexes either, at least as implemented in practice. Implemented regexes favor the leftmost alternative even when both sides of the alternative match. This matters in cases like: capturing groups, and backtracking implementations. There absolutely are cases where one ordering of alternatives could yield catastrophic backtracking for some input, while the other will avoid it completely.
I personally don't like this at all. This means that regex engines that try to generate optimized matching code for an expression can end up generating suboptimal code if you don't want alternative order to matter, since the engine needs to keep that invariant, except in the case when it can prove that the alternatives won't overlap, and a later one can be checked in constant time. If both are true, it is legal to reorder them to do the constant time check before the big complicated wildcard-filled alternative.
But personally, I have never written a regex where I actively cared about the alternative evaluation order. I've used some other people made where order is important but never written one myself.
I'd love to be able to tell the engine "feel free to swap the evaluation order of my alternatives while optimizing", but few if any such engines offer that as a feature.
Now I get that PEGs have commutivity problems are that are different from regexes', which make the issue worse, but that doesn't mean regexes do things right either.
xigoi 4 days ago [-]
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.
layer8 4 days ago [-]
But that’s not how humans writing code generally think about ambiguous expressions. You can see that by how few precedence rules programmers tend to internalize, and often prefer extra parentheses to make sure that the parser interprets it the way they mean.
Timwi 4 days ago [-]
> But that’s not how humans writing code generally think about ambiguous expressions. You can see that by how few precedence rules programmers tend to internalize
I'd argue that it is how humans think about ambiguous syntax, except in the special case of operator precedence, which is the most complex example. A more salient example to me would be, say, the case of an ‘else’ block after a double-‘if’:
if (c) if (d) X; else Y;
It's technically ambiguous, but you only need to run into it once, see how your IDE auto-formatter indents it, and then you've internalized the precedence rule immediately.
xigoi 4 days ago [-]
I am not talking about operator precedence, that’s a separate thing. Consider the parsing of math expressions, where juxtaposition of terms denotes multiplication unless it can be interpreted as something else. So f(x+2) is function application, whereas 3(x+2) is multiplication. With a PEG, you just write a standard expression grammar with an additional choice at the end for the implicit multiplication. With a conventional parser, this is much more difficult – you have to explicitly list all the different ways that terms could be next to each other without meaning something else.
tejtm 4 days ago [-]
We absolutely order more likely / preferred options before other options.
Codifying that as a short circuit optimization is a feature.
layer8 4 days ago [-]
We rarely have preferences that are independent of the concrete use case. Your argument boils down to saying that existing precedence hierarchies are badly designed (or else they would always match everyone’s intuitions), but that’s not the case. (Operator precedence is only one illustrative example here.)
petee 4 days ago [-]
"small peg tracer"[1] is really helpful for breaking down a PEGs operation
Something I'd observe here: without expressing an opinion about PEGs vs regexes, I'd note that regexes are much more widely used. They're also completely sufficient for an awful lot of text processing tasks. PCRE regexes would be a great inclusion to the stdlib, and would probably be popular.
xigoi 4 days ago [-]
> PCRE regexes would be a great inclusion to the stdlib
Why? Anything that can be done with a regex can also be done with a PEG, and the PEG will be much more readable.
nrclark 2 days ago [-]
PEGs are a great replacement for a complicated regex, and can express a lot of things that are hard to do with a regex. But they're also more verbose, and fewer developers are familiar with their usage. PCRE regex is kind of the lingua franca of text-matching, and making it available would be helpful for newcomers imo.
zelphirkalt 4 days ago [-]
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.
layer8 4 days ago [-]
That’s mostly an artifact of concise regex syntax I believe. When you write regular expressions in an ABNF-like form, they become much more intelligible.
bmn__ 4 days ago [-]
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.
xigoi 4 days ago [-]
Under what circumstances does PEG not work?
bmn__ 3 days ago [-]
Many. I don't have enough room on HN to show a representative sample of the shortcomings. Read the relevant literature or converse with an LLM to learn more.
This almost trivial grammar works without any problem in known good parsers. If you want to try out grammars in the wild in Janet, it is nearly guaranteed that they are complex enough for peg to shit itself.
xigoi 3 days ago [-]
Of course this grammar does not work; you violated the two rules of writing PEGs:
• do not use left-recursive rules;
• put alternatives in such an order that none can be a prefix of a subsequent one.
These may seem limiting, but can always be fixed by a simple local change. In contrast, transforming a PEG into a conventional grammar often requires complex, wide-scoped changes. I’ve had the Tree-sitter compiler “shit itself” many times at grammars that PEG accepted with no problem, and had to introduce several ugly hacks to work around the problem of Tree-sitter not allowing ambiguous grammars.
bmn__ 3 days ago [-]
> Of course this grammar does not work [in PEG]
That's the critique, yes. If I put this grammar into a known good parser, it just works. I have to repeat this to hammer the point home.
A user should not have to waste time to find work-arounds for the undocumented limitations. Since there are many more limitations than just the one example I showed, you should realise that there is not much value explaining the particular limitations to me; all the limitations and the required work-around steps should rather go into the Janet documentation so that all users can see them and make use of them. But that's still a crappy developer experience, I would rather see Janet simply adopt a parser that is free of this kind of limitations.
> can always be fixed by a simple local change
I sceptical of that. I claim once the grammar is of the size required to model real-world problems, say about dozens of production rules, fixes become complex, wide-scoped. In the spirit of HN curiosity, I am willing to cooperate with you by conducting an experiment that is designed to change my mind. I would show a grammar that is of the type which is in common use everywhere, and you would apply the fixes to make it work in Janet/PEG, and then we examine whether the changes are always simple and local. Are you willing?
> [PEG grammar in Tree-sitter]
That reads rather bizarre to me because you describe the opposite direction. I have not had that train of thought because in all of my experience and those of the people I know it has always been the case that one receives a grammar that is of the type which is in common use everywhere. And when we try to express it in PEG, it does not work at all, no one knows what to do to make it work, experts who might help cannot be found, and the solution (after wasting a lot of time) is to either give up or try a different parser.
As an aside, I have not examined Tree-sitter yet, and its documentation does not tell me the information I need, so I cannot put it into the category of known good parsers.
AHTERIX5000 4 days ago [-]
Does embedding Janet still lean on global state?
OskarS 4 days ago [-]
My first question too, and I checked out the linked book [1], and sure seems like it! There's global functions like `janet_init()` and `janet_loop()` all over the place.
A language shouldn't advertise itself as "embeddable" if it does this. It means you can't have multiple interpreters, you can't use it on multiple threads, etc. GNU Guile does this too, and it's a baffling decision! For my field (audio plugins like VSTs), it means it's absolutely a no-go, because hosts can load any number of instances of your plugins and potentially run them in parallel in the same address space, they can't rely on global state like this. Each interpreter has to be separate.
Lua does this right, as does Python (as of 3.12, when they made the GIL local to each interpreter) and I think most of the JavaScript engines. And it's not hard, instead of a global `janet_init()`, just have an opaque pointer bundle all the state, like `janet_init(interpreter)`. If you want a global interpreter, just stick it in a global variable.
So you can't execute a Janet script on a different thread than it was created on? Still not good: if you're making audio plugins, you don't control the threads which your program runs on. It's just not good enough, IMHO.
petee 4 days ago [-]
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 mentioned working on audio plugins, and there are a couple other audio-related projects you could check out. Someone there might have a better answer -- https://janet.zulipchat.com/
OskarS 3 days ago [-]
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 Janet using thread-local state, this just doesn't work: the state for one instance is completely different from another, and there's even no guarantee they're running the same scripts.
Consider the most famous embedded language, JavaScript in browsers: you can have any number of tabs open at the same time, and if the JavaScript interpreters for each of those used a bunch of thread-local storage, it would place huge restrictions on how the browsers could schedule and parallelize the callbacks for the JavaScript in those tabs.
The only way I can see this working is if you spin up a thread for each instance, and when these events come in, you wake up those threads, send over the event information, block until the interpreter thread finishes. But that's both inefficient and a real architectural hassle.
All I want is an object that's like `janet_interpreter *interpreter = janet_make_interpreter();` and then you pass that to the functions instead of doing all these magic things with global variables and thread local state. That's it.
petee 3 days ago [-]
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 :)
OskarS 3 days ago [-]
Sure! The main formats are VST3 (from Steinberg, the most popular format), AU (from Apple, supported by most macOS hosts, and Logic only uses AU), AAX (for Avid Pro Tools) and CLAP (an open source variant, that's the best of all of them but is having trouble getting market share). Then there is also "Standalone", which is when you just run your plugin as a standalone app.
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.
petee 2 days ago [-]
Awesome thank you, I appreciate that
zabzonk 4 days ago [-]
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
edwinbalani 4 days ago [-]
From memory, it was for Joint Academic Network. I'm surprised the Wikipedia article doesn't mention it at all, but it seems hard to find an authoritative source.
6LLvveMx2koXfwn 4 days ago [-]
Maybe needs a (2023) in the title?
IshKebab 4 days ago [-]
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.
adrian_b 4 days ago [-]
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).
setopt 4 days ago [-]
> 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.
aeonik 4 days ago [-]
I'm starting to prefer the s expression syntax when dealing with tree structures like json.
I wonder if we were raised on tree based algebra if math would be easier to do, or harder.
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.
Perhaps this exists already somewhere?
veqq 4 days ago [-]
> exists already
The helloworld of macros lets you do `(infix 1 + 2)`:
(defmacro infix [a op b]
~(,op ,a ,b))
A useful one with precedence letting you to `(infix 2 + 4 * 5)`:
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.
veqq 1 days ago [-]
> 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.
Have you ever looked into APL? It was made as a better notation for math over a decade before computers emerged.
krupan 4 days ago [-]
If you ever used an RPN calculator then this is very familiar
4 days ago [-]
tmtvl 4 days ago [-]
All programming languages have horrible syntax (except maybe Forth). Some examples:
Statements are terminated by either a dedicated graphical character, in which case it's easy to forget the character and have a problem, or by a newline (or maybe a different white space character, but I haven't encountered that yet) in which case decent formatting of code may require a dedicated graphical character to indicate that the newline DOESN'T terminate the statement, in which case we have the same problem. Having newline-terminated statements without continuation character would be consistent, but would hamper readability because identifiers would need to be strictly limited in length to keep certain lines from exceeding available screen space (or alternatively readability would suffer from lines only being partially readable).
And that's before getting into the weeds of how mathematical notation is tricky (most people have learned infix notation at maths class in school, so they mightn't appreciate how horrible it is), how different types of brackets (round, square, curly) can have inconsistent semantics, the downsides to the various ways of indicating lexical blocks (brackets, white space, keywords,...), et cetera.
The ideal programming language would probably be one which allows switching between different syntaxes based on what works best for the user (for example, someone could write code in S-expressions, another person could have that code automatically translated into SRFI-119 Wisp expressions and work with it like that, a third person could then have it rendered into something more Lua-like,...). Which is something I think the Racket people are working on, but I may be mistaken.
graemep 4 days ago [-]
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.
IshKebab 3 days ago [-]
> Is static typing that important for a scripting language?
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.
Capricorn2481 18 hours ago [-]
> Look at Javascript - that even has "script" in the name!
Look at Java, it has nothing to do with coffee!
My understanding is a script does two things
1) It can be interpreted. Even if it has some kind of JIT or bytecode step, it can be run as soon as file changes are made.
2) It's one or several informally wired together files for small tasks. A small task meaning you could patch it live without being worried about breaking something, because you can keep it all in your head. It's a narrower definition of a "program."
At that level of programming, terseness becomes an asset rather than a liability, and that's why "scripting languages" tend to be dogged on in larger programs.
xigoi 4 days ago [-]
> 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 use Parinfer, which allows me to edit Janet as if it was an indentation-based language.
veqq 1 days ago [-]
> Parinfer
Have you explored Paredit? Structural editing turns the parentheses into a huge plus so navigating feels like flying.
IshKebab 4 days ago [-]
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.
imtringued 4 days ago [-]
Most editors manage your indentation, parentheses and braces for you. Not sure how that is a unique marker for lisp style languages.
adrian_b 4 days ago [-]
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.
adrian_b 3 days ago [-]
There are too many HN readers who downvote the comments that state real facts about which they are not aware, instead of bothering to investigate and learn something new for them.
What I have written above about the C-derived languages is a fact, not a personal opinion. Anyone who downvoted it has just demonstrated ignorance about programming languages. Too many modern programmers are familiar only with languages derived from "C", which have retained the bad syntax of C, despite criticizing C for unsafety or other such properties, and they do not know anything, or they know only incorrect myths, about the many other programming languages that have existed, and which frequently had certain features that were superior to any of the currently popular languages.
In another comment in this thread I have given a couple of typical program structures of the C programming language, which require a double number of syntactic tokens in comparison with well designed older programming languages, such as ALGOL 68 (which has been the source of several C features, but even some of those have been dumbed down a lot in comparison with the original, e.g. "union").
packetlost 4 days ago [-]
It's a scripting language, so it's not going to compete with anything compiled or JITed, but it has a pretty efficient threaded bytecode interpreter (that is almost more interesting than the language itself!). It's certainly good enough for most situations where you would reach for a scripting language.
IshKebab 4 days ago [-]
AoT/JIT compilation is a property of the implementation, not the language.
It would be good to know order of magnitude anyway. Like, are we talking Ruby/Python level, etc.
veqq 4 days ago [-]
In my tests, it's 5-10x Python for long running things (about 30% slower than Fennel on LuaJit) but for small things, because you can easily shift work to compile time, it beats normal Go: https://codeberg.org/veqq/verse-reader#performance
packetlost 3 days ago [-]
There’s only one implementation so there isn’t a meaningful distinction here, but sure.
It’s faster than Python and Ruby, about as fast as non-JIT Lua.
ux266478 4 days ago [-]
> How fast is it?
Roughly as fast as puc-rio Lua. It won't blow your socks off, but it's more than respectable.
zelphirkalt 4 days ago [-]
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.
Excellent. Although I suspect the author of the programming language invented this Janet for all the perfect puns. Yes, Janet. No. Janet.
boltzmann64 4 days ago [-]
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.
sph 4 days ago [-]
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)
oldes 3 days ago [-]
Rebol is not dead. It's just invisible to the mainstream. There was a new release (3.22) last week.
WalterBright 4 days ago [-]
Dammit, Janet, I love you!
4 days ago [-]
bjourne 4 days ago [-]
Damn it, Janet. No proper namespaces. Hard pass.
xigoi 4 days ago [-]
What do you mean? When you import a module in Janet, it adds a namespace prefix to all symbols. What more do you want?
veqq 1 days ago [-]
It would be really cool to declare multiple modules in the same file, somehow. Also, the Janet community's generally against the word namespace, saying we don't have them. (I don't fully grok why not.)
bjourne 1 days ago [-]
Namespaces as first class objects. Janet namespaces symbols by renaming them. It's not the same thing.
4 days ago [-]
krinne 4 days ago [-]
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.
probably_wrong 4 days ago [-]
> 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.
I suspect real ways to keep AI out of a community, or really to have an online community at all, are going to be structurally incompatible with making anyone rich. The possibility of getting rich poisons the incentives.
CobrastanJorji 3 days ago [-]
It can't just be money. It also has to remove any notion of score or ranking. There should be NO incentive to artificially increase anything.
Look at Advent of Code. Free site, fun community, but it had a leaderboard. The moment AI was advanced enough, it began dominating the leaderboard. The solution: kill the leaderboard. Sure, you can still solve all the problems with AI and get yourself full points, but you're not competing against anybody, so why bother?
As soon as you can get ahead of others at something, even for something as stupid as a karma score on Reddit or on Hacker News, somebody's going to want to increase it badly enough to start cheating.
andrewflnr 3 days ago [-]
Maybe. That's a bit of a different problem: similar mechanic, but much weaker forces with some different pros and cons. Maximizing imaginary internet points is qualitatively different from maximizing actual power in the form of money. I think there's still room to experiment with aligning the incentives on things like karma for community-driven moderation.
klez 3 days ago [-]
If moderation is the problem maybe only allow downvoting? Of course that may bring to the surface a different set of problems (no solution is without drawbacks), but it removes the "numbers go up" incentives.
dwedge 4 days ago [-]
> 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
flir 4 days ago [-]
We've already got models that can handle it - eg web of trust. We don't want to use them.
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.
makkes 4 days ago [-]
Web of trust has been a miserable failure because of the GPG's horrible UX and high entry barrier. It's dead, Jim.
andrewflnr 4 days ago [-]
I think they were referring to invitation trees like lobste.rs.
ASalazarMX 4 days ago [-]
That's for children. Make the Pope a certification authority, and he can certify people he trusts, and so on, until the chain reaches you. When you commit a sin, your certificate gets revoked, along with its children.
It would give the web of trust a flair of biblical damnnation, and after your fall you could always seek a new certification authority more aligned with your values, like Milei or Putin.
When a world leader dies, the tree pruning would be almost apocaliptic.
pbronez 4 days ago [-]
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.
layer8 4 days ago [-]
> Whoever finds a reliable way to keep AI out of an online community first is likely to become a very rich person.
I believe it’s the opposite: You have to pay competent human moderators. Like here on HN.
LtWorf 4 days ago [-]
Half the posts here are AI grifting.
whyenot 4 days ago [-]
That’s a pretty extraordinary claim. Do you have anything quantitative to back it up? HN has bots, I think that is a fair assumption, but half? How do you know that for sure?
GroksBarnacles 4 days ago [-]
[flagged]
4 days ago [-]
dcuthbertson 4 days ago [-]
TIL that statements of obvious exaggeration are called causal, hyperbolic statements. Who knew?
All kidding aside, I've never heard them called causal hyperbolic before. It's a good term.
ponkpanda 4 days ago [-]
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.
nkrisc 4 days ago [-]
Then you’ll end up with a forum of only bots because they’ll spoof it and real people won’t put up with the hassle.
tialaramex 4 days ago [-]
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"]
wbl 4 days ago [-]
Doesn't actually work that well. Browsers hate this, the hardware isn't actually difficult for bots to access, and privacy story is bad. There are solutions being worked on.
layer8 4 days ago [-]
This would result in hardware farms of such devices being automatically operated, like the existing iPhone farms used for similar purposes.
21asdffdsa12 4 days ago [-]
Pay per interaction model? 1 cent per post.
intrasight 4 days ago [-]
Probably the only solution. But the penny has been deprecated so it will have to be a nickel.
imglorp 4 days ago [-]
Only copper was deprecated. Real $0.01 absolutely exists in your bank etc.
Anyway, marketers see a popular site like a physical billboard, where they would pay thousands a month for their message to be seen by thousands of people. If you made it cost pennies to post, and a few more pennies to boost and astroturf, AND that the post would be seen by millions of people, they'd say "By Grabthar's hammer, what a bargain!!" and order a hundred more per day...
phainopepla2 4 days ago [-]
I think pay per account (like the Metafilter model) would be better. If you charge $10 for lifetime access and ban slop-posters, it quickly becomes expensive to be a slop merchant
Cassell 4 days ago [-]
Altman’s orb is as terrifying as it is because businesses might see it as a solution to a real problem—a problem he helped to create.
throwway120385 4 days ago [-]
The reason we didn't see it in the US first is because he was probably gathering data from a pilot system. When he finishes his moonbase and/or volcano lab then we should probably start moving to the Northern Territories or the Yukon.
geokon 4 days ago [-]
lobste.rs uses a web-of-trust referral system. I guess it still involves a moderator killing off bad nodes, but it seems to scale well
dust-jacket 4 days ago [-]
yeah but I can't post there because I don't know anyone with an account and frankly CBA traipsing around looking for someone who has an account.
does seem like more things will have to go this way though
ramon156 4 days ago [-]
+1, if anyone wants to help me I'd be honored.
mail me at ramon(@)odeva(.)nl
Timwi 4 days ago [-]
I actually hung out in their IRC for a while hoping to maybe form a social connection and then get an invite, but somehow it just never materialized, and the chat wasn't engaging, so I stopped coming back...
usefulcat 4 days ago [-]
> it seems to scale well
This seems hard to say without knowing how large it is. To me, it seems like a relatively small community, far smaller than HN anyway.
Maybe you have to be logged in to see that? Because I don't have a login and all it shows me is a bunch of "no data".
akoboldfrying 3 days ago [-]
It shows "No data" for each of the 5 metrics though?
kitd 4 days ago [-]
Age verification with facial ID? ;)
Decabytes 4 days ago [-]
Blizzard's Real ID system would fix all of this. It was ahead of it's time /s
DoughnutHole 4 days ago [-]
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.
NuclearPM 4 days ago [-]
Yes, it’s similar to Trump. But that makes sense right? AI is changing the world drastically, and so is Trump and his fascist friends.
9dev 4 days ago [-]
> a community online where AI isnt allowed.
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.
4 days ago [-]
mr-pink 4 days ago [-]
not really, you can just ask people to do a shit job identifying traffic lights and motorcycles and they'll do it.
matheusmoreira 4 days ago [-]
> I think someone should start a community online where AI isnt allowed.
That's lobsters I guess. AI posts got banned there after a 300+ comment discussion, probably the biggest ever on the site.
The exact rule the moderators settled on was "meaningful human authorship" but don't be fooled: a lot of people on lobsters are ideologically opposed to LLMs. Doesn't matter how "meaningfully" the technology was applied. My work was classified as slop simply because AI touched it. People referred to me as an exhibitionist and fetishist when I talked about using AI. Just a heads up for anyone who's thinking of joining.
crumpled 4 days ago [-]
on my way!
Linux-Fan 4 days ago [-]
I like the Lobsters stance on AI. Also posts are tagged hence you can decide for yourself if the topic may be interesting despite being touched by AI.
I haven't found a way to join Lobsters yet hence for the meantime I keep posting here only. Not so much of an issue since I am mostly a happy lurker.
matheusmoreira 4 days ago [-]
Here's the lobsters stance in case anyone is wondering:
TL;DR Plenty of ideological opposition which will loudly call you out for any usage of AI, and also quite a few nuanced takes which will no doubt be overridden by the vocal opposition. It got to the point the site itself told me to leave.
I don't feel comfortable posting my projects there anymore, even though they do have meaningful human authorship. Still have my account, but I'm essentially a lurker now. I'll participate if someone else independently posts my stuff there.
Feel free to reach out and introduce yourself if you want an invite.
wmedrano 4 days ago [-]
Ironically, the top comment (this) is now about AI.
4 days ago [-]
shevy-java 4 days ago [-]
> a new syntax
How is the syntax new?
It looks like lispy - see the outer parens in the examples given.
embedding-shape 4 days ago [-]
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.
maleldil 4 days ago [-]
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?
drob518 4 days ago [-]
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.
matheusmoreira 4 days ago [-]
Yeah, I didn't get it either until I implemented my own lisp.
> the difficult thing I’ve found over the years is that Lisp is sort of unexplainable
I've found that getting rid of the parentheses helps.
Getting lisp is analogous to spiritual enlightenment. If someone doesn't have the eyes to see and ears to hear, there's little you can do for them, except pray.
layer8 4 days ago [-]
There are reasons why not that many programmers “get it”, and it’s not because the others are uninformed. It’s a matter of valuing different things.
embedding-shape 4 days ago [-]
Hmm, that'd be weird, how do you know you "value something different" if you haven't "got it"? You'd need to "get it" first, then you can understand if you value something different or not, otherwise how would you know?
layer8 4 days ago [-]
The usual insinuation is that if you don’t like it, you “just don’t get it”. I meant not “getting it” in that sense.
drob518 4 days ago [-]
Absolutely! But it’s also because they don’t really understand one of the things. It’s the Blub Paradox.
4 days ago [-]
atdt 3 days ago [-]
Is the magic a property of the broader language-family (and could be experienced with Janet, Racket, whatever), or Common Lisp specifically? When people praise the core execution environment they're typically praising Common Lisp specifically.
What's the quintessential "now I get it" experience, in your mind?
drob518 3 days ago [-]
Any Lisp will do. I had mine with CL and now use Clojure. Racket is great. I’ve never used Janet, but it looks great, too. Pick one. But make sure you engage with the community and ask about editors and tooling. Don’t just fire up VSCode and start typing parentheses. If you do that, you’ll just be frustrated. And nobody who programs in Lisp does that. We use lots of plug-ins and have a live REPL right in our editors at all times. In other words, do what Lisp programmers do. If you try to “do Lisp” the same way you “do JavaScript” or whatever, you’re just going to get frustrated.
If I could explain the moment, I would. But I really can’t. That said, one aha moment for me was reading McCarthy’s original Lisp paper and realizing the whole core of the language was a single page (17).
> What's the quintessential "now I get it" experience, in your mind?
Learning that https://calva.io/paredit/ exists and moving your cursor along the AST or moving expressions around with nice hotkeys. Then making simple macros for infix notation and SQL and so on, which operate on the AST too. Realizing that there is no "architecture" because any repeated code or pattern can be easily abstracted away with a macro. Realizing that you can just describe your problem on paper, making up the perfect notation, then implement that notation in a few hours.
maleldil 4 days ago [-]
> You don’t program in Lisp, do you?
Not anymore. I started with Racket and went through the Little Schemer. I did Clojure for a while. I even used Babashka to write all my scripts, then later rewrote them in other languages.
I gave it a good try. Maybe it wasn't enough to properly "get it"?
chamomeal 4 days ago [-]
Aw man I love babashka. I will say the lack of static types in clojure is pretty brutal for me. Especially when combined with the obtuse error messages. But I still love babashka and the whole REPL driven world.
What did you end up rewriting your bb scripts in?
maleldil 3 days ago [-]
Python, Go, or Rust, depending on the complexity. Python (with strict typing) for the simplest ones, or those where startup time wasn't a concern, Go for the medium-complexity ones that I could do with only the standard library, and Rust for everything else. Besides lisps in general still feeling alien to me, I also really like static types.
drob518 4 days ago [-]
If there's one thing that I sometimes wish Lisp had, it's types. Most of the time, I don't need or even want them. But when you're doing a big refactor or changing the shape of your primary data structure, it would be nice to have the compiler be able to assist you in detecting locations where you've cross-wired something. But other than that, I don't care. And yes, Clojure's error messages could be better, but they have been getting better over time.
tmtvl 4 days ago [-]
> If there's one thing that I sometimes wish Lisp had, it's types.
Let's write some very silly code to turn an integer into a list of digits in Common Lisp:
(deftype Digit ()
"A non-negative integer smaller than 10."
'(Mod 10))
(defun integer->digits (integer)
"Turns a given INTEGER into a list of digits."
(declare (type Integer integer))
(labels ((digit-loop (integer digits)
(declare (type Integer integer)
(type List digits))
(if (< integer 10)
(list* integer digits)
(multiple-value-bind (quotient remainder)
(truncate integer 10)
(declare (type Integer quotient)
(type Digit remainder))
(digit-loop quotient
(list* remainder digits))))))
(declare (ftype (Function (Integer List) List) digit-loop))
(digit-loop (abs integer)
nil)))
(digit-loop 2026) ; => (2 0 2 6)
(digit-loop "2026")
; The value
; "2026"
; is not of type
; INTEGER
; when binding INTEGER
;
; Type HELP for debugger help, or (SB-EXIT:EXIT) to exit from SBCL.
;
; Restarts:
; 0: [ABORT] Exit debugger, returning to top level.
drob518 3 days ago [-]
Yep, I know, but most Lisps do not have those declarations available and even in CL they aren’t used very often. But yes, they would help in CL.
drob518 4 days ago [-]
That's a very reasonable try. Your statements are not unfounded. If I may ask, what's your daily driver now and why do you favor it over Lisps?
maleldil 3 days ago [-]
Python (with types), Go or Rust, depending on the complexity. I really missed static types in Clojure. I think no Lisp does static typing well. I guess there's Coalton, but it's too niche.
cdelsolar 4 days ago [-]
this is incredibly smug, but fun to read :) I briefly "got" Clojure but forgot again. Maybe I'll give this Janet thing a try.
drob518 4 days ago [-]
LOL, indeed. Clojure is fun. I haven't used Janet, but I appreciate seeing some of the good ideas that it stole from Clojure (stealing being the sincerest form of flattery, and all that). IMO, one of Clojure's greatest gifts, above and beyond other traditional Lisps like CL and Scheme, is its focus on immutable data structures. When I started playing with Clojure, I was skeptical. I figured performance was going to be horrible. Now, I can't live without them. It's one of those subtle features that just changes how you program. It's one reason I choose Clojure over CL and Scheme today. Janet seems to have both mutable and immutable data structures, which is nice. Clojure has transients, but that's sort of partially mutable. That said, with Clojure, one of the nice things is that you can always drop back to Java's full mutability if you want, but that's obviously relying on the platform and not Clojure the language.
cmrdporcupine 4 days ago [-]
Honestly... it's entirely possible to "get" Lisp and at the same time not really see anything that compelling about it for doing your own work.
I "get" Lisp just fine, have made my own hobby Lisp interpreters, have written programs in Lisp, am an emacs user, etc. etc.
And yet if you handed me a terminal and an editor and asked me to write a program, I would never reach for Lisp to do it. My eyes don't like it. (Also I like static types).
BoingBoomTschak 4 days ago [-]
Just saying "macros" is a bit reductive: in CL, you have access to the full language at (read) parse time, compile time and runtime. Said macros also mean that logical OR/AND short-circuiting isn't a compiler black box, you can implement such behaviour easily yourself.
------
The syntax is actually a big pro for a lot of people. I love its streamlined look that basically reads like Python once you let your IDE indent properly and learn to see "through" the parentheses (CL, Scheme).
The original language where everything is an expression and it shows. Where Python still needs an ugly ternary and made match a statement, Lisp has had the perfect IF and COND since the dawn of time.
Symbols are still a cool and useful concept that almost no other language I know of got.
The numerical tower - despite some holes - is amazing. Built-in rationals and "correct math" as sane default (i.e. 1/2 not returning 0) never get old.
------
And if you let me rave about CL specifically (e.g. DECLARATIONs as "#pragma done well", restarts, CLOS/MOP, runtime READ/COMPILE, etc...), there are a lot of cool features barely copied anywhere that'd improve other languages, but these aren't part of "what make Lisp Lisp".
evdubs 4 days ago [-]
S-expressions. Defining data in JSON or XML is way worse than S-expressions.
maleldil 3 days ago [-]
I agree that S-expressions for defining data are pretty nice, but you don't need to actually use a Lisp to use them. You can just use them like you would XML.
4 days ago [-]
soomtong 4 days ago [-]
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.
veqq 4 days ago [-]
> I never thought it could happen to me.
But I am truly biased. I have basically forgotten how to code everything else (besides APL family languages) in the past _checks notes_ 10 months since I started Janet. I even run a community [docs site](https://janetdocs.org/) and am writing [my own tutorial](https://janetdocs.org/tutorials/learn-to-program) (albeit slowly). I even use it in production for all new software (within 3 weeks of starting, I had rewritten all personal scripts etc.)
> Janet is simple
You can do literally everything with just hashmaps. The whole language is basically a hashmap, implementation wise. `(keys (curenv))` prints out all locally defined symbols. `(keys (getproto (curenv)))` prints the parent hashmap of the current environment i.e. all the core symbols. I don't, but you can basically do CLOS via hashmaps (and there is a [fuller implementation](https://git.sr.ht/~subsetpark/fugue) too.)
...not really. In reality, the whole standard library constantly returns mutable versions from everything. There's no reason to really try to be immutable at this point. Although there are cool [combinator libraries](https://git.sr.ht/~subsetpark/apcl-janet) and I've even made combinatorish versions of basic functions:
(defn better-cond
[& pairs]
(fn :bc [& arg] # names for stack traces
(label result
(defn argy [f] (if (> (length arg) 0) (apply f arg) (f arg))) # naming is hard
(each [pred body] (partition 2 pairs)
(when (argy pred)
(return result (if (function? body)
(argy body) # calls body on args
body)))))))
Combinatory inspired cond, which allows for pairs. The test does not need an argument and the body may be a simple value or a function:
(map (better-cond
string? "not a number"
odd? "odd"
even? "even")
[1 2 3 "cat"]) # the args!
(map
(better-cond
1 (fn [arr] (array (min ;arr) (max ;arr)))) # (recombine array (unapply min) (unapply max)))
(partition 2 (range 10))) # these are the args!
((better-cond
< "first is smaller"
> "second is smaller")
5 3) # these are the args passed into the func! I am excited!
> Janet lets you pass values from compile-time to run-time
That's what got me hooked, in a few ways. In Racket or Go, I had to do a lot of work to process data at compile time so the runtime could literally just be a lookup table. In Janet? That's the default behavior of any `def` outside of main. The following turns a .tsv of the bible into a hashmap in the binary, when compiling:
(def verses (reduce (fn [acc line]
(let [parts (string/split "\t" line)]
(if (= (length parts) 5)
(let [[_ abbrev ch vs text] parts]
(put-in acc [abbrev ch vs] text))
acc)))
@{}
(string/split "\n" (slurp "kjv.tsv"))))
(def abbrev-array (keys verses)) # also makes an array of the abbreviation column
(defn main [_ & args]
(if (or (empty? args) (= "-h" ;args) (= "help" ;args))
(do (print "Usage: kjv <book> [chapter:verse]") (os/exit 1))) # show help
(let
[Capitalized (string (string/ascii-upper (string/slice (first args) 0 1)) (string/slice (first args) 1))
book (find |(string/has-prefix? $ Capitalized) abbrev-array)]
(pp (match args
[_ chap verse] (get-in verses [book chap verse])
[_ unsure] (match (string/split ":" unsure)
[chap verse] (get-in verses [book chap verse])
[chap] (get-in verses [book chap]))
[_] (verses book)))))
The equivalent go program was 5x longer and required an extra program to convert data into a 40k line .go file with a giant literal hashmap, to be faster than the naive Janet.
...but actually Ian Henry means Janet e.g. keeps closures synced across images/sessions:
(defn timer [t]
(var t t) # this is slightly annoying, must shadow as params are immutable
[(fn [] (set t (+ t 1)))
(fn [] (set t (+ t 2)))])
(def tx (timer 0))
# call like this:
((tx 0))
((tx 1))
# make an image and save it to file
(def my-module @{:public true})
(spit "test.jimage" (make-image (curenv)))
why is it called Janet? perhaps to prevent it to be identified with the acronym for Lots of Irritating Single Parenthesis?
Imustaskforhelp 4 days ago [-]
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
iLemming 4 days ago [-]
> 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 is basically a reoccurring theme on every programming forum, whenever a Lispy PL gets mentioned. There are tons of confused programmers who look at Lisp examples and "hate" it. Without a single practical experience of using Lisp. They don't know anything about structural editing, they never experienced REPL-driven development. And I'm not talking about shit like "Python REPL", which is a bleak attempt, a shallow shell compared to the "true Lisp REPL".
It takes a bit of time and curiosity to realize how enormously powerful, beautiful and practical the idea of Lisp is. And it's really sad that smart people refuse it outright, without even attempting to understand it. Sure, it may take some time to discard the old habits that took years to build and accept this unfamiliar thing. Yet there's a point, after which comes the realization that Lisp can literally replace every single programming language with better ergonomics. I'm so mad at myself for wasting huge chunk of my life, chasing things of lesser importance, instead of just figuring out Lisp sooner.
I guess, to a degree you're right - you either hate Lisp or love Lisp, there's no in-between. But "hate" means you simply don't know it. Once you do - there's no way not to fall in love.
3 days ago [-]
adrian_b 4 days ago [-]
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.
NetMageSCW 4 days ago [-]
Now do
for (i = 1; i <= 128; i *= 2) { … }
with by.
Now do
if (x <= 0)
throw ParameterException;
with fewer “syntactic tokens”.
adrian_b 3 days ago [-]
The "for" structure introduced by the C programming language in 1974 was a very big mistake.
It has forced all programmers to write everyday a lot of superfluous boilerplate for the most frequently used kinds of loops as the price for being able to write some very rarely used kinds of loops.
A much better solution would have been to keep the kind of "for" loop used in PL/I and ALGOL 68, 2 languages from which C has taken many other features, and to add an extra kind of "for", for the rarely used loops.
An even better solution had been found quasi-simultaneously with C in the programming languages Alphard and CLU, where instead of inventing this kind of complex "for", they invented iterators, which allow the writing of "forall" loops having the same form as that for arrays or for arithmetic progressions, but for arbitrary data structures.
Iterators solve in a more ergonomic way the problem for which the C "for" was invented, i.e. to write loops that visit all the members of a linked list or similar data structures.
Your example is also solved trivially in a language with iterators, you just define a geometric progression as a generic type and then you can write a "forall" loop that iterates over all its elements.
The fact that the language C permits to omit the curly braces around a single statement helps to reduce its excessive verbosity, but not enough.
In your "if" example, you have 4 syntactic tokens: "if", "(", ")" and ";".
This is still an extra token in comparison with ALGOL 68, where your example would be written so:
if x <= 0 then
throw ParameterException fi
which uses only 3 syntactic tokens. The opening parenthesis that must follow C keywords like "if", "for", "while" is always a superfluous syntactic token.
For the verbosity of a programming language, only the number of syntactic tokens matters, because, depending on the preferences of the programmer, one syntactic token can be represented by either a long keyword or by an abbreviation or by a single symbol.
If minimum verbosity is desired, single symbols can be used for each syntactic token, e.g. in my own programming language the 3 syntactic tokens of ALGOL 68 would be single symbols:
{ x <= 0 ?
throw ParameterException }
petee 4 days ago [-]
It was named after the sentient computer system in the TV show "The Good Place"
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.
shevy-java 4 days ago [-]
(defn foo [first & rest] ...)
So basically Lisp 2.0.
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.
xigoi 4 days ago [-]
What would be a better syntax according to you? I have found Janet’s syntax very pleasant to work with as opposed to JavaScript, Lua or even Python.
Imustaskforhelp 4 days ago [-]
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.
rmunn 4 days ago [-]
"... all the benefits without additional parenthesis too?"
I guess you don't like Lisp's syntax. I didn't either until I realized the key insight: when you're writing Lisp, you're basically writing an AST. Which is why it's so easy to manipulate your code. Want a new feature the language doesn't have, such as the pattern-matching they added to C# a few versions back? You can add it yourself; you don't need to wait for a language committee to implement it years after you needed it. That's all that macros are: functions that take AST and return AST, which is then executed.
And once I realized that Lisp's syntax was basically an AST, I no longer saw the parentheses. Now I just see blonde, brunette, redhead... Oops. Sorry. Wrong reference.
petee 4 days ago [-]
I guess you could transpile direct to Janet bytecode, and performance would be in theory the same as native Janet?
iLemming 4 days ago [-]
> like lua/wren which can transpile to Janet too.
Really? I've used dozens of languages and honestly, I just can't wrap my head around how ugly Lua code can get. At first, I tried treating it as "javascript with no bad parts", turns out, modern JS is far, far better than 1996 JS and nicer than Lua. The most annoying part about Lua is that I never know how to format it for better readability - should I add line breaks, or not, etc. lua-fmt often just makes it worse.
When I found Fennel I immediately moved to it, even though it was "experimental". Since then, I just don't want to deal with Lua, aside from some small one-liners.
I do LOVE that Janet can create binaries with JPM, scripts, and is very portable. I once put the Janet programming language on the Playdate game console as POC.
I actually do enjoy writing Janet, but every time I do people think I created the language (I did not).
you should totally do a "Janet writes Janet" version
https://github.com/pyrmont/jeep/
It let's you vendor deps and easily install modern Janet bundles without jpm.
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.
i watch ur streams on twitch lol
https://fennel-lang.org/
I think there's a lot of value in forking LuaJIT2 and reworking the debugging and error structures within to make it more suitable for language transparency. Doing so would make languages like Fennel much more attractive.
I gather that some features will be added to 2.1 but others only to 3.0.
What exactly do you mean by this? Speed? Portability? Ease of use?
Where I'd say it advances into breaking SBCL's jaw is that the runtime, interpreter, jitter, etc. are all much smaller than SBCL's runtime and compiler. If you're looking for a complete system, I'd say SBCL wins out obviously. You're talking a world-class REPL, debugger, a high quality stdlib, etc. All it's missing is a text editor like LispWorks (emacs and pretty much every other FOSS Lisp editor I've seen is a massive downgrade.) With that in mind, SBCL is not something you embed in an application written in another language. The holy grail is getting something as fast as SBCL, as flexible as SBCL, but as a 50k loc self-contained runtime. LuaJIT is the reigning heavyweight champ there, so having a Lisp-adjacent language like Fennel running atop it is a pretty damn compelling idea.
Interestingly with regards to text editors, Lua doesn't have that problem technically. Lite-XL is dangerously close to being zmacs/LispWorks for Lua. Poetically, just like Lua it's fairly bare bones and requires extension to be a decent IDE. But the underlying structure is absolutely fantastic, being based around a fairly cohesive object model rather than coats of paint over text buffers.
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.
It makes me sad that some-mthfka got some but perhaps not enough support and the effort stalled after a few months.
I agree GUI is awkward in Emacs/SLIME. I think the reason is there isn't a standardized GUI framework across the Lisp world. Otherwise people can make SLIME support 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.
This part I do not agree. Nowadays "text" in Emacs/SLIME is far from "raw text", there's button that respond to hover, with right click context menu, and can be copy and pasted. I recall some small quirks (like objects in inspector are not presentations) but the only reason they aren't fixed (yet) is nobody get bothered enough. There's rarely any fundamental limitation. After all, it wouldn't be fare to call LispWorks UI "dead pixels".
BTW I once wrote yet another over ambitious project < https://github.com/neomacs-project/neomacs > but it doesn't go anywhere either. People do not care enough, Emacs is good enough.
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
https://bauble.studio
https://toodle.studio
Those two fascinating art tools got me very excited about Janet a while back.
babashka did that for me.
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.
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 you're dealing with data - any data. Clojure is incredibly data-driven, which wins me over Janet. I also reach out to nbb whenever I need to deal with Node. e.g. scraping scripts driven by Playwright.
Janet is great when you need tiny runtime or you're dealing with subprocess-heavy scripts - Janet feels closer to actual shell syntax; or when you have to embed it to C/C++ program.
Fennel is indispensable for any Lua - mpv, Hammerspoon, AwesomeWM and Neovim configs, etc.
I'm curious what differences you see? I've been all in on Janet, but barely used Clojure. What more data driven aspects does Clojure have .... offer? My mental model/assumption's always been that Janet's Clojure without JVM and (sadly) not so pure. I don't use any of Janet's C interop facilities. I'd love to know what I'm missing
afaik, Janet's immutable structs/tuples are flat copies - no structural sharing. Clojure uses HAMTs. So it's truly immutable by default - you'd transform data without intermediate allocations.
In Clojure, the standard library already knows about your data - it has the tools to group, index, validate, serialize, and transform maps/vectors/sets without you reinventing them. In Janet, you have the building blocks but it feels like you're assembling the furniture yourself.
The trade-off is that babashka adds ~200ms to cold start and can be pretty memory hungry, but god, Clojure is so nice to deal with data. For small scripts it may not matter. For processing log files or CSVs with millions of rows, it does.
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.
Once you understand how destructuring works in Clojure, it then becomes obvious what role square-brackets play.
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.
Now if you relaxed just a little bit - the world would be much nicer place.
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.
For me, certainly. But it's not a matter of adding parens, it's more removing extra syntax.
So often people coming from one linguistic syntactical style express themselves in that style which makes their code in the new language less understandable or maintainable.
My point was, replacing n syntactic constructs by n functions or macros doesn’t reduce the cognitive load of having to know how each construct works. To the contrary, one can argue that everything having the same syntactic form makes it more difficult to distinguish different classes of features.
It was just an example, most languages have quirks like this. I don’t know about Java, but in Rust you have the turbofish operator, whose necessity stems from using the less-than sign as both an operator and a delimiter.
> My point was, replacing n syntactic constructs by n functions or macros doesn’t reduce the cognitive load of having to know each of them.
The difference is that if you don’t know a function/macro, you can just read its documentation. If you don’t know a syntactic construct, where do you look?
Another advantage is that if you want to create new functionality similar to existing language features, it won’t stick out like a sore thumb. For example, you could create an until loop:
In Rust, it would have to look completely different from a while loop:I just made a library with [query syntax](https://codeberg.org/veqq/declarative-dsls) over various data structures a la sql:
Printing: It also has datalog and minikanren (with s expr, sharing the same goals etc.) And it vectorizes like APL: Or you can just use [J directly from Janet](https://git.sr.ht/~subsetpark/jnj): The Joy Web Framework has a cool [db query dsl](https://github.com/joy-framework/joy/blob/master/docs/databa...) too: `(var account (db/find-by :account :where {:login (auth-result :login)}))`, used for a [web auth](https://codeberg.org/veqq/janetdocs/src/commit/848dcbd8e54ad...).From my response, bigger than the article: https://lobste.rs/s/y0euno/why_janet_2023#c_lspe6n
Because industry lied to you, promising "simplicity and riches". The industry didn't just overcomplicate programming. It institutionalized the complication. Why? Because complexity is a moat.
Complex frameworks need certified experts. Certified experts charge more. Companies built around expertise need the complexity to persist. So the complexity gets marketed as sophistication.
They've promised: "Java/C# will get you hired anywhere", but you're hired to write xml (these days yaml). "OOP models the real world", they said. The real world doesn't have abstract factory visitors. "Design patterns make you senior", but you only learned workarounds for language deficiencies. "Learn the framework, get the job". Framework dies, you start over. "Specialization is valuable". you're now hostage to one ecosystem.
A programmer who understands fundamentals is dangerous to this system. The fundamentals:
- a function transforms input to output.
- composition builds complexity from simplicity.
- types describe what's possible.
- effects should be explicit.
And then you realize that Lisp is the skeleton key. All that above is Lisp, or came from Lisp. Every language is either: Lisp with different syntax, or C with different syntax, or arguing between the two.
If you learn Lisp, you don't learn a language. You learn what languages are. You're no longer a consumer of a programming language or two, or a few. You are native speaker in all of them.
Of course easier to explain the "strategy pattern" to a florist, instead of saying "imagine a function that takes a function". Who the hell understands functions? Such a mind-bending concept, literally nobody really knows how they work. Einstein famously complained about it. Too bad he didn't know OOP - would've been so much easier. I couldn't grok general and special relativity for so long, thank god I've found Java - it made it so much easier. I don't know what Persian mathematicians been smoking in 12th century to come up with this utterly fucked up idea of a function. And fuck Leibniz as well.
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'm thinking of getting back and am wondering if the niche (and difficult for me to implement) features are worth it. I might be better off skipping dynamic-unwind, maybe even ripping out call/cc, in favor working on the debugability, ecosystem, performance, and package management story.
This is the average reaction I get any time I get the "so what do you do" question. I try to stay very vague "I do computer work" or something. Or I'll say "Oh, nothing interesting" and try to change the subject. Any more specific than that and they start looking for the exits.
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.
I beg to differ. There's just isn't "easy and straightforward" path to simplicity. We thought that explaining the world with "objects" was simple and instead of using already existing language, OOP took "objects" (an easy choice) and invented a elaborate taxonomy of "patterns" to work around the limitations of objects. Just look at this mess:
- Strategy Pattern: Interface + multiple classes + dependency injection + factory maybe. Bruh, it's just a function that takes a function.
- Singleton: Private constructor + static instance + thread safety + double-checked locking. Bruh, it's a fucking value. You define it once. It doesn't change. You're done.
- Observer/Event System: Interface + listener registration + event loop + memory leak when you forget to unsubscribe. Bruh, tis a fucking function applied to a list (or stream).
- Decorator; Wrap a class in another class that implements the same interface. Bruh - it's function composition. You learned this in algebra class before you turned fourteen.
- Command: Encapsulate a method call as an object with execute(), undo(), history queue... It's a function stored in a variable. That's it. That's the pattern.
- Factory: Separate class whose entire job is to call constructors. Come on, it's just a fucking function.
- Template Method: Abstract base class with a method that calls abstract methods subclasses must override. It's a higher-order function.
- Iterator: Interface with hasNext() and next(), mutable state, ConcurrentModificationException. It's fucking map.
The Gang of Four book exists because Java made functions second-class citizens, so programmers spent 20 years building elaborate object scaffolding to simulate... functions. FP didn't solve these problems. It just never had them.
Yet somehow the industry likes to pretend that every programmer knows (or should know) OOP, while keep telling everyone how hard programming is.
Those who found the truth understand that there's a reason why Lisp just refuses to die and it's unlikely it ever will. At 70 years, it is still flourishing.
Why do people write silly things like this? GoF was published in 1995, the same year Java was first released, and includes neither Java code nor any mention of Java. Java had no influence on that book.
> Peter Norvig made this argument explicitly in 1998, showing 16 of 23 patterns are "invisible or simpler" in Lisp
The GoF book even mentions this so Norvig's presentation is a useful read, but even the authors of the book knew it was true. It's not like he added a new idea with that bit you quoted, the useful parts of the presentation were which patterns became invisible or simpler and why.
> Let's try not to nitpick on literal wording to avoid engaging with the substance, could we?
I responded to a common, but false, claim. Don't make false claims and I won't call you out for it.
You wrote:
>> The Gang of Four book exists because Java made functions second-class citizens
That is a false claim. You asserted a causal relationship between Java and the content of the GoF book that does not exist without time travel.
> You probably just have not experienced the "true" nature of Lisp, where you can interactively change any behavior of the running program, directly from your editor, without linking, linting, compiling, restarting or even saving the code you type.
Sure buddy. You know so much about me...
> Sure buddy. You know so much about me...
I should have checked your comment history first before making assumptions. Please accept my apologies if I sounded patronizing. Shouldn't be an excuse for my tone, in my defense I could say: "I said 'probably'". Still disagree with you overly correcting me since I firmly believe the overall notion of my original comment is correct. Thus I won't remove my snarky, sarcastic paragraph above.
https://janetdocs.org/tutorials
https://janet.guide/ (the author's one)
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.
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.
(I've written a lot of Tcl over the years and it'll always have a spot in my heart)
Using for scripting LISP-like languages is much more foolproof, especially for more complex scripts.
tcl if you want a UI, janet if you want an embedded scripting language.
[0] https://hylang.org/
I have the impression that Hy's user base is larger, though (not that either one is huge).
Having tried many tiny interpreters over the years, that's relatively rare IME
Clojure: 2007
Janet: 2019
(for those unfamiliar with the reference: https://www.destroyallsoftware.com/talks/wat)
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.
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.
I personally don't like this at all. This means that regex engines that try to generate optimized matching code for an expression can end up generating suboptimal code if you don't want alternative order to matter, since the engine needs to keep that invariant, except in the case when it can prove that the alternatives won't overlap, and a later one can be checked in constant time. If both are true, it is legal to reorder them to do the constant time check before the big complicated wildcard-filled alternative.
But personally, I have never written a regex where I actively cared about the alternative evaluation order. I've used some other people made where order is important but never written one myself.
I'd love to be able to tell the engine "feel free to swap the evaluation order of my alternatives while optimizing", but few if any such engines offer that as a feature.
Now I get that PEGs have commutivity problems are that are different from regexes', which make the issue worse, but that doesn't mean regexes do things right either.
I'd argue that it is how humans think about ambiguous syntax, except in the special case of operator precedence, which is the most complex example. A more salient example to me would be, say, the case of an ‘else’ block after a double-‘if’:
It's technically ambiguous, but you only need to run into it once, see how your IDE auto-formatter indents it, and then you've internalized the precedence rule immediately.[1] https://github.com/sogaiu/small-peg-tracer
Why? Anything that can be done with a regex can also be done with a PEG, and the PEG will be much more readable.
Typical example, ported from <https://news.ycombinator.com/item?id=16600224>:
This almost trivial grammar works without any problem in known good parsers. If you want to try out grammars in the wild in Janet, it is nearly guaranteed that they are complex enough for peg to shit itself.• do not use left-recursive rules;
• put alternatives in such an order that none can be a prefix of a subsequent one.
These may seem limiting, but can always be fixed by a simple local change. In contrast, transforming a PEG into a conventional grammar often requires complex, wide-scoped changes. I’ve had the Tree-sitter compiler “shit itself” many times at grammars that PEG accepted with no problem, and had to introduce several ugly hacks to work around the problem of Tree-sitter not allowing ambiguous grammars.
That's the critique, yes. If I put this grammar into a known good parser, it just works. I have to repeat this to hammer the point home.
A user should not have to waste time to find work-arounds for the undocumented limitations. Since there are many more limitations than just the one example I showed, you should realise that there is not much value explaining the particular limitations to me; all the limitations and the required work-around steps should rather go into the Janet documentation so that all users can see them and make use of them. But that's still a crappy developer experience, I would rather see Janet simply adopt a parser that is free of this kind of limitations.
> can always be fixed by a simple local change
I sceptical of that. I claim once the grammar is of the size required to model real-world problems, say about dozens of production rules, fixes become complex, wide-scoped. In the spirit of HN curiosity, I am willing to cooperate with you by conducting an experiment that is designed to change my mind. I would show a grammar that is of the type which is in common use everywhere, and you would apply the fixes to make it work in Janet/PEG, and then we examine whether the changes are always simple and local. Are you willing?
> [PEG grammar in Tree-sitter]
That reads rather bizarre to me because you describe the opposite direction. I have not had that train of thought because in all of my experience and those of the people I know it has always been the case that one receives a grammar that is of the type which is in common use everywhere. And when we try to express it in PEG, it does not work at all, no one knows what to do to make it work, experts who might help cannot be found, and the solution (after wasting a lot of time) is to either give up or try a different parser.
As an aside, I have not examined Tree-sitter yet, and its documentation does not tell me the information I need, so I cannot put it into the category of known good parsers.
A language shouldn't advertise itself as "embeddable" if it does this. It means you can't have multiple interpreters, you can't use it on multiple threads, etc. GNU Guile does this too, and it's a baffling decision! For my field (audio plugins like VSTs), it means it's absolutely a no-go, because hosts can load any number of instances of your plugins and potentially run them in parallel in the same address space, they can't rely on global state like this. Each interpreter has to be separate.
Lua does this right, as does Python (as of 3.12, when they made the GIL local to each interpreter) and I think most of the JavaScript engines. And it's not hard, instead of a global `janet_init()`, just have an opaque pointer bundle all the state, like `janet_init(interpreter)`. If you want a global interpreter, just stick it in a global variable.
[1]: https://janet.guide/embedding-janet/
[1] official docs: https://janet-lang.org/capi/embedding.html
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 mentioned working on audio plugins, and there are a couple other audio-related projects you could check out. Someone there might have a better answer -- https://janet.zulipchat.com/
Consider the most famous embedded language, JavaScript in browsers: you can have any number of tabs open at the same time, and if the JavaScript interpreters for each of those used a bunch of thread-local storage, it would place huge restrictions on how the browsers could schedule and parallelize the callbacks for the JavaScript in those tabs.
The only way I can see this working is if you spin up a thread for each instance, and when these events come in, you wake up those threads, send over the event information, block until the interpreter thread finishes. But that's both inefficient and a real architectural hassle.
All I want is an object that's like `janet_interpreter *interpreter = janet_make_interpreter();` and then you pass that to the functions instead of doing all these magic things with global variables and thread local state. That's it.
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.
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.
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).
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.Perhaps this exists already somewhere?
The helloworld of macros lets you do `(infix 1 + 2)`:
A useful one with precedence letting you to `(infix 2 + 4 * 5)`: But ultimately, APL notation is best: https://git.sr.ht/~subsetpark/jnjhttps://janet-lang.org/spork/api/infix.html
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.
Have you ever looked into APL? It was made as a better notation for math over a decade before computers emerged.
Statements are terminated by either a dedicated graphical character, in which case it's easy to forget the character and have a problem, or by a newline (or maybe a different white space character, but I haven't encountered that yet) in which case decent formatting of code may require a dedicated graphical character to indicate that the newline DOESN'T terminate the statement, in which case we have the same problem. Having newline-terminated statements without continuation character would be consistent, but would hamper readability because identifiers would need to be strictly limited in length to keep certain lines from exceeding available screen space (or alternatively readability would suffer from lines only being partially readable).
And that's before getting into the weeds of how mathematical notation is tricky (most people have learned infix notation at maths class in school, so they mightn't appreciate how horrible it is), how different types of brackets (round, square, curly) can have inconsistent semantics, the downsides to the various ways of indicating lexical blocks (brackets, white space, keywords,...), et cetera.
The ideal programming language would probably be one which allows switching between different syntaxes based on what works best for the user (for example, someone could write code in S-expressions, another person could have that code automatically translated into SRFI-119 Wisp expressions and work with it like that, a third person could then have it rendered into something more Lua-like,...). Which is something I think the Racket people are working on, but I may be mistaken.
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.
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.
Look at Java, it has nothing to do with coffee!
My understanding is a script does two things 1) It can be interpreted. Even if it has some kind of JIT or bytecode step, it can be run as soon as file changes are made. 2) It's one or several informally wired together files for small tasks. A small task meaning you could patch it live without being worried about breaking something, because you can keep it all in your head. It's a narrower definition of a "program."
At that level of programming, terseness becomes an asset rather than a liability, and that's why "scripting languages" tend to be dogged on in larger programs.
I use Parinfer, which allows me to edit Janet as if it was an indentation-based language.
Have you explored Paredit? Structural editing turns the parentheses into a huge plus so navigating feels like flying.
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.
What I have written above about the C-derived languages is a fact, not a personal opinion. Anyone who downvoted it has just demonstrated ignorance about programming languages. Too many modern programmers are familiar only with languages derived from "C", which have retained the bad syntax of C, despite criticizing C for unsafety or other such properties, and they do not know anything, or they know only incorrect myths, about the many other programming languages that have existed, and which frequently had certain features that were superior to any of the currently popular languages.
In another comment in this thread I have given a couple of typical program structures of the C programming language, which require a double number of syntactic tokens in comparison with well designed older programming languages, such as ALGOL 68 (which has been the source of several C features, but even some of those have been dumbed down a lot in comparison with the original, e.g. "union").
It would be good to know order of magnitude anyway. Like, are we talking Ruby/Python level, etc.
It’s faster than Python and Ruby, about as fast as non-JIT Lua.
Roughly as fast as puc-rio Lua. It won't blow your socks off, but it's more than respectable.
https://docs.racket-lang.org/sweet/index.html
(I'd include Rebol but it's as mind-blowing as it's dead technology from a lost timeline)
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...
Look at Advent of Code. Free site, fun community, but it had a leaderboard. The moment AI was advanced enough, it began dominating the leaderboard. The solution: kill the leaderboard. Sure, you can still solve all the problems with AI and get yourself full points, but you're not competing against anybody, so why bother?
As soon as you can get ahead of others at something, even for something as stupid as a karma score on Reddit or on Hacker News, somebody's going to want to increase it badly enough to start cheating.
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
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.
It would give the web of trust a flair of biblical damnnation, and after your fall you could always seek a new certification authority more aligned with your values, like Milei or Putin.
When a world leader dies, the tree pruning would be almost apocaliptic.
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.
I believe it’s the opposite: You have to pay competent human moderators. Like here on HN.
All kidding aside, I've never heard them called causal hyperbolic before. It's a good term.
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"]
Anyway, marketers see a popular site like a physical billboard, where they would pay thousands a month for their message to be seen by thousands of people. If you made it cost pennies to post, and a few more pennies to boost and astroturf, AND that the post would be seen by millions of people, they'd say "By Grabthar's hammer, what a bargain!!" and order a hundred more per day...
does seem like more things will have to go this way though
This seems hard to say without knowing how large it is. To me, it seems like a relatively small community, far smaller than HN anyway.
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.
That's lobsters I guess. AI posts got banned there after a 300+ comment discussion, probably the biggest ever on the site.
The exact rule the moderators settled on was "meaningful human authorship" but don't be fooled: a lot of people on lobsters are ideologically opposed to LLMs. Doesn't matter how "meaningfully" the technology was applied. My work was classified as slop simply because AI touched it. People referred to me as an exhibitionist and fetishist when I talked about using AI. Just a heads up for anyone who's thinking of joining.
I haven't found a way to join Lobsters yet hence for the meantime I keep posting here only. Not so much of an issue since I am mostly a happy lurker.
https://lobste.rs/s/29pm2f/llm_generated_submissions_should_...
TL;DR Plenty of ideological opposition which will loudly call you out for any usage of AI, and also quite a few nuanced takes which will no doubt be overridden by the vocal opposition. It got to the point the site itself told me to leave.
I don't feel comfortable posting my projects there anymore, even though they do have meaningful human authorship. Still have my account, but I'm essentially a lurker now. I'll participate if someone else independently posts my stuff there.
Feel free to reach out and introduce yourself if you want an invite.
How is the syntax new?
It looks like lispy - see the outer parens in the examples given.
> the difficult thing I’ve found over the years is that Lisp is sort of unexplainable
I've found that getting rid of the parentheses helps.
Lisp code is just normal Python lists which get evaluated by an interpreter function. Like this: Filling out that eval function is a great way to learn lisp.These articles are very good and accessible:
https://www.norvig.com/lispy.html
https://norvig.com/lispy2.html
What's the quintessential "now I get it" experience, in your mind?
If I could explain the moment, I would. But I really can’t. That said, one aha moment for me was reading McCarthy’s original Lisp paper and realizing the whole core of the language was a single page (17).
https://www.informatik.uni-bremen.de/agbkb/lehre/pi3/folien/...
Learning that https://calva.io/paredit/ exists and moving your cursor along the AST or moving expressions around with nice hotkeys. Then making simple macros for infix notation and SQL and so on, which operate on the AST too. Realizing that there is no "architecture" because any repeated code or pattern can be easily abstracted away with a macro. Realizing that you can just describe your problem on paper, making up the perfect notation, then implement that notation in a few hours.
Not anymore. I started with Racket and went through the Little Schemer. I did Clojure for a while. I even used Babashka to write all my scripts, then later rewrote them in other languages.
I gave it a good try. Maybe it wasn't enough to properly "get it"?
What did you end up rewriting your bb scripts in?
Let's write some very silly code to turn an integer into a list of digits in Common Lisp:
I "get" Lisp just fine, have made my own hobby Lisp interpreters, have written programs in Lisp, am an emacs user, etc. etc.
And yet if you handed me a terminal and an editor and asked me to write a program, I would never reach for Lisp to do it. My eyes don't like it. (Also I like static types).
------
The syntax is actually a big pro for a lot of people. I love its streamlined look that basically reads like Python once you let your IDE indent properly and learn to see "through" the parentheses (CL, Scheme).
The original language where everything is an expression and it shows. Where Python still needs an ugly ternary and made match a statement, Lisp has had the perfect IF and COND since the dawn of time.
Symbols are still a cool and useful concept that almost no other language I know of got.
The numerical tower - despite some holes - is amazing. Built-in rationals and "correct math" as sane default (i.e. 1/2 not returning 0) never get old.
------
And if you let me rave about CL specifically (e.g. DECLARATIONs as "#pragma done well", restarts, CLOS/MOP, runtime READ/COMPILE, etc...), there are a lot of cool features barely copied anywhere that'd improve other languages, but these aren't part of "what make Lisp Lisp".
I was really impressed by how small the executable file was. I’d only ever done web development with Node.js up until then.
But I am truly biased. I have basically forgotten how to code everything else (besides APL family languages) in the past _checks notes_ 10 months since I started Janet. I even run a community [docs site](https://janetdocs.org/) and am writing [my own tutorial](https://janetdocs.org/tutorials/learn-to-program) (albeit slowly). I even use it in production for all new software (within 3 weeks of starting, I had rewritten all personal scripts etc.)
> Janet is simple
You can do literally everything with just hashmaps. The whole language is basically a hashmap, implementation wise. `(keys (curenv))` prints out all locally defined symbols. `(keys (getproto (curenv)))` prints the parent hashmap of the current environment i.e. all the core symbols. I don't, but you can basically do CLOS via hashmaps (and there is a [fuller implementation](https://git.sr.ht/~subsetpark/fugue) too.)
> Janet is distributable
I have like 20 websites and another dozen or so services running on Janet (with the [Joy webframework](https://github.com/joy-framework/joy) which I wrote a [tutorial](https://janetdocs.org/tutorials/Joy-Web-Framework) for), on a single free-tier VPS with 512mb of RAM.
> Janet has ... immutable collections
...not really. In reality, the whole standard library constantly returns mutable versions from everything. There's no reason to really try to be immutable at this point. Although there are cool [combinator libraries](https://git.sr.ht/~subsetpark/apcl-janet) and I've even made combinatorish versions of basic functions:
Combinatory inspired cond, which allows for pairs. The test does not need an argument and the body may be a simple value or a function: > Janet lets you pass values from compile-time to run-timeThat's what got me hooked, in a few ways. In Racket or Go, I had to do a lot of work to process data at compile time so the runtime could literally just be a lookup table. In Janet? That's the default behavior of any `def` outside of main. The following turns a .tsv of the bible into a hashmap in the binary, when compiling:
So the rest of the program is literally just accessing the hashmap ([twice as fast](https://codeberg.org/veqq/verse-reader#performance) as the Golang version using `embed`): The equivalent go program was 5x longer and required an extra program to convert data into a 40k line .go file with a giant literal hashmap, to be faster than the naive Janet....but actually Ian Henry means Janet e.g. keeps closures synced across images/sessions:
Exit and start a new REPL session: It saved the closure and all relevant image in the `(curenv)` hashmap.Condensed from my longer response: https://lobste.rs/s/y0euno/why_janet_2023#c_lspe6n
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
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 is basically a reoccurring theme on every programming forum, whenever a Lispy PL gets mentioned. There are tons of confused programmers who look at Lisp examples and "hate" it. Without a single practical experience of using Lisp. They don't know anything about structural editing, they never experienced REPL-driven development. And I'm not talking about shit like "Python REPL", which is a bleak attempt, a shallow shell compared to the "true Lisp REPL".
It takes a bit of time and curiosity to realize how enormously powerful, beautiful and practical the idea of Lisp is. And it's really sad that smart people refuse it outright, without even attempting to understand it. Sure, it may take some time to discard the old habits that took years to build and accept this unfamiliar thing. Yet there's a point, after which comes the realization that Lisp can literally replace every single programming language with better ergonomics. I'm so mad at myself for wasting huge chunk of my life, chasing things of lesser importance, instead of just figuring out Lisp sooner.
I guess, to a degree you're right - you either hate Lisp or love Lisp, there's no in-between. But "hate" means you simply don't know it. Once you do - there's no way not to fall in love.
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.
Now do
with fewer “syntactic tokens”.It has forced all programmers to write everyday a lot of superfluous boilerplate for the most frequently used kinds of loops as the price for being able to write some very rarely used kinds of loops.
A much better solution would have been to keep the kind of "for" loop used in PL/I and ALGOL 68, 2 languages from which C has taken many other features, and to add an extra kind of "for", for the rarely used loops.
An even better solution had been found quasi-simultaneously with C in the programming languages Alphard and CLU, where instead of inventing this kind of complex "for", they invented iterators, which allow the writing of "forall" loops having the same form as that for arrays or for arithmetic progressions, but for arbitrary data structures.
Iterators solve in a more ergonomic way the problem for which the C "for" was invented, i.e. to write loops that visit all the members of a linked list or similar data structures.
Your example is also solved trivially in a language with iterators, you just define a geometric progression as a generic type and then you can write a "forall" loop that iterates over all its elements.
The fact that the language C permits to omit the curly braces around a single statement helps to reduce its excessive verbosity, but not enough.
In your "if" example, you have 4 syntactic tokens: "if", "(", ")" and ";".
This is still an extra token in comparison with ALGOL 68, where your example would be written so:
which uses only 3 syntactic tokens. The opening parenthesis that must follow C keywords like "if", "for", "while" is always a superfluous syntactic token.For the verbosity of a programming language, only the number of syntactic tokens matters, because, depending on the preferences of the programmer, one syntactic token can be represented by either a long keyword or by an abbreviation or by a single symbol.
If minimum verbosity is desired, single symbols can be used for each syntactic token, e.g. in my own programming language the 3 syntactic tokens of ALGOL 68 would be single symbols:
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
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.
I guess you don't like Lisp's syntax. I didn't either until I realized the key insight: when you're writing Lisp, you're basically writing an AST. Which is why it's so easy to manipulate your code. Want a new feature the language doesn't have, such as the pattern-matching they added to C# a few versions back? You can add it yourself; you don't need to wait for a language committee to implement it years after you needed it. That's all that macros are: functions that take AST and return AST, which is then executed.
And once I realized that Lisp's syntax was basically an AST, I no longer saw the parentheses. Now I just see blonde, brunette, redhead... Oops. Sorry. Wrong reference.
Really? I've used dozens of languages and honestly, I just can't wrap my head around how ugly Lua code can get. At first, I tried treating it as "javascript with no bad parts", turns out, modern JS is far, far better than 1996 JS and nicer than Lua. The most annoying part about Lua is that I never know how to format it for better readability - should I add line breaks, or not, etc. lua-fmt often just makes it worse.
When I found Fennel I immediately moved to it, even though it was "experimental". Since then, I just don't want to deal with Lua, aside from some small one-liners.