4 ms·

1. You really have no theories you want to share, about why we see this kind of trolls from Python people continuously? >>Moreover, I've avoided making persona

by berntb 13y ago

1. You really have no theories you want to share, about why we see this kind of trolls from Python people continuously? >>Moreover, I've avoided making personal attacks on anyone. I argued you wrote extreme flames about subjects you showed you didn't understand -- then claim to understand them. I call yet-another-Python-troll. >>I don't think you understand the issue here. You missed(?) my point: With real inline lambdas and map, you don't need to create/teach list comprehensions Python style. It is there from inflexibility ("no braces!") So, everything has warts(/tradeoffs), you flame about some that you obviously don't understand: >> what benefits do we get from that decision? You really see no possible benefit -- except in Common Lisp? -- from being able to modify the execution environment in code before running a program? 2. I gave the example -- to help with language extensions. No need for that in any environment...?

MichaelSalib 13y ago
You really have no theories you want to share Ah, I see you're still struggling with the 'no personal attacks' suggestion. It is OK; I understand that this may be beyond your capabilities. With real inline lambdas and map, you don't need to create/teach list comprehensions Python style. map allows you to iterate over nested loops? I don't think so. I don't think list/set/dict comprehensions impose a major cognitive load on programmers, but perhaps you find them difficult? Well, you really see no possible benefit -- except for in Common Lisp? -- from being able to modify the execution environment in code before running a program? You misunderstand. Common Lisp offers more expressivity when it comes to changing the load-time/compile-time environment than perl does. But CL is easily parseable by external tools. This isn't a hard problem to solve. CL did it over 3 decades ago. like making syntax extensions easier But that doesn't make any sense: you can have syntax extensions in your language without impeding external parsing; that's...really easy. So that can't be the answer. Then again, I'm not sure I've ever seen a real need to arbitrary syntax redefinition...does anyone actually use that feature?
- berntb 13y ago
  You really show your troll nature when you complain about "personal attacks" (being called troll) while doing two personal attacks yourself: >>Ah, I see you're still struggling with the 'no personal attacks' suggestion. It is OK; I understand that this may be beyond your capabilities. >>I don't think [...] impose a major cognitive load on programmers, but perhaps you find them difficult? Thanks for a good laugh, troll. >>Common Lisp offers more expressivity You are arguing that the specific Common Lisp way is a better implementation of different execution phases. Not relevant, as you know. I argued that the Perl way had advantages, not that it was better than everything else (see chromatic in gp level too). This contradicts your original position that the compilation phases were just crazy and uniquely bad. So this is another point where you are shown to be trolling. Since you made two personal attacks, let me note that... ah, no. I should just pity you irritating trolls. I think I'll stop feeding you now. Please stop trolling on HN.

by berntb 13y ago

MichaelSalib 13y ago

You really have no theories you want to share Ah, I see you're still struggling with the 'no personal attacks' suggestion. It is OK; I understand that this may be beyond your capabilities. With real inline lambdas and map, you don't need to create/teach list comprehensions Python style. map allows you to iterate over nested loops? I don't think so. I don't think list/set/dict comprehensions impose a major cognitive load on programmers, but perhaps you find them difficult? Well, you really see no possible benefit -- except for in Common Lisp? -- from being able to modify the execution environment in code before running a program? You misunderstand. Common Lisp offers more expressivity when it comes to changing the load-time/compile-time environment than perl does. But CL is easily parseable by external tools. This isn't a hard problem to solve. CL did it over 3 decades ago. like making syntax extensions easier But that doesn't make any sense: you can have syntax extensions in your language without impeding external parsing; that's...really easy. So that can't be the answer. Then again, I'm not sure I've ever seen a real need to arbitrary syntax redefinition...does anyone actually use that feature?

berntb 13y ago
You really show your troll nature when you complain about "personal attacks" (being called troll) while doing two personal attacks yourself: >>Ah, I see you're still struggling with the 'no personal attacks' suggestion. It is OK; I understand that this may be beyond your capabilities. >>I don't think [...] impose a major cognitive load on programmers, but perhaps you find them difficult? Thanks for a good laugh, troll. >>Common Lisp offers more expressivity You are arguing that the specific Common Lisp way is a better implementation of different execution phases. Not relevant, as you know. I argued that the Perl way had advantages, not that it was better than everything else (see chromatic in gp level too). This contradicts your original position that the compilation phases were just crazy and uniquely bad. So this is another point where you are shown to be trolling. Since you made two personal attacks, let me note that... ah, no. I should just pity you irritating trolls. I think I'll stop feeding you now. Please stop trolling on HN.