Print(true and true) #=> the parenthesis issue

ruby-talk
21

Robert Klemme wrote:

  

Robert Klemme wrote:

[snip]
    

That makes sense, and yes, that I realized. In print() parenthesis are
      

enclosing the args, whereas in print () parenthesis are affecting
precedence of passed-in expression. However, from the usability
perspective, isn't it against some basic nature laws to leave it like
this?
        

There are no nature laws in IT.

Absolute nonsense.
    
Thanks for your kind reply.
  

I was, of course, referring to your proposition, and not to you. My evaluation is supported (I would hope) by the rest of my statement - again referring to ideas, not person. The "Absolute" is, of course, hyperbole, and also an attempt at humorous irony, since the argument which followed I then made was an appeal to the relative world of real probability, in which absolutes ("laws") are not likely to exist.

  

IT is not an entity unto itself. It is an artifact of the human brain.
Furthermore, it must be USED by the human brain, else it is the proverbial
tree falling in the forest when no one's around, and thus has no
consequence. AND the human brain certainly does have laws, if by "laws" we
mean something like "statements of pattern possessing a high probability of
being true" (my definition). Philosophical idealists will not be satisfied
by that, but such children should be ignored. Real men live with
probability, as a fact of life. (Are we having fun yet?) So...natural law of
IT exist, because all of IT must pass through the filter of the human brain.
    
With that argument the statement "there are nature laws in X" becomes
a tautology because they influence every aspect of reality.

Law of IT need not have relevance outside of that domain. There IS no necessary "influence".

  I prefer
to keep the distinction because this allows me to make more
interesting (i.e. non tautological) statements.
  

Clever, but...um...unfortunately wrong, if you reread my stipulated definition of "law". It's critical.

To put it differently: the brain behaves in patterned ways, which are describable by stochastic statements, the strongest of which approximate what in philosophically (and scientifically) simpler times were referred to as "laws". If this non-chaotic behavior be granted, and if you grant that IT must work in the context of this same brain, else it be irrelevant, then IT must also be non-chaotic, which is to say 'something akin to law-like' - not inherently but functionally. Chaotic IT certainly could (and in some quarters likely does) exist. But USEFUL IT cannot be structured this way, because, as I said, it must pass through the filter of the brain.

I think you are having trouble abandoning the idealist view of law. I certainly grasp that concept, but it seems useful to me only in study of the history of philosophy. Two words: quatum mechanics (which I believe IS supposed to "influence" all of nature). I rest my case.

The point here is that all formalisms in IT are human invented and
there is certainly nothing like a natural law that will demand that
"f(x and y)" is a valid expression.

From that point reasonable point of view, we could well have the usability
problem mentioned. I, for one, find this parenthesis problem obscure in the
extreme. What happened to the principal of least surprise? Yikes.
    
Did it every surprise you before this thread? If not, I don't see any
issue with POLS.
  

So, the falling tree in the forest makes no noise until I hear it? OK. But, pragmatically, if this sort of syntactic nonsense (the parenthesis thing - not the tree) exists in this case in Ruby, I become fearful about where else it might exist. Simply a practical concern. Otherwise, it is, as you point out, likely to be of so little import as to deserve no further attention.

  

Keep it simple, when at all possible.
    
Exactly. Having a feature that makes the language simple which is not
used by anyone (or only rarely) does not justify complicating the
parser more than necessary.
  

A pragmatic question, and you may well be right.

Let's hope so. Of course, the next time my Ruby program fails (and I'm good at that), I WILL have to wonder if I'm hearing a distant tree falling.

t.

···

2008/6/17 Tom Cloyd <tomcloyd@comcast.net>:

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC
Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< tc@tomcloyd.com >> (email)
<< TomCloyd.com >> (website & psychotherapy weblog)
<< sleightmind.wordpress.com >> (mental health issues weblog)
<< directpathdesign.com >> (web site design & consultation)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

22

Marc Heiler wrote:

Dear Tom Cloyd,

"What happened to the principal of least surprise? Yikes.

Keep it simple, when at all possible."

Your suggestive (and false) remarks are irritating at best.

Interest assertions...or rather they might be if there were an argument accompanying them. Name calling is easy. My argument(s) may be false, but at least I made an effort. If you find them false, point out the error. As for the "irritating" part - I'm supposing that that might have to do with a perception that to attempt this might take time and effort. But...I'm speculating.

There is only one principle of least surprise, if ever, and this is by the one who designs the language.

My questions stands. You do not address it. And...I believe there is more than one hand stirring Ruby's pot, and that is common knowledge.

There is no GENERAL CONSENSUS applicable to a "principle of least surprise" because different expectations, patterns, experience will yield to different perceptions of any given situation.
  

Certainly. No issue here.

The KISS strategy is only one more strategy in a pool of different strategies.
  

Obviously, but what's your point? The "principle of parsimony" (often attributed to William of Occam) is well established and accepted in philosophy, the law, and in argumentation in general. It's NOT simply one among many, to paraphrase you. It's fundamental - to good reason and, one could assert (and I do) to good design in general. And to aesthetics.

The point of parsimony, aside from the avoidance or the error which tend to propagate as a function of complexity, would seem to have to do with the issue of usability which the original poster brought up. That which is simple is generally more understandable and thus more useful. Seems like a truly key idea, to me.

I have seen it used in the game Wesnoth and what this basically means it that they slavishly reject features that "would make the game too complicated".
To the extreme that, when one suggests simplification to a game interface, a similar reasoning is used to reject it ("would make the code too complicated")
  

A good tool, poorly applied, is none the worse for it.

Whether this is intentional or not, it is their decision, but it would not be the ONLY available strategy to create/solve something.
  

Who made THAT silly assertion? Not me.

I'd rather not stick to ANYONE's "keep it simple" mantra, definitely not when multiple people jump on it and pick it up to shout something is a bug when it is not what they expect.

If anyone wants to know my principle of leat surprise, then I'd never have a parser that makes a difference between && and "and" or similar. But I am no language designer.
  

To repeat (and I do so in part because you did not address these matters) - I agreed that the particular syntactic issue at hand appears to be trivial to most of us most of the time, and also that its surprising nature leads me, at least, to wonder about other sorts of subtle, hidden issues which may be causing trouble in Ruby. (And give me credit for suggesting that such trouble as I encounter is far more likely to be self-caused than language caused.). It's reasonable to suppose such hidden issues
exist, though probably not reasonable to worry too much about them. They can be fun to talk about however.

t.

···

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC
Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< tc@tomcloyd.com >> (email)
<< TomCloyd.com >> (website & psychotherapy weblog)
<< sleightmind.wordpress.com >> (mental health issues weblog)
<< directpathdesign.com >> (web site design & consultation)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

23

Having a feature that makes the language simple which is not
used by anyone (or only rarely) does not justify complicating the
parser more than necessary.

I wouldn't say that this is unused. I came across this issue when
trying to write an ACL method, looking something like this:
only( a :guest and not the @user ) do end # => 'a' and 'the' are both
methods returning boolean based on supplied arg

Am I unable to have methods which rely on the result of a boolean
expression, without having to resort to double parenthesis, or
remembering to put the subtle extra space? That surprises me very
much, and definitely prevents me from using it. It's a source of hard-
to-find bugs.

24

Todd Benson wrote:

···

On Tue, Jun 17, 2008 at 2:09 AM, Tom Cloyd <tomcloyd@comcast.net> wrote:
  

Robert Klemme wrote:
    

There are no nature laws in IT.

Absolute nonsense.

IT is not an entity unto itself. It is an artifact of the human brain.
    
<snip/>

From that point reasonable point of view, we could well have the usability
problem mentioned. I, for one, find this parenthesis problem obscure in the
extreme. What happened to the principal of least surprise? Yikes.

Keep it simple, when at all possible.
    
You should study linguistics. Then, you might have an idea of how
hard it is to KISS.

Todd

Actually, I have, at the graduate level...and I do. It's a principle (got the spelling right this time, I hope). One aims at it, and hope to get close. I suggest that in this case Ruby may not have gotten close enough. That's all.

t.

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC
Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< tc@tomcloyd.com >> (email)
<< TomCloyd.com >> (website & psychotherapy weblog)
<< sleightmind.wordpress.com >> (mental health issues weblog)
<< directpathdesign.com >> (web site design & consultation)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

25

Hi --

···

On Thu, 19 Jun 2008, Dave Bass wrote:

Robert Klemme wrote:

x = some_work()
putx x if x

I carefully set my little trap... and it caught someone! :smiley:

Note that I wrote "Clarity wins over conciseness every time for me." The
more English-like the code is, the easier it is to understand (for me
anyway). The fact that my version is a few characters longer is
unimportant. Hopefully it won't phase Ruby; anyway, I'm the boss and it
can do what I say.

Your version only tests for false, not both false and nil, so it's not
equivalent to the 'and' one or to Robert's last one. The abstraction
of the nil and false objects into the category of boolean falsehood,
which will fail an 'if' test, isn't *that* hard to get :slight_smile: And then
you get to have code that's both short and clear :slight_smile:

David

--
Rails training from David A. Black and Ruby Power and Light:
   ADVANCING WITH RAILS June 16-19 Berlin
   ADVANCING WITH RAILS July 21-24 Edison, NJ
See http://www.rubypal.com for details and updates!

26

Robert Klemme wrote:

x = some_work()
putx x if x

I carefully set my little trap... and it caught someone! :smiley:

Yes, I can see you struggling in it. :slight_smile:

Note that I wrote "Clarity wins over conciseness every time for me."

So then why did you care to go through multiple negations?

The
more English-like the code is, the easier it is to understand (for me
anyway).

Exactly. That's why I offered a variant that not only has the same
semantics as my version with "and" but also reads much better than
your double negation.

Kind regards

robert

···

2008/6/18 Dave Bass <davebass@musician.org>:

--
use.inject do |as, often| as.you_can - without end

27

Certainly I could do only( a(:guest) && !the(@user) ) but you can see
what this does to a nice convenient acl method.

···

On Jun 17, 8:42 am, hakunin <madfanc...@gmail.com> wrote:

> Having a feature that makes the language simple which is not
> used by anyone (or only rarely) does not justify complicating the
> parser more than necessary.

I wouldn't say that this is unused. I came across this issue when
trying to write an ACL method, looking something like this:
only( a :guest and not the @user ) do end # => 'a' and 'the' are both
methods returning boolean based on supplied arg

Am I unable to have methods which rely on the result of a boolean
expression, without having to resort to double parenthesis, or
remembering to put the subtle extra space? That surprises me very
much, and definitely prevents me from using it. It's a source of hard-
to-find bugs.

28

Not sure how this can work since obviously you want to evaluate the
ACL on access time and not when you define it. Why don't you use a
block?

only { a :guest and not the @user }

Cheers

robert

···

On 17 Jun., 14:42, hakunin <madfanc...@gmail.com> wrote:

> Having a feature that makes the language simple which is not
> used by anyone (or only rarely) does not justify complicating the
> parser more than necessary.

I wouldn't say that this is unused. I came across this issue when
trying to write an ACL method, looking something like this:
only( a :guest and not the @user ) do end # => 'a' and 'the' are both
methods returning boolean based on supplied arg

29

Robert Klemme wrote:

Exactly. That's why I offered a variant that not only has the same
semantics as my version with "and" but also reads much better than
your double negation.

But my double negation is completely and absolutely clear! The whole
point of putting "unless x == false" is that it WON'T respond to nil,
only to false.

The x variable is presumably supposed to be Boolean, i.e. true/false. If
there's a possibility that some_work() could return nil and assign it to
x, it's likely to be because something went wrong within some_work().
That can and should be picked up by a separate test such as "if x.nil?".

It's shortcuts like writing "if x" instead of "unless x == false" that
conceal the potential for bugs. If one means "unless x == false" then
one should write it. If on the other hand one means "unless (x == false

x == nil)" then one should write that instead.

Clarity is more important than conciseness.

Dave

···

--
Posted via http://www.ruby-forum.com/\.

30

I don't want to go too off-topic, as I just wanted to show a usage
example. To be quick - I'm doing web dev, and in my case the role
"guest" and the object @user are stored in current_user session
object. The method is supposed to be like this: only(who){ #do
something for this particular "who" }-- the block passed to "only"
will run only if the boolean returns true.

···

On Jun 17, 8:52 am, Robert Klemme <shortcut...@googlemail.com> wrote:

On 17 Jun., 14:42, hakunin <madfanc...@gmail.com> wrote:

> > Having a feature that makes the language simple which is not
> > used by anyone (or only rarely) does not justify complicating the
> > parser more than necessary.

> I wouldn't say that this is unused. I came across this issue when
> trying to write an ACL method, looking something like this:
> only( a :guest and not the @user ) do end # => 'a' and 'the' are both
> methods returning boolean based on supplied arg

Not sure how this can work since obviously you want to evaluate the
ACL on access time and not when you define it. Why don't you use a
block?

only { a :guest and not the @user }

Cheers

robert

31

It will make more sense if I mentioned this is used by designer in
html templates to output or omit certain parts. : ) But that's beyond
the subject, once again.

···

On Jun 17, 9:11 am, hakunin <madfanc...@gmail.com> wrote:

On Jun 17, 8:52 am, Robert Klemme <shortcut...@googlemail.com> wrote:

> On 17 Jun., 14:42, hakunin <madfanc...@gmail.com> wrote:

> > > Having a feature that makes the language simple which is not
> > > used by anyone (or only rarely) does not justify complicating the
> > > parser more than necessary.

> > I wouldn't say that this is unused. I came across this issue when
> > trying to write an ACL method, looking something like this:
> > only( a :guest and not the @user ) do end # => 'a' and 'the' are both
> > methods returning boolean based on supplied arg

> Not sure how this can work since obviously you want to evaluate the
> ACL on access time and not when you define it. Why don't you use a
> block?

> only { a :guest and not the @user }

> Cheers

> robert

I don't want to go too off-topic, as I just wanted to show a usage
example. To be quick - I'm doing web dev, and in my case the role
"guest" and the object @user are stored in current_user session
object. The method is supposed to be like this: only(who){ #do
something for this particular "who" }-- the block passed to "only"
will run only if the boolean returns true.