Wow I never realized Janet was released more than 10 years after Clojure.
Clojure: 2007
Janet: 2019
Why Janet? (2023)
181–190 of 292 posts
Re: Why Janet? (2023)
#182Earlier quoted context omitted.
> 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. [2] https://www.t…
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.
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.
Re: Why Janet? (2023)
#183if those are the reason why you love janet, then you will love tcl because you will be able to do all the same things without drowning in parenthesis and weird syntax.
There are three languages worth learning that expand your mind: Lisp, Forth and Tcl. Despite all exhibiting homoiconicity, they couldn't be more different from one another.
(I'd include Rebol but it's as mind-blowing as it's dead technology from a lost timeline)
Re: Why Janet? (2023)
#184Earlier quoted context omitted.
This is such a undervalued benefit, once you've learned s-expressions, you can basically learn a bunch of languages without having to learn completely new syntax. It'll be slightly different, with different idioms and names, but a hell of a lot easier than doing the same across every "It's like C but 50% of the syntax is different actually" language out there, which is most of them.
Is the syntax really the stumbling block for most languages? Would Rust's lifetimes or Swift's isolation rules be easier if they used more parens? Are the scoping rule differences between Emacs Lisp and Scheme easier to comprehend because the syntax is similar?
[dead]
Re: Why Janet? (2023)
#185Pretty 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:…
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.
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.
Re: Why Janet? (2023)
#186DSLs. 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.
Re: Why Janet? (2023)
#187[dead]
Re: Why Janet? (2023)
#188Earlier quoted context omitted.
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.
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.
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
Re: Why Janet? (2023)
#189> 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.
> 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.
Re: Why Janet? (2023)
#190Earlier quoted context omitted.
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. Like, solve for x. (= (+ (* 2 x) 3) 11) (= (* 2 x) (- 11 3)) (= (* 2 x) 8) (= x (/ 8 2)) (= x 4) Though this isn't too bad. (= (+ (pow x 2) (pow y 2)) (pow r 2))
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?
> exists already
The helloworld of macros lets you do `(infix 1 + 2)`:
(defmacro infix [a op b]
~(,op ,a ,b))
(defmacro infix [& toks]
(def prec {'+ 1 '- 1 '* 2 '/ 2 '% 2})
(var pos 0)
(defn climb [min-p]
(var left (toks pos))
(++ pos)
(while (>= (get prec (get toks pos) -1) min-p) # nil/operand -> -1, stops the loop
(def op (toks pos))
(++ pos)
(set left ~(,op ,left ,(climb (inc (prec op)))))) # inc => left-associative
left)
(climb 0))