17 ms·

With function signatures and state variables added in 5.010, I consider Perl feature-complete and have not really missed anything from it for as long as I've be

• yamtaddle 4y ago
  > What I do appreciate that's missing from many other languages and systems is the extreme committment to backwards compatibility. The knowledge that the next minor release won't break existing scripts is underrated, IMO. I don't write much Perl these days and haven't for some time, but it's still what I might reach for if I were tasked with writing something suitable for a scripting language that had to run with ~0 operational or upgrade/maintenance budget for a decade or more in environments I wouldn't necessarily be able to control or influence, or else [bad thing will happen].
  • latchkey 4y ago
    Perl needs backwards compatibility given the `write once, read never` nature of the syntax. Imagine trying to upgrade this to some new syntax... https://github.com/schwern/AAAAAAA https://github.com/schwern/AAAAAAA
    • TimTheTinker 4y ago
      That looks more like write-only naming... but the syntax itself isn't bad at all. Here's the main module: https://github.com/schwern/AAAAAAA/blob/aaaaaa/aaa/AAAAAAAAA.pm https://github.com/schwern/AAAAAAA/blob/aaaaaa/aaa/AAAAAAAAA...
      • liveoneggs 4y ago
        gross. Look at all of those non-'A's
    • usefulcat 4y ago
      The fact that it's possible to craft deliberately obfuscated code in a language doesn't actually tell you much about the language.
      • paulryanrogers 4y ago
        My guess is that for many people it's hard to write non-obfuscated Perl code. It has so many operators and ways of doing things that walking into someone else's code may feel like having to learn everything from scratch. (Higher Order Perl and such not withstanding.)
        • kamaal 4y ago
          In all honesty I have read more unreadable code in Python, than Perl. And I have written nearly equal of both over my career. You can write bad code in any language. Bad variable names(sometimes single alphabet names), functions running pages long, duplicate code, algorithmically inefficient code, no error handling, master try/catch statements, OO abuse, functions with unpredictable side effects etc etc. Early internet saw a flood of newbie programmers, and therefore a flood of badly written code too. For that matter you also see badly written C/C++ code from those days. How do you think C++ got its reputation for being too bloated beyond practical use?
    • gerikson 4y ago
      See also Acme::Bleach: <https://metacpan.org/pod/Acme::Bleach https://metacpan.org/pod/Acme::Bleach>
• arthurcolle 4y ago
  What is your project? Raku has some cool features and interesting syntax, I took a look at it before the rename, but find myself reaching for Python for basically everything.
  • forgotmypw17 4y ago
    Link is in my profile.
  • klibertp 4y ago
    Raku is a really nice language. I especially like the features that improve safety of the code: gradual typing, subsets, PRE and POST conditions, and defined/undefined checks. Junctions and multimethods are also nice. I have an article - not finished, and probably won't ever finish it, unfortunately - showcasing these features: https://klibert.pl/statics/raku/writeup.html https://klibert.pl/statics/raku/writeup.html I think Raku deserves way more attention. Its implementation is suboptimal in many ways and it's improving slowly due to very small core team. With more exposure, more people would come, and hopefully some of them would consider contributing, accelerating the pace of development.
• duskwuff 4y ago
  Signatures were added in 5.020, and [edited:] were considered experimental until 5.036.
  • darrenf 4y ago
    > and are still considered experimental No, 5.36 stabilised them. https://perldoc.perl.org/perldelta#Core-Enhancements https://perldoc.perl.org/perldelta#Core-Enhancements > The 5.36 bundle enables the signatures feature. Introduced in Perl version 5.20.0, and modified several times since, the subroutine signatures feature is now no longer considered experimental. It is now considered a stable language feature and no longer prints a warning.
    • jandrese 4y ago
      Oh, that's a bummer. I was kind of excited to use those, but since I never know when I'm going to get a call from the Centos 7 guys I have to stay away from features newer than 5.016. Basically just new enough to get semi-sane UTF support.
    • duskwuff 4y ago
      Ah! Looks like I need to upgrade, then -- I was reading from "perldoc feature" in my install, which was still on 5.34.
  • forgotmypw17 4y ago
    Thanks for the correction. I don't use them anymore (instead doing a few lines of sanity-check boilerplate in each sub) so that's why I made that mistake.
  • theonething 4y ago
    are Perl function signatures the PHP/Python equivalent of type hints?
    • duskwuff 4y ago
      This may shock you, but: historically, Perl functions did not have declared arguments. Like, at all. The function just got arguments implicitly passed to it as an array (@_), and parsing that into individual variables was up to the function -- so most functions would start like this: sub myFunction { my ($self, $arg1, $arg2) = @_; ... } Or, in older code, you might even see this: sub myFunction { my $self = shift; # implicitly get the first value from @_ my $arg1 = shift; my $arg2 = shift; ... } Notably, this didn't even check the number of arguments you passed. If you passed too many or too few arguments to a function which worked this way, the extra arguments would silently be ignored, or missing arguments would silently show up as undef. Function signatures turn this into something that'll look much more familiar to users of other languages: sub myFunction ($self, $arg1, $arg2) { ... } which includes checks to make sure that all the expected arguments (and no more) were passed.
• cogman10 4y ago
  While it's not my favorite language. I have to admit that function signatures go a long way towards making perl feel somewhat normal to work with. I have to imagine they are pretty big boons for IDEs.
• yakubin 4y ago
  I’ve had very limited contact with Perl, but for scripting purposes it does seem like the best option, so I intend to sit down to it and learn it better. It looks like a great next step after sed and awk (perl -pe). I love the ability to write terse scripts, reasonable speed for a scripting language and, as you said, backwards-compatibility (such a stark contrast compared to Python).
  • stjohnswarts 4y ago
    I would argue that ruby as almost all the strengths of perl and conciseness with more coherency if you want a perl-like fluidity and terseness. I personally like python for anything that becomes more than a 100 lines of bash.
    • kqr 4y ago
      Does Ruby come pre-installed on virtually every Unix-like system out there?
      • ARandomerDude 4y ago
        If it's not installed already, Ruby will be installed ASAP on any machine I use.
      • someRandoJunk 4y ago
        You're confusing perl with ruby there.
      • jrochkind1 4y ago
        No, and if it is, who knows what version it is. I think that's the main thing preventing one from using ruby like this. It is otherwise preferable in pretty much every way. Perl is kind of pre-installed on virtually every Unix-like system for what are at this point historical/legacy reasons. It is unlikely any other language can ever achieve this at this point.
        • throwaway111555 4y ago
• cryptonector 4y ago
  Needs static typing. I'll let myself out now.
  • forgotmypw17 4y ago
    I make up for this by writing short subprocedures and many sanity checks.
  • MobiusHorizons 4y ago
    When was the last time this caused a bug for you? My experience of moving from JavaScript to typescript is that it takes significantly longer to write many generic things because the types can’t really express the intended use as well. I will certainly admit that types help a lot at the boundaries between systems , or for catching errors introduced when changing code, but it’s not always a clear win for types, given how much more verbose, and less expressive the language becomes as a result.
    • kqr 4y ago
      We actually have science on specifically plain ECMAScript versus TypeScript, where the software written in the latter has 15 % fewer bugs. https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-quantifying-detectable-bugs-in-javascript/ https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-q... But of course, the study does not account for if increased development time cancel out revenue gained from lower bug count. (And this will be a difficult problem in general, due to first-to-market effects etc.)
    • wruza 4y ago
      This is my experience as well. I have a side project in its prototyping state and tried to use typescript in it. The result was exactly what I was afraid of - the first half of a weekend spent on fine-tuning tsconfig and tsserver integration, the second half on type acrobatics and investigating wrong narrowing issues. No code was written that day. I have a decent experience with both typed and untyped languages to see pros and cons of typing and am consciously choosing untyped for the “development” phase.
• theonething 4y ago
  >Bless you, Larry I see what you did there. Edit: for those downvoting me because they don't understand my comment, it refers to the fact that bless is function of the standard library to associate an object with a class. If you're downvoting me because you think it's a stupid and off topic comment, that is perfectly valid and acceptable to me.
  • forgotmypw17 4y ago
    Thanks for thinking me more clever than I may be. It was a simple blessing, and perhaps a reference to this interview with Larry. To me, the language creator's faith is one more reason to use it. https://slashdot.org/story/28204 https://slashdot.org/story/28204
    • theonething 4y ago
      My suspicion (not in a negative way as I'm Christian as well) is that the function was named so because of Larry's faith.
• singingfish 4y ago
  One of my criteria for good tools is that they scale well from the smallest possible use case to absolutely massive. Git meets this criterion for example. Anyway I manage a 250kline code base written over 20 years which is in surprisingly good shape consider it's age and how many people have touched it. Last time we upgraded the perl for the first time in a decade - going through the addition of many features and major internal changes (e.g. unicode, optimisation) the total number of lines of code we needed to change was at most 50. And very little having to fiddle with underlying cpan libraries. Back to the point. Throwaway script - perfect candidate. Code capable of running the money pump for a billion dollar company. Also just as fine as any other similarly capable environment, better than some, trickier to manage the team than others.
  • lupire 4y ago
    "Perl makes easy things easy and hard things possible."
    • fijiaarone 4y ago
      What we need from a programming language is to make medium complexity things, at worst, medium difficulty. I don’t care about hard problems, and easy problems.
      • nextos 4y ago
        Erlang/OTP does medium difficulty things, i.e. very large applications with good fault tolerance and QoS, really well. But it's a very different niche. Perl and Ruby scale to mid sized applications quite well, but above that fault tolerance and QoS become hard.
        • cutler 4y ago
          I think with languages like Perl, Ruby and Python you just need a static, compiled language to migrate to at a certain scale, preferably with similar features. Kotlin and Scala seem to be currently the best options for Ruby, Python and OO Perl. For procedural Perl maybe Golang.
• gyulai 4y ago
  > What I do appreciate that's missing from many other languages and systems is the extreme committment to backwards compatibility. Is that even something they're doing on purpose? Didn't they completely botch their attempt at a new major version? When Python moved from Python 2 to Python 3, introducing breaking changes, there was enough velocity and acceleration in the Python ecosystem for people to be willing to take the pain. With Perl it's inertia. So even if the language designers and package maintainers wanted to make breaking changes, they couldn't, because people would just stop updating. All that's left to do is to drag out the process of this ecosystem rotting away.
  • wazoox 4y ago
    > When Python moved from Python 2 to Python 3, introducing breaking changes, there was enough velocity and acceleration in the Python ecosystem for people to be willing to take the pain. Paint me unconvinced. Python2 is still a thing, 14 years later.
  • forgotmypw17 4y ago
    It doesn't really matter to me whether it is on purpose or not. All I know is that I can depend on my Perl scripts running a year from now, and I cannot do that with Python. It feels alive and well to me in that sense, while the stability and dependability of Python does seem to rot pretty quickly.
• cutler 4y ago
  I used to think you had to be a hashref to be blessed but The Damian put me straight on that.
• mbrodersen 4y ago
  Backwards compatibility for languages, libraries, environments, compilers etc. etc. is super super important. Without it no language/libraries/.. will be successful long term. Because people will simply switch to more modern offerings instead or not upgrade to newer versions. Making things “deprecated” is really bad. Just don’t. An API is forever. So ack accordingly.