> Perhaps 70% of developer time is spent dealing with parsing, serialization, and persistence. Values are encoded to and from JSON, to and from various binary formats, and to and from various persistent data stores… over and over again.
Off-topic but.. by using Lisp one can refocus that 70% to actually solving problems.
The language allows it to be easily done. The model definitions can be simply transformed into code that directly handles those individual model artifacts.
This is a super common paradigm in Lisp, especially when it comes to class/structure/data definitions, where support functions of any type can be generated straight from the defs. There is no "automatic" language feature there, because no definition of "automatic" covers all useful cases. It's simply easy to do because of the homoiconic nature of Lisp (code = data = code, with easy manipulation to transform between them), and no real distinction between compile time and run time.
Compile-time and load-time occur during run-time. The run-time context of anything already executed is available to subsequent compile-time and load-time contexts. Of course, these then further affect the run-time context going forward.
While these "*-time"s are distinguished, they can be invoked and interplay arbitrarily, unlike most other languages. It's all fundamentally run-time, in contrast to those, especially when considering threaded environments where compilation and run-time execution can happen simultaneously.
Off-topic but.. by using Lisp one can refocus that 70% to actually solving problems.