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.
Then Larry Wall announced Perl6 and focusing on Python while awaiting P6 was an easy call.
Python 3 was announced in 2006, committed to as the future in 2008, and the last significant release of Python 2 was in 2010. There was a hard deprecation deadline of the Python 2 in 2015, which was postponed in 2014 to 2020. It wasn't fantastic and there was some pain and some poor decisions but everybody knew where the language was going and how to stay in front of it.
Perl 6 was announced in 2000 and there were only 2 releases of Perl 5 for 7 years. Then in the 2007-2010 timeframe regular releases of Perl 5 resumed. Eventually everyone kind of realized that Perl6 was DOA as the next major release of Perl, but that process happened gradually over the course of nearly 20 years, by which time most of the rest of the world had written off Perl as a significant entity.
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.)
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.
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.)
1) Natural language doesn't have to worry about backward compatibility in the same way. The exact meaning of older phrases don't have to coexist with those of new phrases.
2) Natural language doesn't have to recruit new users in the same way. I think Spanish is one of the easiest commonly spoken languages - if a random person speaking no commonly-spoken-in-the-world language had to choose languages, Spanish would be ideal. English is weird in saying things with idioms, Chinese has tones and complex characters, etc. English has evolved in a perl-like fashion and if it was a programming
3) No children learn perl or any programming language as their "first language". Everyone learning perl had to wade through it's modes and variable names like "_" and translate them to their internal concept language. (should add: verbs like "be", "do", "have" etc are very fuzzy in English as well as proposition "like" "to", "from", at etc but this fuzziness is incorporated as a person learns the language. But adding an equivalent weirdness to a language someone is just learning isn't necessarily going to be appreciated).
4) Communicating with other humans is arguably a key function of computer languages as well as natural languages. But computer language do also have to communicate exact to descriptions to the very dumb devices known as computers. So "getting the gist" and "getting it exactly" have to be somewhat close and makes "there's more than one way to do things" more problematic, especially as ways to do things multiply.
This story has been told for decades, but it just isn't true. What is particularly convenient to express in Perl? The only thing i can think of is the implicit use of $_. Everything else is no better than or worse than in a more conventional language.
Things like sigil's are useful in this regard because they provide hints that allow extending the language w/ irregular syntax, like with autovivification. Perl wasn't designed; it slowly accreted features as use cases emerged, moderated by implementation constraints, and that was intentional.
Python code today is nowhere near as simple as 20 years ago. Python, Java, and similarly aged languages are ending up w/ a cornucopia of mismatched language syntax and semantics much like Perl, except Perl was never blind to the inevitable. Lua is one of the few exceptions, but that's because Lua has gone through a couple top-down redesigns in addition to its more regular backward compatibility breaks.
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
>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
>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://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
"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
(You mention exactly one thing about Perl's design, namely the "bless" keyword. That's a bit quirky, but it's not a terrible name for what it does and nothing obviously better occurs to me.)
> Going on a missionary expedition [...] sounds to me more like [...] than a sound motivation for programming language design.
In what way were Larry Wall's missionary ambitions a "motivation for programming language design" at all? I don't see any sign that they were.
(I do remember, from many years ago, something in Perl's licence or readme file along the lines of "I make Perl because I think it pleases the Author of my story. If you have a problem with that, your notion of Authorship needs some revision :-)", but I think that means not "I wrote Perl to help me convert the heathen" but "Everything I do is for the greater glory of God". So far as I can see, that doesn't imply any particular language-design choices.)
[EDITED to add: I looked it up. The above doesn't misquote too badly, but one place where it diverges from the original is that he actually wrote "nice things like this", not "Perl" specifically. I think this makes it even clearer that the Perl language design as such is not what LW is saying was religiously motivated. You can find the actual text at https://github.com/Perl/perl5 if you care.]
I listened to as much as I could bear to of that language design conversation. (The audio is incredibly bad for almost all of it, unfortunately.) I didn't notice Larry Wall's contributions being notably less insightful, more dogmatic, more ignorant, or whatever it is you're gesturing towards. The one example you give is that Larry Wall doesn't like IDEs and James Gosling does, which doesn't seem like good evidence of anything.
So, please, if you're going to make this sort of claim, make it explicit enough to engage with properly. What about Perl is the way it is becaues of Larry's "religious fanaticism"?
(As it happens I'm an atheist and don't like Perl very much. There's plenty I dislike a lot about both Christianity and Perl. It's the alleged connection you're trying to draw between them that I don't see at all.)
Yet HN mods have the gall to claim that "reflexive," combative commenting is not allowed, and "reflective," truth-seeking comments are what's required: https://news.ycombinator.com/item?id=26548649
Clearly, certain users are allowed to say whatever they want on HN. If HN were honest, it would go ahead and give them orange checkmarks.
It would also not be allowed if it were against any religion other than Christianity.
Honestly, this could only be said by someone who had never met anyone whose spoken language hadn't been written. I personally know people who have recently done exactly this: Developed a writing system for a tribe of people who previously had no writing system for their own language. The people themselves are amazed to see their language written down. They have generally internalized the negative attitudes of the larger culture they live in toward their own language; they'll say things like (and this is going to be offensive, but again, it's them saying it about their own language, having internalized it from the larger African language groups around them), "I thought our language was just a monkey language". Seeing it written down gives them a sense of value and pride toward their own culture they've never had before. This is exactly the opposite of "the transfer of a dominant language to other people". On the contrary, it gives people a powerful tool to fight linguistic imperialism.
0: https://en.wikipedia.org/wiki/Canadian_Aboriginal_syllabics
This isn't 'Temple OS'. By this line of reasoning we should all only use strongly-typed FP since it's the only 'rational enough' language family.
Not Python -- it has Zen-like practical suggestions about what matters, instead of ideological doctrine about how to do it:
https://www.python.org/dev/peps/pep-0020/
>There should be one-- and preferably only one --obvious way to do it.
>Although that way may not be obvious at first unless you're Dutch.
Does The Zen of Python really sound "imperialistic" to you?
The Zen of Python
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!Anyway, the closest I’ve experienced is Go, to answer your question.
https://en.wikipedia.org/wiki/Christianity_and_colonialism
>Christianity and colonialism
>Christianity and colonialism are often closely associated with each other because Protestantism and Catholicism participated as the state religions of the European colonial powers and in many ways they acted as the "religious arms" of those powers. According to Edward Andrews, Christian missionaries were initially portrayed as "visible saints, exemplars of ideal piety in a sea of persistent savagery". However, by the time the colonial era drew to a close in the last half of the twentieth century, missionaries became viewed as "ideological shock troops for colonial invasion whose zealotry blinded them", colonialism's "agent, scribe and moral alibi."
>In some areas, almost all of the colony's population were removed from their traditional belief systems and were turned into the Christian faith, which the colonizers used as a reason to destroy other faiths, enslave the natives, and exploit the lands and seas.
>"Colonialism is a form of imperialism based on a divine mandate and designed to bring liberation – spiritual, cultural, economic and political – by sharing the blessings of the Christ-inspired civilization of the West with a people suffering under satanic oppression, ignorance and disease, effected by a combination of political, economic and religious forces that cooperate under a regime seeking the benefit of both ruler and ruled." -Jan H. Boer of the Sudan United Mission
Also, the end of slavery was pushed by conscientious Christian evangelists like John Newton and William Wilberforce in the UK. It is easy to argue against slavery in Christianity owing to the Imago Dei doctrine. I suspect it is less easy to argue against slavery in other religions and cultures; many of which still practice forms of it today.
Spreading your religion while separating your culture is difficult. The same way it is difficult for a migrant to fully adapt the customs of any host culture. I think the relationships between these ideas are more complex than the evil catch-all of 'Imperialism!'.
It's fascinating to learn that Larry Wall might have become a missionary had his life gone a different direction, but I don't think one can make a compelling case that Wall's religiosity had a major effect on Perl's language design. Don Knuth is a devout Lutheran who played church organ, taught Sunday school, and wrote a book about the Bible -- but it just doesn't seem likely we should be concerned that typesetting our work with TeX subtly infuses it with Christian apologia.
This always felt like an excessive over-reaction to Perl's "there's more than one way to do it" motto and never struck me as desirable or true.
In the earlier days of Python I remember reading StackOverflow questions which attracted differing solutions and Python advocates (who were a bit abrasive at the time) would reconcile this with the above by saying some answers weren't sufficiently "pythonic". It all seemed rather strange.
https://news.ycombinator.com/item?id=24083738
https://www.mondo2000.com/2018/06/18/the-inspiration-for-hyp...
"In 1985 I swallowed a tiny fleck of gelatin containing a medium dose of LSD, and I spent most of the night sitting on a concrete park bench outside my home in Los Gatos, California." -Bill Atkinson
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.
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.
Once you 'get' the sigils in Perl, you miss them everywhere else.
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.
I mean, sure, in Perl the language "casts" the value into an appropriate type for you, but only in a few select cases..
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.
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.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
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?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.
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.
Can you expand on that a bit? Are you talking about how Perl5's variable sigils?
$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]; $array_ref->[2][2][1];Here's a modified example where it's not as clear how to deref.
Like:
@IP = ('192.168.1.10','192.168.1.15');
@PORT = ("5000","5002");
@TCP = ("Q931","H225","H245");
%TAGS = (L2 =>"ETHERNET",L3=>"IP",L4=>\@TCP);
@PKT = ( \@IP, \@PORT, \%TAGS);
$array_ref=\@PKT;
print $array_ref->[2]{L4}[0];# this works
print $$array_ref[2]{L4}[0]; # this works
print $array_ref[2]{L4}[0]; # this doesn't
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.