On Wed, Apr 07, 2010 at 01:09:54PM +0100, RW wrote:
> On Tue, 6 Apr 2010 21:07:17 -0600
> Chad Perrin <per...@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 <per...@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.

1. No, I used a misquote to lead into a lengthy explanation.

2. Seriously?  Are you not aware of how juvenile that sounds?


> > > 
> > > 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.

Judging by your further disputations with Mr. Schwartz, I don't think I
believe you.


> 
> > > 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. 

This doesn't change anything I said.


> 
> > 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.

It's kind of odd you rail against natural language *in this context*.  I
thought "in this context" was obvious.


> 
> > 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.

Who said anything about being different for the sake of being different?

If you find it too difficult to actually respond to what I said, please
refrain from responding.


> 
> > 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.

It's not a straw man argument.  Your presumption is wrong.

I have no idea how what I said could not be perfectly obvious.  It's
pretty clear.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]

Attachment: pgpv6MIox8pkk.pgp
Description: PGP signature

Reply via email to