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

161–170 of 203 posts

Re: The Janet Language

#161

Post by ravi-delia »

camdez wrote: post #152
mike_hock wrote: post #99

Earlier quoted context omitted.

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

Agreed. This is why I don't do any math I can't do on my fingers. Parentheses are just too scary, and there's no way that parenthesis math junk actually has any useful ideas.

I understand the reaction, but some people feel just as negatively about parentheses as lispers feel positively. If I can feel positively about a language purely because of the parens, it's no sillier to feel negatively for the same reason.

Re: The Janet Language

#162

Post by ravi-delia »

jdrek1 wrote: post #155
mypetocean wrote: post #142

Earlier quoted context omitted.

The funny thing is that it's _not_ more parentheses, roughly, than one would expect to find in any Algol/C-inspired language, like C# or JavaScript. The opening paren is simply relocated to the other side of the function name or keyword. What we're experiencing is just a cognitive bias which causes us to prefer the more familiar over the less familiar ([the mere-exposure effect, also called the familiarity principle]…

There are strictly more parentheses since other languages also use [] and {} (and ) instead for different things. Or even ; or whitespace. Ignoring the majority of available brace types is just stupid if you ask me. The parentheses being at the wrong positions is something I can deal with (still no fan of RPN, but w/e), but intentionally crippling syntax that could help is just not a good idea. Syntax is your friend,…

Janet also uses [] and {}, and there is a reason people like the really consistent syntax. For me that reason is blind aesthetics, but I swear to you I sincerely find lisp code easier to read than non-lisp code. It's not "intentionally crippling syntax" it's a genuine difference in taste.

Re: The Janet Language

#163

Post by ElfinTrousers »

StreamBright wrote: post #83
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 guess: f x -- obscure and mathematical (f x) -- too many parentheses f(x) -- PERFECT

Well hold on, what's wrong with (f) x?

Re: The Janet Language

#165

Post by ravi-delia »

dri_ft wrote: post #59
pmoriarty wrote: post #29

I love Lisp (particularly Scheme), and heard that Janet was strongly inspired by Lisp and is "really Lisp underneath", but is really fast and strong at math, so I thought I'd give it a try, and after learning it I started wondering to myself, "why am I not simply using Lisp?" Though arguably lispy, Janet just wasn't lispy enough for me. It was missing the simple, elegant sexp syntax I dearly loved, and I started to w…

>It was missing the simple, elegant sexp syntax I dearly love In what sense does Janet not have sexp syntax? Seems plenty sexpy to me. Purists seem to say it's not a lisp because its underlying data structure is not (cons-based) lists as in classical lisp, but I don't see what syntactic difference there is.

Op was understandably confusing Janet with Julia

Re: The Janet Language

#166

Post by ravi-delia »

progre wrote: post #33
pmoriarty wrote: post #29

I love Lisp (particularly Scheme), and heard that Janet was strongly inspired by Lisp and is "really Lisp underneath", but is really fast and strong at math, so I thought I'd give it a try, and after learning it I started wondering to myself, "why am I not simply using Lisp?" Though arguably lispy, Janet just wasn't lispy enough for me. It was missing the simple, elegant sexp syntax I dearly loved, and I started to w…

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.

Op was thinking of Julia

Re: The Janet Language

#167

Post by ravi-delia »

nine_k wrote: post #36
pmoriarty wrote: post #29

I love Lisp (particularly Scheme), and heard that Janet was strongly inspired by Lisp and is "really Lisp underneath", but is really fast and strong at math, so I thought I'd give it a try, and after learning it I started wondering to myself, "why am I not simply using Lisp?" Though arguably lispy, Janet just wasn't lispy enough for me. It was missing the simple, elegant sexp syntax I dearly loved, and I started to w…

The list of features available out if the box is pretty impressive, especially if you are scripting something concurrent. I would tolerate the syntax quirks in exchange for that. Or maybe your particular Scheme has all of that out of the box, too. Which one do you normally use, if you don't mind?

Op was thinking of Julia

Re: The Janet Language

#168

Post by tmtvl »

mypetocean wrote: post #143
mypetocean wrote: post #142

Earlier quoted context omitted.

The funny thing is that it's _not_ more parentheses, roughly, than one would expect to find in any Algol/C-inspired language, like C# or JavaScript. The opening paren is simply relocated to the other side of the function name or keyword. What we're experiencing is just a cognitive bias which causes us to prefer the more familiar over the less familiar ([the mere-exposure effect, also called the familiarity principle]…

Oh, I guess Markdown doesn't work. Huh. Well, shoot.

HN comment formatting options can be found here: https://news.ycombinator.com/formatdoc

Re: The Janet Language

#169

Post by eggy »

sergiotapia wrote: post #129
mike_hock wrote: post #99

Earlier quoted context omitted.

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

Same reaction here... wow that is a rough looking language. Then again I always disliked those kinds of languages like Clojure. The syntax is just too much for me. I feel like if I used it, it would atrophy my skills in other more traditional languages.

Quite the opposite. Learning a Lisp or an Array language will build your skills and make you a better programmer. Syntax should fade as a criteria as you become proficient in various PLs.

For example, the sum of a list (not running or cumulative sum, but total sum. Should equal 10, not 1, 3, 6, 10):

Lisp:

  (+ 1 2 3 4)
J/APL[0]:

  +/1 2 3 4
Python:

  Sum = sum([1,2,3,4])
  print(Sum)
They all do the same. I prefer the conciseness of J/APL and Lisp in this case, and the application of a function over the list or vector. The beauty of the REPL is that you see the result without a 'print' statement.

Solving problems in these other languages will influence how you program in your base language as well, and usually for the better. I am also guilty of syntax bias. I prefer LFE (Lisp Flavoured Erlang)[3] over Elixir and Gleam. Gleam[1], another language that runs on the Erlang VM (BEAM), had a more ML syntax, but then it chose to join the syntax popularity contest and move to a more Algol/C/Rust syntax. I prefer vanilla Erlang over it too.

[0] https://www.jsoftware.com/#/ [1] https://gleam.run/ [3] https://lfe.io/

Re: The Janet Language

#170

Post by lispm »

crabbone wrote: post #160
lispm wrote: post #68

Earlier quoted context omitted.

The 'terminal' restriction is long gone. Most Lisp read-eval-print-loops run inside an editor or another specialized tool. In Common Lisp: CL-USER 37 > (sin 3) 0.14112 CL-USER 38 > (cos *) 0.9900591 Above really is (cos (sin 3)). The variable * is bound to the last result.

How'd you go about multiple-value-bind? Same problem with handler-case. When used interactively, Python also has _ to store the previous value (but Python only ever really returns single value, which is sometimes a tuple or a list that can be deconstructed into variables, iirc in CL if you don't request other return values, they are gone.) More generally, you'd want more of xargs-like functionality (eg. split result…

> Java-like languages don't immediately support something like that, but Shell-like do with redirection syntax, tee, xargs.

But in Lisp you are not bound to the language syntax of Java. You can inside the language write tools to process forms. That's one of the main differences between Java and Lisp. Lisp has reader macros (to change the surface syntax of s-expressions) and macros to change the expression syntax. That would allow you to write tools to process code and results in arbitrary ways.

Multiple-values results in a REPL are handled by the variable /. That one is the list of the last values.

  CL-USER 4 > (values 1 2 3)
  1
  2
  3

  CL-USER 5 > (multiple-value-bind (a b c) (values-list /) (list a b c))
  (1 2 3)
But anyway, I would not write Common Lisp in a pure terminal without editing support.

Something like GNU Emacs can use tools like SLIME or has a SHELL mode. That one works fine in a terminal.

SLIME is one of the Common Lisp IDE extensions for GNU Emacs and works fine in a terminal. Writing even the most complex code inside an GNU Emacs & SLIME terminal session is no problem at all. If I have a function call (foo a) and I want to wrap code to the front, I would just move the cursor one s-expression back and type. I'm sure that's easier with one of the other editor extensions which make editing s-expressions kind of structural.

EVEN then, many people write the actual Lisp code in an editor buffer (say GNU Emacs in a terminal connected to a Lisp process via SLIME) and send the expression for evaluation to a connected or underlying interactive Lisp sessions. The editing of s-expressions in a terminal to move forward, backward, upward, etc is really a non-issue.

Interactive read-eval-print-loops does not mean one is forced to use a terminal without editing support.

Post reply on HN