Live data from Hacker News

Janet: a lightweight, expressive and modern Lisp

janet-lang.org

61–70 of 280 posts

Re: Janet: a lightweight, expressive and modern Lisp

#61
post #23

Okay, so when Clojure came along, it came with a strong underlying philosophy of what the language was supposed to be/do. Among them were design decisions such as, e.g.,: - VMs, not OSes, are the platforms of the future, so target the JVM - Object Orientation is overrated, but polymorphism is a good thing - Multi-core is here to stay, so use immutable data structures to greatly facilitate writing correct concurrent p…

What I like in Janet (I'm just a noob so take this comment with a grain of salt as it will sound superficial): - Easy to get started: one click install, great website and concise docs. No matter what some people say, getting started in Clojure is a nightmare. - Lightweight and fresh. No JVM, no Node. - Freedom and expressivity. Mutable or immutable data structures, ultimately is up to me. It might bite me down the ro…

> No matter what some people say, getting started in Clojure is a nightmare.

You just need Java installed on your system, then you install clojure (via brew, or sh install) and that's it, you're good to go.

I've written a guide to starting with Clojure covering installation to REPL & IDE configuration: https://grison.me/2020/04/04/starting-with-clojure/

Re: Janet: a lightweight, expressive and modern Lisp

#62
post #54
post #47

Earlier quoted context omitted.

I did a JVM targeting language as a research project, and was involved into porting KVM to an obscure architecture. It's been a while of course (early 00s) so maybe I misremember something or there were huge strides of progress in JVM. Can you jump over 64Kb in bytecode yet? Allocate a lexically scoped variable? Of course, enormous amount of work has been put into making this particular pig fly at reasonable speed. D…

From the narrow scope of web development, JVM is fine. Kotlin is able to have every ergonomic feature you'd want from a language, and it gets closer to the performance of C in TechEmpower than many other languages (notably C#, Node, and Python, three of the most popular languages). Tuning can be a pain, but scaling anything is hard.

It is clear that a lot of very important and practical work had been delivered with Java/JVM. But the original point was not about what is possible, but what is optimal.

Kotlin, from the little I've seen, appears to be largely a syntactic variation of Java, so there is certainly good impedance to JVM. Clojure is less so, and here lies the reason everyone curses about its backtraces.

Re: Janet: a lightweight, expressive and modern Lisp

#63
post #10

Lisp languages should be great for embedding into games to implement game logic, instead of more straightforward solutions such as embedding Lua. I've always wanted to explore this for my iOS side-project game, which now uses an event-based system inspired by ReactiveX, implemented in Lua. This works pretty well but is very hard to debug. The main thing holding me back to try to replace it with something Lisp-like is…

There is Nu which runs on top of the Objective-C runtime: https://programming-nu.github.io/ Relative easy to read code and has actually been used with some iOS games.

Re: Janet: a lightweight, expressive and modern Lisp

#64

I'd love to hear more from the author (can someone interview him for a podcast please? :-). He also has another programming language called Fennel [1] which compiles a lisp like language to Lua. Both Fennel and Janet seem to orbit around Clojure ideas.... interestingly one of Fennel's main contributors [2] is also the author of Clojure's most popular build system, Leiningen. 1: https://fennel-lang.org/ 2: https://tec…

I kept thinking that in the ‘small scripting Lisp’ category, a startup-time/performance comparison with Fennel would be apropos, as the latter is blazingly fast and thus well suited for scripting in interactive contexts.

Re: Janet: a lightweight, expressive and modern Lisp

#65
post #41

Earlier quoted context omitted.

> antiquated VM I'm always flabbergasted about the ignorance against the JVM on this site. There is nothing out there that has seen similiar research and optimisations and has so good monitoring/debugging tools.

My position on the matter might be summarized as "No TCO, no copyable stackful coroutines, no buy." Separately from that a lot of my experience with the JVM involves things like trusting the JVM's claim that it spent 0 microseconds GCing a certain thread that was running code specifically designed to produce no garbage, then running the code in production for one day and losing tens of thousands of dollars, then lear…

In other words, on the first day day of testing under realistic load conditions you learned how to measure GC pauses; then, presumably, you were able to improve performance.

It shouldn't have happened in a production environment, but setting up a way to lose tens of thousands of dollars if performance is bad, trusting unreasonable numbers, trying to produce no garbage, and requiring no GC pauses because margins are too tight are all your faults, not a shortcoming of your JVM.

Re: Janet: a lightweight, expressive and modern Lisp

#66
post #48
post #47

Earlier quoted context omitted.

I did a JVM targeting language as a research project, and was involved into porting KVM to an obscure architecture. It's been a while of course (early 00s) so maybe I misremember something or there were huge strides of progress in JVM. Can you jump over 64Kb in bytecode yet? Allocate a lexically scoped variable? Of course, enormous amount of work has been put into making this particular pig fly at reasonable speed. D…

so what's better and out there and reasonable stable?

Probably BeamVM, giving you better options for scaling, abstracting away machine borders and lightweight processes.

Re: Janet: a lightweight, expressive and modern Lisp

#68
post #61

Earlier quoted context omitted.

What I like in Janet (I'm just a noob so take this comment with a grain of salt as it will sound superficial): - Easy to get started: one click install, great website and concise docs. No matter what some people say, getting started in Clojure is a nightmare. - Lightweight and fresh. No JVM, no Node. - Freedom and expressivity. Mutable or immutable data structures, ultimately is up to me. It might bite me down the ro…

> No matter what some people say, getting started in Clojure is a nightmare. You just need Java installed on your system, then you install clojure (via brew, or sh install) and that's it, you're good to go. I've written a guide to starting with Clojure covering installation to REPL & IDE configuration: https://grison.me/2020/04/04/starting-with-clojure/

tried to install Clojure on Windows. Just flat out gave up.

Re: Janet: a lightweight, expressive and modern Lisp

#69
post #61

Earlier quoted context omitted.

What I like in Janet (I'm just a noob so take this comment with a grain of salt as it will sound superficial): - Easy to get started: one click install, great website and concise docs. No matter what some people say, getting started in Clojure is a nightmare. - Lightweight and fresh. No JVM, no Node. - Freedom and expressivity. Mutable or immutable data structures, ultimately is up to me. It might bite me down the ro…

> No matter what some people say, getting started in Clojure is a nightmare. You just need Java installed on your system, then you install clojure (via brew, or sh install) and that's it, you're good to go. I've written a guide to starting with Clojure covering installation to REPL & IDE configuration: https://grison.me/2020/04/04/starting-with-clojure/

This process might seem easy for you, but maybe not for people installing Clojure for the first time.

In an extreme case, someone who doesn't know Java ecosystem might want to stop to research: what is JVM, why is it necessary, which version would be the best, what's the difference between Oracle's Java and OpenJDK, etc...

Re: Janet: a lightweight, expressive and modern Lisp

#70
post #40

Earlier quoted context omitted.

Yet Clojure supports a subset of CLOS, so not so much overrated after all.

Clojure was never against any of the ideas in OO, just that they should be accessible individually if or when they make sense. Traditional OO is very “all in”, while Clojure is very a-la-carte use the bits that make sense for the problem you are trying to solve. Clojure also encourages a data-over-objects and a functional-first approach, but when you need the OO features, they’re there and you should use them.

Even Smalltalk supports the other way around, although very few are aware of it, because they never bother to learn it.

You can do LINQ style coding in Smalltalk-80, and modern Smalltalks like Pharo do support traits as well.

So the point being that all major languages embrace both paradigms.

"Traditional OOP" basically boils down to Java until version 8 or C# until version 3, and very little else, but unfortunately most teachers fail at giving overviews of programming languages thorough computing history, and many just learn what they can reach out for.

Post reply on HN