It's not really about read either, it's about this:
> Wait a second, if you take a look at Lisp code, it’s really all made up of lists:
Haskell has `read`, most of your data types can just derive Read and Show and they'll "magically" get a representation allowing you to `read` and `show` them.
But that only works for datatypes, you can't do that with code.
In Lisp you trivially can, because code is represented via basic datatypes (through a reader macro if needed).
It's not macros. It's not read. It's much more basic than that: it's homoiconicity. From that everything falls out, and without that you need some sort of separate, special-purpose preprocessor (whether it's a shitty textual transformer — as in C — or a more advanced and structured one — as with Camlp4 or Template Haskell — does not matter).
And I don't get why the author got the gist (and title) so wrong when he himself notes read is irrelevant and useless in and of itself:
> Think of read like JSON.parse in Javascript. Except since Javascript code isn’t the same as data, you can’t parse any code
`read` does not matter if the language isn't homoiconic, you can `read` all you want it won't give you anything.
Yep, you're absolutely right. I was mainly offering a different viewpoint that might be refreshing to those who have always heard the "code is data and data is code" statement, but never really understood it.
Focusing on `read` was a way to anchor my article, even if it truly isn't about read either. I tried to tie that together at the end.
isnt every language that takes string homoiconic? because code is string and , string is also valid data type in that language? (by wikipedia definition)
Sort of, but only in a trivial and uninteresting sense - similar to how f(x) = 0 is its own derivative, but is much less interesting in that sense than f(x) = e^x.
A string has no additional structure, so if you want to do any transformations beyond simple string/regex substitutions you have to parse it into a more suitable format.
> Wait a second, if you take a look at Lisp code, it’s really all made up of lists:
Haskell has `read`, most of your data types can just derive Read and Show and they'll "magically" get a representation allowing you to `read` and `show` them.
But that only works for datatypes, you can't do that with code.
In Lisp you trivially can, because code is represented via basic datatypes (through a reader macro if needed).
It's not macros. It's not read. It's much more basic than that: it's homoiconicity. From that everything falls out, and without that you need some sort of separate, special-purpose preprocessor (whether it's a shitty textual transformer — as in C — or a more advanced and structured one — as with Camlp4 or Template Haskell — does not matter).
And I don't get why the author got the gist (and title) so wrong when he himself notes read is irrelevant and useless in and of itself:
> Think of read like JSON.parse in Javascript. Except since Javascript code isn’t the same as data, you can’t parse any code
`read` does not matter if the language isn't homoiconic, you can `read` all you want it won't give you anything.