Rakudo Perl 6 Thread

perl is doodoo

We abandoned perl for a reason, newfag.

...

What's that lines business? Anyway I guess it's not much different.

Attached: p.png (964x124, 3.54K)

Perl makes Rust look nice.

It's just simply combing for stuff inbetween '\n' in an optimized way.
say "The file contains ", '50GB-file'.IO.lines.grep(*.contains: 'Perl').elems, " lines that mention Perl";

Rust is genuinely probably the worst modern language, get it right brainlet.

Everyone shits on perl. It's fine when I used it.

See is good but bash+used is awful.

But I do user.
Dem sexy grammars

IKR

Because Perl 6 spent too long bogged down in "development" (that'd be Larry Wall autistically injecting his religion into the specs), and in the end didn't offer a sufficiently compelling alternative to any number of languages, interpreters, and software ecosystems that were developed in the meantime.

Is there a use case for which Perl 6 is clearly and significantly superior to one of Python, Ruby, Lua, or js (node)?

It's better than python at preventing reverse engineering.

That first argument is stupid - no language can be released without sufficient development having taken place. MoarVM is being perfected.

Too. Damn. Slow.
Python 3 > Perl 6

Does Perl 6 come with a REPL yet?
It might be the main reason I didn't continue trying to learn Perl (given that I already knew another language in the same approximate niche). How can you stand it?

Are you joking?

Python's development is pretty fast.
You did interpret that post within the proper context, didn't you? It would be embarassing if you didn't at least read the two posts before it.

I dunno. I like Lua. It leaves an extremely small memory footprint, extremely readable and I'm experienced with it

Oh, the language we're still using 2.7 on since they've added absolutely no fucking reason to upgrade for a decade? It's Perl all over again.

Proper unicode support, type hinting syntax, formatting string literals, dataclasses, lazy operation of standard functions and methods where applicable, sensible division semantics, asynchronous functions, to name a few things.
Python 3 is genuinely a much better language than Python 2, and every minor release brings more.

Python has its performance issues too, and most python developers overlook mistakes in their implementations.

As for Perl6's speed, it is a WIP, though it has greatly improved and offers some great performance currently with exceptions for a few routines.

This is a reasonable argument, but only for Lua. Perl6 is aiming to become something different.

(I like Lua too)

Yeah, it does.

> say (1..^Inf).rotor(1..^Inf)[^5]((1) (2 3) (4 5 6) (7 8 9 10) (11 12 13 14 15))

samefag

Attached: ClipboardImage.png (278x94, 10.3K)

nice one

Attached: Selection_005.png (112x56, 1.8K)

It still doesn't have proper unicode support, we still need ICU bindings. The limited unicode support it has works just as well in python 2.7.
Have you tried using it? Try it before you say it's a feature. It's like C++'s template concepts. I don't expect anyone to ever seriously use it.
Backported to 2.7.
It's a pure python decorator and can be used on 2.7. Many projects, especially web frameworks, already had their own variant in 2.7.
3 remains slow as fuck.
Their division semantics are madness. How does quietly switching types to turn an infinite precision integer into a limited precision float make any sense? Division was consistent in python 2.7 and they fucked it up.
x=222222222222222222222222222222222222222
x/2*2
2.222222222222222e+38
Try to justify that shit as more natural and sensible than python 2.7. Silent information loss converting between infinite and finite, oh yeah, that's so much better than when it used to just fucking work. And why if they have transparently infinite precision integers do they not use their transparently infinite precision floats? It's such a confused mess. You have to be a sycophant or a moron to say this is sensible.
There are numerous libraries for 2.7 that asyncio was based on that go back a decade. It's not a new feature.

There is no reason to migrate to python 3 and lose compatibility with the breadth of 2.7 code for those non-features. Python 3 was a mistake and should be ignored.

Consistently using unicode strings for text without mixing it up with raw bytes is an improvement over Python 2.
I do use it. It works great with mypy.
No. I'm talking about formatting literals, like f"{x}", not "{}".format(x).
Python 3.7 has it in the standard library, so it's reliably available from there on, and versions before 3.6 can't support a version as nice as that one. It lets you do something as simple as this:
@dataclassclass C: x: int y: str z: bool = Falseo = C(3, 'foo')print(o)C(x=3, y='foo', z=False)
It has simple syntax for simple uses and it's standard. That matters.
It's not just about naive speed. Being able to do "x in d.values()" without instantiating an entire list matters a lot in case d is a large dict. In Python 2 you'd have to choose between doing it the simple clear way or the correct way, in Python 3 they're the same way.
It's sensible in a language with dynamic typing.
When you actually use division you usually have a clear idea of whether you want truncating division or true division, and the types involved are only known at runtime. So in Python 2 you either end up with subtle bugs that happen when you get an int where you were expecting a float or vice versa, or you have to put float or int conversions all over the place just to make sure it doesn't accidentally use the wrong kind of division sometimes. Python 3 is much better in most cases.
Your example loses information in Python 2 if it's an odd integer.
Standardization and syntax matter.

Unless Perl 6 start working with Tensorflow and R, NOPE

#include "share/atspre_staload.hats"datatype C = | Crawler of (int, string) | Floater of (int, string, bool)val o = Crawler(3, "foo")fun print_C(coord: C): void = case+ coord of | Crawler(x, y) => print!("C(", x, ", ", y, ")") | Floater(x, y, true) => (print_C(Crawler(x, y)); print!(" ** floating **")) | Floater(x, y, false) => (print_C(Crawler(x, y)); print!(" ** grounded **"))(* permits println!() macro to work with this type *)overload print with print_C(* alt. version *)typedef C = @{ x=int, y=string, z=bool }val q = @{x=3, y="foo", z=false}implement main0() = ( println!(o); println!(q2) where { val @{x=x, y=y, z=z} = q val q2 = Floater(x, y, z) }; println!(Floater(3, "hi", true));)output:C(3, foo)C(3, foo) ** grounded **C(3, hi) ** floating **I was going to go on to mock Python for its speed, but Python 3.6.5 throws an error on your example at @dataclass. Latest Python in Homebrew... probably because shit breaks under 3.7, same as with any other version difference with Python.
ML is a supernova, but you are so far from its light and God's light that the brightness of a candle impresses you.

kek

List of things that Perl 6 does not have.
1. Web scraping (Selenium among others)
2. Machine Learning (Keras and Gluon)
3. Statistics (SciPy ecosystem)
4. Education (Jupyter Notebook)
5. Web building (Django and Flask)
6. Cryptography (too many to count)
7. Image, Audio and Video (FFMPEG)
...
Come back when Perl 6 start having programs or wrappers for these

You did absolutely NO research. Just having looked at the modules page, I've found literally 6/7 of those FULLY built in Perl6, not even just wrappers.

It's a library, called dataclasses. It won't work unless you install (on 3.6) and import the library. You need to add "from dataclasses import dataclass". I should have mentioned that.
Your example is neat, but it's much more tedious than the Python version, or alternatively, less fully featured. ML is not a Python replacement, and Python is not a ML replacement.
I don't think Python dataclasses are particularly impressive or sophisticated, but they are an advantage Python 3.7 has over earlier versions, which was the topic of the conversation. It was more about showing Python 2's deficiencies than about elevating Python 3 above non-Python languages.

Python seems kinda over at this point. It's been completely replaced as an embedding language to the point no one even mentions it as an option for this anymore, it was abandoned by RedHat as the future of shell utilities more than a decade ago, it's been abandoned as a replacement for the script glue in an init system as that all went back to C instead, and even webdev faggots seem desperate to get away from it. There's not even any passion around it, I never hear people wistfully speculating what marvels a python 4 might bring. All its growth seems to be coming from it being the language of choice in diploma mills instead of industry. I don't get why anyone's defending it in this thread.

Attached: main-qimg-aaad44fc3abe2f76484514e6def07f03.jpg (742x768, 70.16K)

Context. This is a
thread, and however badly Python might suck, it is orders of magnitude more popular and more useful than Perl 6 is or will ever be.

Tell me the solution

I would guess that "Academic" refers to scientific uses, not diploma mills.
I've seen a little of this, but it's misguided, because Python 4 won't be necessary to bring marvels. It will be an opportunity to make backward-incompatible changes, but no major ones seem to be necessary, and it won't be as drastic as Python 3. Most of the goodness is coming from minor releases.
The only Python 4 change scheduled so far is lazy evaluation of annotations. Even most code that is affected by it won't be broken by it, and you can already opt into it in 3.7.
Python is ranked fourth on a lot of rankings, and that seems consistent with the percentages in your image. 10% is actually a lot. The hype might have died down, but it established itself.
Someone said Python's development moves faster than Perl's development and a bunch of people misunderstood.

Attached: indeed.png (1000x1000, 58.35K)

Don't forget binning the GIL, speeding Cython and others
infoworld.com/article/3221482/python/4-major-fixes-on-the-python-roadmap.html

The GIL is an implementation detail of CPython. There are compatible implementations of Python 3 that don't have it. Binning it wouldn't be backward-incompatible, so it doesn't require a major release.
Optimizing namedtuple doesn't require a compatibility break either.
Everything in that article is about implementation details. None of it is about changing the language, let alone changing the language in a backward-incompatible way.

Then what is wrong with the syntax, if the guts of it is not the problem?

The syntax of Python 3, you mean? Nothing worth breaking backward compatibility for. There are problems, of course.
You might be missing the point of major releases. Major releases, like Python 3, can make major backward-incompatible changes. Minor releases, like Python 3.7, can add anything that doesn't break backward incompatibility.
Python 4 is allowed to include breaking changes. The only breaking change scheduled so far is a semantic change to annotations.
The things in the article aren't even about the guts of the language itself, they're about the guts of CPython, the most popular implementation of Python. There is no need to release a new major version when they're implemented.

wat

They're going to have to break compat in a major way to solve the startup time problem and if they want to do signed/verifiable libraries. That's all due to how excessively dynamic the language is, and that there is no real "import library", it's just "run code claiming to be a library that will probably modify the environment to present itself as a library would".

I don't feel qualified to say much about startup time, but you probably do have a point there. It could be brought down without breaking compatibility, but it's enough of a structural problem that breaking compatibility could be necessary to get it to the point where it's no longer an issue.
I feel like it should be the job of a package manager, but verifying library signatures at import time could be implemented right now in pure Python. Remove all directories you don't unconditionally trust from sys.path (I assume the standard library is fine to keep), then append your own import system to sys.meta_path. Or replace the default import system with your own.
I actually wrote an import system a few weeks ago for a nasty bit of metaprogramming. It's a lot more accessible than I expected. I implemented one from the ground up because I wasn't importing Python code, but you could subclass the components of the standard import system as exposed in importlib.machinery to do verification before execution.

tbh perl5 still gets me hard

Attached: perl.png (288x288, 32.91K)

Why can't Python be more like Perl?

Same, a lot of people haven't really explored Perl, but it's worth it.

Perl 5 is literally the best language

Attached: perl-scripts-done.jpg (600x425, 27.21K)

The reason why Python took over was that it wasn't like Perl.

Python caters to retards
Perl doesn't

The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.

I doubt it brainlet

Time to read up on your Dijkstra.
cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD340.html

wait a minute did dijkstra say something contrarian??!! no way

This particular thing isn't that controversial. Debugging code is harder than writing it, so if you write code that's as clever as you are you won't be clever enough to debug it. A major trick to writing maintainable software is to make it boring.
Not all software needs to be maintainable. Perl is a good choice for software that doesn't. But it's notoriously bad for software you might want to modify again some day.

It's hard if you're a mental midget, yeah. That's why python exists, so the industry can hire mental midgets for dirt cheap.

Scripting languages give you four advantages:
1. (guaranteed) when any kind of problem crops up with a scripting-language program, you will find the full and complete and immediately alterable and executable (in altered state) source of that program right next to it. This is the height of maintainability--any admin that comes along can dig into things, figure out what the problem is, and then fix it, even fix is a quick temporary patch to only the local copy of the script.
2. (very often, and usually with too great an emphasis) portability of scripting-language programs across architectures
3. (often) a larger pool of potential maintainers because the language can be easy to learn, f.e. because it has only 3-4 super capable types that everything works with, like old adage about why lists are good in Lisp, and unlike languages where you'll get an error saying "woah! you tried to pass an int! But I was looking for a port, which is a very special kind of int!"
4. (ideally) relatively faster coding for some application domains, because the language itself has been optimized for expressing solutions to problems in those domains.
That #1 point there is super fucking important. If you ever have a problem that really doesn't need to be maintainable at all, then write it in Nim or OCaml or whatever you like, produce a standalone binary, deploy that, and then throw away the source.

almost assuredly in education

harsh truth

Attached: 1520468542.jpg (270x270, 26.79K)

Python > Perl if it tried.

Try bringing bugzilla up to modern standards. Learn what it's like to work with a large perl project with multiple contributors, and why perl was abandoned.

Everything modern is bloated botnet shitware tho, so no thanks.

Why would I use Perl? I am not a webdev black slave I am a white man

ever look at bittorrent's source?

Perl isn't just for webdev, it's great for just general scripting.

Find a large perl project with multiple contributors that is not nightmare-tier. Learn why perl was abandoned.

Because Racket, and even Python are better.