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

The Janet Language

janet-lang.org

Post reply on HN
Print view View original

101–110 of 203 posts

Re: The Janet Language

#101

Post by lispm »

xigoi wrote: post #80
lispm wrote: post #38

Earlier quoted context omitted.

Lisp usually has a lot of non-list data structures like arrays. records, strings, classes/objects, hashtables, ... For some data structures there is built-in syntax and with an extensible reader (the extensible parser for s-expressions) the user can add additional syntax. Janet uses a non-extensible parser for the data syntax. What Janet makes a 'not really a Lisp' is that "LISP" stands for "List Processor". Janet is…

An array is just a different way to implement a list data structure.

Lisp especially is built upon linked lists, which have different costs for (more or less) primitive operations (add to the front, get the front item, get a rest list, get a random element, add to the end, ...) compare to a primitive vector. There are also other features not easily replicated by vectors.

  CL-USER 40 > (rest '(1 2 3))
  (2 3)
Above REST operation does not allocate any memory.

  CL-USER 41 > (subseq '#(1 2 3) 1)
  #(2 3)
Above SUBSEQ returns a new vector. Alternatively it would need a more clever implementation underneath.

OTOH getting a random element has a different complexity in a linked list vs. a vector.

Re: The Janet Language

#102

Post by tincholio »

crabbone wrote: post #61

One thing that bothers me about languages that compose functions like this f(g(x)) is that when programming interactively f is typically an afterthought. So, you start out with g(x) and then need to go all the way back and add f . Similarly, when x turns out like it needs to be elaborated, and you either have to go all the way back, or edit the expression in place making it longer and inevitably facing problems with…

I'm not familiar with Janet, but I know it's Clojure-inspired, so it probably has threading macros, which are like shell pipes on steroids. In practice, when doing REPL-based development, it's very common to use these as opposed to (g(f x)).

Re: The Janet Language

#103

Post by masklinn »

SyrupThinker wrote: post #84
masklinn wrote: post #48

Earlier quoted context omitted.

> I'm pretty sure GP meant Closure Closure is not a language so hopefully not? > the language has matching immutable data structures for mutable ones [^1] Looking at the lingo being used, the extremely limited breadth of ABI, and the complexity they assert around "immutable" data structures, they're clearly imperative data structures you can't mutate rather than the persistent data structures you'd expect from a stro…

> Closure is not a language so hopefully not? Very true, the typo is strong in this one. > rather than the persistent data structures you'd expect from a strong clj inspiration What do you mean by persistent here? I assume some kind of shared memory instead of copying? Or something with more practical implications like deep immutability? > looks a lot more like a description of Python datatypes I am surprised where t…

> What do you mean by persistent here?

I mean the class of data structures called persistent: https://en.wikipedia.org/wiki/Persistent_data_structure

> I assume some kind of shared memory instead of copying?

Sure.

> I am surprised where this sentiment comes from. Because of the initial comment?

Because "tuple" for an immutable sequence is rather specific to Python.

And data structures related to clojure (or functional languages in general) would have some sort of logarithmic component because they'd be tree-based. Pretty much the only O(1) operation in functional data structures is prepending to a linked list.

Re: The Janet Language

#104

Post by dunefox »

mike_hock wrote: post #99
ianthehenry wrote: post #9

Oh hey! Nice to see this on the front page here. I love Janet -- I've been using it for about year and a half, and it's now my go-to scripting language when I need something more powerful than bash, or when I want to hack on goofy little side project (some examples in my profile). Parsing expression grammars (think, like, declarative parser combinators?) are a really great feature for ad-hoc text parsing -- and nicer…

I went there, saw the Lisp syntax, and noped back out.

Your loss.

Re: The Janet Language

#105

Post by DennisP »

cfiggers wrote: post #7

Janet is really powerful. Here's a small TUI text editor I'm writing in it, if you want to see a non-trivial example: https://www.github.com/CFiggers/joule-editor

Ooh, nice. I've been messing around with a weird text editor that started with that same tutorial, but in Nim. Janet is intriguing, I'll be digging into your code.

How was the debugging experience?

Re: The Janet Language

#106

Post by krapp »

cosmojg wrote: post #35
progre wrote: post #33

Earlier quoted context omitted.

I think its a pretty nice language. Those extra bits of syntax that makes it "not a lisp" are mostly around defining "not list" kind if data structures. I find it practical.

What data structure isn't just a list with extra steps?

An array in C is a list with fewer steps. Just a continguous chunk of memory of sizeof type * length.

You could fill that with linked list nodes, but it would be pointless.

Re: The Janet Language

#107

Post by co_dh »

mike_hock wrote: post #99
ianthehenry wrote: post #9

Oh hey! Nice to see this on the front page here. I love Janet -- I've been using it for about year and a half, and it's now my go-to scripting language when I need something more powerful than bash, or when I want to hack on goofy little side project (some examples in my profile). Parsing expression grammars (think, like, declarative parser combinators?) are a really great feature for ad-hoc text parsing -- and nicer…

I went there, saw the Lisp syntax, and noped back out.

Me too

Re: The Janet Language

#108

Post by jpk »

bmacho wrote: post #86
davbryn wrote: post #76

I think the language is unreadable. For me, the purpose of a programming language is to let a human talk to a machine. Show me (for instance) control flow for the example function on the home page. It just isn't making things easier

I tried to translate it to python, I translated (defn sum3 "Solve the 3SUM problem in O(n^2) time." [s] (def tab @{}) (def solutions @{}) (def len (length s)) (for k 0 len (put tab (s k) k)) (for i 0 len (for j 0 len (def k (get tab (- 0 (s i) (s j)))) (when (and k (not= k i) (not= k j) (not= i j)) (put solutions {i true j true k true} true)))) solutions) into def sum3(s) : """Solve the 3SUM problem in O(n^2) time.""…

One thing the Python version doesn't suffer from is lines that have to end in something like "))))". Syntax readability may be subjective, and I agree that the business logic in both examples are equally readable, but I think having to read and write a bunch of repeated punctuation at the end of a line, depending on how deeply the final statement is nested, is annoying. I don't know how Janet in particular handles error messaging around unmatched parens, but most languages have trouble localizing errors to the place where missing parens, curlies, etc actually are. This can be alleviated by rainbow highlighting paren pairs, or even having the editor auto-insert closing parens to make you less likely to forget one. But I think if you need additional help from the editor to make using the syntax a nice experience, that may be an objective sign that the syntax isn't the best.

Re: The Janet Language

#109

Post by cfiggers »

DennisP wrote: post #105
cfiggers wrote: post #7

Janet is really powerful. Here's a small TUI text editor I'm writing in it, if you want to see a non-trivial example: https://www.github.com/CFiggers/joule-editor

Ooh, nice. I've been messing around with a weird text editor that started with that same tutorial, but in Nim. Janet is intriguing, I'll be digging into your code. How was the debugging experience?

> I'll be digging into your code.

My apologies in advance, then! (Ha.) The "main" function is at the very bottom of src/joule.janet. So I'd recommend starting there.

As for debugging, Janet embraces REPL-driven development, so the debugging experience is all about setting up, interactively querying, and step-wise updating your program's state, live in memory, using the REPL. It's quite a bit different from a lot of languages—not better, intrinsically, just different. But I like it a lot.

Is your Nim editor public anywhere? I've heard a lot of good things about Nim and wouldn't mind exploring a real-world example.

Re: The Janet Language

#110

Post by otabdeveloper4 »

cosmojg wrote: post #35
progre wrote: post #33

Earlier quoted context omitted.

I think its a pretty nice language. Those extra bits of syntax that makes it "not a lisp" are mostly around defining "not list" kind if data structures. I find it practical.

What data structure isn't just a list with extra steps?

If by "list" you mean "linked list", then those are never used in practice. There is no place for this data structure in a modern CS toolbox.
Post reply on HN