9 ms·

> Macros I don't want my teammates writing macros. When the whole programming community constantly talks about situations within regular, more expressive langu

> Macros I don't want my teammates writing macros. When the whole programming community constantly talks about situations within regular, more expressive languages (with syntax) like Python et al, where teammates look at each others code and are baffled ... I struggle to see a scenario where inventing syntax through macros is a good idea, and won't make that situation so much worse. > arbitrary syntax transformation in macros See above. > object system as powerful as CLOS If I wanted object systems, there are plenty of options that don't involve so many parens, and do involve far more expressive syntax than lisps offer. > and the ability to comfortably use almost any paradigm I kinda want my team to pick a set of known paradigms. This is not an advantage. I've never used a modern programming language and thought 'this lacks paradigms, if only I could let my team invent some, that none of us will understand 6 months from now'. > It's not always useful, but you'll be thankful when it is. From what you've said, I won't. I'll just be upset my teammates invented their own language with macros and whatever paradigms they chose to use that day. The lisp 'trade-off' (homoiconicity over expressive syntax) just seems like it's looking for power in the wrong places. Power like that is more often bad than good.

qwertyuiop924 10y ago
GPP asked what lisp's got that Ruby doesn't. I told him. Lisp isn't the end-all be-all. If you can't trust your teammates, than maybe you shouldn't be using Lisp. But keep in mind that you can write INTERCAL in any language. Lisp just makes it easier, because Lisp does its best not to limit you. Besides, who would invent their own language in macros for no reason? Also, the syntax is one of the best parts about Lisp. It's agressively regular, so you'll never have to worry about screwups or ambiguity. And with readtables, the syntax can be more expressive than you might think. Although you did set the standards pretty low...
- feelsboutlisps 10y ago
  > Also, the syntax is one of the best parts about Lisp. I think you're in the minority there. I would hope most people agree that Lisp 'sacrifices syntax in the name of homoiconicity'. If not, then we have different definitions of syntax and I'm not sure any discussion on that is likely to go anywhere.
  - white-flame 10y ago
    In the case of code that works with code, rich syntax is a problem, not a solution. Getting rid of tons of syntax is not a sacrifice at all, when you're wrapping, transforming, and/or generating code. And as I've stated elsewhere, the fact that you can do this now so easily means it opens up that power for quick little inline tools, where in most other languages that sort of thing is reserved for major undertakings. It also eliminates many syntactic bugs, makes searching & editing code easier for humans, makes editor tools easier to create and more broadly useful when they exist, and eliminates ambiguous precedence completely. You begin to notice that syntax itself really is an anti-feature, after working across a wildly varying range of languages and styles, and designing many fully custom DSLs.
    - feelsboutlisps 10y ago
      > Getting rid of tons of syntax is not a sacrifice at all Getting rid of syntax that usefully expresses common cases absolutely is a sacrifice. What was that Turing tar pit thing about making things of interest easy? Lisp is powerful, but its lack of syntax makes it inexpressive. > It also eliminates many syntactic bugs How so? > makes searching & editing code easier for humans I disagree, code that lacks basic syntax such that programmers end up writing macros, does not make code easier to search and edit. > makes editor tools easier to create and more broadly useful when they exist I can see how that would work, because you're writing ASTs like you're a robot, which of course machines can understand better, just not humans. > eliminates ambiguous precedence completely That is a totally overstated problem. I've literally never been bitten by this in about 10 years of programming. Everyone in every other language just adds parens by default. > You begin to notice that syntax itself really is an anti-feature Having given Clojure I think 'a fair go', I just don't see that happening. Being able to read my teammates code will never be an anti-feature. I just don't agree with the trade-off ...
      - qwertyuiop924 10y ago
        if your teammates are careful, and don't go overboard on macros, than their code will be just as readable as it would be in any language. But that's true of any feature. s/macros/(splitting the program into functions|using gotos|building a class hierarchy)/. You can write INTERCAL in any language. And you keep talking like it's a tradeoff. For you, it may be. But for many of us who write Lisp, the paren-laden syntax is actually enjoyable: it's unambiguous, easy to write so long as the parens match up, and easy to read if you've indented it properly. And if you've got a half-decent editor, it'll indent and match parens for you. With Emacs and paredit, it's even nicer than many other languages: you'll be flinging sexprs around before you know it :-D. Futhermore, you seem to think 90% of Lisp is macros: in fact, I hardly ever write them. I'm glad they're there when I need them, but when I don't, I write perfectly ordinary code just like anybody else, except that it's more pleasant to write because there's faster iteration, better tooling for manipulating code, and a nice, regular syntax that lets me forget about it, so I can focus on the parts of my code that matter, and get s#!t done.
_delirium 10y ago
On large team Lisp projects, you don't have every individual person arbitrarily invent their own idiosyncratic abstractions. The project as a whole has a common set of abstractions that fit the domain, which are designed and modified the way you would design the abstractions regardless of the language and programming paradigm you're using. Macros are a language tool that lets you build abstractions, in some cases imo allowing better abstractions than would be possible without macros, most often ones simulated somewhat clunkily with OO features (or something godawful like C++ template metaprogramming). But if you have a large team project you still need an actually functioning team, common abstractions, project management, documentation, code review, the usual stuff. Successful large Lisp projects of course do all that. I don't see a meaningful difference here between Lisp and, say, C++. If you have a dysfunctional team writing C++, full of cowboy programmers who invent their own idiosyncratic abstractions without coordinating with anyone, the fact that C++ doesn't have proper macros doesn't really meaningfully limit the resulting damage. What stops it from happening in functional teams isn't that C++ the language prevents it from happening, but that the team has some kind of working process that allows them to successfully write code as a team.
- feelsboutlisps 10y ago
  > Macros are a language tool that lets you build abstractions, in some cases imo allowing better abstractions than would be possible without macros I guess 'better' is the operative word I question here. You're creating syntax that no-one has seen before. How is that a good thing? Meanwhile 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. > I don't see a meaningful difference here between Lisp and, say, C++. Agree :) (joke) > If you have a dysfunctional team writing C++, full of cowboy programmers At no point am I suggesting we can save ourselves from cowboys ... > What stops it from happening in functional teams isn't that [...] the language prevents it from happening, but that the team has some kind of working process that allows them to successfully write code as a team. But people are arguing 'the whole point' of lisps is that you can be free to do this, and that this justifies the 'paren-crazy', syntax-less language trade-off, and I'm yet to see any justification it's necessary to allow this at all. What I'm saying is that all the lispy parens give you are footguns and all you're saying is that good teams don't use those guns. Well then why give them the guns at all. Why not give them a language with decent syntax instead.

qwertyuiop924 10y ago

GPP asked what lisp's got that Ruby doesn't. I told him. Lisp isn't the end-all be-all. If you can't trust your teammates, than maybe you shouldn't be using Lisp. But keep in mind that you can write INTERCAL in any language. Lisp just makes it easier, because Lisp does its best not to limit you. Besides, who would invent their own language in macros for no reason? Also, the syntax is one of the best parts about Lisp. It's agressively regular, so you'll never have to worry about screwups or ambiguity. And with readtables, the syntax can be more expressive than you might think. Although you did set the standards pretty low...

feelsboutlisps 10y ago
> Also, the syntax is one of the best parts about Lisp. I think you're in the minority there. I would hope most people agree that Lisp 'sacrifices syntax in the name of homoiconicity'. If not, then we have different definitions of syntax and I'm not sure any discussion on that is likely to go anywhere.
- white-flame 10y ago
  In the case of code that works with code, rich syntax is a problem, not a solution. Getting rid of tons of syntax is not a sacrifice at all, when you're wrapping, transforming, and/or generating code. And as I've stated elsewhere, the fact that you can do this now so easily means it opens up that power for quick little inline tools, where in most other languages that sort of thing is reserved for major undertakings. It also eliminates many syntactic bugs, makes searching & editing code easier for humans, makes editor tools easier to create and more broadly useful when they exist, and eliminates ambiguous precedence completely. You begin to notice that syntax itself really is an anti-feature, after working across a wildly varying range of languages and styles, and designing many fully custom DSLs.
  - feelsboutlisps 10y ago
    > Getting rid of tons of syntax is not a sacrifice at all Getting rid of syntax that usefully expresses common cases absolutely is a sacrifice. What was that Turing tar pit thing about making things of interest easy? Lisp is powerful, but its lack of syntax makes it inexpressive. > It also eliminates many syntactic bugs How so? > makes searching & editing code easier for humans I disagree, code that lacks basic syntax such that programmers end up writing macros, does not make code easier to search and edit. > makes editor tools easier to create and more broadly useful when they exist I can see how that would work, because you're writing ASTs like you're a robot, which of course machines can understand better, just not humans. > eliminates ambiguous precedence completely That is a totally overstated problem. I've literally never been bitten by this in about 10 years of programming. Everyone in every other language just adds parens by default. > You begin to notice that syntax itself really is an anti-feature Having given Clojure I think 'a fair go', I just don't see that happening. Being able to read my teammates code will never be an anti-feature. I just don't agree with the trade-off ...
    - qwertyuiop924 10y ago
      if your teammates are careful, and don't go overboard on macros, than their code will be just as readable as it would be in any language. But that's true of any feature. s/macros/(splitting the program into functions|using gotos|building a class hierarchy)/. You can write INTERCAL in any language. And you keep talking like it's a tradeoff. For you, it may be. But for many of us who write Lisp, the paren-laden syntax is actually enjoyable: it's unambiguous, easy to write so long as the parens match up, and easy to read if you've indented it properly. And if you've got a half-decent editor, it'll indent and match parens for you. With Emacs and paredit, it's even nicer than many other languages: you'll be flinging sexprs around before you know it :-D. Futhermore, you seem to think 90% of Lisp is macros: in fact, I hardly ever write them. I'm glad they're there when I need them, but when I don't, I write perfectly ordinary code just like anybody else, except that it's more pleasant to write because there's faster iteration, better tooling for manipulating code, and a nice, regular syntax that lets me forget about it, so I can focus on the parts of my code that matter, and get s#!t done.

_delirium 10y ago

On large team Lisp projects, you don't have every individual person arbitrarily invent their own idiosyncratic abstractions. The project as a whole has a common set of abstractions that fit the domain, which are designed and modified the way you would design the abstractions regardless of the language and programming paradigm you're using. Macros are a language tool that lets you build abstractions, in some cases imo allowing better abstractions than would be possible without macros, most often ones simulated somewhat clunkily with OO features (or something godawful like C++ template metaprogramming). But if you have a large team project you still need an actually functioning team, common abstractions, project management, documentation, code review, the usual stuff. Successful large Lisp projects of course do all that. I don't see a meaningful difference here between Lisp and, say, C++. If you have a dysfunctional team writing C++, full of cowboy programmers who invent their own idiosyncratic abstractions without coordinating with anyone, the fact that C++ doesn't have proper macros doesn't really meaningfully limit the resulting damage. What stops it from happening in functional teams isn't that C++ the language prevents it from happening, but that the team has some kind of working process that allows them to successfully write code as a team.

feelsboutlisps 10y ago
> Macros are a language tool that lets you build abstractions, in some cases imo allowing better abstractions than would be possible without macros I guess 'better' is the operative word I question here. You're creating syntax that no-one has seen before. How is that a good thing? Meanwhile 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. > I don't see a meaningful difference here between Lisp and, say, C++. Agree :) (joke) > If you have a dysfunctional team writing C++, full of cowboy programmers At no point am I suggesting we can save ourselves from cowboys ... > What stops it from happening in functional teams isn't that [...] the language prevents it from happening, but that the team has some kind of working process that allows them to successfully write code as a team. But people are arguing 'the whole point' of lisps is that you can be free to do this, and that this justifies the 'paren-crazy', syntax-less language trade-off, and I'm yet to see any justification it's necessary to allow this at all. What I'm saying is that all the lispy parens give you are footguns and all you're saying is that good teams don't use those guns. Well then why give them the guns at all. Why not give them a language with decent syntax instead.