5 ms·

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 t

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

xigoi 4y ago
How does the example not show control flow?
StreamBright 4y ago
I guess: f x -- obscure and mathematical (f x) -- too many parentheses f(x) -- PERFECT
- fm2606 4y ago
  >> (f x) -- too many parentheses >> f(x) -- PERFECT They have the same number of parentheses. f(x) is probably something you have seen for the majority of your life as this is how math is taught.
  - StreamBright 4y ago
    I was just saying that syntax arguments most of the time are silly. I like LISP and ML languages, so for me it doesn't really matter if I need to write LISPy code or ML code.
- ElfinTrousers 4y ago
  Well hold on, what's wrong with (f) x?
hnlmorg 4y ago
Readability can be a subjective property. For anyone who’s spent even a casual amount of time with S-Expressions, the example code is extremely readable. But if ALGOL-like code is your main source of experience, then Janet will look like executable line noise.
bmacho 4y ago
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.""" tab = {} solutions = {} l = len(s) for k in range(0,l) : tab[ s[k] ] = k for i in range(0,l) : for j in range(0,l) : k = tab.get( -s[i]-s[j] ) if k and k != i and k != j and i != j : solutions[ {i:True, j:True, k:True} ] = True return solutions pretty much the same. Python is not working because it can't hash dicts, while janet interprets {1:True, 2:True} the same as {2:True,1:True} when these are keys (I think?). In the example janet returns (map keys (keys solutions)) instead of the "solution" dict that converts dicts like {{1:True, 2:True} : True} into [[1,2]], but I don't get it how. But syntactically janet is not much worse(?).
- jpk 4y ago
  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.
  - nmz 4y ago
    This is kind of unfair, unless you're in an indent based language you cannot get rid of this. The only other solution I've seen was in a pascal-like language, where you did end function NAME and that would close everything inside.
modernpink 4y ago
I assume you've not done LISP or LISP-like languages before?

xigoi 4y ago

How does the example not show control flow?

StreamBright 4y ago

I guess: f x -- obscure and mathematical (f x) -- too many parentheses f(x) -- PERFECT

fm2606 4y ago
>> (f x) -- too many parentheses >> f(x) -- PERFECT They have the same number of parentheses. f(x) is probably something you have seen for the majority of your life as this is how math is taught.
- StreamBright 4y ago
  I was just saying that syntax arguments most of the time are silly. I like LISP and ML languages, so for me it doesn't really matter if I need to write LISPy code or ML code.
ElfinTrousers 4y ago
Well hold on, what's wrong with (f) x?

hnlmorg 4y ago

Readability can be a subjective property. For anyone who’s spent even a casual amount of time with S-Expressions, the example code is extremely readable. But if ALGOL-like code is your main source of experience, then Janet will look like executable line noise.

bmacho 4y ago

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.""" tab = {} solutions = {} l = len(s) for k in range(0,l) : tab[ s[k] ] = k for i in range(0,l) : for j in range(0,l) : k = tab.get( -s[i]-s[j] ) if k and k != i and k != j and i != j : solutions[ {i:True, j:True, k:True} ] = True return solutions pretty much the same. Python is not working because it can't hash dicts, while janet interprets {1:True, 2:True} the same as {2:True,1:True} when these are keys (I think?). In the example janet returns (map keys (keys solutions)) instead of the "solution" dict that converts dicts like {{1:True, 2:True} : True} into [[1,2]], but I don't get it how. But syntactically janet is not much worse(?).

jpk 4y ago
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.
- nmz 4y ago
  This is kind of unfair, unless you're in an indent based language you cannot get rid of this. The only other solution I've seen was in a pascal-like language, where you did end function NAME and that would close everything inside.

modernpink 4y ago

I assume you've not done LISP or LISP-like languages before?