Originally posted by schmidtbag
View Post
Announcement
Collapse
No announcement yet.
Perl 7 Announced As Evolving Perl 5 With Modern Defaults
Collapse
X
-
Originally posted by Raka555 View PostEasy to read languages are less expressive (less powerful) by definition.
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.
Originally posted by mos87 View Postself-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.
Maybe put more than 5 seconds into thinking about your responses.Last edited by schmidtbag; 24 June 2020, 04:39 PM.
Comment
-
Originally posted by timofonic View PostCall 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?
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 willmorePerl 6 was an ambitious effort to transorm Perl, but it went out of control and ran into the Wall.
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 schmidtbagThat'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 Raka555Easy to read languages are less expressive (less powerful) by definition.
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.
- Likes 2
Comment
-
Originally posted by schmidtbag View PostWhose 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.
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.
- Likes 4
Comment
-
Originally posted by Michael_S View PostI 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.
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
-
I had a good laugh after reading the justification of the version number.
Originally posted by MadeUpName View PostI 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.
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
-
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
- Likes 1
Comment
-
Originally posted by qlum View PostI 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.
Here are my reasons for using Python over shell scripting:- 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.)
- 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.
- 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()
- I prefer the subprocess and shlex modules to bash's equivalent for building command-lines with minimal worry about introducing bugs/exploits.
- Give me try/finally over trap any day.
- 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.)
- 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.
- 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.)
- Bash's hacky relationship with standard I/O streams can cause unexpected problems.
Last edited by ssokolow; 24 June 2020, 08:52 PM.
Comment
Comment