19 ms·
IMHO the biggest issue that blocked Perl's broader adoption was the really obfuscated handling of nested data structures including objects. Anything beyond arra
by tzmudzin 6y ago
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. It was and it still is way superior to Python for hacking of flat files, but once you needed to go beyond a hash the pain was real.
That was 20+ years ago, and Python filled this space with its easy definition of classes and candy syntax. Where Perl overdid on hackery, Python may have overdone on sugar -- but it clearly won the love of the masses.
Now, 25 years later, the ship has probably sailed for Perl, and -- while I still prefer it to sed/grep/awk and Python for simpler tasks, I don't see it conquering Python space for more complicated processing.
- Tepix 6y agoI think they lost it with Perl 6. Perl 6 was a bit late, but it could have been a better rejuvenation for Perl than Python 3 was for Python. Instead it took way too long, had confusing naming with the various implementations and frankly some features that are not very useful for anyone but linguists. I mean, why would you want to redefine your language from within the language? To confuse your co-workers? To win the obfuscated perl contest? Perl 6 also has some real innovation like its new regular expressions. I'm afraid they will never get widely adopted. FWIW i never had a problem with nested data structures in perl. I found the perl documentation ("perldoc perldata") to be fantastic.
- lizmat 6y agoPlease note that Perl 6 is no longer a thing: it has been renamed to the Raku Programming Language (https://raku.org https://raku.org). If you want to stay up-to-date, you can check out the Rakudo Weekly News at https://rakudoweekly.blog https://rakudoweekly.blog
- arglebargle69 6y agoThis is precisely the problem
- tsjq 6y agoHahaa. So true
- kqr 6y agoThis was the problem. It's now been fixed. Or do you think Perl 6 was the more meaningful name?
- znpy 6y agoEh, it sorta still is? Not really, but if you spent ten years announcing an upcoming perl6, then you rename it to Raku... There will be confusion, at least.
- emodendroket 6y agoNot just confusion. If you hype it up as the future and then drop it how excited are people really going to get for the old stuff?
- lizmat 6y agoPerl 6 was released in December 2015. A little under 4 years later, it was renamed to Raku. Plenty of time to not be confused.
- DonHopkins 6y agoThey should have done what the YAML designers did when they suddenly realized to their great surprise that the language they themselves designed and named was NOT actually a markup language: Keep the exact same name and a perfectly straight face, then recursively retronymonically redefine it to mean something completely different: the opposite of what it initially meant! "Yet Another Markup Language" => "YAML Ain't Markup Language" So "PERL 5" is to "Practical Extraction and Reporting Language 6", as "PERL 6" is a "PERL E___ R___ L___ 6". (Pattern matching and filling in the blanks is left as an exercise for GTP-3.)
- Doctor_Fegg 6y ago
- smitty1e 6y agoI was at the point of deciding whether to focus on Perl or Python when there was the 01Apr "Parrot" gag on Slashdot. This was a couple of decades back. Then Larry Wall announced Perl6 and focusing on Python while awaiting P6 was an easy call.
- lostapathy 6y agoPerl 6 wasn't "a bit late" - the path forward meandered for years, so the point even diehard perl fans (me, at the time) questioned whether it could/would ever happen. And as pointed out down thread, the branding completely changed at least once or twice along the way, to the point perl fans of 20 years ago don't even know "perl 6" became something else today.
- Tepix 6y agoSorry, you're right. What I meant to say was "Perl 6 started a bit late". For a while it looked very promising but then it went downhill.
- stinos 6y agoWhere Perl overdid on hackery, Python may have overdone on sugar Haven't used Perl often, but that's sort of my impression as well. And that Python sugar feels mostly pretty well reasoned about. And fairly usable and readable as well. Whereas in Perl I sometimes had the impression a bunch of people with CS degrees made something they thought out while on LSD and just decided to add it. Cool at the moment, but not too usable by sober minds afterwards.
- kqr 6y agoAs you probably know, contrary to almost every other language out there, Perl was not designed by people with CS degrees adding things that sound cool. Perl was designed by a linguist along the principles of "what would English look like if it was a programming language?" Not in the superficial syntactic sense, but the underlying grammar. What is the implicit "it"? What can we derive from context and decision so we don't have to spell it out? And so on. This makes it very convenient to express common things in different ways (just like English, there is no one true way to say something) but it also creates some peculiar constructs that make sense but you'd go "who says this?" (again, much like in English.)
- DonHopkins 6y agoOk, then if not actually designed under the influence of LSD, then certainly under the influence of religious fanaticism. The tired old "Perl was designed by a linguist" cliché is endlessly Parroted (pardon the pun!), but doesn't actually necessitate or imply good programming language design. But look at the actual factual source of that folklore -- it would be more accurate to say "Perl was designed by a wanna-be missionary", and that certainly shows ("Exegesis", "Apocalypse", "bless", etc): https://en.wikipedia.org/wiki/Larry_Wall https://en.wikipedia.org/wiki/Larry_Wall >While in graduate school at the University of California, Berkeley, Wall and his wife were studying linguistics with the intention of finding an unwritten language, perhaps in Africa, and creating a writing system for it. They would then use this new writing system to translate various texts into the language, among them the Bible. Due to health reasons these plans were cancelled, and they remained in the United States, where Wall instead joined the NASA Jet Propulsion Laboratory after he finished graduate school. Wall is an active member of the New Life, Church of the Nazarene. Going on a missionary expedition in Africa to invent and teach illiterate people of color a written language to read the Bible in certainly sounds to me more like religious and linguistic imperialism than a sound motivation for programming language design. https://en.wikipedia.org/wiki/Linguistic_imperialism https://en.wikipedia.org/wiki/Linguistic_imperialism >Linguistic imperialism or language imperialism is occasionally defined as "the transfer of a dominant language to other people". This language "transfer" (or rather unilateral imposition) comes about because of imperialism. The transfer is considered to be a sign of power; traditionally military power but also, in the modern world, economic power. Aspects of the dominant culture are usually transferred along with the language. Translating CS literary classics like the "Pascal Users Manual and Report" and Anders Hejlsberg's "Turbo Pascal Reference Manual", or even textbooks about sustainable farming techniques, nutrition, medicine, sex ed, and birth control, into their invented written language would do more economic and life sustaining good for those poor Africans than translating the Bible. kqr> "people with CS degrees adding things that sound cool" People with CS degrees add cool things that are sound, not things that sound cool. Do you really believe that programming languages should be intentionally designed to be MORE like religions, MORE imperialistic, MORE evangelical, instead of less? Compare Larry Wall's contributions to this otherwise deep fascinating conversation about language design, versus the contributions of less religiously motivated, more scientifically trained programming language creators with CS degrees, like Guido van Rossum, James Gosling, and Anders Hejlsberg: A Language Creators' Conversation: Guido van Rossum, James Gosling, Larry Wall & Anders Hejlsberg https://news.ycombinator.com/item?id=19568378 https://news.ycombinator.com/item?id=19568378 https://www.youtube.com/watch?v=csL8DLXGNlU&t=49m41s https://www.youtube.com/watch?v=csL8DLXGNlU&t=49m41s James was literally taken aback by Larry's macho IDE shaming: https://news.ycombinator.com/item?id=19568381 https://news.ycombinator.com/item?id=19568381 "I think IDEs make language developers lazy." -Larry Wall "IDEs let me get a lot more done a lot faster. I mean I'm not -- I -- I -- I -- I -- I'm really not into proving my manhood. I'm into getting things done." -James Gosling
- cafard 6y agoThe last real job I did with Perl was just over nine years ago. HTML::TreeBuilder saved just hours, probably weeks, of frustrating work during a web platform transition. I think that you are right about the nested data structures. I was favorably impressed by the little I saw of Moose, but by the time that came along, all the young seemed to know Python and not Perl. It is not just flat files Perl handles nicely, either. One can do fixed-format munging in Python via the struct module, but I've never found it as handy as Perl's pack/unpack, something I used as far back as the Perl 4 days.
- arunix 6y agoWhat does "really obfuscated handling of nested data structures" mean? Can you give an example?
- luckylion 6y agoProbably dereferencing, since Perl never had multidimensional datastructures. You'd put a reference to an array into an array value, and then access it with $array[0]->[0] (iirc) to get the first value of the first array. That was the easy way to write it, the much more annoying way was like ${$array[0]}[0] (or $$array[0][0] if you really wanted to? my memory is fortunately fading), I believe, which got really out of hand when you went three or more levels deep.
- kqr 6y agoThe syntax for accessing nested indices actually automatically resolves references the way you'd expect. So for the specific case of accessing a single deeply nested value, no special incantation is needed.
- tyingq 6y agoPerl has sigils for different data types. $foo="bar"; #scalar/string %hash = { "key" => "value", "key2" => "val2" }; #hashmap @arr = ( 1, 2, "three", 4); #array But, it also has references, like pointers. $array_ref=\@somearray; # array ref $hash_ref=\%somehash; # hash ref $scalar_ref=\$some_scalar; # scalar ref So, you can put scalars into arrays and hashes, refs into hashes and arrays, etc, etc. At whatever nested depth you want. But you have to extract pieces later. And Perl, as usual, allows a zillion ways to do it. These are all exactly the same thing: $$arrayref[0] = "data"; ${$arrayref}[0] = "data"; $arrayref->[0] = "data"; So imagine you need to extract a string that's at the bottom of some data structure. Here's an example: @IP = ('192.168.1.10','192.168.1.15'); @PORT = ("5000","5002"); @TCP = ("Q931","H225","H245"); @LAYER = ("ETHERNET","IP",\@TCP); @PKT = ( \@IP, \@PORT, \@LAYER ); $array_ref = \@PKT; I can extract something using different approaches, like: ${${${$array_ref}[2]}[2]}[1];# oof! # same result, looks better, but imagine # we put a hash in the data structure, or # had deeper structures $array_ref->[2]->[2]->[1];
- u801e 6y ago> 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.
- HeckFeck 6y ago> 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.
- gh-throw 6y agoThey'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.
- hnfong 6y agoIsn'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..
- marbu 6y agoThe issue with nested structures is a good point. Another problem I noticed would be natural language like syntax sugar, which makes it harder to maintain your knowledge of the language if you don't use it regularly. I learned some perl long time ago during one project, and after I stopped working with the project, I also gradually stopped using perl for quick scripts, and settled on sed/grep/awk again for quick simple stuff, and python for the other tasks.
- deleted 6y ago[deleted]
- andi999 6y agoTo me it was the documentation. Whenever I tried to get into it, I only came across books/tutorials(I dont remember) which start with, oh pearl, here are regular expressions. And then a very very unstructured heuristical explanation of regular expressions. Usually gave up at that point.
- p0nce 6y agoExactly. Perl is hardly readable, difficult to understand, and simple things (like parsing a XML) becomes difficult in Perl.
- daotoad 6y agoHow were you parsing XML? I've never found it to be a difficult task. XML::LibXML is a nice wrapper around libXML. XML::Twig is great if you need to process huge files. XML::Rabbit will seamlessly map your XML into objects. There are things to criticise Perl for, like idiosyncratic argument handling in subroutines or the use of weird punctuation variables, but to call out XML parsing as particularly hard is questionable. Take a look at this example from https://grantm.github.io/perl-libxml-by-example/basics.html https://grantm.github.io/perl-libxml-by-example/basics.html use XML::LibXML; my $filename = 'playlist.xml'; my $dom = XML::LibXML->load_xml(location => $filename); foreach my $title ($dom->findnodes('/playlist/movie/title')) { say $title->to_literal(); } How is that particularly difficult?
- Diederich 6y ago> really obfuscated handling of nested data structures including objects Can you expand on that a bit? Are you talking about how Perl5's variable sigils?
- spookthesunset 6y ago> IMHO the biggest issue that blocked Perl's broader adoption was the really obfuscated handling of nested data structures including objects Oh man did we ever abuse the shit out of the loosy-goosy data structures you could make in perl. Almost any time you needed to debug or trace something, you'd pretty print the entire data structure you were passing around. Some of those suckers would be huge and you'd be passing that structure around to almost everything in your codebase! As an outsider it might appear scary and a massive code smell... but when you worked on that codebase it just kinda all made sense somehow. It was just how perl programs rolled. I have yet to work in any other language that let you use and abuse the native data structures quite like you could in Perl.