Hacker News Reader

Comment by xupybd | Hacker News Reader

I'm also shock that in Perl you can alter your return type based on the type of variable the caller is putting your result in.

https://perlmaven.com/wantarray

That always appeared as madness to me. Why would you make things that cryptic to understand?

View on HN

If a Perl script is written and maintained by just one person, or a few people who can agree with each other, then features like that are not a problem: you just agree not to use them. They are, however, an argument for not using Perl for a big project that lots of people will work on.

> I'm also shock that in Perl you can alter your return type based on the type of variable the caller is putting your result in.

You can do that in Java, if I understand that feature correctly.

For example, it's possible to write a method that returns a generic type over whatever type you're trying to assign to, e.g.:

    static <T> List<T> listOfAnything() { return (List<T>) new ArrayList(); }

Which can be used like this:

    List<String> stringList = listOfAnything();

Or by letting the compiler infer the type from the return type of a method:

    List<Integer> listOfInts() { return listOfAnything(); }

This is not just some esoteric feature... it's quite commonly used by, for example, deserialization libraries and functional programming.

Those are all the same underneath. Perl's scalar / array duality is a bit more of a difference.

Generics are awesome. They allow you to do partial typing. You don't specify the exact type but you constrain the output type based on the input type. So you have functions that can operate on many types but still have strong typing.

Wantarray is not a generic implementation. It's closer to reflection. You can detect the type of variable the caller is putting your functions result in. Then you can branch your program based on the variable type that the caller wants. I guess this is similar to type inference but not exactly as it's not part of the type system. For example, if they want an array return the amounts of each transaction in an array if not return the sum of the transaction amounts.

That trick "works" in Java because, for compatibility reasons (Java didn't have generics originally), the generic type is erased by the compiler. Your example compiles to:

    static List listOfAnything() { return (List) new ArrayList(); }

    List stringList = listOfAnything();

    List listOfInts() { return listOfAnything(); }

The generic type isn't monomorphised or even reified; within your method, you don't have access to the generic type T "passed" by the caller. If you need it, you have to pass it explicitly, as commonly used by deserialization libraries:

    static <T> T deserialize(String input, Class<T> cls) { ... }

Which can be used like this:

    MyStruct result = deserialize(input, MyStruct.class);

Note that the deserialization library has no way of knowing the type of the variable the caller is putting the result in, the caller had to pass it explicitly. This is because what the Java compiler actually generated from the code above was something like:

    static Object deserialize(String input, Class cls) { ... }

    MyStruct result = (MyStruct) deserialize(input, MyStruct.class);

It's possible for the deserialization library to know the type from the payload itself, but of course it has to "happen" to coincide with what's being cast to. You don't need to pass the Class object at all.

And that well-studied for of polymorphism is entirely unlike having the callee knowing if the caller expects an array or an it, and changing the result.

wantarray() is a sensing operation that allows a type of transparent function overloading: Oh you wanted just a scalar? OK.

Python's ordered arguments mixed with out of order labeled arguments is worse IMO: Tell me arguments in this order. Or not... I mean, you could just tell me which they are. Wait, I got two of these... F*ck this, I quit

Yes but if you want to know an arrays length you can just put it in a scalar. So you consume some API and want to get the length of the result. You put the array result into a scalar variable. Then what this is not the length?

The API documentation should reflect that the result is context sensitive. Not reading that is a good way to get burned despite the language.

Perl is well known for it's multitude of idiosyncrasies, this is one of the reasons why it can be frustrating to programmers who have better experience in more modern or rigidly structured languages.

That particular API would have been much better had it been documented.

If only there was some well written book about Learning Perl, or well written documentation in the form of manual pages (see perldata).

That doesn't cover this particular third party API.

Isn't Python's mixing rules very simple?

(1) Un-named arguments come before any named arguments and should be passed in order (this is familiar to programmers in almost any mainstream language).

(2) Named arguments can then follow, in whatever order.

Yes, they not complicated, and I imagine it's a non issue for most.

The interface is awkward however in that in other languages you would overload the function or pass a data structure, or reference of one, to manage additional optional parameters when you didn't want the extra arguments explicitly listed.

Python is a popular language and there are a ton of contributors who have developed third party packages. Unfortunately, these are not always well written or maintained and it can be easy to stumble across a bad one when looking for useful things. It's never fun to debug code in an unfamiliar language.

*nix applications also can alter thier output based on where it's going, e.g. to a pipe or to a file.

That's actually a good point. It seems to work well in that context. I'm not sure I have an entirely rational reason for liking it in one context and not the other.

I don't like it! :-D Of course, now I expect it so don't get bitten anymore.

As a Perl developer, I never once used that feature. It does make some sense in the context of how Perl's own operators work, making them "do the right thing" for different cases. But for user code... not needed.

This branch of comments has decent gripes.

I adopted the contextual thinking fairly easily so it was not an issue for me but having worked with so many languages since perl I can see why this would be annoying to others. It's not the most unfortunate aspect though.

It's not so bad when you know what is going on but when you first hit something like that it's hard to figure out what is going on. Basically violating the Principle of least astonishment

https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...

Perl also flagrantly violates the Principle of Least Nausea, with all its emetic Syntactic Syrup of Ipecac.

https://en.wikipedia.org/wiki/Syrup_of_ipecac

Reply on news.ycombinator.com