Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Janet: a lightweight, expressive and modern Lisp

janet-lang.org

Post reply on HN
Print view View original

261–270 of 280 posts

Re: Janet: a lightweight, expressive and modern Lisp

#261

Post by oalae5niMiel7qu »

jimbokun wrote: post #152
thih9 wrote: post #69

Earlier quoted context omitted.

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...

If you don't know what Java is, you are not in the Clojure target market.

Then they should stop talking about it in /r/Lisp. Nobody there wants anything to do with Java, but Clojurians won't shut up about it.

Re: Janet: a lightweight, expressive and modern Lisp

#262

Post by oalae5niMiel7qu »

pjc50 wrote: post #11

1) How is this different from other Lisps or Schemes? 2) When promoting a new programming language, always provide a nontrivial example. Couple of pages of code. Mandelbrot generator, desk calculator, notekeeping app, that sort of thing.

> How is this different from other Lisps or Schemes?

Janet has almost nothing in common with Lisp or Scheme, besides the parentheses and the presence of some form of macro system.

Re: Janet: a lightweight, expressive and modern Lisp

#263

Post by vindarel »

galfarragem wrote: post #35
kleiba wrote: 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…

Then you might like CL by trying it with Portacle, a one-click install away: https://portacle.github.io/ (there's also a good plugin for Atom, SLIMA)

CL is a breeze. Even installing new dependencies into a running image is a breeze, and no need to restart anything.

Re: Janet: a lightweight, expressive and modern Lisp

#264

Post by vindarel »

w0utert wrote: 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…

A great article on compile-time computing (with CL): https://medium.com/@MartinCracauer/a-gentle-introduction-to-...

There are good references and snippets on the Cookbook: https://lispcookbook.github.io/cl-cookbook/

for libraries, see https://github.com/CodyReichert/awesome-cl (and see the lparallel or lfarm libraries, channels, cl-gserver, the built-in SBCL threading functions, etc)

Also note that CL is not purely functional, you can throw in FP or OOP or iterative code.

Re: Janet: a lightweight, expressive and modern Lisp

#265

Post by microcolonel »

oalae5niMiel7qu wrote: post #260
microcolonel wrote: post #144

Earlier quoted context omitted.

> he was explicit that dependency/project management where very hard problems that Clojure didn't really attempt to solve. For what it's worth, having used Clojure for work for a couple years now, and ditching leiningen for deps.edn (built in package and dependency management that hooks into maven), I've not had an issue with it. You just add the dependencies to your deps.edn, and run your program. If your namespace…

>For what it's worth, having used Clojure for work for a couple years now, and ditching leiningen for deps.edn (built in package and dependency management that hooks into maven), I've not had an issue with it. >... >To be clear, projects like this can be run with the base Clojure distribution, no additional tools required. Didn't you just say that dependency management hooks into Maven? So doesn't that imply you need…

> So doesn't that imply you need to get Maven set up before you can run a Clojure project?

Not sure what is meant by "get Maven set up". With Clojure it does not involve any additional work, it's just built in to the Clojure runtime, and it goes ahead and fetches your dependencies either when you ask it to, or right before loading your program for the first time.

I think they just use the Maven repositories, as in the servers themselves, not the Maven client software for Java, whatever that may be (I've never used it).

Re: Janet: a lightweight, expressive and modern Lisp

#266

Post by prirun »

macleginn wrote: post #102

I looked at the first two libraries listed on the landing page, and they seem to be mostly implemented in C. (The same goes for the 3rd lib, but it's SQLite bindings, which makes sense.) This is a bit discouraging.

I have been looking at Nim, Go, and D lately, as a follow-on to Python. Good SQLite support is something I need for HashBackup (author).

Nim has a direct interface to SQLite's C API and a higher-level db_sqlite interface. The higher-level interface doesn't support prepared queries so Nim's SQLite performance on a small test is slower than Python using the sqlite3 API which automatically compiles and caches queries.

The Nim binding replaces all parameters, specified with ?, with quoted values. That means:

- you can't have a null-valued parameter

- numbers get inserted as text (I think)

- blobs are string quoted and get changed to text instead of using SQLite's X'(hex)' blob notation

All returned values from db_sqlite are strings. If you want integers, you have to parseInt() the column.

I do like that Nim's db_sqlite interface is very simple so that you can still use the lower-level sqlite interface with the same db connection. So at least I could cache prepared queries if I wanted, but I have to do the work.

Checking out Go's SQLite interface, there are some issues posted on the repo (mattn/go-sqlite3) about performance problems because Go uses cgo for SQLite. Haven't test that yet.

Since the SQLite module was listed on the front page of Janet's site, I decided to check it out. It, like all the other C code I looked at in the project, is rather beautiful, and that's not a compliment you see very often about C code, my own included.

The SQLite interface handles multiple types, including nulls, blobs, and numbers (everything is a float, I'm guessing because that's how Janet implements all numbers).

It appears to not cache prepared statements (that would probably be a big performance boost), but does allow parameter substitution by name.

If you want to see some really nice C code, check out this project!

Re: Janet: a lightweight, expressive and modern Lisp

#267

Post by capableweb »

blandflakes wrote: post #183
capableweb wrote: post #138

Earlier quoted context omitted.

> Clojure's startup time is pretty brutal for a lot of things I'd like to use it for, and no amount of REPL-driven development can make Clojure appropriate for CLI tools. If you got the repl-driven development down, you wouldn't test your CLI by launching it, you would just evaluate the same functions as the CLI uses. Only time when you'd want to launch the CLI would be before releasing a build or for E2E tests. Once…

It's not about testing, it's about using it. I know how to use a REPL :) GraalVM simply is not production-ready, though I follow its progress with great interest. That said, it's hard to compare the process of integrating with GraalVM against a language that actually just has fast startup. Babashka is pretty cool, but it's another example of something that isn't quite Clojure. Nice if you can tolerate various "almost…

I hear you, GraalVM is pretty new and while I've managed to write and deploy plenty of clis using it without any problems, it's a big hassle to deal with anything GUI or server related. So it does have a long way to go.

And while Babashka is not Clojure, it's interpreter (sci - https://github.com/borkdude/sci) is in fact a "Small Clojure Interpreter" that tries to stay as close to Clojure as possible. Unless you're using the Java interop, I've yet to hit anything I cannot do in Babashka that I could do in Clojure (I barely use Java interop)

Re: Janet: a lightweight, expressive and modern Lisp

#268

Post by flavio81 »

oalae5niMiel7qu wrote: post #258
armitron wrote: post #221

Earlier quoted context omitted.

I never thought I'd see a Lisp without lists. Oh wait, I didn't because this isn't a Lisp. I know naming is hard, but this is getting out of hand. Don't say you're a Lisp when you're clearly not. Say Lisp-inspired. Don't use the term 'modern Lisp', 9/10 it's signaling the wrong thing.

> Don't use the term 'modern Lisp', 9/10 it's signaling the wrong thing. I think it's signalling exactly the right thing. We know exactly what to expect when someone claims they've made a "modern Lisp". That phrase has come to mean "something with parentheses that demonstrates that its author doesn't understand Lisp at all."

Hilarious, but true!

Re: Janet: a lightweight, expressive and modern Lisp

#269

Post by flavio81 »

vindarel wrote: post #263
galfarragem wrote: post #35

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…

Then you might like CL by trying it with Portacle, a one-click install away: https://portacle.github.io/ (there's also a good plugin for Atom, SLIMA) CL is a breeze. Even installing new dependencies into a running image is a breeze, and no need to restart anything.

>Even installing new dependencies into a running image is a breeze, and no need to restart anything.

You don't even need to leave the REPL!

Re: Janet: a lightweight, expressive and modern Lisp

#270

Post by flavio81 »

Scarbutt wrote: post #233
pron wrote: post #60

Earlier quoted context omitted.

Is it? I've looked hard and couldn't find any runtime that isn't more than five years behind OpenJDK(+Graal) in those areas, but maybe I missed something. I'm not saying it's perfect, but there's nothing out there that's better in those areas.

You don't need Graal when you have Golang around the corner.

Golang's garbage collection system isn't just NOT state-of-the-art; it brings you back to the 1970s. A big pain point there.
Post reply on HN