hmm? You wouldn't do it all in the -same app- though. Its just so you can use standard syntax and constructs to query data, without caring about its source (much). Whats strange with that? I'm probably misunderstanding something from your post.
LINQ to SQL isn't C# though. Its just a very very simple LINQ implementation like any other. And they're not technically killing it off, they're merging both it and the Entity Framework together.
I think evolving fast is a good thing, because it gives choice (you have many environments, some conservative, some not, and you pick whatever works for you), but the particular evolutions they are adding in C# 4.0 that you mentionned are crap. I was the first to post a big long rant on the developer blogs when it was announced. C# 3.0 has pretty much the perfect feature set, IMO... maybe enhancing a few existing features, but nothing drastic. Anything beyond that is just too much. I don't even see why they HAVE to add all that crap.. the.NET Framework was designed to support multiple languages exactly so we wouldn't need a single "Kitchen Sink" language.
The guy who designed C# is being pushed in the back kicking and screaming, because he didn't agree to these things... but the marketing department rules the world at MS, hehehe.
C++ is missing stuff at the core syntax level that templates won't help with. You need lambda expressions (which isn't yet part of C++), and extension methods to be able to tack on methods (with implementation) to some core interfaces (that I guess you could somewhat do with templates I guess, but it would be harder to make retroactive, but its possible, if messy). Then you need a compiler change to map the LINQ syntax sugar to these things so they're "understood".
Then, you need a way to be able to get the chain of Lambda expressions (a compile time syntax element) in a data structure that can be analyzed at runtime, dynamically, on the fly. Not something OO can help you with.
its non-trivial, and you can't change C/C++ on a whim. The C++ standards move SLOOOOOOOOOOOOOOW. Implementing something LINQ-like without compiler change can be done in dynamic languages that support lambda. You don't get the syntax sugar, but thats no big deal. In C++ though? No so easy.
o'reilly.NET books in general seem to be fairly awful. I have their design patterns with C# 3.0 book, which advertise itself as a book that takes the Gang of Four design patterns and show how they can be implemented better using built in C# 3.0 features (such as the observer pattern with delegates or events)
That sounds promising, except the author clearly fails to understand what C# 3.0 has to offer, and thus most of the book uses only C# 2.0 features (and explains them in great details, as if they were new). They also heavily misunderstand some of the patterns, which could mislead someone not familiar with the design patterns to begin with.
All around awful. So I'm not surprised about this one.
Your template wouldn't work for "tons of data structures". It would work for only one scenario -> collections/lists/arrays/objects/whatever.
If you do LINQ to XML, the LINQ expression tree has to be converted to efficient XML cursors (DOM is too slow). If you want to query relational databases, you need to translate it to, well, SQL. If you want to query a ldap, you need to convert it to an ldap query. If you want to query a REST dataservice, you need to convert it to a path + query strings. If you want to query a conceptual data model, you need to query it to something like the hibernate query language, Entity SQL, or equivalents.
All of these are completly different. Once you have the LINQ provider done though? The querying mechanism becomes all the same (well, almost, there are some implementation specific additions to each). It puts data as a "first class concept" (part of the language). Thats the innovation here.
Yes they do. Various versions depending on when the products were released (keep in mind.NET 3.5 is.NET 2.0 with a lot of extensions, its still.NET 2.0), so you have Windows Workflow in Biztalk and Sharepoint, Expression Blend is in WPF, of course, many of their own sites use Silverlight 2.0, etc etc etc..NET 3.5 is fairly recent, especially 3.5 SP1, so we don't see that -as much-, but.NET in general is fairly pervasive at MS.
People implement it left and right because its easy: its just one interface to implement (its not trivial, but its not hard either). Also, having something exposed as IQueryable (what you need to "implement LINQ") also allows you to expose it to ADO.NET Data Services, which is a huge time saver.
I don't see why you get "less maintainability for designers" though. Functional programming (which LINQ somewhat is) is a heck of a lot easier to maintain than the alternative.
Thats what I get for replying to a post when I just woke up... I had reread it like 5 times originally, and saw "power pc" everytime in the grandparent's post.
Well, considering its officially stated not to be supported on Power PC, what do you expect exactly? What are you going to try next? Install Mac software on a Windows machine?
Cars don't get anywhere close to 99.9%, since just a flat tire can take you out for a while, nevermind a broken transmition. If you need to let the car sit overnight, thats pretty much done for. And well over 50% of flights are delayed, even just 99% reliability is a pipe dream (i know you basically meant plane crashes, but still).
This is exactly like software piracy: As long as people pirate software, there's no need to change existing laws and reform the copyright system.
In the same way, as long as there's tons of illegal immigrants, there's no need(or its too hard to manage) to reform the immigration system to allow for people to come and pick cabbages legally.
If there were ZERO illegal immigration, you could easily put in place a bunch of special, easy-to-access Visas for situations like these... but instead, you have to spend all your efforts and energy making sure visas aren't abused, like how the work visa system is so corrupt.
Wouldnt how your site is ajax/js intensive be irrelevent when it comes to chrome compared to safari? The javascript engine isn't even the same, only the rendering engine is. So my CSS/XHTML issues do show up in both, but the javascript issues are totally different... The app I just finished today was an example of that: Safari wasn't part of the browsers required by the client, but when we tested for fun, it just happened to work. So did Opera (which we also hadn't tested). The javascript broke all kind of crazy on Chrome (even though the XHTML/CSS was working perfect), though (and not on browser-specific checks or anything like that).
You'd be surprised. I work for a fairly large company (several thousand employees). People at the head office have control on their machines. A large portion of them (many who barely know how to turn on their computer) downloaded and use Firefox, and many even Chrome!
But for the people in the outlets... their computers are locked down (very...locked down. For good reasons: if it breaks, someone needs to take a trip from the headoffice, thats time consuming and expensive), old, and purely controlled by the network administrators. Pushing IE is easy, though there are some machines on Win2k out there, so IE7 and above are no go. Pushing Firefox or others would be more difficult, for little gain (from a business perspective), even if users want it.
The consequence in the end is: I have to make our -internal- apps work in IE6/7, and only those. Not a good thing.
Then find us some good news. My in-laws are chinese (born in china, and extremely patriotic...or well, they used to be), and even they are having trouble, even though they work for a chinese newspaper that is known to be pro-mainland-china. Lately they seriously have issues finding good news. Nevermind Slashdot...
OpenID 2.0, on the other hand, is a disaster. Its architecture reeks of design-by-committee
Basically all open standards do, or eventually do, which is why many commercial entities decide to roll up their own. Yup, while definately many of the times when Microsoft did something like this WAS out of "evil", a large portion was for the same darn reason as this. There's VERY few open standards that aren't an insane mess of "I'll add your idea if you add mine" crap.
Yes, you can expose your service as WS-RM without it being actually reliable, which achieves pretty much nothing. I understand your point, and I guess my previous post was overly simplistic... but without the MSMQ support, enabling WS-RM is like filling the checklist of Section 508 without having a semantically acceptable page... it will "validate", but still be useless:)
You won't see a difference because pages are designed for slow browsers (IE6/7, FF2, etc). So they don't tap into the power of javascript as much as they could be, for performance reasons. You'll see the difference in a fully client side (aside for json REST service calls) javascript app made in ExtJS or similar toolkits (there's a few). Then performance matters.
Most likely. MSMQ actually works fine, and its still maintained (that is, they pop out a new version roughly with every version of Windows). Its also what they used under WCF to make for a WS-Reliable (is that the real name? I forget... the OASIS standard along with WS-I basic profile and others) compliant solution. Works decently well, too, and it interoperate quite fine.
Well, technically its not:: in Java, and C doesn't have namespaces. So -if- you consider PHP a mix of C/C++/Java (I wouldn't, but meh), it wouldn't fit all that good to use "::".
Java and.NET most definately have hashtables built in. My definition of "built in" means "can be used with the default libraries". And it is there, along with most data structures you'll ever need.
Thats all good. I personally feel its just easier to avoid PHP altogether and not have to adjust to all of the language's quirks for little to no benefits from other offerings. Simpler that way.
Slashdot Mirror
hmm? You wouldn't do it all in the -same app- though. Its just so you can use standard syntax and constructs to query data, without caring about its source (much). Whats strange with that? I'm probably misunderstanding something from your post.
LINQ to SQL isn't C# though. Its just a very very simple LINQ implementation like any other. And they're not technically killing it off, they're merging both it and the Entity Framework together.
I think evolving fast is a good thing, because it gives choice (you have many environments, some conservative, some not, and you pick whatever works for you), but the particular evolutions they are adding in C# 4.0 that you mentionned are crap. I was the first to post a big long rant on the developer blogs when it was announced. C# 3.0 has pretty much the perfect feature set, IMO... maybe enhancing a few existing features, but nothing drastic. Anything beyond that is just too much. I don't even see why they HAVE to add all that crap.. the .NET Framework was designed to support multiple languages exactly so we wouldn't need a single "Kitchen Sink" language.
The guy who designed C# is being pushed in the back kicking and screaming, because he didn't agree to these things... but the marketing department rules the world at MS, hehehe.
C++ is missing stuff at the core syntax level that templates won't help with. You need lambda expressions (which isn't yet part of C++), and extension methods to be able to tack on methods (with implementation) to some core interfaces (that I guess you could somewhat do with templates I guess, but it would be harder to make retroactive, but its possible, if messy). Then you need a compiler change to map the LINQ syntax sugar to these things so they're "understood".
Then, you need a way to be able to get the chain of Lambda expressions (a compile time syntax element) in a data structure that can be analyzed at runtime, dynamically, on the fly. Not something OO can help you with.
its non-trivial, and you can't change C/C++ on a whim. The C++ standards move SLOOOOOOOOOOOOOOW.
Implementing something LINQ-like without compiler change can be done in dynamic languages that support lambda. You don't get the syntax sugar, but thats no big deal. In C++ though? No so easy.
o'reilly .NET books in general seem to be fairly awful. I have their design patterns with C# 3.0 book, which advertise itself as a book that takes the Gang of Four design patterns and show how they can be implemented better using built in C# 3.0 features (such as the observer pattern with delegates or events)
That sounds promising, except the author clearly fails to understand what C# 3.0 has to offer, and thus most of the book uses only C# 2.0 features (and explains them in great details, as if they were new). They also heavily misunderstand some of the patterns, which could mislead someone not familiar with the design patterns to begin with.
All around awful. So I'm not surprised about this one.
Your template wouldn't work for "tons of data structures". It would work for only one scenario -> collections/lists/arrays/objects/whatever.
If you do LINQ to XML, the LINQ expression tree has to be converted to efficient XML cursors (DOM is too slow). If you want to query relational databases, you need to translate it to, well, SQL. If you want to query a ldap, you need to convert it to an ldap query. If you want to query a REST dataservice, you need to convert it to a path + query strings. If you want to query a conceptual data model, you need to query it to something like the hibernate query language, Entity SQL, or equivalents.
All of these are completly different. Once you have the LINQ provider done though? The querying mechanism becomes all the same (well, almost, there are some implementation specific additions to each). It puts data as a "first class concept" (part of the language). Thats the innovation here.
Yes they do. Various versions depending on when the products were released (keep in mind .NET 3.5 is .NET 2.0 with a lot of extensions, its still .NET 2.0), so you have Windows Workflow in Biztalk and Sharepoint, Expression Blend is in WPF, of course, many of their own sites use Silverlight 2.0, etc etc etc. .NET 3.5 is fairly recent, especially 3.5 SP1, so we don't see that -as much-, but .NET in general is fairly pervasive at MS.
People implement it left and right because its easy: its just one interface to implement (its not trivial, but its not hard either). Also, having something exposed as IQueryable (what you need to "implement LINQ") also allows you to expose it to ADO.NET Data Services, which is a huge time saver.
I don't see why you get "less maintainability for designers" though. Functional programming (which LINQ somewhat is) is a heck of a lot easier to maintain than the alternative.
Ignore my other post, since it seems like I can't read in the morning. That said, do you have Adblock installed?
Thats what I get for replying to a post when I just woke up... I had reread it like 5 times originally, and saw "power pc" everytime in the grandparent's post.
All I can say right now is... whoops.
Well, considering its officially stated not to be supported on Power PC, what do you expect exactly? What are you going to try next? Install Mac software on a Windows machine?
Cars don't get anywhere close to 99.9%, since just a flat tire can take you out for a while, nevermind a broken transmition. If you need to let the car sit overnight, thats pretty much done for. And well over 50% of flights are delayed, even just 99% reliability is a pipe dream (i know you basically meant plane crashes, but still).
This is exactly like software piracy: As long as people pirate software, there's no need to change existing laws and reform the copyright system.
In the same way, as long as there's tons of illegal immigrants, there's no need(or its too hard to manage) to reform the immigration system to allow for people to come and pick cabbages legally.
If there were ZERO illegal immigration, you could easily put in place a bunch of special, easy-to-access Visas for situations like these... but instead, you have to spend all your efforts and energy making sure visas aren't abused, like how the work visa system is so corrupt.
Wouldnt how your site is ajax/js intensive be irrelevent when it comes to chrome compared to safari? The javascript engine isn't even the same, only the rendering engine is. So my CSS/XHTML issues do show up in both, but the javascript issues are totally different... The app I just finished today was an example of that: Safari wasn't part of the browsers required by the client, but when we tested for fun, it just happened to work. So did Opera (which we also hadn't tested). The javascript broke all kind of crazy on Chrome (even though the XHTML/CSS was working perfect), though (and not on browser-specific checks or anything like that).
You'd be surprised. I work for a fairly large company (several thousand employees). People at the head office have control on their machines. A large portion of them (many who barely know how to turn on their computer) downloaded and use Firefox, and many even Chrome!
But for the people in the outlets... their computers are locked down (very...locked down. For good reasons: if it breaks, someone needs to take a trip from the headoffice, thats time consuming and expensive), old, and purely controlled by the network administrators. Pushing IE is easy, though there are some machines on Win2k out there, so IE7 and above are no go. Pushing Firefox or others would be more difficult, for little gain (from a business perspective), even if users want it.
The consequence in the end is: I have to make our -internal- apps work in IE6/7, and only those. Not a good thing.
Then find us some good news. My in-laws are chinese (born in china, and extremely patriotic...or well, they used to be), and even they are having trouble, even though they work for a chinese newspaper that is known to be pro-mainland-china. Lately they seriously have issues finding good news. Nevermind Slashdot...
Basically all open standards do, or eventually do, which is why many commercial entities decide to roll up their own. Yup, while definately many of the times when Microsoft did something like this WAS out of "evil", a large portion was for the same darn reason as this. There's VERY few open standards that aren't an insane mess of "I'll add your idea if you add mine" crap.
Yes, you can expose your service as WS-RM without it being actually reliable, which achieves pretty much nothing. I understand your point, and I guess my previous post was overly simplistic... but without the MSMQ support, enabling WS-RM is like filling the checklist of Section 508 without having a semantically acceptable page... it will "validate", but still be useless :)
You won't see a difference because pages are designed for slow browsers (IE6/7, FF2, etc). So they don't tap into the power of javascript as much as they could be, for performance reasons. You'll see the difference in a fully client side (aside for json REST service calls) javascript app made in ExtJS or similar toolkits (there's a few). Then performance matters.
Most likely. MSMQ actually works fine, and its still maintained (that is, they pop out a new version roughly with every version of Windows). Its also what they used under WCF to make for a WS-Reliable (is that the real name? I forget... the OASIS standard along with WS-I basic profile and others) compliant solution. Works decently well, too, and it interoperate quite fine.
Well, technically its not :: in Java, and C doesn't have namespaces. So -if- you consider PHP a mix of C/C++/Java (I wouldn't, but meh), it wouldn't fit all that good to use "::".
Java and .NET most definately have hashtables built in. My definition of "built in" means "can be used with the default libraries". And it is there, along with most data structures you'll ever need.
You mean, like in every dynamically typed language out there?
Is there any modern language that -doesn't- have a built-in hashtable and functions to manipulate them?
Thats all good. I personally feel its just easier to avoid PHP altogether and not have to adjust to all of the language's quirks for little to no benefits from other offerings. Simpler that way.
While at it, they should have picked a page from the W3C and made namespaces full, compliant URIs.
That would have been epic! /sarcasm.