Simplicity Made Easy
blogs.perl.org
blogs.perl.org
I think a more relevant title for this post would be: "any paradigm made straightforward in Perl 6".
The problem with this: if you give people a multi-paradigm language, they'd be using all of them. Often in the same codebase.
There is one school which says people ought to be giving a powerful programming language to better write powerful programs in the best way. The idea is to amplify what a single programmer can produce.
Another school says you should give programmers a non-powerful language because they aren’t to be trusted. The goal is to make changing enormous codebases easy (or maybe to maximise lines of code).
Perl fits into the first category and java is representative of the second. So I think this argument isn’t so much about Perl as it is a complaint about its philosophy. It could equally go on an article about the next c++ feature.
The problem is, this rarely happens and with a language like Perl and Java you end up with a mish mosh of hard to reason about code bases because the authors at the time were just trying to muddle through as best they could with whatever approach resonated with them.
I find more opinionated languages like Clojure help. On that note, is the title a riff on "Simple Made Easy"?
Fixed that for you. The whole point of the comment was that Clojure, by and large, forces you to work one way and Python doesn't.
The point of my comment is that it's not true (except in a narrow educational meaning). Your working environment (managers, colleagues, existing codebase) is what defines your limits in general, including language, approach, style, and frameworks. If your current shop can't accept your call to write more functional code in whatever language is used there, it obviously won't start developing in Clojure. It works exactly this way, not in the opposite direction. Ergo, the guy's problem was that his environment wasn't inclined to switch from OO. He couldn't say "Mates, let's use Clojure, because it will finally FORCE you to discover the beautiful world of FP", because they just want to keep doing what they were doing yesterday.
Fixed that for you.
It's not a correction, and I hope you see now what I mean.
Sadly also software is hardly ever one working environment. In Python, the libraries are a strong feature, and each library will have different contributors. Each with their own opinion on what is the most effective programming style.
Take Python's Django framework for an example, it contains both OO and functional ways of doing most things. This can be confusing for newcomers who just want to know what is the best methodology going forward. One of the key features of using a framework is it allows you to add new developers to your project and they will know how to get things done.
Does that all make Clojure less powerful than other languages? It turns out it, actually that makes it a lot more fun to work with. So yes, I agree with you, the article takes "Simple Made Easy" and turns it upside down. That talk is absolutely not about what was demonstrated in the article.
Never mind that functional and imperative programming have been attached to OO languages since at least SmallTalk…
I guess a killer framework is lacking too.
1) The Perl 5 community itself was dwindling before Perl 6.
2) Perl 6 took a good chunk of time to arrive.
3) It's still not 100% baked.
4) Perl 6 is mostly a different language.
5) Perl in general doesn't have a good "name" with todays devs
6) There's no killer app
7) Python got the data/science niche, Node got the web/services niche, Go got the backend niche - what's left for Perl 6?
8) The libs are also lacking.
9) Too complex to begin with (kitchen sink offering), at a time when devs started valuing simplicity more than before.
10) Maturity of implementation, tooling, support, etc.
11) No major commercial backing...
More people are writing Perl everyday than may be even Java, Let's put this Perl is dwindling argument to rest. Perl's niche, more like empire is glue language for anything Unix. That is a huge empire to govern on. Unless Unix is going away, Perl is here to stay.
>> 5) Perl in general doesn't have a good "name" with todays devs >> Node got the web/services niche
Most dynamic languages are in the same bucket. Today everybody is hesitant to start any serious big project in a dynamic programming language. Even in case of JavaScript most things will move to TypeScript eventually. And that too is more or less a totally new language.
>>Go got the backend niche
Go got nothing. Heck, merely shell scripting exceeds Go usage by several multiplicative factors.
>> 7) Python got the data/science niche
Most of the use case for Python's 'Data science' library is basically spread sheet automation. Perl has been used to that kind of work since early 90s.
>>what's left for Perl 6?
Firstly, and entire universe exists outside of web development. And most that universe is far more exciting than majority of api and json plumbing work in web dev work.
Secondly, Not sure, but no one can rebut an argument that says there is no scope for any new software to be ever written anymore.
Err, that's just a link to a submissions page. That's not a statistic, and it doesn't even show if Perl kept its people or lost them. Perl could even have more people than 1999, but much smaller mindshare given how hugely larger the dev market is in 2019 vs 1999.
Actual long term analysis look like "Perl is dwindling" is right:
https://insights.dice.com/2018/04/05/perl-uncertain-future-t...
>Perl's niche, more like empire is glue language for anything Unix. That is a huge empire to govern on.
And that "empire" is already lost for Perl. Dev ops have moved to Ansible, Puppet, Chef, etc, and Python and other languages are used as the glue. The "Perl gluing admin" is a relic.
>Most of the use case for Python's 'Data science' library is basically spread sheet automation. Perl has been used to that kind of work since early 90s.
Which is irrelevant as to who does it now (and it's not even right, Pandas, Numpy and co are not "spread sheet automation").
>Most dynamic languages are in the same bucket. Today everybody is hesitant to start any serious big project in a dynamic programming language.
Actually millions start serious big projects in JS, Python and other dynamic languages. There's a movement towards static typing but not that strong in actual practice. Typescript is tiny compared to the size of greenfield JS being written.
>Firstly, and entire universe exists outside of web development. And most that universe is far more exciting than majority of api and json plumbing work in web dev work.
Also far smaller, devs wise. And I didn't just mention web work, but also data science, microservices, and so on.
(And my point wasn't that Perl 6 can't do those, but that people aren't doing those with Perl 6 -- people as in, "people in quantities large enough to matter").
>>Dev ops have moved to Ansible, Puppet, Chef, etc, and Python and other languages are used as the glue.
This is glue? Sorry but we seem to come from very different worlds.
>>Also far smaller, devs wise.
Wow, Just wow!
You probably won't like to hear this, but this how most of the software world works:
1. C based backend language: Java. C Based embedded/speed requirement systems: C/C++
2. Glue: Shell/Perl
3. Web dev: Node, Java(Webservices)
4. Lisp Based languages backend: Clojure/Racket.
5. ML based languages backend: F#, OCaml, Haskell.
6. Database: SQL.
There are other special languages which rule their domain. But this is how bulk of the world works.
Data science area is still a extremely small part of even the web dev world, let alone the broader software ecosystem.
Imagine a start-up that didn't set out to solve a problem...
So it's a kind of research language - which is important and has its place.
I'd rather say that Perl 6 is an inspirational language. With other languages stealing ideas and features from it. But also a complete, production ready language on its own. Based on MoarVM, a virtual machine specifically designed to run Perl 6 on, but with more general applicability as well.
And with some exciting developments for the GSOC: one of which should allow creation of a single executable for a Perl 6 application on Linux / MacOS and Windows.
What ideas have come out of Perl 6?
Have you looked at Cro? Cro is a set of libraries for building reactive distributed systems taking advantage of all Perl 6 has to offer. The high level APIs make the easy things easy, and the asynchronous pipeline concept at Cro's heart makes the hard things possible. https://cro.services . With HTTP/1.1 / HTTPS, HTTP/2.0 and Web Sockets support out the box.
> 10) Maturity of implementation, tooling, support, etc.
Comma is an IDE for Perl 6, based on the JetBrains platform, with detailed syntax highlighting, grammar support, auto-completion, refactoring support, integrated test runner / graphical debugger, stack explorer and direct profiling. https://commaide.com
None of that seems "killer app", or anything more impressive than what e.g. Node or Golang offer out of the box...
13) perl6 is above most mainstream languages conceptually, people aren't ready to use it IMO
One person posted to #perl6 on freenode.net code written in both Perl6 and C/C++. They reported that the Perl6 code was faster. (I'm sure that the difference is mainly because the C/C++ code had to copy strings around, and iterate over them to locate the null terminators.)
Unless you are doing something where you might consider writing parts of it in assembly, Perl6 may be fast enough already. (I wouldn't write a first person shooter in it yet.)
There are some parts of it that are still in need of optimization. (If you find something that is egregiously slow, file a bug report.)
$ time perl6 -e ''
real 0m0.120s
$ time perl -MMoose -e ''
real 0m0.131s
So in that sense, if you are interested in Moose functionality, you're better of in Perl 6.
Perl 6 is an entirely different language though - IMHO a mistake to call it Perl at all, it's just so confusing outside of the community, but the damage is done with no obvious way to fix that, making people think it's kind of a Python 2 to Python 3 breaking change - so it's like saying Crystal does not run Rails.
One has to think of it as 'Perl6', not 'Perl v6.0'. Perl (the language whose current version is 5.22) is very much alive and will continue to be so for the foreseeable future, regardless of progress of 'Rakudo Perl 6'.
'rakudo' is an implementation of 'Rakudo', huh? It's only natural for one to tag the specification and an implemention of it with different nouns in one's mind, even when there's only one implementation. I tend to think of 'go' being the reference implementation of the language called 'Golang', although its Google backers don't differentiate their official names.
I get your point theoretically, yet this is not without significant previous occurences: from the top of my head 'Java', 'Ruby', 'Python', 'Go', 'Lua' the languages have 'java', 'ruby', 'python', 'go', 'lua' as the official implementations†. Alternative names for the implementations are merely informal. People even still call the official Ruby implementation 'MRI' when it's not that anymore ever since 1.9 (It's actually YARV or KRI). TBH 'Golang' is more of a search engine hack.
Regarding Perl 6 they could have done so too, but they locked in on theory and wanted to leverage Perl's heritage, which backfired hard. IMHO had they done some initial announcement like "Meet Rakudo, Perls' heir", they would have achieved the same goal with none of the drawbacks. Now the community web has built itself around the Perl 6 name so it's too late.
† I'm perfectly aware that there are significant other examples though, like Common Lisp, Haskell, C, C++ that make that distinction. But then again, many of those implementations turn out to have specifics implemented that turns the actual implementation into a slight to extensive variant of the language, which turns into its own bag of hurts. Naming things definitely is Hard.
s/5.22/5.30/
However, I'm not sure having to parse 3-4 very different syntax constructs to arrive at the same mental model is an advantage.
I do appreciate the terseness though.
Obviously, the Date (and other) type stuff is new to Perl 6, and is quite lovely.
How's that different from any other language? Isn't the expression argument evaluated before being passed to print, so at that point it's just a string anyway?
>>> print ", ".join(["a","b","c"])
a, b, c
>>> print "\n".join(["a","b","c"]),
a
b
cIt's true for all perl functions. Unusual part, if I got you right, is that parenthesis are optional in perl. So, this:
foo bar "\n", @baz;
foo(bar("\n", @baz));
TIMTOWTDI can get out of hand, at times, but it's really nice to have such beautiful concise ways to solve a problem in OO, functional, parallel, etc. styles all of which are very readable and quite concise.
Though that is more about time optimization than space optimization.