Live data from Hacker News

Janet: a lightweight, expressive and modern Lisp

janet-lang.org

161–170 of 280 posts

Re: Janet: a lightweight, expressive and modern Lisp

#161
post #151

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…

That is a perfectly reasonable way of doing things. However, the official reference [0] recommends: (1) Your way (but also throw in an :only and doesn't mention :refer) (2) (require 'clojure.contrib.def 'clojure.contrib.except 'clojure.contrib.sql) (3) (require '(clojure.contrib def except sql)) And leaves open a lot of room for someone to try to use (use) which is probably a mistake since you don't use it. And somet…

> Even your way has two completely different code paths (import vs require) to bring in dependencies.

import and require have different purposes though, it makes perfect sense to me that they are separate. Import, here, is used to import Java classes, which don't hook into Clojure's namespaces directly; require is for bringing in symbols from Clojure namespaces. In general, a beginner or intermediate Clojure user will not touch the :import feature at all, nor the :use feature.

> It is really sloppy and confusing to learn.

That's one opinion of it I guess; though in my experience, the way that I do it is very common in publicly-visible Clojure modules. I've been doing it the same way since day one, without issue. There may be other ways, but you don't really need to care about them.

With this you'll understand most modules you come across, and you'll be able to accomplish basically anything you'll want to.

Given the average completeness of documentation on publicly-visible packages (though to be fair most big ones have what most would consider adequate documentation) including the core, you're going to have lots of opportunities to read other people's modules, and these minutiae will fade into obscurity and be overshadowed by your own program's problem space.

Re: Janet: a lightweight, expressive and modern Lisp

#162
post #106

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…

I've posted this quote before, but it might help explain why making Clojure easier to get into maybe hasn't been a priority for Hickey et al. So we need players. I would rant here, but I won't. But look at this guitar player with blisters. A harpist has blisters, a base player with blisters. There's this barrier to overcome for every musician. Imagine if you downloaded something from GitHub and it gave you blisters.…

I am full to my neckline with Clojure kool-aid: I love the language and programming experience. But the "getting started" your parent is referring to, IMO, is getting the tooling set up, getting the repls connected, figuring out what a full-stack app looks like with its 2 distinct repls and toolchains and lein config mashups, hooking up an editor... and then having it break the next day. After 5 years of Clojure I still get frustrated if I'm away for more than a month.

It's like you were getting blisters from stringing your guitar. You buy a guitar, get home, and it takes three days to open the case. Then another week to figure out which strings go where. God help you when you realize you have to tune the thing.

Two, five, seven days pass and you haven't played a note. I don't think that's what Hickey meant.

That said, it's worth it.

Re: Janet: a lightweight, expressive and modern Lisp

#163

Earlier quoted context omitted.

> you install clojure (via brew, or sh install) and that's it, you're good to go The vast majority of PCs are Windows, not Mac or Linux. Though WSL2 (available with Windows Insiders) makes working with Linux software a breeze, it's not the standard flow. Java isn't installed by default, either. Your guide suggests using WSL and IntelliJ. Does IntilliJ actually work with Closure running in WSL? For that matter, does t…

The Windows story for Clojure is disappointingly weak, especially if you are going by the "Getting Started" section on their website.[0] They have reasonable instructions for Linux and MacOS, but for Windows they point you to an "alpha" level tool. I think this is especially disappointing because there are mature, cross platform solutions available but whoever manages the Clojure project seems hell bent on pushing th…

At least lein and boot-clj is available for/via scoop.sh. Seems a bit of a missed opportunity that "official" clojure "clj" isn't just using scoop.

Re: Janet: a lightweight, expressive and modern Lisp

#164
post #125
post #97

Earlier quoted context omitted.

Of course, that's not the official instructions. These are the official instructions: https://github.com/clojure/tools.deps.alpha/wiki/clj-on-Wind... - they've managed to work out what the powershell is for "run untrusted shell script directly from HTTPs". What there should be is an exe or MSI installer like every other Windows program.

The official instructions are here, https://clojure.org/guides/getting_started#_installation_on_... Not directly the link you provided. Yes, they require Java knowledge I guess, but then again using guest languages without caring for the host platform is a fallacy. Now I do agree that an installer would be the right experience to provide.

So according to that page, there are 3 ways to install on Windows.

1. Alpha version of "clj on Windows", which seems to be the recommended approach, and requires going to another page to get the instructions.

2. Homebrew on Linux or Windows with WSL, linked to under "Installation on Linux".

3. Build from source, under "Other ways to run Clojure", which assumes git, Java, and Maven installed, with no instructions on how to install them.

I would say it's pretty confusing from that what is the optimal, recommended way to install Clojure on Windows. It might be better to have subheadings under "Installation on Windows" like "For Java developers" (assuming Java tools already installed), "For WSL users" (Homebrew), "For Powershell users" (clj on Windows). This would consolidate the Windows installation strategies and reflect the diversity in the Windows developer population. Some are already full time Java developers, some live in WSL as much as possible, and some fully embrace Windows specific tools like Powershell.

Re: Janet: a lightweight, expressive and modern Lisp

#166

Earlier quoted context omitted.

Janet's purported focus is that it's easy to embed in a larger C program. I haven't really seen that in practice, but I have used the C api to write some language extensions, and it is a joy. In comparison with Clojure, I much prefer using either C or janet to using Java and lisp side by side; with Clojure running on multiple hosts now the differences in language semantics between clj and cljs are just annoying. As f…

> Janet's purported focus is that it's easy to embed in a larger C program. There is Guile https://www.gnu.org/software/guile/ that is an implementation of Schema with the focus on being an extension language that integrates with C and C++. Wouldn't it more practical to adopt and contribute to it, rather than invent an own wheel?

I'm in no way associated with Janet, so I can't answer for them. But as someone who is implementing their own language which shares a lot of goals with Guile, the reason I didn't contribute to Guile is that Guile is an implementation of the Scheme Standard, and it bound at least loosely to that. Certain modern features just aren't compatible and might not be accepted if you go through the effort of implementing them. There are real benefits to implementing a standard, and I'm not criticizing Guile for doing that--I use Guile. But if your goals aren't compatible with the standard you have no choice but to go a different way.

Re: Janet: a lightweight, expressive and modern Lisp

#167

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…

> Easy to get started: one click install, great website and concise docs. Idunno, I read the whole homepage and I don't really know where to go to download it. Is "clone and run Meson" what you meant by "one click install"? > No matter what some people say, getting started in Clojure is a nightmare. On my distro I just do pacman -S clojure and I have a working clojure environment, on everything else it's usually avai…

[deleted]

Re: Janet: a lightweight, expressive and modern Lisp

#168
post #30

Earlier quoted context omitted.

> but when I try to reason about common subproblems I really have no idea how to map them to something like Lisp. For example how to efficiently implement a message bus with observers that can register for certain events. I think that's a badly posed question. The main benefits of using Lisp are its introspection and interactivity. You can use the REPL to inspect your message bus at runtime, you can modify parts of i…

Maybe I phrased that incorrectly indeed. It's not so much that I want to find a 'better way to implement a message bus', but more 'if I want to re-implement the message bus I already have, how can I use the features of a Lisp-like languate to improve the implementation'. For the logic in my iOS game I started out with a straighforward imperative system based on objects and explicit state, which quickly devolved in a…

For your particular example, it seems you could use a dataflow approach, like the one in Cells (K. Tilton)

(see tutorial: http://stefano.dissegna.me/cells-tutorial.html, and documentation: https://gitlab.common-lisp.net/cells/cells/-/tree/master/doc)

    (ql:quickload :cells)
    (defpackage :robot (:use :cl :cells))
    (in-package :robot)
Define a robot model (class) where command in an input, and velocity is defined by an update rule:

    (defmodel robot ()
      ((command :accessor command :initform (c-in nil))
       (velocity :initform (c? (case (command self)
                                (:left -10)
                                (:right 10)
                                (t 0))))))
Whenever command is modified, velocity is updated accordingly. You can add observers for slot changes:

    (defun log-change (what from to)
      (print `(:change ,what :from ,from :to ,to)
             *debug-io*))

    (defobserver velocity ((model robot) new old boundp)
      (when boundp
        (log-change `(velocity ,model) old new)))
Then, if you instanciate the model, and mutate the command slot:

    (let ((w (make-instance 'robot)))
      (setf (command w) :right)
      (setf (command w) :left)
      (setf (command w) nil))
The following is logged:

    (:CHANGE (VELOCITY #) :FROM 0 :TO 10) 
    (:CHANGE (VELOCITY #) :FROM 10 :TO -10) 
    (:CHANGE (VELOCITY #) :FROM -10 :TO 0) 
Anyway, the book Common Lisp Recipes (E. Weitz) is good for solving actual, pratical problems with Lisp.

Re: Janet: a lightweight, expressive and modern Lisp

#169
post #151

Earlier quoted context omitted.

That is a perfectly reasonable way of doing things. However, the official reference [0] recommends: (1) Your way (but also throw in an :only and doesn't mention :refer) (2) (require 'clojure.contrib.def 'clojure.contrib.except 'clojure.contrib.sql) (3) (require '(clojure.contrib def except sql)) And leaves open a lot of room for someone to try to use (use) which is probably a mistake since you don't use it. And somet…

> Even your way has two completely different code paths (import vs require) to bring in dependencies. import and require have different purposes though, it makes perfect sense to me that they are separate. Import, here, is used to import Java classes, which don't hook into Clojure's namespaces directly; require is for bringing in symbols from Clojure namespaces. In general, a beginner or intermediate Clojure user wil…

> For what it's worth, having used Clojure for work for a couple years now...

> ...it makes perfect sense to me that they are separate...

> A lib’s container is a Java resource whose classpath-relative path is derived from the lib name [0]

> No matter what some people say, getting started in Clojure is a nightmare. ~ galfarragem (earlier in the thread).

I'm hoping this smorgasbord of quotes is making my point for me - the fact that there is an easy way is good, but the problem is that the easy way is very well hidden and Clojure is competing with systems like 'pip install foo', 'import foo' in every single piece of documentation on Python there is on the internet.

I'm not budging from Clojure's import system being byzantine. I don't care that the people who stuck with Clojure figured out something that works for them, it is stupid and it is a very effective filter on keeping people out of the language. The lesson 'ignore half the reference manual page' is not an appropriate lesson to be learning while working out how to load dependencies.

EDIT If all the other parts of the project build were easy then obviously this wouldn't be an effective filter; but this combined with a misconfigured classpath issue for someone who doesn't know Java well would be the end of it.

[0] https://clojure.org/reference/libs

Re: Janet: a lightweight, expressive and modern Lisp

#170

Earlier quoted context omitted.

Janet's purported focus is that it's easy to embed in a larger C program. I haven't really seen that in practice, but I have used the C api to write some language extensions, and it is a joy. In comparison with Clojure, I much prefer using either C or janet to using Java and lisp side by side; with Clojure running on multiple hosts now the differences in language semantics between clj and cljs are just annoying. As f…

> Janet's purported focus is that it's easy to embed in a larger C program. There is Guile https://www.gnu.org/software/guile/ that is an implementation of Schema with the focus on being an extension language that integrates with C and C++. Wouldn't it more practical to adopt and contribute to it, rather than invent an own wheel?

Janet uses an MIT license, so you've got a pretty big divergence right there.
Post reply on HN