On Apr 6, 2010, at 11:07 AM, Randal L. Schwartz wrote: >> "Chuck" == Chuck Swiger <cswi...@mac.com> writes: > Chuck> Let's suppose you want to display one message if debugging is > Chuck> enabled, and a shorter message if it is not. > > Then you wouldn't have used this construct.
If the construct isn't a good idea considering the most obvious change one might make to the code, I would conclude that it's probably never going to be a good idea to use such a thing. Surely Perl source code shouldn't be considered as write-once, modify-never? >>> If you don't like all this freedom, there's always Python. :) > > Chuck> Yes, Perl lets you innovate a remarkable number of ways of > Chuck> solving the same problem using syntax that varies from clean and > Chuck> maintainable to constructs which even the original author won't > Chuck> understand without effort a few months later. It seems to be > Chuck> uncommon for one to write unreadable Python code; I'm not sure > Chuck> additional freedom to write obfuscated code would be as > Chuck> beneficial as one may assume.... > > I call shenanigans: False dichotomy. I agree: the assertion you've made that Python lacks freedom is a false dichotomy. As we all know, any language which is adequately expressive can be used to write arbitrary code; much less languages which permit callouts or extension mechanisms to invoke native C/assembler/etc code. If you really find an advantage in obfuscated syntax and regard it as representing more freedom, I won't argue that opinion with you directly, but instead ask that you demonstrate that this supposed freedom results in better code, ease of maintainability, etc: > Perl has *many* options that are all clear and readable, and some > that aren't. Python has a *few* options that are all clear and > readable, and some that aren't. ...and an example or two would be? > You may not appreciate that freedom. Others do. With freedom comes > responsibility. If that's not for you, Perl's not for you. I would suggest that good software not only allows the user the full freedom to do anything which is possible, it should also avoid asking the user about choices which are impossible/invalid/wrong/etc. This can be input field validation, middleware logic, this can be determining the present state and greying out options which are not currently applicable, etc. Regards, -- -Chuck _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
