I work on a pretty huge C# code base. Use of LINQ is the least of it's problems. If anything I'd say one problem is people not knowing about things like lambda expressions, linq, generics or whatever. It can really make code harder to parse when it's written in ways that don't take advantage of the full power of the platform.
How much of that C# code pre-dates the availablilty of those features?
Some of the code was certainly written before those features was available, especially some C# 4 features. I'm sure someone might look at my code someday and wonder why I didn't use async and await. I'm talking about code written today though.
As languages go, C# may be the ultimate "middle ground" because it really excels and providing a middling implementation of [your-favorite-language-feature]. That is, if you're a functional programming enthusiast, you can do a lot of functional programming in C#. Sure, it's often more painful than haskell or lisp or F#, but it's workable. If you're a dynamic programming enthusiast, C# has a perfectly workable (but ul…
Sorry, but you're really attacking a straw man here. Neither C# itself nor the OP's article sell C# as being a prime language for functional, dynamic, or systems programming. Rather, it has inherited some convenient little bits of each paradigm to make the language that much nicer to write. For example, don't want to redeclare that "List >" you're copying over because it has a scope of 2 lines? Just dynamically type…
"var" is not dynamic typing. It's just a way to enable type inference - it's still as static as can be. It also has a very limited useful scope in C#, as type inference isn't supported in most areas.
Sorry, but you're really attacking a straw man here. Neither C# itself nor the OP's article sell C# as being a prime language for functional, dynamic, or systems programming. Rather, it has inherited some convenient little bits of each paradigm to make the language that much nicer to write. For example, don't want to redeclare that "List >" you're copying over because it has a scope of 2 lines? Just dynamically type…
"var" is not dynamic typing. It's just a way to enable type inference - it's still as static as can be. It also has a very limited useful scope in C#, as type inference isn't supported in most areas.
There is only one place where the type inferencing is not supported, field declarations. Not sure how that became "most areas".
Sigh . Okay, let's play this game. 1. "Cutting edge", first thing listed is asynchronous programming. Okay, don't get me wrong, I like C#, I like the Task Parallel Library, but Grand Central Dispatch in OS X/iOS is beautifully simple and incredibly powerful. It does everything I need it to do. 2. "Powerful features" - OOP. Really? And Java/Objective-C don't support OOP/encapsulation? You can't do dependency injection…
I like MonoTouch so far but I must admit these are all valid points. There are more downsides Xamarin doesn't like to advertise, like problems with AOT compiler you can't anticipate until they bite you in the ass, the-GC-won't-collect-some-stuff problems that basically force you to always dispose native objects manually, and horribly buggy IDE that MonoDevelop is.
I dont think I have your email address, but would love to share with you a tool I have been prototyping to identify the hard cycles in Objective-C that are causing the above leak problem.
In short, you should not need to manually Dispose, but you might need to use weak references from children to parents.
Sorry, but you're really attacking a straw man here. Neither C# itself nor the OP's article sell C# as being a prime language for functional, dynamic, or systems programming. Rather, it has inherited some convenient little bits of each paradigm to make the language that much nicer to write. For example, don't want to redeclare that "List >" you're copying over because it has a scope of 2 lines? Just dynamically type…
"var" is not dynamic typing. It's just a way to enable type inference - it's still as static as can be. It also has a very limited useful scope in C#, as type inference isn't supported in most areas.
You're right. The var keyword isn't dynamic typing. The dynamic keyword is though. dynamic C# 4.0 can do mixins, method missing, etc: http://amirrajan.net/Blog/dynamic-c-sharp
Sorry, but you're really attacking a straw man here. Neither C# itself nor the OP's article sell C# as being a prime language for functional, dynamic, or systems programming. Rather, it has inherited some convenient little bits of each paradigm to make the language that much nicer to write. For example, don't want to redeclare that "List >" you're copying over because it has a scope of 2 lines? Just dynamically type…
"var" is not dynamic typing. It's just a way to enable type inference - it's still as static as can be. It also has a very limited useful scope in C#, as type inference isn't supported in most areas.
I've long suspected that when programmers ask for dynamic typing, 95% of the time - or more - they are really trying to save FINGER typing, and not data typing.
This is perfectly fine and good - bookkeeping is one of those things that computers are good at.
As languages go, C# may be the ultimate "middle ground" because it really excels and providing a middling implementation of [your-favorite-language-feature]. That is, if you're a functional programming enthusiast, you can do a lot of functional programming in C#. Sure, it's often more painful than haskell or lisp or F#, but it's workable. If you're a dynamic programming enthusiast, C# has a perfectly workable (but ul…
Then why use C# over F#? F# has a more flexible dynamic system (provide your own implementation), better type inference, and even more unsafe access. So you lose nothing but goto and a bit of loop flexibility.
In theory, a better JIT could provide as-good-as-C output, but in practice you end up screwing around and ending up with less-than-optimal machine code. But F# actually provides an advantage here: inlining. The F# compiler can inline any function, whereas the JIT is somewhat limited in what it will inline. This makes a big difference, as the CLR JIT does a much better job optimizing inside one function than it does cross-function.
Sigh . Okay, let's play this game. 1. "Cutting edge", first thing listed is asynchronous programming. Okay, don't get me wrong, I like C#, I like the Task Parallel Library, but Grand Central Dispatch in OS X/iOS is beautifully simple and incredibly powerful. It does everything I need it to do. 2. "Powerful features" - OOP. Really? And Java/Objective-C don't support OOP/encapsulation? You can't do dependency injection…
LINQ is pretty sick and if obj-c has a similar feature I have never seen it.
Eh, disagree. It's confusing for a number of reasons, firstly because instead of choosing the common functional names -- map, filter, reduce, flatten, etc. they choose to go with SQL-like naming. Just an annoyance. Secondly, Expressions are a clever hack on top of the language, but they are not intuitive for the person using them and requires you to know too much about the particular implementation you are using (for example, if using Microsoft's ORM, string concantenation inside an Expression is disallowed). It's not their fault, C# isn't really functional, and Expressions allow them to make it look functional and have some laziness built in, but there are still enough gotchas that make using it a pain.
"var" is not dynamic typing. It's just a way to enable type inference - it's still as static as can be. It also has a very limited useful scope in C#, as type inference isn't supported in most areas.
There is only one place where the type inferencing is not supported, field declarations. Not sure how that became "most areas".
There are several other limitations. For instance, method signatures can't be inferred. In F#, you can write
member this.AddOne(i) = i + 1
and AddOne will be inferred to have the signature (int -> int).
There are plenty of other annoying restrictions, too, such as locals defined by lambdas.