On Sun, May 31, 2009 at 5:35 AM, Michael Bruschkewitz
[email protected] wrote:
for some really significant whitespace…
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
Juan Z. wrote:
And arguably, excluding any discussion of indentation, Ruby is a
better language.
And as you can see on the same lists the top 5 languages (which includes
PHP, which is the most popular scripting language) all use an “end” or
{} for code blocks. That could be a clear indication that identation is
not the preferred method to define code blocks.
I’m told that at Google they won’t even let you code in Ruby. They
only allow a limited number of popular languages, which includes
Python but not Ruby.
It makes sense to limit the amount of languages programmed in an
environment, as you need programmers with the appropriate knowledge and
skills to maintain your code. My previous employer did everything in PHP
It’s hard to understand why Ruby would allow semicolons to be optional but not “end” keywords.
There’s necessarily a newline where the semicolon would be no? This
makes the ommission of semicolons more of an obvious choice to me than
removing ends.
My best guess (and personal reason to be against such an option) is that it would add complexity
to programming and maintaining Ruby code without actually providing new functionality (it would only
add a new syntax option).
+1: you don’t want to mire the progress of a language by constantly
seeking backward compatibility, but at the same time it seems like a
lot of upheaval for a small change.
Any time any language change is proposed, one could use the same argument: there is <language_that_contains_feature_x>
for those who want feature x. I want the Ruby language, but I think it might well be improved by making a change.
+1: new to Ruby and the list, so hope I’m not too rude in saying I’m not
impressed with some of the attitudes of ‘piss off and use a different
language’. Everything’s discussable!
There is simply no perfect programming language. If one would exist it would be the only programming language
and we would all be using it.
IMHO if that logic was right, then you’re effectively saying all
software studios are using the best tools for the job?! Popularity isn’t
the gauge of utility.
Maybe any code in any language should be stored in some generic form meta language (we would have enough space to
store it now - car crysis left enough oil to create magnetic tapes) and the Editor provides the view which best fits to the
current developer. (Example: translate keyword to japanese signs, direction of writing a.s.o.)
Love it! Be interested to see anyone playing with that idea in any
language. It’d certainly solve the endless debate.
A.
There is simply no perfect programming language. If one would exist it
would be the only programming language and we would all be using it.
On 2 Jun 2009, at 06:20, Andy F wrote:
+1: new to Ruby and the list, so hope I’m not too rude in saying I’m
not impressed with some of the attitudes of ‘piss off and use a
different language’. Everything’s discussable!
I’m not going to defend any ‘piss off’ attitude that may be inferred
from some responses to this discussion, but do bear in mind that on
any mailing list there are discussion topics which have been done to
death in the past and that when they recur the posters responsible
will get short shrift.
It’s also incredibly rude for someone to make their first post to a
mailing list with something along the lines of “I’m new to this and
think it’s really cool, but you’re all dumb because…” which whilst
it isn’t a fair characterisation of the original post in this thread
does sum up how some people will have perceived it. Were an
established poster to raise such a topic, having already demonstrated
that they understand the trade-offs in the design of Ruby, the
reaction would be very different - but then again the original post
itself would probably have been phrased very differently as well.
As to this particular topic. Outside the Python and Haskell
communities I’ve seen very little hunger for significant indentation,
and the benefits are hard to demonstrate as suitably compelling to
outweigh all of the other changes people would like to see in their
language of choice. In the case of the Ruby community the main hunger
seems to be for ever-more-powerful meta-programming techniques and
extension of the higher order functionals that so much of our code
comprises of.
In particular Python developers newly acquainted with Ruby tend to
underestimate the difference between statement-oriented and expression-
oriented languages. In the former a statement is an isolated entity
whereas in the latter every expression returns a value, and therefore
it is thoroughly legitimate to treat that expression as a sub-
expression. Whilst I don’t doubt that expression-based languages can
be framed in a manner that is compatible with significant indentation,
in doing so they still need to guarantee maintainability.
Our penchant for a certain variety of meta-programming also makes me
uneasy about significant indentation and whilst that unease may be
misplaced I’m sure it’s not an isolated phenomenon. The community
would need to be certain that a change such as significant indentation
didn’t undermine either the fundamental ability to use those
techniques nor their maintainability, and in hindsight I think a lot
of the posts opposing such a change - even as an optional feature -
reflect that.
Ellie
raise ArgumentError unless @reality.responds_to? :reason
there are discussion topics which have been done to
death in the past and that when they recur the posters
responsible will get short shrift.
I do disagree with your opinion about this.
There is no “hive opinion”. Everyone is an individual.
Some may have this opinion, some may have another opinion.
What you deem “have been done to death in the past” someone
else may regard as a topic that is not finished at all. Why
would they then follow your point of view about this?
I find it prematurely to stifle discussion just because someone
disagrees with something.
It’s also incredibly rude for someone to make their first post to
a mailing list with something along the lines of "I’m new to this
and think it’s really cool, but you’re all dumb because…
I do not think it is “incredibly rude”.
Quite the opposite - I believe a healthy community must be able to
attract newbies just as easily, without an arrogant bossy tone to
deem what is rude and what is not. Ideas should be kept in free
flow rather than locked down.
The message is there, it is pointless to use argumentum ad hominem
against someone else just because someone gets mad over written
text.
Let’s concentrate on the subject at hand without attacking whoever
voiced a specific opinion. People who do insult others aren’t
likely to convince anyone whatsoever anyway. And this subject
seems to alienate people much more readily, in that they say
“i hate this idea”, and then defend that point of view, rather
than judging from a neutral POINT of view.
And please:
In the case of the Ruby community the main hunger
seems to be for ever-more-powerful meta-programming techniques and
extension of the higher order functionals that so much of our code
comprises of.
This speculation should not be done about a whole “community”.
Every community consists of individuals, even if they have a very
similar opinion about something, they still may have different
point of views or arguments as to how they reached that point.
It isn’t good to unite all point of views into “logical groups”.
For example:
So many people equate the Ruby on Rails community with the Ruby
community - but in my experience these two do not largely overlap.
It is simply unfair to attempt to equate different opinions into
one pool. What does “meta-programming” NEED to have to do anything
with indent at all?
Last but not least, the ultimate freedom would be to have the ability
to omit end as an optional feature in ruby available with a default
being the way it currently is.
To switch between indents, one could use #comment marks, like it is
done for the Encoding stuff already (or for vim files etc…)
Enforcement about official ruby stdlib could still follow one specific
guideline - i.e. it must be properly documented and tested, and it must
use “official” useage of end. (This would be an enforcement of a policy,
rather than syntax.)
On Tue, Jun 2, 2009 at 8:12 AM, Eleanor McHugh <
[email protected]> wrote:
In particular Python developers newly acquainted with Ruby tend to
underestimate the difference between statement-oriented and
expression-oriented languages. In the former a statement is an isolated
entity whereas in the latter every expression returns a value, and therefore
it is thoroughly legitimate to treat that expression as a sub-expression.
Whilst I don’t doubt that expression-based languages can be framed in a
manner that is compatible with significant indentation, in doing so they
still need to guarantee maintainability.
Indeed! Python’s statement structured grammar is essential to the way
it
implements significant indentation.
What I find incredibly curious is people keep equating the solutions
proposed to Python (which has mandatory statement-structured
indentation)
when in actuality they resemble the Haskell approach (optional indent
blocks
in lieu of delimiting tokens in a pure expression grammar)
This is what I was trying to explain at the beginning of the thread (if
you
want significant indentation in Ruby look to Haskell, not Python), but
few
seemed to understand. The proposed solutions aren’t “Pythonic”,
they’re…
Haskellish? Or whatever the proper term for that is.
On 3 Jun 2009, at 17:30, Marc H. wrote:
What does “meta-programming” NEED to have to do anything
with indent at all?
Because if indentation becomes significant it’s important that it
doesn’t break any central feature of Ruby, and my gut feeling (which I
concede may be totally misguided) is that the area where such breakage
is most likely to occur will be meta-programming. So whilst it may not
have anything to do with the matter at all, determining whether or not
that is the case is still an important consideration. At least for me.
Last but not least, the ultimate freedom would be to have the ability
to omit end as an optional feature in ruby available with a default
being the way it currently is.
I’m not sure that is such an ultimate freedom, but if it is remember
that all freedom comes with responsibility. In this case ensuring code
consistency.
To switch between indents, one could use #comment marks, like it is
done for the Encoding stuff already (or for vim files etc…)
Making two distinct structural layouts interchangeable in a single
codebase would make them marginally less readable than sticking to one
or other convention. And as maintenance of code is often orders of
magnitude more expensive than development that difference of
readability equates to a real long-term cost.
Enforcement about official ruby stdlib could still follow one specific
guideline - i.e. it must be properly documented and tested, and it
must
use “official” useage of end. (This would be an enforcement of a
policy,
rather than syntax.)
The stdlib is as close to a definition of Ruby idiom as we have, so if
significant indentation isn’t going to be allowed there it follows
that significant indentation will not become idiomatic and will
instead be idiosyncratic. If that’s the case, then what problem is it
solving?
Ellie
raise ArgumentError unless @reality.responds_to? :reason
On 6/3/09, Eleanor McHugh [email protected] wrote:
On 3 Jun 2009, at 17:30, Marc H. wrote:
What does “meta-programming” NEED to have to do anything
with indent at all?Because if indentation becomes significant it’s important that it
doesn’t break any central feature of Ruby, and my gut feeling (which I
concede may be totally misguided) is that the area where such breakage
is most likely to occur will be meta-programming. So whilst it may not
have anything to do with the matter at all, determining whether or not
that is the case is still an important consideration. At least for me.
So why metaprogramming, particularly? Ahhh, is it because code
generators may not take care to indent their generated code properly?
I know I’ve written code generators that do that…
Tony A. wrote:
This is what I was trying to explain at the beginning of the thread (if you
want significant indentation in Ruby look to Haskell, not Python), but few
seemed to understand. The proposed solutions aren’t “Pythonic”, they’re…
Haskellish? Or whatever the proper term for that is.
can’t resist ‘Haskellish’.gsub!(‘ask’,’’)
On Wed, Jun 3, 2009 at 8:44 PM, Reid T.
[email protected]wrote:
Tony A. wrote:
can’t resist ‘Haskellish’.gsub!(‘ask’,‘’)
I am not going to disagree
On 6/4/09, Eleanor McHugh [email protected] wrote:
me much more than typing ‘end’ ever could.
OTOH, as I am a macro bigot myself, I’d have to argue the position
that generating a bunch or ruby code to be passed to eval is the wrong
way to go about it; equivalent macros should be used instead…
On 4 Jun 2009, at 02:10, Caleb C. wrote:
is most likely to occur will be meta-programming. So whilst it may
not
have anything to do with the matter at all, determining whether or
not
that is the case is still an important consideration. At least for
me.So why metaprogramming, particularly? Ahhh, is it because code
generators may not take care to indent their generated code properly?
I know I’ve written code generators that do that…
Precisely.
We use code generation so often in mainstream Ruby code - and
sometimes in some pretty arcane ways - that the possibility of
introducing a whole new category of defect into the process concerns
me much more than typing ‘end’ ever could.
Ellie
raise ArgumentError unless @reality.responds_to? :reason
On 4 Jun 2009, at 17:30, Caleb C. wrote:
sometimes in some pretty arcane ways - that the possibility of
introducing a whole new category of defect into the process concerns
me much more than typing ‘end’ ever could.OTOH, as I am a macro bigot myself, I’d have to argue the position
that generating a bunch or ruby code to be passed to eval is the wrong
way to go about it; equivalent macros should be used instead…
And I wouldn’t disagree with you 
Ellie
raise ArgumentError unless @reality.responds_to? :reason
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs