Live data from Hacker News

Perl 6 Optimism

p6weekly.wordpress.com

161–170 of 243 posts

Re: Perl 6 Optimism

#161
post #51

Is anybody here using perl 6 in production at the moment? Or perl 5 for that matter?

If you would have actually read the blog post, you would have seen a "Rakudo Perl 6 in production" section in it.

Thank you, I did read the post. I asked if anyone here (participating in this discussion) was using it.

Re: Perl 6 Optimism

#162
post #18

Earlier quoted context omitted.

The failure to admit it was going slowly was another killer. It will be released at Christmas, we just aren't telling you which one. After a few years of hoping, I gave up and am in the world of Python and Django. Its a shame as Perl feels like a more powerful / expressive language than Python.

I'm one that moved to Python and don't want to look back. It is not that Python is easier read (I would say it is less noisy) but it is almost impossible to write your own "DSL" like you can do with Perl or Ruby. YMMV but for me this is what makes it easy to maintain: you just need to learn Python not the personal programming style of the previous developer.

Generally, yes, but at least in organizations you can enforce some style. The problem definitely arises (and often) when you can't write and enforce that standard. Python and Perl definitely have diametrically opposed philosophies on that front.

Re: Perl 6 Optimism

#163
post #153
post #76

Earlier quoted context omitted.

XS is the "same" hack all the time, though. A Perl library that can only be called in list context in Perl 6 is a substantial change from Perl 5. I've seen much smaller changes trash code bases before. I've got real code that would be affected by that. (I also think the context idea was a misfire in Perl That said, why is it impossible to call a Perl 5 function in scalar context? Shouldn't the equivalent of Perl 5's…

> why is it impossible to call a Perl 5 function in scalar context? Has Stefan (who wrote IP5) said or written that it's impossible? 18 months ago he wrote "So far I've found 3 different ways to implement scalar/list context for method/function calls".[1] He has left issue #31 open.[2] Where did you read that it's impossible? [1] https://irclog.perlgeek.de/perl6/2016-08-03#i_12961486 [2] https://github.com/niner/Inli…

"Where did you read that it's impossible?"

Grandparent of my post, no further research.

Bear in mind that as I posted doubt, that I am indeed doubting it, so don't expect me to be too surprised if you confirm that it is worth doubting. :)

Re: Perl 6 Optimism

#164
post #2

I don’t understand why Perl 5 and 6 are still tied together as if they are the same language. There’s no compatibility between the two. You can’t write a library that works in both versions, so you lose CPAN and the thousands of packages that make Perl so powerful. I don’t think there’s even any reliable way to translate Perl 5 source code. This is a vastly larger change than python 2->3, and people are still using p…

Also, how would similar functions even be enough? The average Perl script I had was full of special operators, etc. (they all changed and are impossible to Google anyway). And code bases have more than enough churn without being fundamentally rewritten multiple times to do the same thing.

Re: Perl 6 Optimism

#165

Earlier quoted context omitted.

APL has used a huge set of non ASCII characters for more than 30 years in production by large companies.

Modern APL derivatives (namely J and K) have ditched them though in favor of pure ascii.

The character set and font constraints of the early 1990s, when J (1990) and K (1993) were developed, no longer apply. APL symbols are part of Unicode. There is no technical advantage left to ASCII-only syntax for APL-derived languages.

Re: Perl 6 Optimism

#166
post #75
post #57

Earlier quoted context omitted.

The visual marker of scope is there and it's massive: indentation. You can write bad code in every syntax, but when a language carries jokes about being "write-only" and the other has a reputation for being anal about indentation (the single most helpful scope-marker in any syntax), I don't think you can argue about objectivity when discussing readability. This said, I'd like to see scientific comparisons, which are…

Python was designed for doing quick throw away prototypes. Perl 5 was designed to support devops before that was a word. If you are writing a large code base in either, there is a good chance you are doing something horribly wrong. (I still prefer perl though)

[deleted]

Re: Perl 6 Optimism

#167
post #19
post #9

Earlier quoted context omitted.

Perl 6 has ASCII versions of every unicode operator: https://docs.perl6.org/language/unicode_ascii

Is there a key for it on my keyboard though?

Here is a nickel kid, get yourself a real text editor: https://www.gnu.org/software/emacs/manual/html_node/emacs/In...

Do you realize people that speak more than two languages already use multiple keyboard layouts all of the time?

Re: Perl 6 Optimism

#168
post #22

Earlier quoted context omitted.

I heard many times that perl is «write only». Unicode operators takes it to the next level.

Seriously, if Unicode operators are confusing to you(r group), don't use the feature. But if you're a mathematician, it's nice to have a language that understands set operators.

Python does: foo in bar

Re: Perl 6 Optimism

#169
post #90
post #80

Earlier quoted context omitted.

There are real companies doing real work in newer languages like Swift and Go too. Perl 6 is a toy in comparison. Zoffix Znet I use it at $work for throw-away one-liners Awesome

There are real companies doing real work in newer languages like Swift and Go too Apples and oranges, given that Swift and Go were started with the deep pockets of Apple and Google behind them. Look at Ruby for a more fair comparison: It took 10 years to take off, stayed "hot" for ~3 years and has been in slow decline ever since.

>Apples and oranges, given that Swift and Go were started with the deep pockets of Apple and Google behind them.

Go did not have "Google's deep pockets" behind it. It was something like 4-5 Google employees working on it in their spare time as a side project until it was released to the public, at which point it pretty much became an open source project like any other. The vast, vast majority of Go contributors are not Google employees.

It faced initial hostility everywhere, including at Google itself, and it's been incredibly hard work to get it promoted, marketed, etc.

Hell, I bet the core Go team has spent just as much time writing documentation, tutorials, shooting videos, creating news groups and irc channels and evangelizing as developing the damn thing.

Perl6 needs that - incessant, in-your-face promotion and marketing, conferences, videos, tutorials, the whole shebang. It's not the 90's anymore and I have choice when choosing a language to be productive in, so Perl6 better beef up its efforts to tell me why I should spend even 5 minutes of my time in learning it.

With Go, I was blown away with how easy it was to setup a scalable HTTP server, accept requests, parse JSON, reach out to multiple systems concurrently, the breadth and quality of its std. lib, etc - I had an immediate use-case for such stuff at work. I started investing time in learning Go before it hit 1.0, and it's paid off.

What's Perl6's killer use-case? Performance? compile-time safety? concurrency? scalability? Amazing std. lib? I don't know. It's not immediately clear. So if I'm comfortable scripting with bash/sed/awk or python for those harder use cases - why transition to Perl6? What does it offer in 2018?

Re: Perl 6 Optimism

#170
post #113

Earlier quoted context omitted.

One of the bigger features of P6 is that it can use modules written in other languages such as python.[1] Are you aware of the compatibility with Perl 5 that I mentioned in my prior comment in this thread? If so, why do you discount it? [1] https://www.perl.com/article/plotting-with-perl-6/

P5 also has inline python, but it's nowhere near as easy as using a native library.

Stefan Seifert authored or maintains both the P5 and P6 versions of Inline::Python, the Inline::Perl5 for P6 and the Inline::Perl6 for P5.

Three of the four are at the first stage. They work in much the same way, using `.run( ... )` to run a line of code at a time.

One of the four is at the second stage. It works as easily as using a native library. No need for `.run` etc.

Post reply on HN