JSON is not a programming language.
You are absolutely right. My point exactly.
Now you need "two hammers" to get a single job done. Your current programming language of choice and a data expression language.
For example: In C, C++, Java, or related, you "first" have to build you structure to represent a Person with first_name and last_name and then you have to write it to JSON:
Java:
class Person { String firstName; String lastName; }
var names = [{"firstName": "John", "lastName": "Smith"}, {"firstName": "Bob", "lastName": "Jones"}]
eval("(" + names + ")");
Lisp ver:
(defvar names '((:firstName "John" :lastName "Smith") (:firstName "Bob" :lastName "Jones")))
(eval names)> or example: In C, C++, Java, or related, you "first" have
to build you structure to represent a Person with
first_name and last_name
Not if you're using Protocol Buffers, which is essentially a version of JSON that has "batteries included."
> Lisp ver:
Lisp is not the only programming language around. How am I going to consume that data from another language? Embed an entire Lisp interpreter?
Not all problems require communicating your data structure outside of the program. And I don't think it's accurate to say "Now you need." For problems where you do need to communicate data outside of the program, that's been true since the days of Fortran.
Which just goes to show we still have not made all the way back to where Lisp was a few decades ago.
Consider that JSON has features Lisp does not. Like a tiny implementation, very wide language interoperability, being purely a data language (sandboxed by design), and not being Turing-complete (time to interpret is automatically bounded).
Now I clearly understand what some of the veterans in "Coders at Work" really meant by "Very little progress, if any, has been made in the Programming space".