81–90 of 125 posts
Earlier quoted context omitted.
Well, off the top of my head C# doesn't support mixins or multiple inheritance. You can get around the lack of mixins with extension methods and tight scoping but it's messy.
C#'s (and Java's) lack of multiple inheritance is a virtue, IMO.
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…
Earlier quoted context omitted.
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…
As to the names, I'm not sure it's safe to assume that "Map" would result in better usability than "Select", for MS's target audience.
And how would using C# help me deal with the fragmentation issue ?
Earlier quoted context omitted.
That is a false statement. dynamic C# 4.0 can do mixins: http://amirrajan.net/Blog/dynamic-c-sharp
so, yes this leveraging of dynamic metadata provider technically satisfies the requirements for a mixin, but you're still not applying this mixin to a poco, therefore i don't think it's fair to say the language/spec supports it natively. this is another example of adding mixins to .net code via 3rd party library: http://remix.codeplex.com/
Clarify?
Because we all know all the top-selling iPhone / Android apps do ship with an embedded SQL DB right!?
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…
Anyway, I'm sure others will point this out, but var is NOT dynamic typing. It's type inference, which you seem to know, judging by the last sentence in that paragraph. Dynamic typing doesn't just mean that no type is declared -- it means that no type is inferred (by the compiler).
Earlier quoted context omitted.
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.
Yes until we get to: List , string>>>
See also: "primitive obsession" http://c2.com/cgi/wiki?PrimitiveObsession http://sourcemaking.com/refactoring/primitive-obsession
"Async support as a first-class feature" - that's actually a flaw. C#'s async implementation would be better served by having e.g. a generic monad system that allows async to be done in a library. Instead, it's another baked-in compiler feature, like C#'s duck typing and LINQ's query operators. Calling it "cutting-edge" is an exaggeration, too.
While a bit of an aside, personally I find LINQ to have been a horrendous misstep in the evolution of the language. While the argument that it makes code more concise and easy to maintain holds in the small, once a project grows it becomes a terrible cancer -- everything becomes an amorphous blob of stuff, unintuitive, performance-disaster LINQ filters applied everywhere to bend it into shape.
I couldn't agree less. Any language construct can be abused, but LINQ is not particularly susceptible to abuse, unless you try very hard.