Re^2: What are the drawbacks of autobox?

[LanX]

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.

[BrowserUk]

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 }

[punkish]

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.

[BrowserUk]

I think there is value in autobox. I too would like to explore, like Lanx, ..., and what its costs are.

My inquiry of LanX in no way prevents you (or others) continuing that discussion in the main thread.

what that value is

For me, that was the more interesting discussion. And I've yet to see any such value. That doesn't stop you finding value, but it stops me from giving it any further consideration.

[chromatic]

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.)

[BrowserUk]

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".

Well, it has been a long time, but I think you are more confused than I am. Precedence, (or a lack thereof), does not preclude the use of normal math infix operators. (Or as they call them "the usual binary arithmetic operators".)

And if you look at the best example I turned up in a quick peruse of my 20 y/o SmallTalk V/PM manual, you'll see ^self fromSeconds:((( hours*60 ) + minutes ) * 60 ) + seconds doesn't look any different to the way many people would code the same thing in a language that supports precedence. Contrast that with the same expression in languages that use reverse polish notation, or postfix method syntax.

Indeed, there are many programming books that advocate that precedence should be ignored and all compound expressions should be fully bracketed. This for the clarity and simplicity it gives the programmer. Not the computer parser.

[Anonymous Monk]

You know, I really like hot dogs and beer

[LanX]

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

[BrowserUk]

I spend 4 hours constructing methodical, rational, reasoned, non-flame responses to your reasons for using autobox, and you counter with a dismissive, "there are good answers to your questions". Yeah right!

If you can't justify why you would use it, why are you concerned with whether it is safe to be used?

[dsheroh]

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.

[Herkum]

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.

[chromatic]

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.

[Herkum]

I think the issue I have is that it is not really solving anything. It is just using different syntax to do the same thing that can already be done. That was the whole point behind Ruby, someone wanted different syntax for doing the same thing. I fail to see the benefit of trying to make Perl act like Ruby.

I also don't see a huge advantage of autobox just because it distinguish between objects and non-objects and can apply generic method calls. So what; Java does this as well and Java is not any better for it.

I keep thinking of autobox being a lot like Louisiana Creole, French and English mixed together to form something that no one outside of Louisiana can understand it.

[LanX]

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!

[DrHyde]

One thing that most people forget is that TIMTOWTDI doesn't mean "There Is More Than One Way To Do It". It means "There Is More Than One Way To Do It (but most of them are wrong)".

[dsheroh]

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.

[LanX]

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!

[dsheroh]

Touche. :) I copy-pasted from the docs and failed to notice that BrowserUK's version was slightly different.

[BrowserUk]

1. Rhetoric: Rhetoric is the art of using language as a means to persuade.

   When correspondents refuse to give straight answers to straight questions, and instead start hiding behind the political tactics of diversion, evasion or disingenuousness, the use of rhetorical forms to draw out the answers sought, is neither trickery nor ridicule. Just good debate.

   Without debate, a site as this would be nothing more than an interactive, crowd sourced, memory prompt and FAQ. The human component utterly replaceable by google's search algorithms.

   Each would state their opinion; each would retain their opinion unchallenged. Noone would learn a damn thing.

   I love having my opinions challenged. The things I learn that way are usually far more important than anything I get from following one person's, or book's, take on the world verbatim.

   But I admit it does bug me when people make assertions and then won't back them up with proof. Or at least drop the matter quietly. Under those circumstances, especially when there seems to be a genuine clash of conception, the refusal to try and reach a common understanding, even if only that they agree to differ, leaves me with an unresolved dilemma.

   And that irritates me beyond all else. I'd far rather be proved wrong, than be left hanging, or going around in circles, when my gut tells me that there is something important in the other person's argument that either I'm missing, or they are misconceiving; but I am left unsure as to which.

   These situations can in most cases, be so easily resolved, by showing what they mean, rather than describing it, in their own, particular environmentally influenced and non-transferable language.

   In short, on this site that means returning to the cry of the '90s: Show us the code!

2. Straw man: a weak or sham argument set up to be easily refuted.

   I have on occasion, deliberately used a straw man in an attempt to get the other party to clarify their argument. But not nearly as often as I am accused of doing so.

   The problem with discerning a straw man, from the genuine misinterpretation of your words, is that you think that because you understand them, everyone else will.

3. and ridiculizes the opponent: I don't have opponents here. And I do not set out to ridicule anyone.

   I will on occasion attempt to prod another monk into clarifying their statements when they seem reluctant to do so. But I never do this to newbies. And never for sport.

   The tactic is always reserved solely for those a) I genuinely believe can teach me something; b) who have previously demonstrated robust personalities and debating skills. And purely as an attempt reach a resolution.

There. It's on the record. Make of it what you will.

[LanX]

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)

[BrowserUk]

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;

[LanX]

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.

[BrowserUk]

but it's not as "natural" as you want us to believe.

I never suggested it was natural. Just countered your argument by saying that both are equally unnatural.

Again it's only an example. ... not meant as a use case

An example that's not a use case is an interesting concept.

I claim that you primarily want to win a debate.

Nope. I seriously wanted to understand why you would even be considering using autobox in production code.

I've got fairly well enchrenched views on programming langauges & paradigms, but every now and then I see someone who's opinions I value, suggest things that are contrary to my views, and I seek further information. And, potentially, reform my positions accordingly.

I've reached my conclusions now, and no longer seek that understanding. I only re-joined this thread because I noticed your update explicitly addressed to me.

explain you the benefits of OOP

I don't need them explaining. But I do think they are way oversold.

OO is just one of several programming paradigms, each of which has its place and its drawbacks. I like Perl because it allows me to choose the appropriate paradigm for the problem at hand, and mix them transparently.

My confusion and disquiet arises when I see people moving towards the One True (whichever) Paradigm, to the exclusion of all others.