Let's take a step back. I feel this discussion has got off track a bit.

The original claim was that Lisp's reputation as having lots of parentheses was undeserved because it uses the same number of parens as other languages that use () for function calls; Lisp just puts the parens in a different place.

My objection was basically that Lisp also uses parentheses for what in other languages is a declaration, a statement, a block, an operator, etc so just looking at function calls doesn't give you the whole picture.

You said that "Lisp" is actually a family of languages, that Clojure uses fewer parens than other Lisps (I object: still more than non-Lisps), that there are macros for infix expression syntax (I object: non-standard/3rd-party solutions that only help with operators), that parens don't even matter because of structural editing tools (I object: irrelevant, the discussion was about the number of parens, not whether they "matter").

I also disagree with "the total number of parens in your examples is about the same". This is a micro-example, so when the original Lisp (Clojure) code has 4 pairs of parens and the C-style (JavaScript, Perl) version has 2, that's twice the parentheses to me, not "about the same".

I've tried to find a slightly bigger code sample, so I clicked around in the Clojure standard library. Here's a chunk of clojure.string: https://github.com/clojure/clojure/blob/ade22645ba5dbf4c0d8115b19938af96d6fb4cd5/src/clj/clojure/string.clj#L275-L317

(defn ^String trim-newline  "Removes all trailing newline \\n or return \\r characters from  string.  Similar to Perl's chomp."  {:added "1.2"}  [^CharSequence s]  (loop [index (.length s)]    (if (zero? index)      ""      (let [ch (.charAt s (dec index))]        (if (or (= ch \newline) (= ch \return))          (recur (dec index))          (.. s (subSequence 0 index) toString))))))(defn blank?  "True if s is nil, empty, or contains only whitespace."  {:added "1.2"}  [^CharSequence s]  (if s    (loop [index (int 0)]      (if (= (.length s) index)        true        (if (Character/isWhitespace (.charAt s index))          (recur (inc index))          false)))    true))(defn ^String escape  "Return a new string, using cmap to escape each character ch   from s as follows:   If (cmap ch) is nil, append ch to the new string.   If (cmap ch) is non-nil, append (str (cmap ch)) instead."  {:added "1.2"}  [^CharSequence s cmap]  (loop [index (int 0)         buffer (StringBuilder. (.length s))]    (if (= (.length s) index)      (.toString buffer)      (let [ch (.charAt s index)]        (if-let [replacement (cmap ch)]          (.append buffer replacement)          (.append buffer ch))        (recur (inc index) buffer)))))

Total number of pairs of parentheses (not counting doc-strings): 45

My translation of the code to JavaScript:

function trim_newline(s) {    for (let index = s.length; index > 0; index--) {        let ch = s.charAt(index - 1);        if (ch != '\n' && ch != '\r') {            return s.substr(0, index);        }    }    return "";}function blank(s) {    if (s == null) {        return true;    }    for (let index = 0; index < s.length; index++) {        if (!Character.isWhitespace(s.charAt(index))) {            return false;        }    }    return true;}function escape(s, cmap) {    let buffer = "";    for (let index = 0; index < s.length; index++) {        let ch = s.charAt(index),            replacement = cmap(ch);        buffer +=            replacement !== undefined                ? replacement                : ch;    }    return buffer;}

Total number of pairs of parentheses: 15

That's about a factor of 3. Now, you can argue that I shouldn't care about the parentheses, but my point is simply that they're there and you can't really avoid them if you write in anything resembling idiomatic Lisp.

Transfers are predictable and rapid.

And don't forget how easy it is to reverse them in case of error.

Again, "strong types" doesn't mean anything.

But from a type theory perspective, having "dynamic types" absolutely means you don't have a type system. All Python has is runtime exceptions. The fact that one of them is named TypeError doesn't make it a type error in the formal sense.

The point of a type system is not that variables have types, but that types are assigned to expressions (i.e. pieces of code in your source file), not to values (i.e. pieces of data). This is important because it guarantees that certain errors cannot occur in a program that passes the type checker (assuming you have a sensible/useful type system). And you get this assurance without running a single line of code.

To get a similar guarantee from Python, you need to write exhaustive tests, just as with any other runtime error.

"Strongly typed" is meaningless. (Or nearly so; in practice it means "I like this language" and "weakly typed" means "I dislike this language".) The point is that Python has no type system.

Python is un(i)typed.

include Hebrew in their language, because I guess they were feeling kabbalistic

... or because the developers were Israeli: https://en.wikipedia.org/wiki/Zend/_(company)#History

My CGI script is a SaaS.

for (int i = INT_MIN; ; i++) {    ...    if (i == INT_MAX) break;}

Isn't this COBOL or 4GL or something?

That confirms exactly what tyler said. I'm not sure if you're misreading replies to your posts or misreading your own posts, but I think you're really missing the point.

Let's go through it point by point.

• tyler said "JSON Schema is not an ISO standard". As far as I can tell, this is true, and you have not presented any evidence to the contrary.

• tyler said "JSON Data Interchange Format is a standard, but it wasn’t published until 2017, and it doesn’t say anything about 1.0 needs to auto cast to 1". This is true and confirmed by your own link, which is a standard from 2017 that declares compatibility with RFC 8259 (tyler's link) and doesn't say anything about autocasting 1.0 to 0 (because that's semantics, and your ISO standard only describes syntax).

• tyler said "JSON Schema isn’t a specification of the language, it’s for defining a schema for your code", which is true (and you haven't disputed it).

Your response starts with "yes it is", but it's unclear what part you're disagreeing with, because your own link agrees with pretty much everything tyler said.

Even the part of the standard you're explicitly quoting does not say anything about 1.0 and 1 being the same number.

Why did you bring up JSON Schema (by linking to their website) in the first place? Were you just confused about the difference between JSON in general and JSON Schema?

@masterspace Love the confidence, but your facts could do with some work.

• "Interpreted language" is not a thing. Interpreted vs compiled is a property of a particular implementation, not the language.
  (I wonder how you would classify lazy functional languages like Haskell. The first implementations were all interpreters because it was not clear that the well-known graph reduction technique for lazy evaluation could be compiled to native code at all.Today, hugs (a Haskell interpreter written in C) isn't maintained anymore, but GHC still comes with both a native compiler (ghc) and an interpreter (runghc, ghci).)

• Most implementations that employ interpretation are compiler/interpreter hybrids. It is rare to find an interpreter that parses and directly executes each line of code before proceeding to the next (the major exception being shells/shell scripts). Instead they first compile the source code to an internal representation, which is then interpreted (or, in some cases, stored elsewhere, like Python's .pyc files or PHP's "opcache").

• You can tell something is a compile-time error if its occurrence anywhere in the file prevents the whole file from running. For example, if you take valid code and add a random { at the end, none of the code will be executed (in Javascript, Python, Perl, PHP, C, Haskell, but not in shell scripts).

• The original "lint" tool was developed because old C compilers did little to no error checking. (For example, they couldn't verify the number and type of arguments in function calls against the corresponding function definitions.) "Linting" specifically refers to doing extra checks (some of which may be more stylistic in nature, like a /*FALLTHRU*/ comment in switch statements) beyond what the compiler does by itself.

• If I refer to an undeclared variable in a Perl function, none of the code runs, even if the function is defined at the end of the file and never called. It's a compile-time error (and I don't have to install and configure a linting tool first). The same is true of Haskell.
  What's funny to me is that Javascript copied use strict directly from Perl (albeit as a string because Javascript doesn't have use declarations), but turned it into a runtime check, which makes it a lot less useful.

@jaror

main = do putStrLn (cycle "buffalo " ++ !getLine)