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

81–90 of 280 posts

Re: Janet: a lightweight, expressive and modern Lisp

#81

Post by yrio »

pron wrote: post #55
varjag wrote: post #34

Earlier quoted context omitted.

The first point clearly didn't pan out. In reality, applications ended up bundling their own OSes along, so Clojure is stuck with antiquated VM on its ankle for no good reason.

That "antiquated" VM is head and shoulders above any other extant runtime in compilation, GC and observability. Not only that, most of the major innovations in recent years in those areas seem to be happening there. Moving from the JVM to almost anything else -- be it Python, Go, Erlang or Node -- feels like being transported to medieval society. Don't get me wrong, some find it liberating as in, huh, I turns out I c…

What do you think about .NET?

Re: Janet: a lightweight, expressive and modern Lisp

#82

Post by junke »

mhd wrote: post #46
oblio wrote: post #26

Earlier quoted context omitted.

It's not really something new. Ada ( https://en.wikipedia.org/wiki/Ada_(programming_language) ) was created 40 years ago. Kids with crazy names is a long standing tradition, going back millenia :-)

Also Amos, Haskell, Idris, Joy, Miranda or Yorick. Arguably Dylan or Pascal. I'm more confused by a name starting with a capital "J" not being associated with Java, as once was custom. As for kid's names, definitely[1]. [1]: https://www.youtube.com/watch?v=Jg9w0YSMLHY

Julia too

Re: Janet: a lightweight, expressive and modern Lisp

#83

Post by cellularmitosis »

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.

1) the startup time is fantastic https://github.com/janet-lang/janet/issues/324#issuecomment-...

Function call throughput is just behind the JIT’ed lisps, which is understandable for a bytecode runtime.

Re: Janet: a lightweight, expressive and modern Lisp

#84

Post by anonymoushn »

HelloNurse wrote: post #65
anonymoushn wrote: post #44

Earlier quoted context omitted.

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 t…

Right, we improved the performance by moving the work out of the JVM.

It's my fault that if you trade US equities based on old information you lose money?

Edit: Actually, I'm still not sure how to correctly measure GC pauses, other than from inside the application.

Re: Janet: a lightweight, expressive and modern Lisp

#86

Post by pron »

yrio wrote: post #81
pron wrote: post #55

Earlier quoted context omitted.

That "antiquated" VM is head and shoulders above any other extant runtime in compilation, GC and observability. Not only that, most of the major innovations in recent years in those areas seem to be happening there. Moving from the JVM to almost anything else -- be it Python, Go, Erlang or Node -- feels like being transported to medieval society. Don't get me wrong, some find it liberating as in, huh, I turns out I c…

What do you think about .NET?

It's probably the closest contender [1], but its non-Windows story is still a handicap, as is Microsoft's habit of making sweeping incompatible changes to their development platforms every 5-6 years.

[1]: A different philosophy that gives more control to the user in exchange for explicitness puts it ahead in some areas (structs) and behind in others (compilation quality, GC), but as a runtime engineer it's "technologically" behind (I work on OpenJDK so I'm biased, but I came to work on OpenJDK because that's where most interesting innovation in runtimes happens).

Re: Janet: a lightweight, expressive and modern Lisp

#87

Post by kleiba »

varjag wrote: post #34
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…

The first point clearly didn't pan out. In reality, applications ended up bundling their own OSes along, so Clojure is stuck with antiquated VM on its ankle for no good reason.

But that's besides the point, right? My question is about what Janet's niche is -- or are you arguing that we need a native Lisp because Clojure is only available on the JVM?

Re: Janet: a lightweight, expressive and modern Lisp

#88

Post by neutronicus »

flaie wrote: post #61
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…

> 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 I think is a fundamental impedance mismatch between Lispers and everyone else.

A Lisper sees a REPL, and thinks they have "gotten started." When I think most language learners don't think they have "gotten started" until they, on the low end, have printed something at a familiar terminal, or, on the high end, pointed a web browser to localhost:8080 and seen some text there.

Re: Janet: a lightweight, expressive and modern Lisp

#89

Post by widdershins »

w0utert wrote: post #30
phoe-krk wrote: post #13

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…

In terms of the basic tools available to you, Lisp and Lua are remarkably similar. In both you will rely heavily on closures to get the job you mentioned done. Lua offers the table as its primary data structure, though this can also be used as an array. Lisp offers the list, though this can also be used as a table (associative container, whatever).

Where Lisp and Lua differ is that Lisps are infinitely more malleable as languages. You can more-or-less invent new syntax to assist in your problem domain. For example, if you find that constructing your 'event nodes' requires boilerplate in Lua, you can write Lisp macros that make things clear again. Or you might write a little macro DSL to make constructing your graphs easier.

I enjoy Lua, but I constantly pine for the flexibility of a Lisp when Lua's clunky syntax annoys me. I find Fennel is a good compromise between the two - especially if you already have Lua code that you want to port over.

Re: Janet: a lightweight, expressive and modern Lisp

#90

Post by dmos62 »

phoe-krk wrote: post #8

janet:1:> (cons 1 2) compile error: unknown symbol cons on line 1, column 1 while compiling repl janet:2:> (list 1 2) compile error: unknown symbol list on line 2, column 1 while compiling repl janet:3:> (vector 1 2) compile error: unknown symbol vector on line 3, column 1 while compiling repl I certainly need to learn the basic idioms of this dialect; it looks nothing like Common Lisp under the hood.

I found this interesting so looked it up:

    Janet 1.9.1-4ae3722 Copyright (C) 2017-2019 Calvin Rose
    janet:1:> (array 1 2 3)
    @[1 2 3]
    janet:2:> (tuple 1 2 3)
    (1 2 3)
    janet:3:> (rest (tuple 1 2 3))
    compile error: unknown symbol rest on line 3, column 1 while compiling repl
    janet:5:> (tail (tuple 1 2 3))
    compile error: unknown symbol tail on line 5, column 1 while compiling repl
    janet:6:> (car (tuple 1 2 3))
    compile error: unknown symbol car on line 6, column 1 while compiling repl
    janet:7:> (cdr (tuple 1 2 3))
    compile error: unknown symbol cdr on line 7, column 1 while compiling repl
    janet:8:> (def t (tuple 1 2 3))
    (1 2 3)
    janet:9:> (def a (array 1 2 3))
    @[1 2 3]
    janet:11:> (drop 1 t)
    (2 3)
    janet:12:> (drop 1 a)
    (2 3)
    janet:13:> (first t)
    1
    janet:14:> (first a)
    1
Post reply on HN