perl qstn...

RW rwmaillists at googlemail.com
Wed Apr 7 12:10:01 UTC 2010


On Tue, 6 Apr 2010 21:07:17 -0600
Chad Perrin <perrin at apotheon.com> wrote:

> On Tue, Apr 06, 2010 at 01:20:49PM +0100, RW wrote:
> > On Mon, 5 Apr 2010 19:55:44 -0600
> > Chad Perrin <perrin at apotheon.com> wrote:
> > 
> > > On Mon, Apr 05, 2010 at 05:36:32PM +0100, RW wrote:

> > > There are more things in heav'n and earth, Horatio, than are
> > > dreamt of by designers of eagerly evaluated prefix notation
> > > languages.
> > 
> > And most of them are obscure for good reasons. Just because a a
> > syntax fits into a classification scheme doesn't make it a good
> > idea.

> Shall we trade more trite sniping, or would you like to say something
> more substantive? 

You started it.
 
> > 
> > Natural languages are mostly driven by spoken usage, in which people
> > firm-up half-formed ideas as they speak - this is not a good model
> > for programming languages. If you are hacking out a quick and dirty
> > script it may be convenient to type the decision after the action,
> > but it don't I think it promotes good quality software.
> 
> This sounds exactly like the complaints Pythonistas use to explain why
> they have a deep hatred of Perl.  If that's how you feel, I'd prefer
> you stop trying to tell me how Perl should work, and just use
> something else.

I'm not, I'm expressing an opinion that this is not a feature worth
copying.

> > Imperative languages have a natural order of decision followed by
> > action, and code is most easily readable if the syntax doesn't try
> > to subvert that.  
> 
> . . . except when the "natural order of decision" varies
> significantly, such as when comparing functions with operators.  It
> gets even more confusing when both "functions" and "operators" are
> actually methods in object oriented languages with an imperative
> design, because suddenly the difference between a "function" and an
> "operator" becomes purely arbitrary.  There's nothing about
> arbitrariness that suggests a "natural order".

Expression are different. When you are trying to understand thousands
of lines of code, the order of execution within an expression is fine
detail, but the flow of execution is something that needs to be
taken-in easily. 

> It's kind of odd you rail against natural language then talk about

I'm not railing again natural languages, I just don't think they have
much relevance.

> imperative languages having a "natural order" -- which is, presumably,
> based on the expectations of people who have been conditioned to think
> that way by their use of natural language.

No, it's conditioned by causality, and other mainstream programming
languages.
 
People juggle a lot of languages, being different for the sake of it
isn't very helpful.

> Frankly, if everybody just stuck to a purely "natural order of
> decision" approach to imperative language design, we would never even
> have developed structured programming.

I have no idea what you trying to say here. I presume it must be some
kind of straw man argument.


More information about the freebsd-questions mailing list