I think the unicode character operators are very very bad.

I agree.

While it maybe nice that "..." and the ellipses work as the same thing, it prevents code editors from searching on such things.

The only thing I use to search for certain operators is Google, and it doesn't support searching for interpunction anyway. I've never used a search or grep tool to try and find operators in source code, except when discussing on perl6-language how often something is used in Perl 5.

I think there are WAY too many operators (queue link to the table of operators).

There are a lot of operators, but this is not as big a problem as many think. Many are logical and can be put in a simple table, and here having multiple operators for what is now the "same thing" actually makes things easier. I'm talking about the bitwise operators here. | will be +|, ~|, and ?|. Same for &, <<, >>, etcetera.

• They're ugly. But how often do you use bitwise operators?
• There are many. But this makes knowing what is meant (stringy or numeric?) easier in a clean way.
• The nice looking | and & are now something else. But the new thing is much neater and something that will be used much more often: junctions

Then there are hyper-operators, which means the combination of » and/or « and another operator. This is just like modification operators like +=: once you know how it works, it saves you a lot of time. Have you ever needed to look up what ||= does? (If so, why?).

If you don't count compound operators, the difference with Perl 5 is much less shocking. 42 stay the same, 14 change (of which 5 are these bitwise operators) and we get 13 new ones (excluding the hypers). This is in a total of 84 operators not such a big change. (I'm counting op= as one operator).

Perl5 ALREADY has a problem with newbies being able to read code written by uber-perl programmers (like myself :)).

Quoting TimToady (source):

Any language that doesn't occasionally surprise the novice will pay for it by continually surprising the expert.

We're going to make it more obscure possibly, without adding clarity.

As always, it will be so that if you want clarity, you can get clarity. If you want obscurity, you can get obscurity. The difference will be in *how* this is done. Some will go away, some new ones will be introduced.

I do like the freedom of expression, but we are going to create a lot of dialects with uber-TIMTOWDI.

More than before, I think that Perl 6 will have clearer "best" ways to do it. Junctions will help a lot.

I think the tendancy to have a lot of modifiers on declarations, etc, is confusing -- there is getting to be too much syntax to remember.

Why would you even try to remember everything? I use documentation all the time when I code. Even if you do remember the syntax and function calls, there are some important warnings to be made aware of.

Why is Perl5 cool? It's a minimalist language.

I think you are using a different Perl 5.

I want to see Python, Perl, and Ruby folks actively working on Parrot, not just Perl folks

I'm sure that any help is welcome. I think that as Parrot gets more complete and polished, integration gets better. Although I've seen all kinds of languages discussed already.

it needs to be VERY mindful of the things it is getting wrong in the way to that clean-ness.

I agree, and in some parts it is indeed going in the wrong direction, IMHO. (To sum them up: unicode operators, \d{1,5} becoming \d**{1..5}, over-use of «», confusing over-use of :).

I don't think you understand the process of language design.

Why is Perl5 cool? It's a minimalist language.

I like Perl 5 but I have no idea what you mean by "minimalist".

I do like the freedom of expression, but we are going to create a lot of dialects with uber-TIMTOWDI.

Have you ever used a module? APIs are dialects.

Perl5 ALREADY has a problem with newbies being able to read code written by uber-perl programmers

I have trouble reading Pascal (the mathemetician) or Proust in the original French too, yet plenty of francophones seem to do okay with the language. Heck, I have trouble with Pynchon, Joyce, and DFW in English but I make a living working with it.

I don't care if new programmers can't read my code. I care if people who understand the problems I'm trying to solve can maintain my code. I wouldn't expect my 18 month old nephew to write or edit a 300 page book. Why should I expect the equivalent in the coding world?

You're right that it's as silly to expect a newbie to be able to read my perl code as it is to expect a newbie to be able to read Dickens.

However, if someone claims to be writing in English (like Joyce) and yet a fluent English speaker (me) can't understand what the hell he's going on about, then that indicates that Joyce's work is, in fact, crap. Same applies to perl code that is hard for a fluent perl coder to read. It's crap code.

DrHyde wrote: Same applies to perl code that is hard for a fluent perl coder to read. It's crap code.

If you can't read my "hello world" program, you're right. My program is crap. However, some problems are hard. There is no easy way to solve them and thus there is no easy way to express them. For example, most people do not refer to Damian Conway's modules as "crap", but frequently one finds them to be crap by your definition. While Damian can be viewed as an extreme case, it's because he chooses to solve extreme problems. I've worked with chromatic before and I've seen him write some head spinning code -- but not for "hello world."

Cheers,
Ovid

New address of my CGI Course.

What prevents editors from searching on ... vs …?

But mostly, I take exception to your characterization of perl as a minimalist language. It is most certianly not. It has dozens of features that aren't minimal -- that could be easily built out of smaller building blocks. Hashes, for example. It's not difficult to make a hash out of simpler bits. There's no reason for it to be built in to the language, when it can be written inside of the language. That's a minimalist point of view -- but easy hashes are part of what makes perl so nice to deal with. C# and VB and a slew of other languages have objects that are very hash-like... but them being objects instead of first-level concepts makes them annoying to work with.

Perl5 also has lots of things that aren't used, in pratice. Perl6 will get rid of some of those, and introduce some new ones. Also, perl6 is much less a language for beginners then perl5. There are a lot of techniques that you can use in perl6 that are difficult to understand for beginners, or can be. This also means that in the hands of an expert, you can do a lot more with a lot less. It's not a question of better or worse, it's a question of goals, and I think I'll like writing perl6 more then I liked writing perl5 (and I like writing perl5 a lot).

Terminology. Suppose one language requires an open desk reference and a web page open to the standard library. That's Java. Suppose another is easily learned and remembered. That's Perl 5. Now suppose we add 50 operators to Perl 5... just like the File test operators, that's something else to remember.

Having only 3 major data types IS pretty minimalist, maybe not uber-minimalist, but that's a good thing.

I think I'll like writing perl6 more then I liked writing perl5 (and I like writing perl5 a lot).

Oh yeah, I totally agree here. Depends who wins the Perl5/Ruby thing, probably, but I know I'll like it better. Can't say that makes it wrong to ask questions about how it could be simpler though.

Complex tools are a good thing. Advanced concepts in the core are an awesome thing. Innovation is a good thing. However, keeping the syntax clean and straightforward, and ... yes .. minimialist while adding features is important to me. I don't want another "open desk reference" kind of language.

Can you remember:

• where split() in void context puts the results?
• what $| = 2; print $|; will output?
• what weak references are, and why you might need them?
• how to use formats?
• what all of the default punctuation variables do?

These are just things I thought of off the top of my head. I know the answers to these (except the last two), but I bet another very experianced Perl coder would have to look it up (and some of this stuff is in very obscure places). They'd come up with a completely different list that would stump me. In other words, we would each know a some details that the other doesn't.

(Unless, that is, your name is Abigail. He can probably beat Larry.)

Neither of us would a truely complete understanding of the language. We'd just know a useful subset which has been grown over time by our individual experiances with the language.

In their orginal forms, C and LISP are minimalist languages (I find LISP surprisingly so). If they display complex behavior, it's because they use combinational explosion to produce it (i.e., combining individual components on a massive scale). Perl does do combinational explosion, but it gets a lot of power by refining the details of individual components.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.