I’m creating a new language which borrows heavily from Ruby, and I’m
curious
what features of Ruby its users enjoy the most.
I’ve put up a poll here:
http://www.twiigs.com/poll/Technology/Computers/25588
It’s multiple choice, but if possible, try to limit yourself to the top
10
features of Ruby you consider important, rather than checking every
single
box.
And of course, feel free to respond on the list, particularly with any
features you think I’ve omitted which are worthy of attention.
Tony A. wrote:
features of Ruby you consider important, rather than checking every single
box.
Many of the items you list, such as “metaprogramming”, or “easy to
create DSLs”,
are now must-have features for any language, going forward. That is
Ruby’s
impact on the industry.
But about “Redefining the behavior of core types”, one might conflate
overriding
with Monkey Patching. Overriding is good - it’s what OO is all about.
But…
It would be nice if Ruby, and your language, made Monkey Patching safe.
One
reason we monkeys must patch is lack of Construction Encapsulation. If
we could
simply upgrade the target object itself to our derived type, then we
would not
need to “underride” a method and risk everyone gets it. So a system that
encapsulates construction automatically, so programmers don’t need to
work extra
for it, might be useful.
Another way to make MP safe might be Aspect Oriented Programming. I
suspect that
AOP is actually Monkey Patching, with the added benefit you can declare
which
modules see the patch and which see the classic behavior.
Finally, this may come as a shock to those who read my posts, but I tend
to
think that TDD support systems, beginning with the lowly assert()
method, should
behave like a debugger’s variable watch system when they fail. They
should
report the source code and value of every expression in their
neighborhood when
they fail. But implementing that for an assertion - even within the
mighty Ruby
Could your language provide all those abilities as first-class features,
under
the “metaprogramming” and “reflection” banners, so we can use them
anywhere?
(And [ahem!] why weren’t they in your list?
Phlip wrote:
Many of the items you list, such as “metaprogramming”, or “easy to
create DSLs”, are now must-have features for any language, going
forward. That is Ruby’s impact on the industry.
Those existed in Lisp, Scheme and Forth, but Ruby made them popular
and quite a bit more readable.
Another way to make MP safe might be Aspect Oriented Programming. I
suspect that AOP is actually Monkey Patching, with the added benefit you
can declare which modules see the patch and which see the classic behavior.
Well … there are AOP languages. Does anybody use them? 
–
M. Edward (Ed) Borasky
I’ve never met a happy clam. In fact, most of them were pretty steamed.
Exception Handling , though it gets wacky at times…
2009/2/16 Tony A. [email protected]:
I’m creating a new language
Why?
which borrows heavily from Ruby, and I’m curious
what features of Ruby its users enjoy the most.I’ve put up a poll here:
http://www.twiigs.com/poll/Technology/Computers/25588
It’s multiple choice, but if possible, try to limit yourself to the top 10
features of Ruby you consider important, rather than checking every single
box.
I got 9. Phew!
Kind regards
robert
On Mon, Feb 16, 2009 at 5:26 AM, Tony A. [email protected] wrote:
Very nice, thank you for showing the polling results.
I see that the single most loved feature is lambdas with 88%.
I like that but do we use them to that extent?
Maybe something to reflect upon, right;)? - or is this high-jacking
this thread, yup feels so. I will open a new one.
Robert
Hi –
On Mon, 16 Feb 2009, Tony A. wrote:
And of course, feel free to respond on the list, particularly with any
features you think I’ve omitted which are worthy of attention.
Some of the choices involve coupling things that I wouldn’t
necessarily put together, like the standard library and its use of
blocks (I’m not sure what you mean by the latter; things like
File.open {} ?) or open classes and monkeypatching (I don’t know which
of the various meanings of the latter you mean; I think they’re all
subsets of the former) or optional parens and English-like readability
(I’m ambivalent about both, but for different reasons, and it depends
a bit which optional parens you mean).
A couple of other things that might go on such a list:
String interpolation
Zero being true
Single inheritance
Anyway, I had no trouble finding ten and then some! 
David
–
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (The Well-Grounded Rubyist)
http://www.wishsight.com => Independent, social wishlist management!
Bezan K. wrote:
Exception Handling , though it gets wacky at times…
The great thing about blocks is you can hide the wackiness:
def foo
x = 42
yield_me do
return x + 1
end
end
def yield_me
prepare()
yield()
explode()
ensure
cleanup()
end
That is the “execute around pattern” - prepare() and cleanup() will
always call
around blocks passed to yield_me. Even if the block raises an exception.
Question - does the return throw away the explode() call? I have not yet
bothered to determine this while coding, though I may even have used the
effect
in others’ blocks, already!
Hi –
On Mon, 16 Feb 2009, Robert D. wrote:
On Mon, Feb 16, 2009 at 5:26 AM, Tony A. [email protected] wrote:
Very nice, thank you for showing the polling results.
I see that the single most loved feature is lambdas with 88%.
I like that but do we use them to that extent?
There’s no usage extent implied. Does your diet consist mainly of your
favorite food?
David
–
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (The Well-Grounded Rubyist)
http://www.wishsight.com => Independent, social wishlist management!
On Mon, 16 Feb 2009, Robert D. wrote:
There’s no usage extent implied. Does your diet consist mainly of your
favorite food?
Good point, David, but in “my favor” ;). My diet consists mostly of my
favorite food… (pasta, caffè, cioccolati )
Surely you will eat as much of your favorite food as a balanced diet
allows (and probably just a little more).
Do we do this with lambdas? I do not think so…, do you?
Language features aren’t gratifying in the same way that food is,
though. There’s another agenda: writing a program as well as possible.
If that agenda isn’t served by lambdas, then there are no lambdas,
even if I think lambdas are really cool.
I love many Ruby features but they don’t have the same kind of pull
as, say, Sugar Pops
David
–
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (The Well-Grounded Rubyist)
http://www.wishsight.com => Independent, social wishlist management!
On Mon, Feb 16, 2009 at 2:13 PM, David A. Black [email protected]
wrote:
Language features aren’t gratifying in the same way that food is,
though.
I am glad you realize.
Now do you really think it is a bad idea to think about modifying our
approach to what we do in general and programming in Ruby in special?
Is there anything intrinsically counter productive or maybe even
stupid in my remark?
I have the feeling you did not take my suggestion seriously, pity…
Robert
On Mon, Feb 16, 2009 at 12:36 PM, David A. Black [email protected]
wrote:
favorite food?
Good point, David, but in “my favor” ;). My diet consists mostly of my
favorite food… (pasta, caffè, cioccolati )
Surely you will eat as much of your favorite food as a balanced diet
allows (and probably just a little more).
Do we do this with lambdas? I do not think so…, do you?
R.
I can tell you what feature/style recommendation I hate the most. Using
“"
instead of camel notation makes the language too verbose. If you want to
give some meaningful names to a method or variable, if you use more than
two
underscores, it looks loooooooong. Ruby is so elegant in so many ways,
why
do we have to subject ourselves to the ugliness of "” ? You might say
that
nobody is forcing me, but being the purist that I am I want a total
immersion in the language. And it looks like the leaders recommend using
this notation. Is everybody happy with the ugly_like_hell_notation ?
On Mon, Feb 16, 2009 at 5:21 PM, Horea R. [email protected]
wrote:
I can tell you what feature/style recommendation I hate the most. Using “"
instead of camel notation makes the language too verbose. If you want to
give some meaningful names to a method or variable, if you use more than two
underscores, it looks loooooooong. Ruby is so elegant in so many ways, why
do we have to subject ourselves to the ugliness of "” ? You might say that
nobody is forcing me, but being the purist that I am I want a total
immersion in the language. And it looks like the leaders recommend using
this notation. Is everybody happy with the ugly_like_hell_notation ?
I think this is a matter of opinion and getting used to things,
there’s no right or wrong here.
I am quite happy with that notation. For my eyes it’s easier to parse
the words because they are physically separated. For me it’s
beautiful_like_heaven_notation, as opposed to uglyLikeHellNotation
Jesus.
In my opinion a well managed project will use whatever style convention
is
predominant in the language of choice. So I am stuck with the ugly
convention. Maybe it is just me, looks like no other people complain.
But it
is like a thorn in my eye and I think it reduces the expressiveness of
the
language, it almost forces us to use short/non-expressive names for
methods
and variables.
On Mon, Feb 16, 2009 at 12:01 PM, M. Edward (Ed) Borasky
On Mon, Feb 16, 2009 at 8:29 AM, Jesús Gabriel y Galán
[email protected] wrote:
I think this is a matter of opinion and getting used to things,
there’s no right or wrong here.
I am quite happy with that notation. For my eyes it’s easier to parse
the words because they are physically separated. For me it’s
beautiful_like_heaven_notation, as opposed to uglyLikeHellNotationJesus.
+1 … I much prefer the Ruby / Rails convention. But you really need
to use whatever convention / programming style is in use on the
project. If it’s a project that uses words_separated_by_underscores,
do that. If the first letter of a variableName is lower case, do that.
If
underscore.is.not.a.letter.like.earlier.versions.of.R.but.dot.is.a.letter
then do that, etc.
M. Edward (Ed) Borasky
I’ve never met a happy clam. In fact, most of them were pretty steamed.
On 16.02.2009 18:48, Horea R. wrote:
In my opinion a well managed project will use whatever style convention is
predominant in the language of choice. So I am stuck with the ugly
convention. Maybe it is just me, looks like no other people complain. But it
is like a thorn in my eye and I think it reduces the expressiveness of the
language, it almost forces us to use short/non-expressive names for methods
and variables.
That’s interesting, I see it the other way round: because we have
underscores as clear separators between parts of an identifier we can
use short names (e.g. #to_s as compared to Java’s toString(), #to_a
etc.).
Having said that I do not really care much and follow the rule you
posted: just blend with whatever convention is present in the language
of choice. Readability - especially for others - is more important than
feelings about ugliness. In a project with at least two developers you
can be pretty sure that whatever convention you choose it will hurt at
least one of them in the eye.
Kind regards
robert
Tony A. wrote:
I’m creating a new language which borrows heavily from Ruby, and I’m
curious
what features of Ruby its users enjoy the most.
Are you interested in borrowing from other languages too? In that case:
maybe you should poll (say) Erlang users about what their favourite
features are of that language
maybe poll Ruby users about what their favourite features from other
languages are, that they would have liked to have seen in Ruby
maybe poll Ruby users if there are any things they dislike about Ruby
in its current form
On Mon, Feb 16, 2009 at 3:25 AM, David A. Black [email protected]
wrote:
Some of the choices involve coupling things that I wouldn’t
necessarily put together, like the standard library and its use of
blocks (I’m not sure what you mean by the latter; things like
File.open {} ?)
Sorry about that. That one was a particularly bad case of trying to jam
together poll options so there weren’t so many to pick from.
But yes, you’re correct: in regard to usage of blocks by the standard
library I’m talking about things like File.open {}, or for that matter
String#gsub(x) {} or Enumerable#zip {}
I feel the Ruby standard library does a great job of making use of
blocks
and feel that’s one of the reasons blocks are so popular in general.
or open classes and monkeypatching (I don’t know which
of the various meanings of the latter you mean; I think they’re all
subsets of the former)
Pretty much, that was meant to cover all cases of altering the
definitions
of existing classes/modules at runtime by a facility which may lack
formal
knowledge of what the original definition actually was.
or optional parens and English-like readability
(I’m ambivalent about both, but for different reasons, and it depends
a bit which optional parens you mean).
This is another case of overlap… the “English-like readability” bit
typically plays into DSLs which use English words and generally try to
make
your code read more like a natural language (e.g. RSpec)
I certainly understand that people can like optional parens for other
reasons but DSLs are one particularly compelling use case for them, I
believe.
A couple of other things that might go on such a list:
String interpolation
This was covered by the poll, I believe, although described as:
Embedding code in strings with “#{mycode}”
I hadn’t heard the phrase “string interpolation” before but that’s what
it
covers, correct? If so, glad to know the proper term. That’s a
particularly nasty one to implement but one I’d like to try my hand at
soon
Zero being true
Yes, definitely a noticeable omission. I love Ruby’s boolean semantics
although they seem to confuse newbies to the language.
Single inheritance
Given how pervasive single inheritance is (and the fact I already
implement
it) I wasn’t particularly concerned about this, so much as using mixins
in
lieu of multiple inheritance. I thought about putting it on the poll,
but
decided to just list mixins instead.
On Mon, Feb 16, 2009 at 1:31 PM, Brian C. [email protected]
wrote:
Are you interested in borrowing from other languages too?
Yes!
In that case:
- maybe you should poll (say) Erlang users about what their favourite
features are of that language
Well, in my case, my language is running on the Erlang VM (
http://wiki.reia-lang.org) and will have all the features of Erlang and
then
some.
But yes, this is excellent advice, and as I’m trying to borrow the best
features of Python as well I intend to post a similar thread on
python-list
maybe poll Ruby users about what their favourite features from other
languages are, that they would have liked to have seen in Rubymaybe poll Ruby users if there are any things they dislike about Ruby
in its current form
Both excellent advice
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