I found schwern's list of things to consider when designing a new language quite good. Personally, the one "emergency" question is:

Does the language have a string eval command?
If so, then I can emulate includes, arrays, hashes, namespaces, closures and various other neccessary things through this. This is the most ugly solution to all these requirements, but if all else fails, having string-eval helps.

Thanks for the link -- and for bringing up string-eval. That particular feature hadn't actually made my list before this, though primarily because (as I see now) I hadn't fully considered its implications for dealing with a paucity of important features. It's going in my list of language litmus tests now.

print substr("Just another Perl hacker", 0, -2);

- apotheon CopyWrite Chad Perrin

An interesting question.

My gut reaction is, "How easy is it to read the code?" I've just started investigating Drupal as a CMS, so that means getting into PHP. I've looked into the language before, and it seems simple enough, except without some of the groovy things that Perl does. I'm also looking into Python because my CTO mentioned that Red Hat is using it to build their distros. Again, the language reads like a simplified version of Perl.

Since you touched on IDEs, I did just want to say that I used an IDE from Borland to do development in C many years ago -- but I'm now familiar enough with the language that I use every day (Perl) that if I get a syntax error, I almost always know what the mistake is -- I don't need a visual reminder of where to look. More useful would be an OO debugger, although I'm currently quite happy with the Perl debugger -- that's probably just my machine language background speaking.

I 'get' OO -- but I've never used C++ or Java much; pure OO usually seems to be twisting reality to fit the language, rather than having the language do the acrobatics. Perl's OO layer is just that -- a layer, and not really built in. However, the hints I see occasionally about Perl6 suggest that it will be much more OO. That's OK -- as long as I can still get stuff done quickly and efficiently, I'll make the jump to Perl6.

Eventually.

I think that code readability is of great importance, of course -- but that's more of a high-level goal of language choice, rather than an example of language choice criteria. For instance, one might say "no variable sigils" in answer to my question, with the explanation that the reason for that answer is to improve readability. One might also say "significant whitespace" for the same reason. Code readability is affected by a combination of such language characteristics, programming style, and the particular accent a given programmer lends to the language in his/her code.

(Note that I make no judgments here about what effects variable name sigils and significant whitespace have on code readability. I only bring them up as examples of things people have suggested apply to code readability.)

Regarding your commentary on OOP: Have you had a look at Ruby? Through all my encounters with object oriented programming, including the way it's accomplished in C++, Java, Perl, and Python, I tended to find that OOP was well overhyped. In Ruby, however, I have learned to love the stuff. It's by no means the only way to program, and there are times when it's probably entirely the "wrong" approach to even a high-level problem, but the object model employed by Ruby is subtly pervasive and quite consistent in a way that makes me realize that there's a lot more to OOP than I had previously thought. The problem is not that OOP isn't all that useful -- it's that most languages get OOP substantially wrong.

With the usual caveats that I've never used Smalltalk or the CLOS, Ruby is by far the best OOP I've encountered. You may find it was worth looking into, while you wait for Perl 6. Quickness and efficient task completion are in no way hindered by the pervasiveness and universality of object orientation in Ruby.

Speaking of which -- the ability to employ OOP techniques in a Ruby-like "everything is an object" manner is one of the things I include in my list of language litmus tests, at least when looking at a language for purposes of doing any object oriented programming.

print substr("Just another Perl hacker", 0, -2);

- apotheon CopyWrite Chad Perrin

For instance, one might say "no variable sigils" in answer to my question, with the explanation that the reason for that answer is to improve readability.

Actually, coming from my C background, Perl sigils were a change for me -- sure, * means a pointer, but apart from that C doesn't have them -- but I quite liked them. Which will be a change going to Perl6.

And thanks for mentioning Ruby -- that's the third language that I need to look into (in my spare time) in order to stay up to date on what's happening with the new languages. It'll probably be easier for me if I can draw a big chart showing how you do certain things in each of the languages. For example, a pop in Python takes things off the *front* of an array, not the back, like Perl. Not what I expected.

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

You already mentioned these :-) Closures are so incredibly useful I don't really want to code without them, but if I must, the language should at least support functions as a data type (i.e. C-style function pointers). Java-style object systems are a much too rigid on their own.

Closures and its flexible object system are what make JavaScript a good language. Shame about the ugly syntax, though :-)

Basically, anything that helps writing real functional code is a big plus.

Backtracking.

It's sort of a niche technique, but it's amazingly useful when applicable. See also the discussion at How implement AMB in perl?

A "freestyle" type/object system

I like perl's automatic type conversions. I like Ruby's strategy of duck-typing. I like C-style pointer casting. I even like the idea behind C++ templates. I don't like being restricted by the language.

"Real (i.e. LISP-style) Macros"

Anything that allows you to subvert the language itself is a good thing :-) Though it seems it's hard to implement unless the language syntax is extremely simple (this might not be a bad thing, I'm only just getting my feet wet with LISP, so it just looks more intimidating than it probably is :-) )

It's not just the syntax that gets in the way with JavaScript -- it's the broken implementations and the short-sighted language definition (no direct system I/O, for example). It's a good language the same way Lance Armstrong would be a good athlete if he was was riding a circa 1980 banana seat bicycle designed for a ten year old girl in the Tour de France.

Anyhow -- yeah, I agree, regarding "anything that helps writing real functional code", as long as it doesn't also get in the way of writing real useful code. I'm not saying that writing real functional code necessarily makes the code less useful -- just that I've seen some people do some really boneheaded things with language design for the purpose of rigidly adhering to some kind of design aesthetic.

Thanks for the link about implementing amb in Perl, and the other commentary. I'll need to get significantly more well versed in things Lispy to really appreciate macros, I think, but one of the things I tend to look for in a programming language is duck typing or, alternatively, type inference. Thus, none of your suggestions really go amiss for me.

print substr("Just another Perl hacker", 0, -2);

- apotheon CopyWrite Chad Perrin

It is a successor to APL and is remarkably concise. It is also a highly functional language. It has computer language counterparts to English parts of speech such as noun, verb, adverb, gerund, and conjunction. Besides concise operators, there is one concept, called verb rank, which went through more than 10 years of development and research to develop. It has a long history of development. I will now give a small taste of each of my overview statements.

descriptive, not proscriptive

J is descriptive in a number of ways, but I will only go over one that is necessary to read the next section. It has to do with a concept called "verb trains"... In most languages, a series of functions implies function composition. In J, two functions in series applied to data gets rewritten like so:

(f g) data => data f (g data)
[download]

a brief aside

J verbs (functions) are monadic, dyadic, or ambivalent (meaning they have implementations for both monad and dyad cases). The monadic case looks normal:

fn data    NB. function applied to data "NB. is comment in J"
[download]

but the dyadic case is just like in English sentences where you have Subject Verb Object:

5 + 5   NB. 5 adds_to 5
5 , 6   NB. 5 appended_to 6
4 { 1 2 3 4 5    NB. 4th element_of the_list_12345
[download]

So when you see

(f g) data => data f (g data)
[download]

the data f (g data) is Noun Verb Noun and is not like in perl where a function taking two arguments would have both nouns to the right of the verb.

Now three verbs in a row is called a fork. So

(f g h) data => (f data) g (h data)
[download]

highly concise

Check out this J code to average a list of numbers:

avg =: +/ % #
[download]

% is simple. It divides 2 numbers

# is simple. It counts the number of elements in a list

So remember that a train of verbs gets rewritten? So basically what we have is

(+/ data) % (# data)
(sum-of data) divided-by (number-of-elems data)
results in average
[download]

the rest of J

Falkoff and Iverson, The Design of APL, 1973.
Falkoff and Iverson, The Evolution of APL, 1978.
Iverson, A Personal View of APL, 1991.
[download]

Also Ken E. Iverson memoriam page has plenty of insight to APL and J language culture.

It's a very different language. And it will make you think differently, but I am enjoying my time with it.

The Cons

Now even though the community is small, you can check the mailing list archives to see that there is a tremendous amount of activity amongst the small userbase.

• How easy is it to start a new function? How much "junk" do you have to write as a basic framework for any addition?
• Can I remember how to do it right easily, or does it pretty much require to copy/paste a boilerplate for the code before starting?
• Can I express what I want easily without having to jump through too many hoops? This mostly boils down to: what kind of stuff can I pass as parameters?
• If I change my mind ever so slightly, do I have to rewrite a lot of code just to fit the change?
• How tricky is it to get it right?

Needless to say, for me, Perl scores highly on all these points.

I think it's telling that I've never heard of a "read-only" language. The implication I draw from this is that readability is dependent upon writability: the extent to which a language is writable is an upper bound to its readability. So, yeah -- writability is of pretty significant importance objectively, I think, as well as subjectively.

print substr("Just another Perl hacker", 0, -2);

- apotheon CopyWrite Chad Perrin

One thing I find rather useful is for a language to behave as expected. By this, I mean that if does not do odd things such as redefine operator precedence (see APL) or have odd restrictions, such as preventing one from casting an integer to a float.

I view regex as a feature that could be added, not something that needs to be intrinsic to the language, such as tail-call recursion or closures.

I've really not mucked around in languages other than imperative languages, so I can't comment on languages in any of the other families, such as Ocaml, Lisp, etc.

The one syntax feature I tend to dislike is for whitespace to be used for something other than token separators; in some languages, such as JCL, two, vs one, blank can completely change a statement's meaning. I also tend to dislike languages, like APL, which use a very non-standard character set.

Perl has passed my test; APL hasn't. I've been forced to use JCL, and still bear the scars. Two languages I would really like to learn are Ruby (got to love the name) and Lisp (good thing I can touch type; Lisp would wear out the markings on the open and close parenthesis keys).

1. First-class closures
2. Most common idioms are easy or trivial to do

Anything else is negotiable. First-class closures were already mentioned in the OP, and by the second, I mean what Perl has got mostly right: sometimes you can even manage with a one-liner. Of course, how this is actually done depends on the language. Perl is bent towards text processing, thus regular expressions and many other features are easily accessible and embedded into the language core.

A good example of the opposite is Java. No matter what you want to do, you always have to create at least one class. There are no exceptions to this, no common case optimizations. The "main" function of the program is the most common function, as unless your program is a library (and even then, you might use the main function in testing!), your program will have the main function. In Perl, your program source code is, by default, the main function, unless you explicitly direct the program flow elsewhere. In Java, you have to:

class Somesuch {
  public void main(String[] arguments) {
    ...
  }
}
[download]

That is, you always need to declare a class, even when it's completely useless, and you always need to explicitly name the variable where you want to put the command-line arguments, and you always need to explicitly declare the main function.

Another common-case optimization in Perl is the lexically bound implicit (loop) variable $_. In Java, C, C++, and awfully many other languages, you always need to declare the loop variable, even though when you write a loop, the most common case is that you are looping over some data structure and you need to access the contents inside the loop body. In C++, for example, using indexing:

  std::vector<Data> myArray;

  /* Time passes... */

  for (int i = 0; i < myArray.size(); i++) {
    process(&myArray[i]);
  }
[download]

or iterators:

  for (std::vector<Data>::iterator i = myArray.begin();
       i != myArray.end();
       i++) {
    process(&*i);
  }
[download]

In Perl, of course:

  for (@array) {
    process($_);
  }
[download]

or even

  process($_) for (@array);
[download]

(Granted, the latter C++ example uses iterators, but still, it's an awfully verbose way to do a very common case in programming.)

The examples are not the best, but when such mentality pervades the language design, I steer clear.