Announcement

Collapse
No announcement yet.

Perl 7 Announced As Evolving Perl 5 With Modern Defaults

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by schmidtbag View Post
    Well, I don't love peanuts, and monkeys tend to sling crap for no good reason.
    self-descriptive really. Perl isn't harder to get into than any other lang, thanks in part to a *sane* ecosystem and resources like perlmonks and folks that really know what they're are doing - not for the monkeys tho.

    Comment


    • #22
      Originally posted by Raka555 View Post
      Easy to read languages are less expressive (less powerful) by definition.
      Whose definition? I find C and Java easier to read than Perl and they sure as hell are more powerful. Although this is hardly comprehensive, Perl is the 2nd slowest language in this test:
      https://blog.famzah.net/2016/02/09/c...enchmark-2016/
      Perl has fewer libraries than most modern languages too. It may have the potential to be more powerful, but considering it's age, I don't think it will catch up.
      I guess few people will have enough incentive to do that today.
      Do you blame them? Most languages you can learn without a book. I learned how to write programs in python, PHP, and Javascript without spending more than 5 minutes on tutorials, and I was paid using all 3.


      Originally posted by mos87 View Post
      self-descriptive really. Perl isn't harder to get into than any other lang, thanks in part to a *sane* ecosystem and resources like perlmonks and folks that really know what they're are doing - not for the monkeys tho.
      Right, I guess that's why it's so popular, eh?
      Maybe put more than 5 seconds into thinking about your responses.
      Last edited by schmidtbag; 24 June 2020, 04:39 PM.

      Comment


      • #23
        Originally posted by timofonic View Post
        Call me a weirdo if you all want, but I find Raku to be a lot more interesting than Perl. https://en.wikipedia.org/wiki/Raku_(...mming_language) What do you all think?
        I love Raku, I've been playing with it. It's got everything - object-oriented top to bottom, multiple inheritance, functional programming, generics, operator overloading, adjustments to the regex syntax to make it easier to read, named function parameters, default function parameters, optional static types (that are enforced - if you declare "my Int $x = 'c';" you will get a type error), nice syntax for async, and a new grammar system that makes it easy to write complex parsers.

        It was agonizingly slow in the initial release in December 2015 but has speed up two orders of magnitude since and is within the same ballpark as Python, Ruby, or Perl 5. There is still work on optimizations.

        Originally posted by willmore
        Perl 6 was an ambitious effort to transorm Perl, but it went out of control and ran into the Wall.
        I see what you did there.

        For anyone that doesn't know, Larry Wall created Perl and lead the design of all versions of Perl up through Perl 6, and the Perl 6 design was too ambitious and it took 15 years for it to be released.

        Originally posted by schmidtbag
        That's a double-edged sword. The shortcuts may be great for those who know the language, but that's also it's greatest weakness to anyone who doesn't know the language.
        IMO, programming languages are best when they're easy to read.
        Originally posted by Raka555
        Easy to read languages are less expressive (less powerful) by definition.
        It's not a single continuum between "easy to read" and "less expressive" on one side and "hard to read" and "expressive" on the other.

        Look at a Java class that stores an immutable Integer and a mutable String which are initialized in the constructor.
        In Java:
        public class Foo
        public final Integer x;
        public String y;
        public Foo(Integer x1, String y1) { this.x = x1; this.y = y1; }
        }

        In Kotlin:
        public class Foo(val x: Integer, var y: String) {}

        The Kotlin is just as easy to read if you know what "val" and "var" mean, and save four lines of boilerplate.

        Or let's say you want to define a function with parameters x and y, with y default value 3 if not supplied. Java:
        public void doSomething(int x, int y) {
        // actually do something
        }
        public void doSomething(int x) {
        doSomething(x, 3);
        }

        Now look at the Python equivalent:
        def doSomething(x, y=3):
        # actually do something

        If you know how Python parameter default values work, the Python version saves two lines of boilerplate. If you're combining a lot of optional parameters, the Python version can save many dozens of lines of code.

        So I would say it operates in two dimensions - more expressive vs less expressive, but also well-designed and poorly designed.

        Comment


        • #24
          Originally posted by schmidtbag View Post
          Whose definition? I find C and Java easier to read than Perl and they sure as hell are more powerful. Although this is hardly comprehensive, Perl is the 2nd slowest language in this test:
          https://blog.famzah.net/2016/02/09/c...enchmark-2016/
          Perl has fewer libraries than most modern languages too. It may have the potential to be more powerful, but considering it's age, I don't think it will catch up.
          I suspect you were defining "powerful" as fast and memory efficient and the other person was defining it as "expressive" - able to solve a problem with as few or fewer lines of code compared to most other options.

          And for just about any problem, if you can take the performance hit of a Perl rewrite the Perl solution is likely to have fewer lines of code than the Java or C version.

          And that's without resorting to Perl special variables and fancy tricks, just the language basics. Perl functions for IO, hashes, arrays, filtering (grep), and so forth are all in scope by default, and Perl has convenience operators for accessing slices of arrays and hashes. So no import statements, no fancy tricks to get parts of the data. For example:
          my %h = ('foo', 1, 'bar', 2, 'baz', 3); # define an associative array (hash) of foo=>1, bar=>2, baz=3
          my @vals = @h{'foo', 'baz'}; # extract the values for both the first and third keys
          print @vals[0]; # 1
          print @vals[1]; # 3

          And the Perl5 startup is very short - the command line version of the code above runs in 0.003 seconds on my machine. So for scripting, command line utilities, anything where performance isn't critical it's a great choice.

          I'm not saying you should use it or must use it. I have nothing against Python, PHP, or Ruby. I mean it. I just think Perl gets an undeserved reputation for being hard to read and use.

          Comment


          • #25
            Get Chromatics book and learn howto code perl object oriented

            Comment


            • #26
              Originally posted by Candy View Post
              Get Chromatics book and learn howto code perl object oriented
              bless {}

              Sorry, I could not resist
              Last edited by Raka555; 24 June 2020, 05:53 PM.

              Comment


              • #27
                Originally posted by Michael_S View Post
                I suspect you were defining "powerful" as fast and memory efficient and the other person was defining it as "expressive" - able to solve a problem with as few or fewer lines of code compared to most other options.
                No, I'm defining powerful in terms of compute performance and overall capability.

                Although in a human legibility standpoint shorter is better, there is such thing as shortening too much. In most languages, you can verbally read the code, where things like commas, colons, semicolons, parenthesis, brackets, and periods are all assumed to be silent (because that's how they normally are). To someone who doesn't know Perl, the % and @ symbols don't have an obvious function and without your comments, someone coming into Perl for the first time couldn't read that and immediately understand what's going on. Write the same code in any other language and you could probably figure it out in the first pass of reading it. Write it in a language like Python and it'd be the same number of lines (though each line would be longer).

                What you wrote isn't complicated. Imagine writing a program that actually serves a significant purpose. That's when things get harder to read. If you need comments so others understand the code whereas another language might not, it defeats the purpose of the shortcuts.
                Last edited by schmidtbag; 24 June 2020, 06:01 PM.

                Comment


                • #28
                  I had a good laugh after reading the justification of the version number.

                  Originally posted by MadeUpName View Post
                  I will be writing Perl till the day I die. I can get so much done so fast and I love the syntax. I absolutely despise any language that depends on indenting like basic and Python.
                  It is extremely difficult and expensive for the average "developer" to write maintainable Perl. I do appreciate people that are passionate enough to become very specialized/skilled/productive in Perl. I've had some good conversations with the 2 or 3 people that I have spoken to that can actually write good Perl quickly. It is my opinion that it is more productive (in a generic/universal sense) to write code that is typed AKA easy to predict for the average developer, especially the past 10 years. Modern developers today have little time and many new languages that improves their productivity at their skill level.

                  I enjoyed Perl while I was studying. Did obfuscation challenges, wrote a few bots and websites, didn't use it for ~7 years. Worked for a company that used the Pareto Principle with Perl (absolutely no CD/CI). It was a massive **** show of messy spaghetti. It is comparable to X11 but orders of magnitude worse. Sadly I have not touched Perl since.

                  Comment


                  • #29
                    I'm still an avid Perl user but trying to move on to Ruby. I still love using Perl but no one where I work seems to take a script seriously unless it's written in !Perl. I don't think it deserves a lot of the flack it gets but it surely deserves some of it... Raku addresses some of this but in reality the servers at work have Ruby or Python 2. Even if they had Python 3 frankly I'd lean towards Ruby but that's only because I fall into the "mandatory whitespace is malarky" camp

                    One thing I will always love and use Perl for is parsing logs with sick nasty one-liners... My bash history is always littered with `perl -ne` and `perl -pe`

                    Code:
                    daniel@goldmember:~/Downloads$ history | perl -ne 'print if /perl\ -(p|n)e/;'
                    660 openssl s_client -connect swagg.net:443 2> /dev/null | openssl x509 -noout -text | grep 'DNS:' | perl -pe 's/,\ /\n/g; s/^\ +//;'
                    661 history | perl -ne 'print if /perl\ -(p|n)e/;'
                    daniel@goldmember:~/Downloads$ openssl s_client -connect swagg.net:443 2> /dev/null | openssl x509 -noout -text | grep 'DNS:' | perl -pe 's/,\ /\n/g; s/^\ +//;'
                    DNS:ipv6.swagg.cc
                    DNS:ipv6.swagg.net
                    DNS:mirror.swagg.cc
                    DNS:mirror.swagg.net
                    DNS:swagg.cc
                    DNS:swagg.net
                    DNS:www.swagg.cc
                    DNS:www.swagg.net

                    Comment


                    • #30
                      Originally posted by qlum View Post
                      I think bash is excellent for it's job. if you need to run a lot of different utilities and the primary thing you are doing is calling external processes bash is the best tool for the job. Granted you can do the same with a more limited shell. It's mostly a matter of picking the right tool for hte job. Python is more cumbersome in that regard.
                      That depends on what you expect out of it.

                      Here are my reasons for using Python over shell scripting:
                      1. More portable (Seriously. It's much easier to get something that'll Just Work on any Unixy OS with Python, let alone Windows too, than with shell scripting... even if you're specifically targeting bash, simply because, in the real world, versions and default configurations of bash vary enough to make things a hassle.)
                      2. Not doubling as an interactive shell and not needing to be backwards compatible with the original Bourne shells allow for saner quoting, escaping, and arrays.
                      3. I got used to preferring Python for scripts longer than half a dozen lines before bash copied zsh's ** as an analogue to Python's os.walk()
                      4. I prefer the subprocess and shlex modules to bash's equivalent for building command-lines with minimal worry about introducing bugs/exploits.
                      5. Give me try/finally over trap any day.
                      6. The Python standard library contains a ton of stuff that is a pain to rely on with bash. (eg. Does your distro include wget by default and omit curl or vice-versa? Is the zip command installed by default or not? etc.)
                      7. These days, it's often much easier to ask a subprocess to speak JSON than to parse its human-formatted output, and Python's standard library has that covered, while things like jq aren't guaranteed to be installed.
                      8. BashFAQ strongly advises against using errexit, while, in Python, it's as simple as using check_call or check_output from the subprocess module and not catching the exceptions. (And, if that's too verbose, just import them as a shorter name.)
                      9. Bash's hacky relationship with standard I/O streams can cause unexpected problems.
                      Heck, ESR's 2008 answer to the UNIX Haters Handbook's complaints about UNIX's composability was basically "Fair points, but we were already starting to migrate to coding our admin scripts in Perl when the book came out, rather than shell script, and that negates the issues raised".
                      Last edited by ssokolow; 24 June 2020, 08:52 PM.

                      Comment

                      Working...
                      X