|
Re^2: What are the drawbacks of autobox?
by LanX (Saint) on Feb 28, 2010 at 14:27 UTC
|
UPDATE: I surely do not intend to write something like my $error = 3.1415927->minus( 22->divide( 7 ) )->abs();. (Come on, BUK! even from you this example is quite polemic... ;-)
hmm some brainstorming
-
it's easier to read (and write)
$ar->[$x][$y][$z]->push("element")
than
push @{$ar->[$x][$y][$z]}, "element"
The flow is in one left-to-right direction and doesn't jump around, the association is much more evident.
- this clear association make it much easier to parse (statically) and to design help systems in IDEs, interactively popping up the documentation for a method.
- method calls often allow cascading, like this enabling more expressive code.
- from a learners and documentation perspective its much easier to check the method of an object than browsing through docs to find the function and search what it does combined with a special datatype.
- it's easier to introspect (dynamically) which methods are possible for an object, even using a REPL which tab-expands to possible methods (that's really a powerful feature in the Python shell)
- Extending new methods which only work with special data-types (like adding ruby's each-behaviour to arrays) is easier and cleaner than prototyping a function each() ¹)
- it gets easier to port JS or Python code to Perl, strengthening the powerful future of our beloved language. ;)
- look at the arguments from the Perl6 designers ...
- TIMTOWTDI =)
¹) yes I know I could use "for", "each" was just an example, but please try to design a function which is restricted to arrayrefs, thats really far more complicated.
UPDATE: corrected code and added further explanations in italics.
| [reply]
[d/l]
[select] |
|
|
it's easier to read (and write)
$ar->[$x][$y][$z]->push("element") than push @{$ar->[$x][$y][$z]}, "element"
The basic programming 'association' as you term it is: $name = value;
And I think there is clarity in the mirrors: push @array, value; and push @{ <arrayRef> }, $value;.
The flow is in one left-to-right direction and doesn't jump around, the association is much more evident.
The left to right association of an array reference pushed onto an element?
I don't know of any language where the car->get's into->the man or the queue->joins->the boy are valid. Syntactically or semantically.
this clear association ...
I do not see this association you speak of, let alone clearly.
make it much easier to parse (statically) and to design help systems in IDEs, interactively popping up the documentation for a method.
Hm. So you consider making the language easier for the computer to parse, at the expense of making it harder for the human being, a benefit?
method calls often allow cascading, like this enabling more expressive code.
I'd really like to see you find a real live working example that demonstrates the use of cascading method calls. Once you find an example, we can then argue about how "expressive" it is.
For me, one of the many things I like about Perl is the wonderful expressiveness of the carefully tuned syntax. Making every operator a method call, is like fitting a tiller and anchor to your Fireblade.
it's easier to introspect (dynamically)
I absolutely challenge the need for dynamic introspection. Beyond your, REPL-prompts-the-programmer example, do you have a good example of when you might make use of this?
Extending new methods which only work with special data-types (like adding ruby's each-behaviour to arrays)
Is defining each() for arrays so hard? Or do you even need to do it at all:
map{ ... } @array;
... for @array;
sub each{
my $code = shift;
$code->( $_ ) for @_;
}
it gets easier to port JS or Ruby code to Perl,
That'd be a nice challenge. Pick a piece of published Ruby code, and you can port it with autobox and me without?
look at the arguments from the Perl6 designers ...
Only time will tell how well that works out in practice.
TIMTOWTDI =)
Actually, the underlying tenet of autobox is TIOOWTDI. Ie. The only operator allowed is ->.
JS, Ruby and even Smalltalk don't try and replace the normal math infix operators with a post-fix operator and verbose method names.
If you really want your 2009 cpu to run like a 1999 cpu, investigate:
use DB;
sub DB::db{ sleep 1 }
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l]
[select] |
|
|
I don't know of any language where the car->get's into->the man or the queue->joins->the boy are valid. Syntactically or semantically.
So, this is an interesting thing I learned a while back, when trying to understand OO. While in English, the verb comes first followed by the subject, it is actually quite the opposite in other languages. For example, in English, we say lift chair, while in Hindi, I would say कुर्सी उठाअो. It is actually quite natural in other languages to first establish what we are referring to, and then specify what we are going to do to it. Not unlike how, say, copying or moving a file works in a Mac (or any graphic user interface). We first select the file with the mouse, and once the file is selected, we copy, move, delete or duplicate it, unlike a terminal command where we type 'copy file <target' or 'delete file'.
Now, on to another topic... does being able to cascade methods help in programming? I don't know. I had been doing stuff like (fake example ahead)
left(uc(substr($string, 0, length($string) - 4)),1) until I discovered JavaScript (Note: I particularly enjoy method chaining in jQuery) where I could do string.substr(0, string.length - 4).upper.left(1)
In the former, I have to start in the very inside and work my way to the outside, while in the latter, I just move from left to right, applying methods as I go along.
I think there is value in autobox. I too would like to explore, like Lanx, what that value is, and what its costs are.
--
when small people start casting long shadows, it is time to go to bed
| [reply]
[d/l]
[select] |
|
|
|
|
I'm not sure anyone who's ever used Smalltalk would use the phrase "normal math infix operators", as Smalltalk has no operator precedence, not even for "normal math infix operators".
I suppose that's an example of making the language easier to parse at the expense of humans, though. (What a useless false dilemma that is; I had a lovely discussion with Adin Falkoff a couple of years ago about teaching APL to inner-city students in the '60s. I asked him specifically about operator precedence and the like, and his approach was very different from that of Alan Kay, Dan Ingalls, et al.)
| [reply] |
|
|
|
|
|
|
|
|
|
Yes there are good answers to your questions¹ but I'm not in the mode to flame with you...we had this already.
Anyway it's simple, if you don't like autobox ... better don't use it. 8)
PS: To get back to the OP. Anyone knowing side effects of autobox making it not suitable for production?
Footnotes:
¹) I mean the non-polemic portions of them
| [reply] |
|
|
A reply falls below the community's threshold of quality. You may see it by logging in.
|
|
|
I don't know of any language where the car->get's into->the man or the queue->joins->the boy are valid. Syntactically or semantically.
Listen to Yoda enough you have not.
| [reply] |
|
|
While the language may seem clearer and in theory easier to understand, I find that it just syntax sugar candy. Looks tasty, but not does really provide anything.
Basically, if you want "Ruby" style code, then you can cut out the middle man and code in Ruby.
| [reply] |
|
|
I find that it just syntax sugar candy.
Be careful; this argument slides down a slippery slope to "Everything's just NAND gates anyway!"
The fact that you don't have to worry about an (artificial) distinction between non-object primitives and your own objects and types in terms of polymorphism and genericity is a huge advantage of autobox. Whether that advantage is practically realizable is a matter of opinion, but it's a potential benefit.
| [reply] |
|
|
|
|
|
|
|
Well I brought a list of arguments and you answer with your personal "findings"?
>While the language may seem clearer and in theory easier to understand, ...
Wasn't "make frequent things easy to code" a Perl mantra?
> Basically, if you want "Ruby" style code, then you can cut out the middle man and code in Ruby.
Silly me, and I thought TIMTOWTDI is Perl's style to code... ;-)
I'm curious what would your answer become if I edit my posts to s/Ruby/Perl6/g ?
BTW your not answering the OP about autobox and I never propagated that others should code this way!
| [reply] |
|
|
|
|
|
|
UPDATE: I surely do not intend to write something like my $error = 3.1415927->minus( 22->divide( 7 ) )->abs();. (Come on, BUK! even from you this example is quite polemic... ;-)
Erm... You do realize that my $error = 3.1415927->minus(22/7)->abs(); came straight from the autobox documentation (it's the second example under "SYNOPSIS"), don't you? It's not some fevered nightmare that BrowserUK dreamt up in an attempt to ridicule autobox, it's something that autobox's author put forward in a presumed attempt to show off how great it is.
| [reply]
[d/l] |
|
|
You do realize that
3.1415927->minus(22/7)->abs();
and
3.1415927->minus( 22->divide( 7 ) )->abs();
are not identical? 8)
It's not some fevered nightmare that BrowserUK dreamt up in an attempt to ridicule autobox ...
Hmm let me phrase it differently:
It's difficult to find a long BUK-thread where he doesn't use rhetorical tricks, straw mans and ridiculizes the opponent...
... prove me wrong!
| [reply]
[d/l]
[select] |
|
|
|
|
|
|
|
|
No I didn't realize it, but again I do not have to justify the moduls I want to use!
Or did the monastery turned recently into George Orwell's “Ministry of Truth”?
Some people here vividly dislike (these aspects?) of OOP.. ok I'm fine with it!
I'm neither preaching to them nor will I try to convert them in any flame.
(it's a concept called tolerance... 8)
| [reply] |
|
|
UPDATE: I surely do not intend to write something like my $error = 3.1415927->minus( 22->divide( 7 ) )->abs();. (Come on, BUK! even from you this example is quite polemic... ;-)
I just saw your above update. My only defense is that it is drawn directly from the second example given in the autobox POD.
I also saw your post, saying "how absurd this argument about Perl reflecting natural language is.".
It was you that suggested that array->push->element was somehow better than push array, element.
Another counter example is COBOL's MOVE value TO variable., though that's long been superceded by COMPUTE variable = expression;
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l]
[select] |
|
|
BUK it's this kind of polemic nitpicking why I'm not discussing with you.
Let me explain:
> I also saw your post, saying "how absurd this argument about Perl reflecting natural language is.".
This is taken out of context and why swapping the objects brakes the natural language rules is perfectly explained in this post.
As I said, Perl's push is OK for me, but it's not as "natural" as you want us to believe. You seem to have double standards!
> My only defense is that it is drawn directly from the second example given in the autobox POD.
Again it's only an example. It's meant to demonstrate the new syntactical possibilities of autobox. It's evidently not meant as a use case, which should be evident for reasonable minds.
Forcing someone with nitpicking into examples which can't be criticized in any possible way, is a good method to make him speechless. I'm not playing this game...
You claim that you want me to explain things to you, I claim that you primarily want to win a debate.
Sorry if I do you wrong, but others here will certainly be willing to explain you the benefits of OOP and of reusing code from other languages.
| [reply] |
|
|