On Saturday, 14 March 2015 at 09:59:05 UTC, dnewer wrote:
> yes,java is good lang,but i dont think it's better than c#,if no oracle or google support java will less and less.
> C# is a good and easy lang.
> i like C# .
> but,C# cant compiled to native code.
>
> So far, I have been searching for a language, like c # write efficiency, but more secure than that of c #, more efficient (runs), stronger (system-level, driving level)

More like C#? How? Convert all names to PascalCase?

On Sunday, 15 March 2015 at 00:56:24 UTC, Ellery Newcomer wrote:
> On Saturday, 14 March 2015 at 23:57:33 UTC, weaselcat wrote:
>> On Saturday, 14 March 2015 at 23:46:28 UTC, Ellery Newcomer wrote:
>>> And C# has LINQ, which when combined with the last point is fricken awesome.
>>
>> what does LINQ offer that UFCS-style functional programming does not?
>
> LINQ basically is a UFCS-style api. AST reflection is what makes it nice.
>
> consider:
>
> X.Where(x => x.Members.Count() == x.Admins.Count())
>
> straightforward in both D and C# when X is an array or container type.
>
> When X is a table in a database, things get tricky for D.
>
> C# can interpret the lambda as an Expression<Func> (an AST type), so the implementation of X can reflect over the body of the lambda and use it to generate the appropriate SQL. ORMs such as entity framework and nhibernate do this now.

Even if we can't get the lambdas as syntax tress, the fact that we can send whatever types we want to the delegates and overload operators and stuff means we can still convert the lambdas into SQL.

Here is a very crude, very basic example: http://dpaste.dzfl.pl/94d851d7ca63. An enterprise implementation will be much bigger and much more complicated - but so is the C# implementation.

At any rate, I really don't like what C# did with LINQ-to-SQL. The whole special-syntax to functional-style to syntax-tree to SQL is too overcomplicated - a simply lisp-style macro system(like what they have in Scala or Rust) could have done the trick in a simpler and faster way.

On Sunday, 15 March 2015 at 14:58:54 UTC, Idan Arye wrote:
> On Sunday, 15 March 2015 at 00:56:24 UTC, Ellery Newcomer wrote:
>> On Saturday, 14 March 2015 at 23:57:33 UTC, weaselcat wrote:
>>> On Saturday, 14 March 2015 at 23:46:28 UTC, Ellery Newcomer wrote:
>>>> And C# has LINQ, which when combined with the last point is fricken awesome.
>>>
>>> what does LINQ offer that UFCS-style functional programming does not?
>>
>> LINQ basically is a UFCS-style api. AST reflection is what makes it nice.
>>
>> consider:
>>
>> X.Where(x => x.Members.Count() == x.Admins.Count())
>>
>> straightforward in both D and C# when X is an array or container type.
>>
>> When X is a table in a database, things get tricky for D.
>>
>> C# can interpret the lambda as an Expression<Func> (an AST type), so the implementation of X can reflect over the body of the lambda and use it to generate the appropriate SQL. ORMs such as entity framework and nhibernate do this now.
>
> Even if we can't get the lambdas as syntax tress, the fact that we can send whatever types we want to the delegates and overload operators and stuff means we can still convert the lambdas into SQL.
>
> Here is a very crude, very basic example: http://dpaste.dzfl.pl/94d851d7ca63. An enterprise implementation will be much bigger and much more complicated - but so is the C# implementation.
>
> At any rate, I really don't like what C# did with LINQ-to-SQL. The whole special-syntax to functional-style to syntax-tree to SQL is too overcomplicated - a simply lisp-style macro system(like what they have in Scala or Rust) could have done the trick in a simpler and faster way.

i dont think linq is good.(its make C# bloated, huge, slow!)
i think just class library structure,and class library IntelliSense!
Take its essence to the dregs!
D language has its own characteristics, such as the lower.Should be maintained and developed.

On Sunday, 15 March 2015 at 14:58:54 UTC, Idan Arye wrote:
> Here is a very crude, very basic example: http://dpaste.dzfl.pl/94d851d7ca63.

U++ approach will probably give more succinct result. Not sure how it fares against D philosophy: does it replace range primitives with whole new thing?

On Saturday, 14 March 2015 at 09:59:05 UTC, dnewer wrote:
> yes,java is good lang,but i dont think it's better than c#,if no oracle or google support java will less and less.
> C# is a good and easy lang.
> i like C# .

Not sure what do you mean. D has classes, interfaces and foreach, that should be enough to make a C#.

On Sunday, 15 March 2015 at 14:58:54 UTC, Idan Arye wrote:
>
> Even if we can't get the lambdas as syntax tress, the fact that we can send whatever types we want to the delegates and overload operators and stuff means we can still convert the lambdas into SQL.

There are limitations on operator overloading that make it much less likely you can use the exact same lambdas for collections and sql. Bad for testability.

> At any rate, I really don't like what C# did with LINQ-to-SQL. The whole special-syntax to functional-style to syntax-tree to SQL is too overcomplicated - a simply lisp-style macro system(like what they have in Scala or Rust) could have done the trick in a simpler and faster way.

overcomplicated? probably - it's microsoft. And any time I have to manipulate the ASTs I find myself wishing for a language with pattern matching. I wonder if F# offers anything in that regards..

On Monday, 16 March 2015 at 12:18:42 UTC, Ellery Newcomer wrote:
> On Sunday, 15 March 2015 at 14:58:54 UTC, Idan Arye wrote:
>>
>> Even if we can't get the lambdas as syntax tress, the fact that we can send whatever types we want to the delegates and overload operators and stuff means we can still convert the lambdas into SQL.
>
> There are limitations on operator overloading that make it much less likely you can use the exact same lambdas for collections and sql. Bad for testability.
>
>> At any rate, I really don't like what C# did with LINQ-to-SQL. The whole special-syntax to functional-style to syntax-tree to SQL is too overcomplicated - a simply lisp-style macro system(like what they have in Scala or Rust) could have done the trick in a simpler and faster way.
>
> overcomplicated? probably - it's microsoft. And any time I have to manipulate the ASTs I find myself wishing for a language with pattern matching. I wonder if F# offers anything in that regards..

I don't think the problem is the lack of pattern matching. I think the problem is that by forcing the query syntax into lambda expression syntax, you obfuscate the syntax tree without really gaining any value.

On Saturday, 14 March 2015 at 23:46:28 UTC, Ellery Newcomer wrote:
> On Saturday, 14 March 2015 at 13:52:13 UTC, Craig Dillabaugh wrote:
>>
>> I don't have any C# experience so I can't compare those languages much, but I've heard people say their are D / C# similarities.
>>
>> Anyway, this isn't a criticism of your comment, I was just curious what (other than the shared C++ syntax heritage) you find so Java-like in D?
>>
>> Cheers,
>>
>> Craig
>
> I've been using C# pretty extensively for the last year or so. Superficially, at least, C# and D are pretty similar, eg auto (var), foreach, lambdas, classes and structs. C# is more biased towards OO than D.
>
> Metaprogramming is significantly weaker in C#. This is probably the one area where I've wished for some of D's functionality.
>
> Reflection is all runtime.
>
> C# has some AST capabilities that D doesn't. This is probably the main area where I envy C# when using D.
>
> And C# has LINQ, which when combined with the last point is fricken awesome.

You should give C# a try, its actually great. The only thing that holds me back is that its maintained by microsoft, Multi Platform support is sub par, and it cant be targeted towards other architectures.

On Monday, 16 March 2015 at 13:24:28 UTC, Idan Arye wrote:
> I don't think the problem is the lack of pattern matching. I think the problem is that by forcing the query syntax into lambda expression syntax, you obfuscate the syntax tree without really gaining any value.

Where takes a delegate because that's how it works: https://msdn.microsoft.com/en-us/library/vstudio/system.linq.enumerable.where.aspx

On Tuesday, 17 March 2015 at 10:07:19 UTC, Kagamin wrote:
> On Monday, 16 March 2015 at 13:24:28 UTC, Idan Arye wrote:
>> I don't think the problem is the lack of pattern matching. I think the problem is that by forcing the query syntax into lambda expression syntax, you obfuscate the syntax tree without really gaining any value.
>
> Where takes a delegate because that's how it works: https://msdn.microsoft.com/en-us/library/vstudio/system.linq.enumerable.where.aspx


The version of where that works on .NET objects takes a delegate - but the version used to generate SQL takes an `Expression` - https://msdn.microsoft.com/en-us/library/vstudio/bb535040%28v=vs.110%29.aspx