Suggestions for Larry Wall.... the author
and sustainer of the perl computer language

I'm not certain who to write about suggestions for Perl version 6... but I have many ideas.
According to information at perl.org, Larry Wall has explicitly requested lots
 of input of ideas for a new version of this language.

Now, designing a computer language is a big responsibility. The person who does this
 is making a house for millions of people to live in daily. If that house has a low doorway,
 or unsanded railings, or bad air circulation, there can be very serious posture problems in 
living there day in and day out. In real spoken languages, the words and syntax can 
change and transform according to the consensus of people as they work with it daily.
Computer languages, however, are set in stone.

Thankfully, perl is designed at it's root, as a text manipulator - and so one can very easily,
even today, create one's own idioms, and phrasings... and transcribe them, using a custom
made tool.

However, it would really be nice to make some very substantial changes to perl 6.

My hope and dream for computer languages is that someday they would be designed to allow
  someone to get an instant overview of the entire program by looking at the text on the page.

For instance, if you climb a mountain next to your town or village, or go for a plane ride over your
 city... you would see the whole layout of the town. And you could look at it and say - "Oh there
 is place A, there is place B and there is place C" - the aerial image of the community is, in itself, 
a context for all the individual places you see if you're driving around, or walking about
the community.

Unfortunately, computer code does not work in a similar fashion. The main problem, of course, is
that time takes several twists and turns and loops over the course of the computer program.

But there are some things that could be done to improve the legibility of code, and
 thus improve the  ease and fluidity with which programmers can do their work.

One thing that perl has dedicated itself to, is allowing for complex tasks to be prescribed with only
  a few letters of code. Because this cuts down on the clutter of the page... it becomes much easier
to read and work with perl scripts.

Another thing which could be done is that each concept in perl could be given it's own symbol. 
Look at how many symbols are in a spoken language. And everybody is able to speak with all
 those words, and write with all those words. The human mind does not have a
 problem with a multitude of symbols. The problem the human mind has, comes when there is
 an overlap - one symbol for two different concepts. For instance, microsoft has always had both
 a back and an up button for it's file manager. The eyes see the same visual effect  when you go
 back to a folder in a different branch of the tree... as when you hop one folder towards the root
 of the tree. And so when you have two buttons right next to each other - one "back" and
 one "up" - this creates a certain amount of confusion - and will every single time.


 There are certainly plenty of extra symbols, now that unicode is the worldwide
 standard for our computers.  And no programmer would be sad about switching over to a
 different keyboard layout which would allow him to access a few new symbols.

Specifically what should be given it's own unique symbol?
Well, for instance, I think that one should never be forced to pair the name of a list or 
a hash, or a reference with the dollar sign. That sign should be reserved for simple text
 or numbers.

If one was conscientious and always used the same name for the same kind of token
 (my word for "variable"), then eventually you would develop your own set of keywords,
 and you could easily pick them out of a page of code, whether they were
 paired with $ @ or %. But it's very unusual that programmers will choose to do that. 
Usually they want flexibility, and the freedom to use different token labels in different
 types of programs.

So, a list should always be paired with the @ symbol. A hash should always be paired with the % symbol.
I think there should be no exception for when you are retrieving one element out of that list or hash. 

I like the concept of being given different bits of information  depending on scalar or list
context. This tends to make it possible to work more intuitively... and it cuts down on the
 amount of code you need to write.

However...  Let's look at this idea in terms of an analogy of how things are traded between
 people in the real world. It's not a stretch to compare these things... if you are putting an
 amount or a bit of text into a token...    $token = "text", you are asking for and receiving
 information.

Let's say we have two friends: Bob and Sally.  Bob wants something from his friend.
    Perhaps he idolizes her and we could say that what Bob really wants is
       emulate her in every sense. This would be written in computer code as
               Bob = Sally.

 Or perhaps, instead, Bob simply wants a bit of her time. Or he would like to borrow her 
   car. Bob can ask his friend for that thing he wants... he doesn't get what he wants
  by simply equivocating her with that item. If he thought of Sally as being equivalent
   with her car, he wouldn't be a very good friend, now would he be?
According to that pattern, we wouldn't say:
               Bob wants = car of Sally
                    We should rather say:
               Bob asks for car = from Sally.

So to say $info=time or @info=time makes sense. The context is requested by the thing
 which is asking for the information. 

There's no need to speak about the context in two places... 
as you would by saying  $something=$list[5];

Instead, I believe it's better form to write it like so: $something=@list[5]
  

Other suggestions...

   There should be instructive error messages written in real english... not in the computer guild
     techie language.

One of the things we're seeing a lot these days is that computer software designers are passing on
    cryptic error messages to users. This is a very big problem for the field. So, a computer language 
 writer,  in being gracious to programmers in how he explains typos in their code, can set
 precedent for  programmers who will then create gracious messages to the general public when
 there is a need to communicate something onwards to them.

My ethic about computer software design is that a software designer needs to predict where
 people will have problems as they use his machine, and he needs to use those moments 
as teachable moments.

 It is absurd that php code will spit out cryptic messages at the general
public, when there is something amiss in the page layout instructions.

It's absurd that web hosting companies don't design a system whereby the public is given
 a message about a server being down. Instead, they want to just let the person's browser
 tell him some generic message which could mean any number of things. 

Thus, I hope that perl version 6 includes clearly worded messages which help a programmer
  quickly identify what kind of typo he made...

There are a couple of really typical typos which could be caught immediately... One is not including
 a semicolon at the end of a line. Another is accidentally placing a backlay mark "\" - to the
left of a quote mark at the end of a block of text.

___________
___________

Regular expressions could also be redesigned.. you could have the option of using a standard
  regular expression, or a special perl style of search pattern.

Again... the same symbol should not be used in two different contexts.
 If you want tokens (variables) to interpolate in a search pattern, you cannot use the same
 symbol - the dollar sign - as something which indicates an anchor to the end of a particular
 block of text. It's not kind to make us use the carat mark "^" to mean both the anchor, 
 and also have it mean "not".

"Escaping." This concept needs to be reworked altogether. You ought not to use the same symbol
 to insert normal text, which you use to insert special symbols....
I would prefer a smaller symbol than the backlay mark. Perhaps a period or a comma
 or a hyphen could be used to insert special symbols.  This would cut the clutter,
and thus make search patterns more legible.

One solution would be to require the use of a set of brackets for real english text... and then
 there would be no need for a special backlay mark at all.

For instance... here I'm searching for the phrase "the rain in spain" bordered by two three letter
words.

/s+...s+[the rain in spain]s+...s+/