3 ms·

> in languages like Python, with syntax built-in, people build large apps without ever doing this, making their code far more understandable for the next person

by ordu 10y ago

> in languages like Python, with syntax built-in, people build large apps without ever doing this, making their code far more understandable for the next person that touches it. No. Lack of macros makes code bigger, more error prone and harder to understand. When I use something like cl-ppcre:do-register-groups, this one word hides all the loop orginization, and underlines meaning of local variables which are bound to regex groups. Or cl-sql:select, which allows programmer to use SQL syntax as part of lisp while hiding special chars escaping, converting numbers to strings, ensuring sql-syntax is correct. Or simplier example: gl:with-primitives, which hides glBegin(...); ... glEnd(). Note, it not just hides, it makes impossible to forget glEnd. Macros makes life easier. Otherwise no one would use it. Macros such a convinient way to make an abstractions, that switching from Lisp to any other language becomes a great pain. One start to see tons of boilerplate code, which needs to be written by hands, checked for errors with eyes, which hides logic somewhere inside of boilerplate... It becomes better with practice, but nevertheless lisp nostalgia will last forever.

feelsboutlisps 10y ago
> No. Lack of macros makes code bigger, more error prone and harder to understand. I mean, that's provably not true. Or at least not provably true. Let's me throw out at alternative statement: Macros make code harder to understand. > When I use something like cl-ppcre:do-register-groups, this one word hides all the loop orginization You don't need a lisp to hide things. > Or cl-sql:select, which allows programmer to use SQL syntax as part of lisp Eugh, why would I want SQL interspersed with my lisp. > [...] gl:with-primitives, which hides glBegin(...); [...] Note, it not just hides, it makes impossible to forget glEnd. Python has 'with' statements and 'context managers' that do this (make sure some cleanup happens). [1] > Macros makes life easier [...] such a convinient way to make an abstractions They might make life easier for the person writing them in the short term. And I can see how when you find a really solid case for a macro and document it well, open source it etc, it can be broadly useful, but then why not add that case to the damn language. Instead you open the floodgates to everyone in your team writing macros that aren't widely understood. > Otherwise no one would use it. A lot of people avoid them like the plague in all other languages. > but nevertheless lisp nostalgia will last forever. Maybe that's all it is though. [1] https://docs.python.org/2/reference/compound_stmts.html#the-with-statement https://docs.python.org/2/reference/compound_stmts.html#the-...
- qwertyuiop924 10y ago
  So python's got a with statement. What of it didn't? Well then, you're screwed. Hope you like calling file.close(). If lisp didn't have a with statement, you could add one yourself. And if scheme didn't have a with statement... well, you could always add one, but before dynamic-wind got added, it could break if you weren't careful. Some things you can't just patch in. Anyways, now you'll say, "but python does have a with statement!" But that was just an example: there are things python will never have that you can add to lisp yourself. Like multimethod dispatch and generics, anaphoric operators, lazy module loading, pattern matching, ADTs, regex literals (with readtables), non-deterministic operators (the classic amb/assert operators, for concisely expressing searching a list (although they're admittedly more toys than anything else)), and a full-on looping construct that allows for awk-style record processing of arbitrarily typed records from arbitrary sources (field splitting is handled by other functions). And that's just a few examples I came across. There are dozens of others. That would never all be added to the language: there's way too much, and it's too specialized. As for your theory that macros make code harder to understand, you don't have any proof. In fact, you have negative proof, as there's plenty of logic, good programming practice, and individual cases indicating that careful use of macros can make code easier to understand.
  - feelsboutlisps 10y ago
    > But that was just an example: there are things python will never have that you can add to lisp yourself. I don't want to. I want a language that has sensible norms. > As for your theory that macros make code harder to understand, you don't have any proof. In fact, you have negative proof, Do I? > as there's plenty of logic, What logic? Show me. I simply don't believe you, as it's not provable. > good programming practice Still not proof. I believe the opposite, that it's not good programming practice to use macros. > and individual cases indicating that careful use of macros can make code easier to understand. So anecdotal evidence, not proof. You have no more proof than I have. My personal experience is that in most mainstream languages, the most common arguments are over invention of frameworks/libs vs using existing ones, and those devs certainly would not be happy having macros thrown in the mix.

by ordu 10y ago

feelsboutlisps 10y ago

> No. Lack of macros makes code bigger, more error prone and harder to understand. I mean, that's provably not true. Or at least not provably true. Let's me throw out at alternative statement: Macros make code harder to understand. > When I use something like cl-ppcre:do-register-groups, this one word hides all the loop orginization You don't need a lisp to hide things. > Or cl-sql:select, which allows programmer to use SQL syntax as part of lisp Eugh, why would I want SQL interspersed with my lisp. > [...] gl:with-primitives, which hides glBegin(...); [...] Note, it not just hides, it makes impossible to forget glEnd. Python has 'with' statements and 'context managers' that do this (make sure some cleanup happens). [1] > Macros makes life easier [...] such a convinient way to make an abstractions They might make life easier for the person writing them in the short term. And I can see how when you find a really solid case for a macro and document it well, open source it etc, it can be broadly useful, but then why not add that case to the damn language. Instead you open the floodgates to everyone in your team writing macros that aren't widely understood. > Otherwise no one would use it. A lot of people avoid them like the plague in all other languages. > but nevertheless lisp nostalgia will last forever. Maybe that's all it is though. [1] https://docs.python.org/2/reference/compound_stmts.html#the-with-statement https://docs.python.org/2/reference/compound_stmts.html#the-...

qwertyuiop924 10y ago
So python's got a with statement. What of it didn't? Well then, you're screwed. Hope you like calling file.close(). If lisp didn't have a with statement, you could add one yourself. And if scheme didn't have a with statement... well, you could always add one, but before dynamic-wind got added, it could break if you weren't careful. Some things you can't just patch in. Anyways, now you'll say, "but python does have a with statement!" But that was just an example: there are things python will never have that you can add to lisp yourself. Like multimethod dispatch and generics, anaphoric operators, lazy module loading, pattern matching, ADTs, regex literals (with readtables), non-deterministic operators (the classic amb/assert operators, for concisely expressing searching a list (although they're admittedly more toys than anything else)), and a full-on looping construct that allows for awk-style record processing of arbitrarily typed records from arbitrary sources (field splitting is handled by other functions). And that's just a few examples I came across. There are dozens of others. That would never all be added to the language: there's way too much, and it's too specialized. As for your theory that macros make code harder to understand, you don't have any proof. In fact, you have negative proof, as there's plenty of logic, good programming practice, and individual cases indicating that careful use of macros can make code easier to understand.
- feelsboutlisps 10y ago
  > But that was just an example: there are things python will never have that you can add to lisp yourself. I don't want to. I want a language that has sensible norms. > As for your theory that macros make code harder to understand, you don't have any proof. In fact, you have negative proof, Do I? > as there's plenty of logic, What logic? Show me. I simply don't believe you, as it's not provable. > good programming practice Still not proof. I believe the opposite, that it's not good programming practice to use macros. > and individual cases indicating that careful use of macros can make code easier to understand. So anecdotal evidence, not proof. You have no more proof than I have. My personal experience is that in most mainstream languages, the most common arguments are over invention of frameworks/libs vs using existing ones, and those devs certainly would not be happy having macros thrown in the mix.