Steve Yegge's rant on The Next Big Language

[BCS]

Jarrett Billingsley wrote:
> "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.
> 
> 

Yes that would be nice, but it is one hell of a can of worms. It has 
more corner cases than general cases. About the only things that would 
be safe and reasonably understandable would be to put the whole stack 
frame on the heap.

If someone can figure out how to fix all the problems in a reasonably 
understandable manner, I'd love to see it. Until then, I think Explicit 
scoping (using structs) is the way to go.

Again, just my opinion.

>>>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];
> 

Cool, LISPisums.

Again, it would be a lib but I think it is possible, it would look 
something like this:

int[] squares = mapOver(numbers, (int x){return x*x;});
int[] evens = Filter(numbers, (int x){return !(x & 1);});

A smart compiler would try real hard to inline these so you'd even get 
most of the performance.

> 
>>>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.
> 

Would this count?

struct foo{int x=1; int y=1;}

void fn(foo f){...}

fn({x:0});
fn({y:0});

not as nice, but with a little tweaking we could have this:

void fn(struct {int x=1; int y=1;}){...}

use an anon struct as the arguments.

>>>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). 
> 
> 

Ah... UTF, Oh, yeah. Forgot about that.