Steve Yegge's rant on The Next Big Language

[Jarrett Billingsley]

"BCS" <ao at pathlink.com> wrote in message 
news:ce0a334373a38c91d108e764264 at news.digitalmars.com...
>>
>> 5. Function literals and first-class, non-broken closures
>>
>
> that's broken usage, not a broken feature, they work if you do them right, 
> just as pointers do.

I'd consider the current incarnation of closures "broken."  Are they useful 
as they are now?  Hell yes.  But can you do everything with them that you 
can in languages that have true closures?  No.  Functions are *almost* first 
class types in D ;)  Being able to return closures without having to 
manually create the context would be.. amazing.

>> 9. List comprehensions
>
> Ok, I'll bite, What is it?

Basically it's a way of really easily applying functions and such over a 
list.  They're kind of like array operations (a[] = b[] + c[]), which D 
doesn't have yet, but more flexible.  You can do stuff like (using very 
python-like syntax):

int[] numbers = [1, 2, 3, 4, 5, 6, 7, 8];

// This loops through numbers, seeing if the condition holds true,
// and if it does, adds it to a new list, which is eventually assigned
// to evens.
int[] evens = [x for x in numbers if !(x & 1)];

// Square the list
int[] squares = [x * x for x in numbers];

>> 13. Keyword and rest parameters
>
> I'm not sure what this is

Keyword parameters are another thing found in python.  They allow you to 
call functions with named parameters:

foo(x = 5, y = 10);

In python, the keyword parameters are interpreted as a hashtable, but since 
D is statically typed, it could probably just map the parameters right to 
the parameters defined in the function.  I'd really like to see this.

>> 16. Type expressions and statically checkable semantics
>
> I'd count template's that construct types under this, as well as the 
> ability to statically check operator restrictions
>
> somewhere Oskar Linde has a Unit checking template that at compile time 
> checks for errors like adding meters to Newtons

Oh, alright then.  That's cool.

>> 17. Solid string and collection libraries
>>
>> _Libraries_?  Noooo.
>>
>
> We don't need them, D's AA's and dynamic arrays cover most of it and IIRC 
> there are about a dozen libs for playing with them when you need more, 
> clean them up a little and you've got it.

I'll agree with you mostly for collections (I haven't missed STL a bit), but 
std.string is kind of an embarassment.  It only really has support for 
char[] (major shortfall in a language that supposedly handles UTF-16 and 
UTF-32) and doesn't provide any in-place functions (which would be great 
when you're writing a program that doesn't want to make any heap 
allocations).