Comment by wolfi1

6 hours ago

why is it called Janet? perhaps to prevent it to be identified with the acronym for Lots of Irritating Single Parenthesis?

If it was called [Something] Lisp, Lisp enthusiasts would complain that it’s not a lisp because it does not use linked lists as the primary data structure.

I know that Lisp has lots of paranthesis and I don't have enough experience with Lisp at all.

But from the looks of it, Janet has some great ideas like the one that @ramblurr shared here about sandboxing ("Disable feature sets to prevent the interpreter from using certain system resources. Once a feature is disabled, there is no way to re-enable it.")

Lisp from my understanding is incredibly polarizing and many people love it and many people hate it and that's fine, but at a certain point wouldn't it feel repetitive for statement like this and I am unsure of how healthy discussion about programming concepts can be done this way.

There are so many interesting things from lisp-y languages like Janet and Julia is technically lisp-y too and Julia's compilation to GPU is awesome and Nim too which can compile to C/C++/JS!

It's just so many interesting concepts overall in programming that paranthesis don't seem a concern to me as the underlying concept can be translated to something else, like sandboxing feature, transpilation to GPU or multiple targets!

And there are many unique concepts in non-lispy languages like golang (cross-compat, portability with static binaries), elixir (concurrency!) too.

It's just good to see the amount of innovation within programming from all spheres of influence :-D

  • While I do not like the excess of parentheses of LISP and similar languages, their syntax is very consistent and predictable. Moreover, while LISP has an excess of parentheses, it omits a greater number of commas that are required in many other programming languages.

    I am much more annoyed by the random syntax inconsistencies of most popular programming languages, which are either caused by original language design mistakes, or, more frequently, by the late addition of some features that were not planned in the original language, so they had to be squeezed in with the help of various ugly workarounds.

    While during the last years I have not used much LISP like languages, there have been times when I used them a lot, for several years, in scripting applications, e.g. the LISP variant of old AutoCAD, the Scheme-like scripting language of the Cadence EDA applications, or the scsh Scheme dialect that is usable for replacing UNIX shell scripts.

    In all cases, these languages allowed a greater productivity associated with rarer bugs than the more popular scripting languages, like Python, Perl, TCL, bash.

    While aesthetically I might prefer the look of a Python program, for solving a practical production problem I would prefer to write scripts in one of the LISP derivatives. Obviously, the productivity in various programming languages depends a lot on individual preferences and previous experiences.

    It should be noted by all those who believe that the LISP-derived languages have too many parentheses, that the C programming language and all languages with syntax derived from it, like Java or Rust, have a great excess of parentheses in comparison with the older languages that had better designed syntaxes, e.g. ALGOL 68 or IBM PL/I.

    For example, compare

      for (i = 1; i <= 100; i += 5) { ... }
    

    with

      for i from 1 to 100 by 5 do ... od
    

    or

      if ( ... ) { ... } else { ... }
    

    with

      if ... then ... else ... fi
    

    The first example has 12 syntactic tokens instead of the minimum required, which is 6.

    The second example has 8 syntactic tokens instead of the minimum required, which is 4.

    If I cannot have a decent programming language with a minimum number of parentheses, I would rather have a programming language where all the places that need parentheses are predictable, like in LISP, instead of having a language like C and its derivatives, which require parentheses in random places, for no good reason at all.

    • Now do

          for (i = 1; i <= 128; i *= 2) { … }
      

      with by.

      Now do

          if (x <= 0)
              throw ParameterException;
      

      with fewer “syntactic tokens”.