101–110 of 130 posts
Earlier quoted context omitted.
Perl gets installed wherever `git` CLI is available, generally. I'd say it's more ubiquitous. And it doesn't suffer from the python2/3 split.
Neither does Python, for years now.
I believe they should have been Py3 when they wrote them. It was not my decision, but it did become my problem.
Earlier quoted context omitted.
> Larry Wall was a polarising character. He could be witty but also tiresome. To whom? Unless you were working on the Perl language itself, there was no need to interact with him.
I offered to help out with the Perl 6 logo, as I had both experience writing Perl as a career and having gone to art and design school - while also running a printing studio of my own. I joined the Perl6 dev mailing lists, listened in on them, offered my support, gave a broad stroke on design ideas, backed them up with reasonable arguments and asked for comments. Larry chimed in basically saying, "no, because this su…
Earlier quoted context omitted.
> Larry Wall was a polarising character. He could be witty but also tiresome. To whom? Unless you were working on the Perl language itself, there was no need to interact with him.
I offered to help out with the Perl 6 logo, as I had both experience writing Perl as a career and having gone to art and design school - while also running a printing studio of my own. I joined the Perl6 dev mailing lists, listened in on them, offered my support, gave a broad stroke on design ideas, backed them up with reasonable arguments and asked for comments. Larry chimed in basically saying, "no, because this su…
About 5-6 years ago I found a new niche for Perl in my day-to-day work. I did a lot of shell scripting at the time and was constantly getting annoyed by subtle differences between macOS and Linux. Sed is especially difficult, because the flags in BSD version and GNU version for in-place search and replace do not match. Plus, sed regexes are more primitive compared to most other languages. I decided to switch from sed…
One such case is adhoc small scripts mid pipeline. There's just certain Perl syntax that's so deeply embedded in me that no matter how much I try to learn sed/awk/tr, I can't help but reach out to my old love in times of weakness and need. I just know how to talk to Perl in the most intimate of ways that's been hard to reproduce in other languages.
I still feel a little like I've betrayed Perl a bit every time I use Python.
Perl, Larry Wall, Randal Schwartz, Tom Christiansen, brian d foy, O'Reilly, and the many other participants of comp.lang.perl.* had such a lasting influence on my programming career. I wouldn't be who I am today as a programmer without having experienced all the Perl community put out into the world.
Earlier quoted context omitted.
Unfortunately, "do not reinvent the wheel" coupled with "there is more than one way to do it" leads to a proliferation of wheels that you pull in in any medium-to-large project. There are many ways to have OOP? Moose, Mouse, Moo, MooseX::Declare, Class::Accessor — you are pretty much guaranteed to pull in them all and have them coexist in runtime. Now Corinna or whassname is coming in, but it has no users yet so it d…
>There are many ways to have OOP? Moose, Mouse, Moo, MooseX::Declare, Class::Accessor — you are pretty much guaranteed to pull in them all and have them coexist in runtime. I think this is hyperbole. Generally, you won't be mixing Class::Accessor and Mo* based dependencies unless you are dealing with a shitty, barely maintained legacy codebase. There was a progression to things, mostly because of performance reasons…
(Looks at the dependency graph) No, it’s a fact.
> Generally, you won't be mixing Class::Accessor and Mo* based dependencies unless you are dealing with a shitty, barely maintained legacy codebase.
I don’t. But the modules my project depends on (transitively) do, because those modules were developed and last touched during different fad eras. So when the app starts, I have, like, four OO systems, three ways to do JSON, two to do YAML, and four ways to do HTTP in the memory.
Also, the authors of said modules tend to have Egos and Opinions (capitalization intended) that prevent them from converging on common things.
Yeah, while everyone still discussing on how to do FP in mainstream languages, Higher-Order Perl was published in 2005, placing many of such ideas how we were already doing that stuff in Perl into paper. Perl allows to come at peace with UNIX being done in C, by exposing similar programing language capabilities, mixed with Lisp like wizardy, without having to deal with C security faults unless required for performanc…
Higher Order Perl is such a gem, one of the best programming books in general.
Earlier quoted context omitted.
Unfortunately, "do not reinvent the wheel" coupled with "there is more than one way to do it" leads to a proliferation of wheels that you pull in in any medium-to-large project. There are many ways to have OOP? Moose, Mouse, Moo, MooseX::Declare, Class::Accessor — you are pretty much guaranteed to pull in them all and have them coexist in runtime. Now Corinna or whassname is coming in, but it has no users yet so it d…
>There are many ways to have OOP? Moose, Mouse, Moo, MooseX::Declare, Class::Accessor — you are pretty much guaranteed to pull in them all and have them coexist in runtime. I think this is hyperbole. Generally, you won't be mixing Class::Accessor and Mo* based dependencies unless you are dealing with a shitty, barely maintained legacy codebase. There was a progression to things, mostly because of performance reasons…
Earlier quoted context omitted.
I so much feel the same. At the time I was writing Perl, each line made so much sense, as if I was speaking my mother tongue. It was clearly an extension of my brain. Never had that feeling with any other programming language, and it took me years to eventually let Perl go and try to wrap my head around Python.
I wonder how much Larry Wall's background as a linguist has to do with that, which perhaps also explain some of Perl's "messier" features, just like natural language is kind of messy. I once had a long conversation about this with a linguist and Perl programmer that I randomly met in a pub. However, I was quite drunk and don't really recall too much, and we never saw each other again.
Computer programming theory has large swathes of inspiration from theoretical linguistics - think lisp. That's nice for theoreticians because it makes things like parsing easier to think about rigorously. Perl on the other hand, to my knowledge is the only significant programming language to be inspired by practical linguistics, and therefore appeals to concepts like context and ambiguity way more than other languages. This means that a lot of computer scientists academics absolutely hate it, and so it was very much neglected in the education space.
The other side effect of this is you still get a good number of talented programmers with backgrounds in the humanities and social sciences who do very well on perl.
Earlier quoted context omitted.
Do you develop with Perl collaboratively with teammates?
Last year I finished over a decade on very large Perl project, collaborating within a team. When I joined that project it was already over a decade old a most of the code was much like what you are probably imagining. When I left the project, all the parts we had touched were much like any other high quality modern codebase, and we could almost as readily maintain the decade-old parts (that we had worked on) as the w…
Earlier quoted context omitted.
> Larry Wall was a polarising character. He could be witty but also tiresome. To whom? Unless you were working on the Perl language itself, there was no need to interact with him.
I offered to help out with the Perl 6 logo, as I had both experience writing Perl as a career and having gone to art and design school - while also running a printing studio of my own. I joined the Perl6 dev mailing lists, listened in on them, offered my support, gave a broad stroke on design ideas, backed them up with reasonable arguments and asked for comments. Larry chimed in basically saying, "no, because this su…
I am qualified to help design a logo. And if the feedback was, "great ideas, but not the direction I want to go. What about..." or anything similar, that would be a fine way to show that my offer for doing free work is still happily welcome, with reasonable direction from the owner of the project. You know like a discussion.
There's some great OS logos. The Linux Penguin was great. BSD Daemon, etc, etc, etc. I love the camel, but that's not owned by Perl. It's not an impossible task.