I find it amazing that you find five characters (the space is optional) for lambdas too long -- heck, the proper name of the feature is longer then that. OTOH, while I find them useful from time to time, they aren't a basic feature of my code often.

OTOH, I would include the ability to do predictable memory layouts and pointer arithmetic as at least something that is very nice to have. OTOH, perl has these, via pack.

I wouldn't inlcude higher-order functions on my list because they are a neccessary side-effect of coderefs as far as I can tell.

On the other hand, I would include a CPAN, or something close to it... but I would also note that I consider apt-get, and even similar (but worse) repositories of other distributions, close enough to CPAN to count, at least for C and C++. Freshmeat and even sourceforge are also vaugely close.

Easy foreaches are also important, even across somewhat abstract list-like things, which leaves out C, C++, and Java, so far as I know.

Really, though, the number one requirement for a language (beyond obvious stuff like turing-completeness) is hashes.

Easy foreaches are also important . . . which leaves out C, C++, and Java

Java now has a foreach-like construct.

beyond obvious stuff like turing-completeness

I dunno. I think you could get some pretty nifty stuff in a language which isn't TC. Maybe it wouldn't work for general programming, but it may solve a specific problem domain very well.

Which is why I'm more interested in Parrot than Perl6, but that's another issue.

----
send money to your kernel via the boot loader.. This and more wisdom available from Markov Hardburn.

The C++ STL also has std::for_each(), so I guess that just leaves C.

I find it amazing that you find five characters (the space is optional) for lambdas too long -- heck, the proper name of the feature is longer then that.

I've given this a bit of thought: it's not so much the sub {...} part that I find verbose as the fact that I can't bind variables in a convenient way: I either have to use up keystrokes with a my ($x,$y,$z) = @_; at the front of the lambda, or constantly index @_ (which looks awful).

For instance, in Haskell the "zip" function (take a pair of lists and return a list of pairs) is defined as:

zip = zipWith (\x y -> (x,y))
[download]

(What's important here is the lambda.) In Perl, assuming an equivalent zipWith, you'd have to say:

zipWith {[$_[0], $_[1]]} @foo, @bar;
# or:
zipWith {($a,$b)=@_;[$a,$b]} @foo, @bar;
# or:
zipWith {[unshift,unshift]} @foo, @bar;
[download]

none of which looks as pretty. That's more a matter of opinion, of course.

--
F o x t r o t U n i f o r m
Found a typo in this node? /msg me
% man 3 strfry

I agree, none of those are pretty. In Perl 6 you can also use either of:

    zipWith {[$^a, $^b]} @foo, @bar;
[download]

or

    zipWith -> $a, $b {[$a,$b]} @foo, @bar;
[download]

But then, your entire OP reads a bit like an ad for Perl 6... :-)

I don't know how I ever got along without hashes. Well, I do, but it wasn't pretty. It still isn't. In the statically typed language I'm forced to work with, 'associative array'-like classes have been added, but they are less than robust. You have to have one class for numeric keys and string values, another for string keys and string values, and ... you get the idea (if you need multidimensional hashes, just bang your head against the wall...you'll forget that you needed them in the first place :).

Another feature I appreciate is variable length argument lists for functions. More than once I've wanted to add an optional argument to a function, but don't want to change every call to the function.

• ability to execute dynamically constructed code (ala eval in perl)
• automatic memory management (unless there's a really, really, really good reason to do this yourself)
• exception handling
• namespacing

------------
:Wq
Not an editor command: Wq
[download]

Mine are:

• Regular expressions.
• Topicalizers $_, @_ etc.
• The compact, expressive nature of the language.
• Statement modifiers.

I don't think there is anything that I have to have in a language. I find different languages valuable for different things. If I have selected, for example C to implement something it is because it matches the problem. If I need hashes and closures I select Perl not C.

Now different languages clearly have distinct "areas of competence", but the trick surely is to have enough tools in your belt to always have one that is suitable.

• Anonymous functions

Without it, dispatch tables that curry their arguments are almost impossible.

I think "Anonymous functions" are implied by the OP in "Lambdas (basically, anonymous closures)".

P.S. - I love a good Curried Dispatch Table too, with a little Mango Chuntney and fresh Roti,... yummy ;-)

-stvn

I think "Anonymous functions" are implied by the OP in "Lambdas (basically, anonymous closures)".

"Implied"?

Yeah, I probably should have been more clear. When I mentioned "lambdas", I meant "anonymous functions, closures, and combinations thereof".

Incidentally, one thing that I'm really starting to like about Haskell is its ability to seamlessly manipulate functions via currying, composition, and higher-order functions like flip. I'll try to come up with some examples that are neither trivial nor obscure for the next part of my Haskell intro.

--
F o x t r o t U n i f o r m
Found a typo in this node? /msg me
% man 3 strfry

In addition to those already mentioned I'd add:

• a testing framework
• a profiler
• lexical (my) and dynamic (local) variable scoping
• decent runtime type system (any language that forces me to cast types to do anything useful is broken IMHO :-)