[Imustaskforhelp]

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

[iLemming]

> Lisp from my understanding is incredibly polarizing

No it's not! It's as "polarizing" as "group theory" or "set theory". Lisp is fucking math - it maps closely to formal mathematical/logical notation. You just can't "hate" math - you can be confused by it, be unfamiliar with it, intimidated by it. But hatred directed at something that is simply precise and consistent says more about the person than the thing.

This is basically a reoccurring theme on every programming forum, whenever a Lispy PL gets mentioned. There are tons of confused programmers who look at Lisp examples and "hate" it. Without a single practical experience of using Lisp. They don't know anything about structural editing, they never experienced REPL-driven development. And I'm not talking about shit like "Python REPL", which is a bleak attempt, a shallow shell compared to the "true Lisp REPL".

It takes a bit of time and curiosity to realize how enormously powerful, beautiful and practical the idea of Lisp is. And it's really sad that smart people refuse it outright, without even attempting to understand it. Sure, it may take some time to discard the old habits that took years to build and accept this unfamiliar thing. Yet there's a point, after which comes the realization that Lisp can literally replace every single programming language with better ergonomics. I'm so mad at myself for wasting huge chunk of my life, chasing things of lesser importance, instead of just figuring out Lisp sooner.

I guess, to a degree you're right - you either hate Lisp or love Lisp, there's no in-between. But "hate" means you simply don't know it. Once you do - there's no way not to fall in love.

[adrian_b]

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.

[NetMageSCW]

Now do

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

with by.

Now do

    if (x <= 0)
        throw ParameterException;

with fewer “syntactic tokens”.

[adrian_b]

The "for" structure introduced by the C programming language in 1974 was a very big mistake.

It has forced all programmers to write everyday a lot of superfluous boilerplate for the most frequently used kinds of loops as the price for being able to write some very rarely used kinds of loops.

A much better solution would have been to keep the kind of "for" loop used in PL/I and ALGOL 68, 2 languages from which C has taken many other features, and to add an extra kind of "for", for the rarely used loops.

An even better solution had been found quasi-simultaneously with C in the programming languages Alphard and CLU, where instead of inventing this kind of complex "for", they invented iterators, which allow the writing of "forall" loops having the same form as that for arrays or for arithmetic progressions, but for arbitrary data structures.

Iterators solve in a more ergonomic way the problem for which the C "for" was invented, i.e. to write loops that visit all the members of a linked list or similar data structures.

Your example is also solved trivially in a language with iterators, you just define a geometric progression as a generic type and then you can write a "forall" loop that iterates over all its elements.

The fact that the language C permits to omit the curly braces around a single statement helps to reduce its excessive verbosity, but not enough.

In your "if" example, you have 4 syntactic tokens: "if", "(", ")" and ";".

This is still an extra token in comparison with ALGOL 68, where your example would be written so:

  if x <= 0 then
    throw ParameterException fi

which uses only 3 syntactic tokens. The opening parenthesis that must follow C keywords like "if", "for", "while" is always a superfluous syntactic token.

For the verbosity of a programming language, only the number of syntactic tokens matters, because, depending on the preferences of the programmer, one syntactic token can be represented by either a long keyword or by an abbreviation or by a single symbol.

If minimum verbosity is desired, single symbols can be used for each syntactic token, e.g. in my own programming language the 3 syntactic tokens of ALGOL 68 would be single symbols:

  { x <= 0 ?
     throw ParameterException }