Mentions D, and is an interesting article overall.

http://steve-yegge.blogspot.com/2007/02/next-big-language.html

-- 
Remove ".doesnotlike.spam" from the mail address.

Deewiant wrote

> Mentions D, and is an interesting article overall.

Seems pretty clear, that NBL == D.

-manfred

"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:eqoukm$17se$1@digitalmars.com...
> Deewiant wrote
>
>> Mentions D, and is an interesting article overall.
>
> Seems pretty clear, that NBL == D.
>
> -manfred

Except for the typing system (though it could certainly get there), the absolute lack of tools, and missing about half of the Kitchen Sink points ;) Admit it, we all look at the programming language world through D-colored glasses.  Though this article seems more oriented at the next big _apps_ language.  I could really see D taking over C/C++'s slot as the systems language, and maybe a little of the apps as well.

Jarrett Billingsley wrote:
> "Manfred Nowak" <svv1999@hotmail.com> wrote in message news:eqoukm$17se$1@digitalmars.com...
> 
>>Deewiant wrote
>>
>>
>>>Mentions D, and is an interesting article overall.
>>
>>Seems pretty clear, that NBL == D.
>>
>>-manfred
> 
> 
> Except for the typing system (though it could certainly get there), the absolute lack of tools, and missing about half of the Kitchen Sink points ;) Admit it, we all look at the programming language world through D-colored glasses.  Though this article seems more oriented at the next big _apps_ language.  I could really see D taking over C/C++'s slot as the systems language, and maybe a little of the apps as well. 
> 
> 

Yeah, I'd bet that, at least in Steve's eyes, D != NBL.  After all, D was mentioned under the "NBL does not replace C++" section, and he said D was a contender to replace C++.  Hey, we can always shoot for The Big Language After The Next Big Language, or TBLATNBL!

"Chad J" <gamerChad@_spamIsBad_gmail.com> wrote in message news:eqovmi$1952$1@digitalmars.com...

>
> Yeah, I'd bet that, at least in Steve's eyes, D != NBL.  After all, D was mentioned under the "NBL does not replace C++" section, and he said D was a contender to replace C++.  Hey, we can always shoot for The Big Language After The Next Big Language, or TBLATNBL!

I'd like "The Language that The Next Big Language is Written In" ;)

Chad J wrote:
> Jarrett Billingsley wrote:
>> "Manfred Nowak" <svv1999@hotmail.com> wrote in message news:eqoukm$17se$1@digitalmars.com...
>>
>>> Deewiant wrote
>>>
>>>
>>>> Mentions D, and is an interesting article overall.
>>>
>>> Seems pretty clear, that NBL == D.
>>>
>>> -manfred
>>
>>
>> Except for the typing system (though it could certainly get there), the absolute lack of tools, and missing about half of the Kitchen Sink points ;) Admit it, we all look at the programming language world through D-colored glasses.  Though this article seems more oriented at the next big _apps_ language.  I could really see D taking over C/C++'s slot as the systems language, and maybe a little of the apps as well.
>>
> 
> Yeah, I'd bet that, at least in Steve's eyes, D != NBL.  After all, D was mentioned under the "NBL does not replace C++" section, and he said D was a contender to replace C++.  Hey, we can always shoot for The Big Language After The Next Big Language, or TBLATNBL!

He seems to exclude D from the NBL for categorical reasons, i.e. the replaces C++ thing.  But it's pretty impressive that in this long negative article about how all languages suck, and every language is criticized for rampant inadequacies, but the little section on D reads like he is in love with D nevertheless.

Kevin

Deewiant wrote:
> Mentions D, and is an interesting article overall.
> 
> http://steve-yegge.blogspot.com/2007/02/next-big-language.html
> 

Here's another interesting article, relavent to current discussions, that I found while trying to find out who this steve yegge guy is:
   http://steve.yegge.googlepages.com/scheming-is-believing

But I didn't succeed in finding out who Mr. Yegge is other than a guy with a blog who knows how to program.  Is he famous for something besides his blog?

--bb

Bill Baxter wrote:
> Here's another interesting article, relavent to current discussions, that I found while trying to find out who this steve yegge guy is:
>    http://steve.yegge.googlepages.com/scheming-is-believing

That's a good read.

Jarrett Billingsley wrote:
> 
> 
> Except for the typing system (though it could certainly get there), the absolute lack of tools, and missing about half of the Kitchen Sink points ;) 

Half?, more like one or two hard misses and a few more close calls.

I can kill one close calls:

>4 Destructuring bind (e.g. x, y = returnTwoValues())

If I'm reading it right this does that, and nicely:

struct SetT(V...)
{
  V args_m;
  static SetT go(inout V args)
  {
    SetT ret;
    foreach (i, arg; args) ret.args_m[i] = arg;
    return ret;
  }
  void opCall(inout V args)
  {
    foreach (i, arg; args_m) args[i] = arg;
  }
}

SetT!(int,int) bar(int i, int j)
{
  return SetT!(int,int).go(i,j);
}

void main()
{
	int i=1,j=2,k=0,l=0;

	bar(i,j)(k,l);

	writef("[k,l]=[%d,%d]\n", k,l);
}

BCS wrote:
> Jarrett Billingsley wrote:
>>
>>
>> Except for the typing system (though it could certainly get there), the absolute lack of tools, and missing about half of the Kitchen Sink points ;) 
> 
> Half?, more like one or two hard misses and a few more close calls.
> 
> I can kill one close calls:
> 
>  >4 Destructuring bind (e.g. x, y = returnTwoValues())
> 
> If I'm reading it right this does that, and nicely:

Uh... no.  Sort of does it, yes.  Nicely? no.

>     bar(i,j)(k,l);

The winning solution should use the syntax
   i,j = bar(k,l);

And should also work in situations like
   // swap i and j
   i,j = j,i;

And should at least allow bar to be implemented like:

SetT!(int,int) bar(int i, int j)
{
   return SetT(i,j);
}

With a little tweaking of the way Tuples are handled, I think tuples could be made to satisfy this Kitchen Sink requirement.

Tuple!(int,int) bar(int i, int j)
{
   return Tuple!(i,j);
}

You can make a tuple from a struct with tupleof.  So value tuples are in a way just anonymous structs.  You can return a struct from a function.  So why not a value tuple?  Given that, plus a new rule that lets you assign a value tuple to a comma separated list (or alias tuple?), you'd be there.  These sorts of things seem like the direction Tuples are headed, taken to their logical conclusions.

If that happens I think maybe it's time for Tuple! to get a first class syntax.  Something on par with [a,b,c] for lists.  (a,b,c) would be great if that could be made to work.  If not, maybe !(a,b,c).  This would be nice to be able to write:

(int,int) bar(int i, int j)
{
   return (i,j);
}

x,y = bar(1,2);

--bb