3 ms·

... and God granted zoomers homoiconicity, macros and parenthesis. "No," said the zoomers, "we want to write XML, build scaffolding tools and eat shit." "Your

... and God granted zoomers homoiconicity, macros and parenthesis. "No," said the zoomers, "we want to write XML, build scaffolding tools and eat shit." "Your language will never be a LISP," was the God's reply.

johan_felisaz 4y ago
Does it come from somewhere or you just made that up ? I have a really strong feeling of déjà vu but cannot figure out from where.
- maydup-nem 4y ago
  I just made it up. But I guess we both must be reading the same kind of memes or something.
- awinter-py 4y ago
  you may be thinking of rootless root, ESR's zen koan styled thoughts on software http://catb.org/~esr/writings/unix-koans/index.html http://catb.org/~esr/writings/unix-koans/index.html
all2 4y ago
I'm clueless. How do these fix the scaffolding problem? If I start a new Python project I have a short checklist I go through 1. Poetry (dependency management) 2. pyenv and pyvirtualenv (execution environment management) Just these two are somewhat of a headache to get going. Once they're up, though, they do the job they're supposed to in an admirable fashion. How would a language with homoiconicity and macros handle this?
- maydup-nem 4y ago
  I am not too knowledgable about Python to tell you exactly. But let's take Common Lisp for an example and why I don't feel the need for a scaffolding tool. Well, actually I do need _some_ very basic scaffolding, namely: create two directories called src and tests + add two very short project files with my names and project names embedded in them, along with a couple of package files. Nothing fancy and certainly nothing that's particularly problematic. Everything that's part of the project code (such as package description with imported symbols and such) maybe be done by using a macro from an external library (ex: certain functions of some library that I import in each of my projects). But you are right anyway, not everything is a language-specific problem here, only the stuff that gets repeated in code, from one project to another. In CL that includes documentation and the testing framework (from the article's points). Well, the build/project description is just a macro too. Anyway, I didn't mean to diminish the major points of the article in any way. The author is right about the fact that generators are not aware of the user's changes and that can be problematic at times (as with his license and license metadata example).

johan_felisaz 4y ago

Does it come from somewhere or you just made that up ? I have a really strong feeling of déjà vu but cannot figure out from where.

maydup-nem 4y ago
I just made it up. But I guess we both must be reading the same kind of memes or something.
awinter-py 4y ago
you may be thinking of rootless root, ESR's zen koan styled thoughts on software http://catb.org/~esr/writings/unix-koans/index.html http://catb.org/~esr/writings/unix-koans/index.html

all2 4y ago

I'm clueless. How do these fix the scaffolding problem? If I start a new Python project I have a short checklist I go through 1. Poetry (dependency management) 2. pyenv and pyvirtualenv (execution environment management) Just these two are somewhat of a headache to get going. Once they're up, though, they do the job they're supposed to in an admirable fashion. How would a language with homoiconicity and macros handle this?

maydup-nem 4y ago
I am not too knowledgable about Python to tell you exactly. But let's take Common Lisp for an example and why I don't feel the need for a scaffolding tool. Well, actually I do need _some_ very basic scaffolding, namely: create two directories called src and tests + add two very short project files with my names and project names embedded in them, along with a couple of package files. Nothing fancy and certainly nothing that's particularly problematic. Everything that's part of the project code (such as package description with imported symbols and such) maybe be done by using a macro from an external library (ex: certain functions of some library that I import in each of my projects). But you are right anyway, not everything is a language-specific problem here, only the stuff that gets repeated in code, from one project to another. In CL that includes documentation and the testing framework (from the article's points). Well, the build/project description is just a macro too. Anyway, I didn't mean to diminish the major points of the article in any way. The author is right about the fact that generators are not aware of the user's changes and that can be problematic at times (as with his license and license metadata example).