Live data from Hacker News

Is Perl 6 Being Renamed?

blogs.perl.org

321–330 of 424 posts

Re: Is Perl 6 Being Renamed?

#321
post #132
post #118

Earlier quoted context omitted.

I don't think you should place too much emphasis/concern/whatever on most of the special variables available in Perl 5. I would wager that most Perl programmers never use about 95% of them (that is, the short 2-3 character ones listed on that man page). At the very least, I would guess, most Perl programmers almost never use 95% of them -- and many would choose (as the perlvar man page says) to 'use English;' -- and…

In practice (from a rough survey of CPAN code and Perl code in the wild I've looked at), people rarely use the English versions, and tend to memorize the few punctuation variables that are commonly used: $_, @_, $/, $], $$, $@, $!, $? (and note that some of these are out of familiarity with other languages) and ignore the rest unless needed for a specific problem.

This is probably accurate. I personally use this subset all of the time (for reasons that will be obvious to Perl programmers): $_, @_, $@, $!, $?

I have occasion to use $$, but not too often. I tend not to use much else, and like others have said in this thread, I just look up things that I need when I need them. If it is not obvious what something does (especially if it is one of these special variables), I will add a comment to explain (as I would in any programming language I use).

I understand why people don't like this particular characteristic of Perl, and it is a legitimate thing to have differing tastes. But I don't personally find it to be anywhere near as "end of the world" awful as many people who can't stand Perl make it out to be.

Re: Is Perl 6 Being Renamed?

#322

Earlier quoted context omitted.

As an active perl5 programmer, what do you mean by (1)? To this day, I've seen package management systems for many languages, and none I've seen has been as good as CPAN in terms of (1) Consistent place for distribution + documentation (cpan.org/metacpan.org) (2) Automated testing on a wide variety of platform and configuration (cpantesters.org) (3) CPAN has as standard for declaring dependencies in packages, but a n…

I don’t know where you’ve been looking, but none of that is particularly interesting or new at this point. I worked with Perl daily and find CPAN even more of a wasteland than NPM. The average package there hasn’t been updated in a decade and has ancient dependencies to match; takes months / years for clients to be written for new tech.

What's wrong with a package not being updated for 10 years?

Languages like perl--like common lisp, and c--are Stable. They change, some, but you can count on old code working. If a 10-year-old package Works, what reason is there to update it? I wrote a c library which has seen no updates in about 2 years--because it doesn't need them. It already does everything I need it to do.

Re: Is Perl 6 Being Renamed?

#324
post #26

Earlier quoted context omitted.

> performance prevents it being taken seriously in production. Performance is a big one. Not focusing on performance is like a strategic mistake for a programming language these days.

On one hand, you're totally right. I've been writing perl for twenty years, and while I love its practical expressiveness (higher than any other language currently in use, as an objective measure), I've frequently wished it had better performance and lower memory footprint. The go-to solution for that has been to profile one's code and rewrite the critical path in C, with which perl interfaces readily. It's the same…

Too early? In 4 months it will be 4 years since Perl 6 was released and it's still 5 times slower than Ruby at simple tasks like parsing a log file with a regex.

Re: Is Perl 6 Being Renamed?

#325

Earlier quoted context omitted.

# copy stdin to stdout, except for lines starting with # while left_angle_right_angle: if dollar_underscore[0] =eq= "#": continue_next; } print dollar_underscore; } Hilarious...

The opening block with `:` and ending block with `}` literally killed me.

My condolences to your family and friends.

Re: Is Perl 6 Being Renamed?

#326

Earlier quoted context omitted.

FWIW, C++ is a different language from C, and C code is more C++ compatible than Perl 5 is for Perl 6.

> FWIW, C++ is a different language from C It's been 20 years so my information could be very much out of date, but at that time anyway I would not have said this statement was true. C++ then was a superset of C, and any C++ compiler was capable of compiling ANSI C.

Your information is very much out of date. C++ makes a few important changes that make most c code incompatible. #1, implicit cast between void and non-void pointers is not allowed, so something like:

    int *x = malloc(sizeof(int) * 15)
is legal c, but in c++ you would have to cast the malloc call. Also, type of character literals is int in c but char in c++. String literals are const only in c++. Functions that take no arguments must be declared as taking void (as in void func(void)) in c, but simply () in c++.

Re: Is Perl 6 Being Renamed?

#327

Earlier quoted context omitted.

My experience is that Perl scripts other people wrote are impossible to understand. It made me never want to touch it again. I was handed several unmaintained ten year old Perl scripts to update and in every case I just rewrote it in python just because Perl gave me a migraine looking at it.

That's a problem with the people who wrote the script, though, not the language itself. Consider the difference between a minified JS script or one produced with emscripten and the code pre-minification. One is unintelligible guaranteed, the other … maybe haha. Unfortunately, what tended to happen is people would write one liners, and slowly expand the one liners into more complex one liners, and then integrate them…

That's a problem with the people who wrote the script, though, not the language itself.

That's like the folks who say "the problem with C (buffer overflow, UB, etc.) isn't C, it's the people who write C". Which leads to at some point contemplative folks deciding either "this is happening so often, maybe it is the language" or "the majority of people writing this language are incompetent". While I've heard plenty of people in the C community espouse the latter view, having written C since K&R days, I think most people acknowledge it's a problematic language. But I don't have empirical evidence of a ratio.

I wrote a ton of Perl <=5 back in the day. I'm pretty sure I know why I thought it was a good idea at the time. I know where I fall on the above. I know why I, and virtually everyone I know professionally, don't solve problems in Perl any more. But hey...maybe I'm just incompetent.

Re: Is Perl 6 Being Renamed?

#328

I'm sorry but Perl 6 isnt relevant IMO. It took too long. I was a Perl developer at etoys.com in 2000 and BBC in 2001. I wrote OneMusic for Radio1 and even convinced the BBCs uptight ops team to run it with modperl so it could handle the high traffic it did. I also created the job search engine WorkZoo in modperl, one of Time Magazines top 50 sites of 2005 and Indeed's main competitor at the time. Perl6 was promised.…

Okay, but is it a good, useful programming language? In some ways, the long development timeline suggests a slower, more stable way of doing language changes that appeals a lot to me.

I think so. I regularly use JS and Java in daily life and used to use a whole host other languages in the past.

Perl 6 is actually a joy to code in, as weird as that sounds. It's fairly straightforward to begin using, but the deeper I go the more I see the huge benefit to its long development which was mainly in spec-writing. The two killer features (for my work, at least) have been the grammars (a sort of regex on steroids that is actually readable) and the multiparadigm approach. I mean you can do functional coding with Javascript sort of, but you end up with a lot of extra line noise compared to P6 where it was contempalted from the beginning (and multisubs clear things up even more). All the typical paradigms are integrated fairly seamlessly to let you choose the best tool for the job for whatever block of coding you're working on.

Re: Is Perl 6 Being Renamed?

#329

Earlier quoted context omitted.

I've found over the past 6 years that anything nice about Perl is negated by how hard it is to think of the right way to do something from among the 30 different ways. And it makes it difficult to write maintainable code because there are no good ways to constrain the input domain of functions. I also don't think it's a good thing that the language has idioms. In a human language idiomatic expressions are a barrier t…

While it's true in human language that idiomatic expressions are a barrier to learners, they are also a means of enhancing communication between experienced users of the language. Take Jargon for example, I've not got deep experience in functional programming, category theory, or discrete mathematics (really anything much higher than college stats), so the phrase "constrain the input domain of functions" set me scrat…

> While it's true in human language that idiomatic expressions are a barrier to learners, they are also a means of enhancing communication between experienced users of the language.

Except that this is a computer language. Computer languages don't have nearly the same range as a human language, and there are very specific formal rules to be followed. If I want to I can speak English without any idioms. Another difference between computer language and human language is that there is a huge amount of duplicated information in a human language, whereas a computer language like Perl is designed to be as terse as possible. So if I want to know what an idiom means in English, I can A) ask the speaker what they meant by it, B) infer what it means based on the context in which it was spoken which includes the time and place and the situation, or C) look it up on the internet.

In a computer language, A requires either direct access to the language designer, code comments, or dialogue with the user of the idiom. B requires context information, which is simply not present. There is no situational analogue to the scene and people involved in an English conversation. You're conversing with a compiler. C is made difficult by the terseness of the syntax. So really having idioms in a computer language doesn't work at all without having someone to decode those idioms for you. And in the end if we all have to decode idioms then we should just make the meaning explicit in the code. If you have too many idioms then your code becomes unreadable without some kind of codex.

> The best Perl developers I know understand this and what you see as praise for arcane-ness is usually in my opinion just embracing the idea that jargon and idiomatic language is inescapable, and should be just another tool in the toolbox for expressive writing.

While I think we can agree that Thomas Pynchon is a highly expressive writer, I also think we can agree that he is very obtuse at times. It's fun if you get it, but it's infuriating if you don't. There's a difference between being expressive and having so many facilities that casual users of the language can't remember how to do simple things because there's just so much syntax to learn and so few mnemonics with which to do so.

Re: Is Perl 6 Being Renamed?

#330
post #70

Routinely I see in numerous online discussions that people refuse to even consider Perl 6 because they hate Perl. Or there are younger people who think of Perl as "their grandfather's language" (in much the same way people in my generation view COBOL). I am not a fan of Perl, but this feels tragic to me. Perl was so radically different. I remember being on Perlmonks way back in the day, and someone would post a quest…

You are not alone feeling that. Check out to paper titled "93% of Paint Splatters are Valid Perl Programs" https://famicol.in/sigbovik/ "In this paper, we aim to answer a long-standing open problem in the programming languages community: is it possible to smear paint on the wall without creating valid Perl?"

Except that the vast majority of those OCRs are just a series of letters. They all parse as "a variable name, that's it", and it's not even weird for that to be a valid line.

It's the kind of joke that doesn't teach you anything, rather than the kind that does.

Post reply on HN