Hacker News Reader

Comment by u801e | Hacker News Reader

> IMHO the biggest issue that blocked Perl's broader adoption was the really obfuscated handling of nested data structures including objects. Anything beyond array of arrays or hash of hashes was a pain.

How was it a pain specifically? If you used references, then defining an arbitrary data structure shouldn't be an issue and accessing individual elements would be a matter of prefixing the reference with the appropriate sigil.

In python, you need to be aware of when you're making a copy of an element in a data structure rather than getting a reference of that element. In perl, you would know based on syntax whether you're dealing with a reference as opposed to a copy of an instance.

View on HN

> In perl, you would know based on syntax whether you're dealing with a reference as opposed to a copy of an instance.

Once you 'get' the sigils in Perl, you miss them everywhere else.

They're kinda just a barely-there static-typing system, but damned if that's not way better than none. And if one recalls that monochrome screens used to be a thing, and that syntax highlighting was wonky (because shortcutted to be usable on weak hardware) and/or too computationally expensive for computers for a while after that, one really understands the appeal of the sigils. Perl is one of the most notepad-friendly languages around.

PHP's weird half-assed copy of the sigil system ($ only, for everything) is one of my least-favorite things about it (but I don't really hate PHP the way some people do, so that may not be saying much).

$, %, and @ are why using complex multi-dimensional arrays & associative arrays in Perl is non-crazymaking. You can at least state the kind of thing you're intending to use at each layer of the array, and have that intention readable even when syntax highlighting isn't available, which is a lot better than nothing.

Isn't that just a half-assed mandatory Hungarian-notation system? :-/

I mean, sure, in Perl the language "casts" the value into an appropriate type for you, but only in a few select cases..

Yeah, I mean more in the information it carries for the human reader than its effect on how the machine sees it.

Well, making it enforced by the runtime answers at least one obvious objection to Hungarian notation.

It is pretty similar to Hungarian notation, but it also denotes context. But is it half-assed? I'm not sure. It expresses the type of the variable over a very narrow set of types. If anything you could say that the type system is half-assed. I've thought a lot about this over the years and I have come to believe that it is really a minimal type set that offers an incredibly useful set of abstractions.

For me, the main advantages of sigils are that I can immediately see if I am looking at a variable or a function name and that the sigil effectively separates the name spaces between functions and variables. This has the side effect of making it easy to distinguish functions that have been passed in as variables from functions declared or imported into the particular scope.

Even with a nice IDE I miss the distinction that the sigils provide.

Yes, I definitely miss this in Ruby since it also has optional parens for method calls but lacks sigils. Even the most basic-looking expressions can have arbitrarily complicated meanings:

  foo.bar = 1

Is that just an attribute set on an object, is it calling a method foo that returns an object containing a bar attribute with a normal getter/setter, or is bar= a method that has arbitrary functionality?

I also like the more explicit operators in Perl that help show context:

  $foo + $bar

This is specifically numeric addition and those operands are probably at least somewhat number-like. Yes you can potentially overload it, but by convention, it will still be something like addition, so you don't have to wonder if you are adding, concatenating, appending a list, or something else, because they have different operators.

Reply on news.ycombinator.com