Fortran is an example of an early DSL for the Domain of numerical
algorithms
and
APL or at least a large subset, is an example of a DSL for matrix and
vector manipulation
Neither of these is particularly English like, in the second case not even
remotely.
···
On Mon, Feb 16, 2009 at 9:59 PM, David A. Black <dblack@rubypal.com> wrote:
On Tue, 17 Feb 2009, Tony Arcieri wrote:
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.
I know people sometimes bundle the concept of DSL and the idea of
sounding like English together (with mixed success, usually, in my
view), but "domain-specific" doesn't really imply emulation of natural
language; it just implies a particular well-defined emergent notation
based on a subset of (computer) language constructs. At least, that's
how I see it.
It's possible that without the humble feature of optional parentheses Rake would never have been invented and I might never have been compelled to take a serious look at Ruby. Since then I've often wondered why parentheses are still so heavily used in most Ruby code even when they offer no compelling utility for most uses. In contrast, omitting unnecessary semicolons seems almost universal. I suppose parentheses are more habit forming for some reason.
···
On 17 févr. 09, at 01:16, David Masover wrote:
I like Ruby's relaxed syntax. I like letting things like parentheses be implied, leading to interesting, emergent phenomena like hashes as named arguments. (Not that I would complain if the language implemented named arguments -- even better if I don't have to use them as a hash -- so long as I can if I need to.)
I like the ability to create good-looking DSLs, but that's similar to the above.
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 2:13 PM, David A. Black <dblack@rubypal.com> wrote:
Language features aren't gratifying in the same way that food is,
though.
IMHO, coding Ruby without parentheses is a particular kind of spice.
Whether you should use a particular spice depends on what you are cooking.
The parentheses free style works well for certain internal DSLs like Rake or
ActiveRecord association declarations, since they make run-time executed
expressions feel declarative.
On the other hand, I've always found leaving out parentheses in Ruby code,
"just because you can" to tend to look far stranger to my eye than putting
them in. In fact, sometimes when reading code without them I find myself
having to read very slowly in order to figure out just how Ruby is parsing
what I'm reading.
···
On Tue, Feb 17, 2009 at 9:44 AM, Juan Zanos <juan_zanos@talkhouse.com>wrote:
On 17 févr. 09, at 01:16, David Masover wrote:
I like Ruby's relaxed syntax. I like letting things like parentheses be
implied, leading to interesting, emergent phenomena like hashes as named
arguments. (Not that I would complain if the language implemented named
arguments -- even better if I don't have to use them as a hash -- so long as
I can if I need to.)
I like the ability to create good-looking DSLs, but that's similar to the
above.
It's possible that without the humble feature of optional parentheses Rake
would never have been invented and I might never have been compelled to take
a serious look at Ruby. Since then I've often wondered why parentheses are
still so heavily used in most Ruby code even when they offer no compelling
utility for most uses. In contrast, omitting unnecessary semicolons seems
almost universal. I suppose parentheses are more habit forming for some
reason.
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 10:54 AM, Robert Dober <robert.dober@gmail.com>wrote:
On Mon, Feb 16, 2009 at 2:13 PM, David A. Black <dblack@rubypal.com> > 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....
I like to switch on situation. Usually, my rule of thumb is:
Descriptive code without braces, algorithmic code with braces.
···
On Feb 17, 2009, at 5:59 PM, Rick DeNatale wrote:
On Tue, Feb 17, 2009 at 9:44 AM, Juan Zanos > <juan_zanos@talkhouse.com>wrote:
IMHO, coding Ruby without parentheses is a particular kind of spice.
Whether you should use a particular spice depends on what you are cooking.
On the other hand, I've always found leaving out parentheses in Ruby code,
"just because you can" to tend to look far stranger to my eye than putting
them in. In fact, sometimes when reading code without them I find myself
having to read very slowly in order to figure out just how Ruby is parsing
what I'm reading.
===
has_many :foobars #vs.
has_many(:foobars)
(really, the braces bring no gain)
and
===
foo(bar(batz)) #vs.
foo bar(batz)
(the omission kills readability)
Btw., my favourite feature about Ruby is its ability to mix descriptive code and algorithmic code very well.
It seems to me as if the coding style and the language feature are at odds with regard to Ruby and optional parenthesis. And I wonder if this is a consideration in making a new language, choosing features, and determining coding style. Should you add features that you plane to avoid using in common practice? I don't know if DSLs were a consideration when deciding to have optional parenthesis. If they weren't, then maybe the utility of Ruby for DSLs required a bit more luck than otherwise. Parenthesis seem so often used at times that it's almost if the option doesn't exist.
Strangeness is somewhat arbitrary. That's why a brought up the use of semicolons. Many languages require them all over the place. Ruby makes them
optional. Yet Ruby style conventions universally omit them when they're superfluous. So it isn't strange to not use them even though many common languages do. And of course some language don't use parentheses nearly as much as is commonly practiced in Ruby and it isn't strange in those languages.
···
On 17 févr. 09, at 11:59, Rick DeNatale wrote:
On Tue, Feb 17, 2009 at 9:44 AM, Juan Zanos > <juan_zanos@talkhouse.com>wrote:
On 17 févr. 09, at 01:16, David Masover wrote:
I like Ruby's relaxed syntax. I like letting things like parentheses be
implied, leading to interesting, emergent phenomena like hashes as named
arguments. (Not that I would complain if the language implemented named
arguments -- even better if I don't have to use them as a hash -- so long as
I can if I need to.)
I like the ability to create good-looking DSLs, but that's similar to the
above.
It's possible that without the humble feature of optional parentheses Rake
would never have been invented and I might never have been compelled to take
a serious look at Ruby. Since then I've often wondered why parentheses are
still so heavily used in most Ruby code even when they offer no compelling
utility for most uses. In contrast, omitting unnecessary semicolons seems
almost universal. I suppose parentheses are more habit forming for some
reason.
IMHO, coding Ruby without parentheses is a particular kind of spice.
Whether you should use a particular spice depends on what you are cooking.
The parentheses free style works well for certain internal DSLs like Rake or
ActiveRecord association declarations, since they make run-time executed
expressions feel declarative.
On the other hand, I've always found leaving out parentheses in Ruby code,
"just because you can" to tend to look far stranger to my eye than putting
them in. In fact, sometimes when reading code without them I find myself
having to read very slowly in order to figure out just how Ruby is parsing
what I'm reading.
On the other hand, I've always found leaving out parentheses in Ruby code,
"just because you can" to tend to look far stranger to my eye than putting
them in. In fact, sometimes when reading code without them I find myself
having to read very slowly in order to figure out just how Ruby is parsing
what I'm reading.
I found that after a few days of deliberately only using parentheses when needed, combined with a decent editor with synatx highlighting, and I no longer need them at all. I don't find code unreadable with them -- I have to work in JavaScript, after all -- but I don't have a problem without them, and they do get annoying sometimes.
On Mon, Feb 16, 2009 at 2:13 PM, David A. Black <dblack@rubypal.com> 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....
I'm not sure I quite understood. Can you recap your suggestion?
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.
···
On Mon, Feb 16, 2009 at 5:21 PM, Horea Raducan <hraducan@gmail.com> 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 ?
On the other hand, I've always found leaving out parentheses in Ruby code,
"just because you can" to tend to look far stranger to my eye than putting
them in. In fact, sometimes when reading code without them I find myself
having to read very slowly in order to figure out just how Ruby is parsing
what I'm reading.
I found that after a few days of deliberately only using parentheses when needed, combined with a decent editor with synatx highlighting, and I no longer need them at all. I don't find code unreadable with them -- I have to work in JavaScript, after all -- but I don't have a problem without them, and they do get annoying sometimes.
Same here. I think of them as FGPs: Feel-good parentheses, used because they make people accustomed to C or Java feel more comfortable, though they do not contribute any real code value.
Gladly, let us ponder why lambdas are not used more although everyone
likes them so much.
That does not mean that we shall use them more (though that is my
guess), but only that we might not be able to tell if we do not try.
What kind of confused me was your metaphor with food, of which, when I
took it up, you said: "well one cannot compare with food" ...
And that somehow was a show stopper which I found a lit bit a pity.
No big deal of course, nobody seems to be interested anyway ...
Cheers
Robert
···
On Tue, Feb 17, 2009 at 10:45 PM, David A. Black <dblack@rubypal.com> wrote:
Hi --
I'm not sure I quite understood. Can you recap your suggestion?
--
There are some people who begin the Zoo at the beginning, called
WAYIN, and walk as quickly as they can past every cage until they get
to the one called WAYOUT, but the nicest people go straight to the
animal they love the most, and stay there. ~ A.A. Milne (from
Winnie-the-Pooh)
That might be fine as long as you are the only one reading your code.
But I've read lots of ruby code written by myself and a lot of other ruby
programmers of varying levels, and I find code which eschews parentheses
whenever possible rather than in more declarative DSL contexts MUCH harder
to read.
And to second what other have said
def foo bar
Is not a declarative DSL context, at least in my estimation.
···
On Tue, Feb 17, 2009 at 2:40 PM, David Masover <ninja@slaphack.com> wrote:
Rick DeNatale wrote:
On the other hand, I've always found leaving out parentheses in Ruby code,
"just because you can" to tend to look far stranger to my eye than putting
them in. In fact, sometimes when reading code without them I find myself
having to read very slowly in order to figure out just how Ruby is parsing
what I'm reading.
I found that after a few days of deliberately only using parentheses when
needed, combined with a decent editor with synatx highlighting, and I no
longer need them at all. I don't find code unreadable with them -- I have to
work in JavaScript, after all -- but I don't have a problem without them,
and they do get annoying sometimes
+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.
···
On Mon, Feb 16, 2009 at 8:29 AM, Jesús Gabriel y Galán <jgabrielygalan@gmail.com> 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 uglyLikeHellNotation
Jesus.
--
M. Edward (Ed) Borasky
I've never met a happy clam. In fact, most of them were pretty steamed.
I'm not sure I quite understood. Can you recap your suggestion?
Gladly, let us ponder why lambdas are not used more although everyone
likes them so much.
That does not mean that we shall use them more (though that is my
guess), but only that we might not be able to tell if we do not try.
What kind of confused me was your metaphor with food, of which, when I
took it up, you said: "well one cannot compare with food" ...
And that somehow was a show stopper which I found a lit bit a pity.
I didn't actually say that, but the food analogy isn't really worth a
whole analysis.
No big deal of course, nobody seems to be interested anyway ...
I think what I was saying mainly was: even if I like, say, string
interpolation, that doesn't mean that I get pleasure out of placing
"#{}" into my programs as often as I can, nor that I think I should
look for ways to write programs with string interpolation. I don't
think that's what it means to like a language feature.
Of course there are language features that one might want to use more
because they solve particular problems, or do things better than other
ways, but those may or may not be the ones I would put on an informal
list of my favorite bits of Ruby.
David
···
On Wed, 18 Feb 2009, Robert Dober wrote:
On Tue, Feb 17, 2009 at 10:45 PM, David A. Black <dblack@rubypal.com> wrote:
Thats a harsh statement for those that do actually like parantheses and not because they are C//Java-Guys.
For example, i find the following irritating and bad style:
···
On Feb 17, 2009, at 9:30 PM, James Britt wrote:
David Masover wrote:
Same here. I think of them as FGPs: Feel-good parentheses, used because they make people accustomed to C or Java feel more comfortable, though they do not contribute any real code value.
===
def initialize foo, bar, batz = {}, &block
#(vs.)
def initialize( foo, bar, batz = {}, &block )
I see the argument list as a tuple and I like it to resemble one.
Also, i tend to brace long and unbalanced statements:
Good point. Syntax isn't all there is to readability. But it does have some effect.
In this case the parenthesis don't make anything inherently more readable and aren't helpful in resolving the nonsense names. The parenthesis are only meaningful if you already know what they mean. Readability arguments are often tainted by experience with previous languages. And it must be remembered that no programmer is born knowing a previous programming language. If we insist, implicitly or otherwise, that readability means that something looks like 'C' or Java or any other language then we place limits on how much we can simplify syntax. I'd actually say that each example with parenthesis requires a lot more explanation of why they are their, what they mean, what are the syntax rules that govern them, etc.
Cheers,
Juan
···
On 18 févr. 09, at 09:07, Robert Dober wrote:
On Wed, Feb 18, 2009 at 2:38 PM, Rick DeNatale > <rick.denatale@gmail.com> wrote:
On Tue, Feb 17, 2009 at 2:40 PM, David Masover >> <ninja@slaphack.com> wrote:
def foo bar
That is very hard to read indeed, but why?
def foo( bar )
This is not so much better!
We are all totally accustomed to the fact that foos and bars designate
the same kind of thing.
I therefore think that
def fact n
is more readable for most people than
def n( fact )
which is nonsense of course (in the particular context).
Naming seems more important than params or not params (of course if I
might say?).
Cheers
Robert
--
There are some people who begin the Zoo at the beginning, called
WAYIN, and walk as quickly as they can past every cage until they get
to the one called WAYOUT, but the nicest people go straight to the
animal they love the most, and stay there. ~ A.A. Milne (from
Winnie-the-Pooh)
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 <zznmeb@gmail.com>wrote:
On Mon, Feb 16, 2009 at 8:29 AM, Jesús Gabriel y Galán > <jgabrielygalan@gmail.com> 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 uglyLikeHellNotation
>
> Jesus.
+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.
Of course there are language features that one might want to use more
because they solve particular problems, or do things better than other
ways, but those may or may not be the ones I would put on an informal
list of my favorite bits of Ruby.
Understood David
I did not want to say what I think about lambdas because I was really
interested in what people might think of it.
But nothing happened :(.
Well that's life.
At least I can speak freely now and sorry for having been cryptic but
it was intentional, although not productive.
I believe that Ruby would highly benefit of using *all* of its
behavior implementing features.
Assumption: "Lambdas are often the better way to implement behavior
instead of using a class right away." Problem is that I am so
conditioned to using classes that I *never* think of it.
I once looked at some of the easier Ruby Quizzes and I estimated that
more than 50% could have been written with lambdas and without classes
resulting in "simpler" code...
But it remains to be seen what the exact advantage of that approach
would be. In order to be able to do that one would need more code
examples, right? And in order to have more code examples one would
need some folks to adapt that approach... ( me first LOL)
Am I talking too much? Well at least it should be clear now what I
wanted to say.
And of course I accept all opinions that this exercise might be
futile, which indeed it might be of course.
Thanx for listening.
Robert
···
On Wed, Feb 18, 2009 at 2:38 AM, David A. Black <dblack@rubypal.com> wrote:
--
There are some people who begin the Zoo at the beginning, called
WAYIN, and walk as quickly as they can past every cage until they get
to the one called WAYOUT, but the nicest people go straight to the
animal they love the most, and stay there. ~ A.A. Milne (from
Winnie-the-Pooh)
David Masover wrote:
Same here. I think of them as FGPs: Feel-good parentheses, used because
they make people accustomed to C or Java feel more comfortable, though they
do not contribute any real code value.
Thats a harsh statement for those that do actually like parantheses and not
because they are C//Java-Guys.
I did not think so, unless you feel inferior because you are a C /
Java guy, which IMHO you should not.
For example, i find the following irritating and bad style:
===
def initialize foo, bar, batz = {}, &block
#(vs.)
def initialize( foo, bar, batz = {}, &block )
I find the second irritating because those parens are sooo superfluous.
Does that mean that the first idiom is bad style??? Certainly not, I
can get used to it if I must.
I see the argument list as a tuple and I like it to resemble one.
Very valid point of view, but my brain sees it as a declaration. My
brain could be trained to see it as a tuple, but right now I do not
want to do that.
Cheers
Robert
···
On Wed, Feb 18, 2009 at 9:48 AM, Florian Gilcher <flo@andersground.net> wrote:
On Feb 17, 2009, at 9:30 PM, James Britt wrote:
--
There are some people who begin the Zoo at the beginning, called
WAYIN, and walk as quickly as they can past every cage until they get
to the one called WAYOUT, but the nicest people go straight to the
animal they love the most, and stay there. ~ A.A. Milne (from
Winnie-the-Pooh)
