BS. Not unexpected. Besides beauty is in the eye of the beerholder,
cleanliness likewise.
Somewhat of an inflammatory response.
Guess there are perl lovers out there still 
-R
Marc H. wrote:
We need to solve something, the perl guys do it.
Oh, something was lost. I actually meant we BOTH (ruby folks, and perl
folks)
need to solve a (or several) specific problem(s).Then we can see which language is cleaner.
Who’s gonna be the judge? Besides, define cleaner!
No matter the solutions, the Ruby ones will look cleaner to the Ruby
proponents and the Perl one to the Perl ones. There’s nothing to be
gained from this exercise.
Jenda
We need to solve something, the perl guys do it.
Oh, something was lost. I actually meant we BOTH (ruby folks, and perl
folks)
need to solve a (or several) specific problem(s).
Then we can see which language is cleaner.
On Fri, Jun 6, 2008 at 1:27 PM, Jenda K. [email protected] wrote:
Who’s gonna be the judge? Besides, define cleaner!
No matter the solutions, the Ruby ones will look cleaner to the Ruby
proponents and the Perl one to the Perl ones. There’s nothing to be
gained from this exercise.
You would need a third party.
Todd
Todd B. wrote:
On Fri, Jun 6, 2008 at 1:27 PM, Jenda K. [email protected] wrote:
Who’s gonna be the judge? Besides, define cleaner!
No matter the solutions, the Ruby ones will look cleaner to the Ruby
proponents and the Perl one to the Perl ones. There’s nothing to be
gained from this exercise.You would need a third party.
Todd
Someone who doesn’t know either language? Which would not help much
'cause that someone needs to know at least some other programming
language to have any idea whatsoever what’s going on in here and then
which ever’s closer to his/her language wins.
Spanish makes more sense that English to a portuguese that doesn’t know
either, does it say anything about the relative complexity of the two
languages?
Beauty contests are a nice pretext for watching a few chicks in swimwear
(or wet tshirts), but it’s not a way to find the most beautiful girl of
the USA in the year 2008. Cause there is no such thing.
Jenda
On Fri, Jun 6, 2008 at 10:49 AM, Robert K.
[email protected] wrote:
The usual solution in Ruby would probably be a) which I find perfectly ok.
Since the manipulation is typically encapsulated inside a LinkedList class
it does not bother me too much if there are two additional elements (for
head and tail).But I can see how this might be a bit more elegant with
references (although not as much to create an urgent need for references in
Ruby).
Definitely no urgent need, but a nice thing to have in a bag of
tricks. It could be implemented in Ruby, but you’ll get more
efficiency if done in C (ruby implementation would typically need eval
- at least for local vars). No special syntax needed.
=> #<Generator:0x1002ffe8 @cont_endp=nil, @index=0,
@block=#Proc:0x1001bbc4@/usr/lib/ruby/1.8/generator.rb:71,
@cont_yield=#Continuation:0x1002f5fc, @cont_next=nil, @queue=[“foo”]>
irb(main):030:0> until it.end?; puts it.current; it.next; end
foo
bar
baz
=> nil
This just gives a very limited external iterator that can read and
move forward (just like an internal iterator). In C++ terms, this
corresponds to one of the simplest - “Input Iterator”. Other
operations you might want to do where the iterator is at would be:
write, move back, insert, delete, random access.
An external iterator could be thought of as a
superset of the reference/pointer concept (external iterator looks
like a pointer in C++).Which is nicely done (in C++'s STL, I mean). But with blocks I don’t really
miss external iterators. I rarely have to iterate through multiple
collections in lock step and if I had #zip served me well.
#zip doesn’t help if you want to write, back-up, insert, delete, etc
during iteration.
Maybe I’m just not doing enough development that involves sophisticated
algorithms.
Well, the last year or so I’ve been exposed to quite a bit of
computational geometry and graph theory. Most of that has been in C++
and a bit of Python (would have used Ruby, but needed a certain API).
Outside of that, my experience would say the same as you. Usually
simple data structures and access methods suffice.
Eric
On 07.06.2008 04:30, Eric M. wrote:
project. I still think having something like this readily available
efficiency if done in C (ruby implementation would typically need eval
- at least for local vars). No special syntax needed.
Acutally, there is an implementation already:
irb(main):002:0> s=SimpleDelegator.new nil
=> nil
irb(main):003:0> s.getobj
=> nil
irb(main):004:0> s.setobj “foo”
=> “foo”
irb(main):005:0> s
=> “foo”
irb(main):006:0> s.getobj
=> “foo”
irb(main):007:0> s.setobj “bar”
=> “bar”
irb(main):008:0> s.getobj
=> “bar”
irb(main):009:0> s.length
=> 3
irb(main):010:0> s.gsub /./, ‘X’
=> “XXX”
External iterators are also like lvalue references and is something
ruby is missing (IMHO).
Is it?irb(main):027:0> require ‘generator’
This just gives a very limited external iterator that can read and
move forward (just like an internal iterator). In C++ terms, this
corresponds to one of the simplest - “Input Iterator”. Other
operations you might want to do where the iterator is at would be:
write, move back, insert, delete, random access.
Right you are.
An external iterator could be thought of as a
superset of the reference/pointer concept (external iterator looks
like a pointer in C++).
Which is nicely done (in C++'s STL, I mean). But with blocks I don’t really
miss external iterators. I rarely have to iterate through multiple
collections in lock step and if I had #zip served me well.#zip doesn’t help if you want to write, back-up, insert, delete, etc
during iteration.
Correct. For Array this could easily be build as an external class
(attached is an experimental version).
Maybe I’m just not doing enough development that involves sophisticated
algorithms.Well, the last year or so I’ve been exposed to quite a bit of
computational geometry and graph theory. Most of that has been in C++
and a bit of Python (would have used Ruby, but needed a certain API).
Outside of that, my experience would say the same as you. Usually
simple data structures and access methods suffice.
Thank you for this exchange!
Kind regards
robert
On 6/7/08, Robert K. [email protected] wrote:
On 07.06.2008 04:30, Eric M. wrote:
On Fri, Jun 6, 2008 at 10:49 AM, Robert K.
[email protected] wrote:On 06.06.2008 17:01, Eric M. wrote:
another solution: a) pass the node containing the link you want to
operate along with something saying which link in the node (you’ll
probably also need a dummy node at the root/head), b) have a
separate
object for the link so you can pass it around (i.e. simply an Array
of
it does not bother me too much if there are two additional elements
(for
head and tail).
elegant
with
references (although not as much to create an urgent need for
references
Acutally, there is an implementation already:
=> “foo”
irb(main):007:0> s.setobj “bar”
=> “bar”
irb(main):008:0> s.getobj
=> “bar”
irb(main):009:0> s.length
=> 3
irb(main):010:0> s.gsub /./, ‘X’
=> “XXX”
But, this doesn’t give you an lvalue reference, just an anonymous
reference
(which could be used for a case b implementation). A one element Array
would work just as well:
s = [“foo”]
p s[0] # => “foo”
s[0] = “bar”
p s[0] # => “bar”
I usually make a little class with [] and []= methods that take no args
in
the [], so I don’t need the “0” and the [] suffix is equivalent to the *
prefix in C/C++.
Here would be an fairly efficient instance variable lvalue reference
class:
class InstanceVariable
def initialize(obj, var); @obj=obj; @var=var; end
def []; @obj.instance_variable_get(@var); end
def []=(val); @obj.instance_variable_set(@var, val); end
end
node = Object.new
node.instance_variable_set(:@next, nil)
node2 = Object.new
link = InstanceVariable.new(node, :@next)
p link[] # => nil
link[] = node2
p link[].equal?(node2) # => true
p node.instance_variable_get(:@next).equal?(node2) # => true
Here would be a more general class for referencing any lvalue:
class LValue
def initialize(&lvalue); @lvalue = lvalue; end
def []; eval(@lvalue[].to_s, @lvalue.binding); end
def []=(val); eval(“proc {|v| #{@lvalue[].to_s} = v}”,
@lvalue.binding)[val]; end
end
def swap(a, b); b[], a[] = a[], b[]; end
x = 1
y = 2
swap(LValue.new { :x }, LValue.new { :y })
p x # => 2
p y # => 1
#zip doesn’t help if you want to write, back-up, insert, delete, etc
during iteration.Correct. For Array this could easily be build as an external class
(attached is an experimental version).
For Array, there isn’t a whole lot of value for an external iterator,
because we already have something that works as a poor man’s replacement
index (an integer). The index can’t do its own dereferencing (to read
and
write an element), but Array can using an index. In C++ STL, an
external
iterator can’t do all operations either. To do an erase or insert for
example, you call a method on the container with an iterator.
I think external iterators are more useful for other data structures
where
you don’t have random access - linked lists, trees, etc. I guess you
could
provide an index-like API (but the index might not be an integer)
instead of
a normal external iterator.
BTW, another external iterator we already have is IO, which operates at
a
specific point in a file.
Eric
On Friday 06 June 2008 12:21:08 Marc H. wrote:
Then we compare our solutions. (Only “in-built” stuff is allowed, i.e.
no cpan modules rubygems etc… things would have to be used from
scratch, so that no language gains an inherent advantage over the other)
That would still potentially be a comparison of standard libraries. And
you
can’t get away from that, really.
But it is a valid point that beauty is in the eye of the beholder.
Almost no
one I know who’s seen Ruby code argues that Perl is better – but then,
almost no one I know dislikes Firefly or Serenity. I’m finding out that
the
Internet is a bigger place – if there is an opinion, someone holds it.
Some people hate Firefly.
On Friday 06 June 2008 12:02:19 Jenda K. wrote:
David M. wrote:
On Wednesday 04 June 2008 12:20:37 Star Cross wrote:
Lesson: You can make Ruby every bit as messy as Perl if you want to.
Very true. But can you make Perl as pretty as Ruby?
BS. Not unexpected. Besides beauty is in the eye of the beerholder,
cleanliness likewise.
People who don’t know me often make the mistake of assuming I ask
rhetorical
questions.
I really don’t think Perl can be made as pretty as Ruby, but then, Perl
has
Acme::Lingua::Pirate::Perl, so anything’s possible.
Every language can be made messy. Not every language can be made clean.
Agreed. For example with the meaningful newlines there are cases when
you can’t make the Ruby code clean, because you either can’t break the
overly long line or you can, but you end up with an operator lost on the
far right or with some silly line continuation character.
However, with required semicolons, you have every line looking ugly,
except
just the edge cases. And that’s just line endings – never mind the
dereference operator and $calar prefix that become pretty much pure
annoyance
for OOP.
Also, it’s hardly unprecedented – shells have had meaningful newlines
with
escaping forever.
Robert K. (Guest) on 04.06.2008 23:00 wrote:
I have the impression that when writing Perl programs people usually
use nested structures of arrays, hashes and scalars to represent
complex data whereas in Ruby land people - at least I - tend to rather
create classes and use them because it is so much easier than in Perl.Or could it be that using the nested structures is harder in Ruby?
Is it? Looks pretty easy to me.
Oftentimes the classes are simple to make but do they give you anything?
Yes, it’s called Object-Oriented Programming. Perhaps not in every case,
but I
would argue that because of how much more tedious Perl makes classes –
and
nice patterns like setters/getters – there are going to be cases where
a
separate class would really be appropriate, but Perl people will tend
towards
data structures instead.
Dave B. (dogsbody) on 05.06.2008 17:01 wrote:
I find the contrary. Uncommented Perl is typically impossible to
understand unless you wrote it yourself. It is possible to write
clear Perl but, as with C, most people don’t bother.Uncommented hungarian is impossible to understand as well … unless you
actually know that language. Or maybe you were talking about golf or
yaph or poetry?
I don’t think this is a comment on the actual languages, but their
respective
communities. If people are drawn to Ruby because of pretty syntax,
they’re
probably likely to hold clean, readable syntax as a desirable goal.
But that could also be a reflection of Perl having been around for so
much
longer that it has a more diverse community.
I won’t say more about that, though. I care more about being able to
code
cleanly from scratch than how much clean code already exists to play
with –
otherwise, I’d probably be using Perl, for CPAN alone.
Phlip wrote:
$foo->{bar}(42);
Oh, and what does the 42 look like inside the method? local var = unshift?
Perl calling a method will look like
$foo->bar(42);
The argument 42 inside the method will normally look like
my $whatever = shift;
You don’t usually want/need “local” these days. Note that if there are a
number of arguments you might do
my ($arg1, $arg2, …) = @_;
AHS
On Jun 7, 10:41 am, David M. [email protected] wrote:
one I know who’s seen Ruby code argues that Perl is better – but then,
almost no one I know dislikes Firefly or Serenity. I’m finding out that the
Internet is a bigger place – if there is an opinion, someone holds it.
Not that I have anything to contribute, but now you have me thinking
about this entire discussion and Rule 34.
I’m scared.
On 6/7/08, Eric M. [email protected] wrote:
node2 = Object.new
def []; eval(@lvalue[].to_s, @lvalue.binding); end
p y # => 1
Here is a little richer and more efficient solution:
class Ref
def initialize(get=nil, &set); @get = get||set; @set = set; end
def []; @get[]; end
def []=(val); @set[val]; end
end
def Ref(get=nil, &set); Ref.new(get, set); end
def LValue(&lvalue)
Ref.new(eval(“proc { #{lvalue[].to_s} }”, lvalue.binding),
&eval(“proc { |val| #{lvalue[].to_s} = val}”))
end
def InstVar(obj, var)
Ref.new(lambda { obj.instance_variable_get(var) }) { |val|
obj.instance_variable_set(var, val)
}
end
def Attr(obj, attr, *args)
get = obj.method(attr)
set = obj.method(“#{attr.to_s}=”)
if args.empty?
Ref.new(get, &set)
else
# curry *args
Ref.new(lambda { get[args] }) { |val|
set[(args.clone<<val)]
}
end
end
some examples
def swap(a, b); b[], a[] = a[], b[]; end
x = 1
y = 2
swap(LValue { :x }, LValue { :y }) # swap x an y
p x # => 2
p y # => 1
x = [1, 2, 3, 4]
y = [5, 6, 7, 8]
swap(Attr(x, :[], 0…2), Attr(y, :[], 3…3)) # swap x[0…2] and y[3…3]
p x # => [8, 4]
p y # => [5, 6, 7, 1, 2, 3]
x = Struct.new(:a).new(1)
y = Object.new; y.instance_variable_set(:@b, 2)
swap(Attr(x, :a), InstVar(y, :@b)) # swap x.a and y.@b
p x.a # => 2
p y.instance_variable_get(:@b) # => 1
David M. wrote:
I really don’t think Perl can be made as pretty as Ruby, but then, Perl
has
Acme::Lingua::Pirate::Perl, so anything’s possible.
And I don’t think Ruby can be made pretty at all.
Every language can be made messy. Not every language can be made clean.
Agreed. For example with the meaningful newlines there are cases when
you can’t make the Ruby code clean, because you either can’t break the
overly long line or you can, but you end up with an operator lost on the
far right or with some silly line continuation character.However, with required semicolons, you have every line looking ugly,
except
just the edge cases. And that’s just line endings – never mind the
dereference operator and $calar prefix that become pretty much pure
annoyance
for OOP.
I hate languages that do not use any sigil. I want to know what is a
variable and what is not and be able to tell the difference at the very
first glance. And not have to think about what methods, functions,
classes, … exist or might exist in the future when naming my
variables.
And for the semicolons making every line look ugly … every sentence in
english ends with a dot, except for those that end with a question or
exclamation mark. Does that make the sentences ugly? A statement in a
program is a sentence and a sentence should end with a marker, not fall
off at the end of line unless I bend backwards.
Oftentimes the classes are simple to make but do they give you anything?
Yes, it’s called Object-Oriented Programming. Perhaps not in every case,
but I
would argue that because of how much more tedious Perl makes classes –
and
nice patterns like setters/getters – there are going to be cases where
a
separate class would really be appropriate, but Perl people will tend
towards
data structures instead.
OOP is not a holly grail, the fact that something is made into a class
with getters and setters doesn’t make it any better in itself. A class
that only has the default getters and setters is a pointless class. No
matter how easy was it to create it. You should not be creating classes
just because you can, you should do that because it allows for a cleaner
code, because it allows you to hide some complexity from whoever’s using
that class.
I don’t think this is a comment on the actual languages, but their
respective
communities. If people are drawn to Ruby because of pretty syntax,
they’re
probably likely to hold clean, readable syntax as a desirable goal.
I don’t think people get drawn to Ruby because of pretty syntax. I think
it’s all marketing. Ruby on Rails is (or is it still?) hip. The new cool
kid on the block.
Jenda
On Fri, Jun 6, 2008 at 7:47 PM, Jenda K. [email protected] wrote:
Todd
Someone who doesn’t know either language?
Yes
Which would not help much
'cause that someone needs to know at least some other programming
language to have any idea whatsoever what’s going on in here and then
which ever’s closer to his/her language wins.
Agreed.
Spanish makes more sense that English to a portuguese that doesn’t know
either, does it say anything about the relative complexity of the two
languages?Beauty contests are a nice pretext for watching a few chicks in swimwear
(or wet tshirts), but it’s not a way to find the most beautiful girl of
the USA in the year 2008. Cause there is no such thing.
Also, here I agree.
In any situation, you need a context for beauty, which you pointed
out. I was subtly suggesting that if you remove the context, then
everyone would be on a level playing field.
What would you suggest? A pissing contest? Just curious.
Todd
David M. wrote:
On Friday 06 June 2008 12:21:08 Marc H. wrote:
Then we compare our solutions. (Only “in-built” stuff is allowed, i.e.
no cpan modules rubygems etc… things would have to be used from
scratch, so that no language gains an inherent advantage over the other)That would still potentially be a comparison of standard libraries. And
you
can’t get away from that, really.But it is a valid point that beauty is in the eye of the beholder.
Almost no
one I know who’s seen Ruby code argues that Perl is better
We all live in certain communities and we tend to socialize with people
we have something in common with. So it’s not such a surprise that a
Ruby programmer knows a lot of people who like Ruby 
<…>
And for the semicolons making every line look ugly … every sentence in
english ends with a dot, except for those that end with a question or
exclamation mark. Does that make the sentences ugly?
In English you do not write every sentence on the separate line, hence
the need to have something to mark the end of the sentence.
Same in Ruby, if you put several statements in one line you use
semicolons
to separate them.
A statement in a program is a sentence and a sentence should end with
a marker, not fall off at the end of line unless I bend backwards.
Yep, it ends. That marker is newline. Pretty good choice - it marks the
end
of the statement and does not bring any visual clutter. I like this a
lot,
others may not like it, but they have a bunch of other languages to
choose from.
<…>
Regards,
Rimantas
Todd B. wrote:
On Fri, Jun 6, 2008 at 7:47 PM, Jenda K. [email protected] wrote:
Beauty contests are a nice pretext for watching a few chicks in swimwear
(or wet tshirts), but it’s not a way to find the most beautiful girl of
the USA in the year 2008. Cause there is no such thing.Also, here I agree.
In any situation, you need a context for beauty, which you pointed
out. I was subtly suggesting that if you remove the context, then
everyone would be on a level playing field.What would you suggest? A pissing contest? Just curious.
Todd
I suggest to drop the idea. A beauty contest in this area is just a
flamewar-sure-to-happen. And it’s completely pointless, you can’t
convince anyone something (or someone) is more beautiful (or clean). And
there’s penty of both Perl and Ruby examples all around the Internet so
there is no point to add yet another bunch.
Jenda
On Fri, Jun 13, 2008 at 6:22 AM, Jenda K. [email protected] wrote:
Todd B. wrote:
I suggest to drop the idea. A beauty contest in this area is just a
flamewar-sure-to-happen. And it’s completely pointless, you can’t
convince anyone something (or someone) is more beautiful (or clean). And
there’s penty of both Perl and Ruby examples all around the Internet so
there is no point to add yet another bunch.
I’m just going to have to agree with you again. I’m torn, you see. I
see elegance in Ruby, but at the same time get a little frustrated
with its flexibility; a taste of scariness even. I’ll continue to
favor the language over some popular other ones, because, for me, I
can read the code easier, even if the same thing is done several
different ways.
I should point out as a side note that I still haven’t bought into the
whole “pragmatic” thing, simply because I don’t think that programming
paradigm really trustfully exists yet, be it Perl, PHP, Ruby, Python,
whatever. I guess I’m kind of old school in thinking “there’s no free
lunch”, and that’s probably having to do with the database/engineer
background. Ah, well, maybe I’ll grow up.
Todd
2008/6/13 Jenda K. [email protected]:
rant
You do not have to use Ruby if you do not like to.
I don’t think this is a comment on the actual languages, but their
respective
communities. If people are drawn to Ruby because of pretty syntax,
they’re
probably likely to hold clean, readable syntax as a desirable goal.I don’t think people get drawn to Ruby because of pretty syntax. I think
it’s all marketing. Ruby on Rails is (or is it still?) hip. The new cool
kid on the block.
That’s not true for me. I don’t use Rails but I do use Ruby because
of its OO capabilities and the clean syntax. I was attracted way
before the hype and I believe Rails did not even exist at that point
in time.
Regards
robert