var is useful when used with factory functions. Makes changing the type returned by your factory function much easier if all the calls use "var x = MyFactory.GetConnection("foo");" Otherwise you may find yourself replacing 3000 SqlConnection declarations with DbConnection as we had to do.
"pinpoints the origin of weaker bones at the beginning of the Holocene epoch roughly 12,000 years ago, when humans began adopting agriculture". This doesn't have anything to do with tractor farming.
You can spin up Windows servers and sql server instances in AWS. And other commercial products, like HANA. So cloud providers certainly do track licenses. It's baked into the price you pay for those instances.
Why are you locked in? If you have web services calling web services it doesn't really matter what a web service is written in. There are some nice.net platforms that don't come from MS, like ServiceStack or Nancy. Even the MS Mvc.Net platform is mono compatible (and was already open source) so you can run Linux with docker running 6 instances of your service.
Depends on what you mean. We don't use linq to sql because you're not sure of the sql you'll generate. Linq to objects is quite nice. Joining two lists of objects in memory automatically rather than writing your own low level code to copy things over is awesome.
You don't actually. That's the point of open sourcing.net core, to really beef up mono. MS has a strong commitment to supporting mono, especially in vNext. You can write C# to target mono, ios, and android and ignore Windows deployment entirely
Which is probably more important than anything else. The benefit of open sourcing.net core is that mono will get better. So if you have a lot of existing.net code and want to get away from ms licensing, at least ms will keep the dev tool revenue.
Depends on your context a bit. When dealing with automatically binding form fields to a view model like with an MVC.net project the convenience and speed pay off handsomely, even at the cost of having to have your form fields and properties identically named.
The syntactic overhead in C# is at least lighter than Java/C++. It's just Foo.Bar == 'something' or Foo.Bar = 'thing', you just have to declare Bar with a {get; set; }
No good reason I shouldn't be able to shoot laser beams out of my eyes either. But I can neither change how an attribute is accessed in Java/.Net nor shoot laser beams out of my eyes.
About the only thing a getter and setter offers is an advantage of doing something before / after accessing the variable for a read / write operation... which breaks the objected oriented mentality.
How does it do that? A form might pass over [date] [time] [timezone] and my object might have [utc_datetime]. The setters for date, time, and timezone set private variables that i don't care about individually. And my getter for utc_datetime will stick date and time together, then look at the timezone and the date and figure out what amount of hours to add or subtract, and return the utc_datetime. But only in cases where the calling code actually ends up requesting it. Otherwise that calculation can be skipped.
Slashdot Mirror
Who's doing anti GLBT hate crimes in DC? It's not white male techies.
I make all my coffee decisions based on the company's IT department. Glad to meet someone else who feels the same
"You're standing on the surface of the Earth." There's no reason to think that you need to be standing on dirt, just on the surface of planet Earth
var is useful when used with factory functions. Makes changing the type returned by your factory function much easier if all the calls use "var x = MyFactory.GetConnection("foo");" Otherwise you may find yourself replacing 3000 SqlConnection declarations with DbConnection as we had to do.
Bitnami rocks. Lots of different stacks to pick from: plain LAMP, different CMSs, OSQA, all kinds of goodies
Agreed. If the site was developed in it/web I'll pass. It's easy to avoid browser problems by making everything look like is 1996
"It never comes true and it never is going to come true.". It apparently happened 12,000 years ago
"pinpoints the origin of weaker bones at the beginning of the Holocene epoch roughly 12,000 years ago, when humans began adopting agriculture". This doesn't have anything to do with tractor farming.
You can spin up Windows servers and sql server instances in AWS. And other commercial products, like HANA. So cloud providers certainly do track licenses. It's baked into the price you pay for those instances.
Why are you locked in? If you have web services calling web services it doesn't really matter what a web service is written in. There are some nice .net platforms that don't come from MS, like ServiceStack or Nancy. Even the MS Mvc.Net platform is mono compatible (and was already open source) so you can run Linux with docker running 6 instances of your service.
I didn't realize you didn't have to declare runtime errors, sorry.
Depends on what you mean. We don't use linq to sql because you're not sure of the sql you'll generate. Linq to objects is quite nice. Joining two lists of objects in memory automatically rather than writing your own low level code to copy things over is awesome.
Because you know ahead of time all the possible things that can go wrong in your method?
C# can compile to android apps and ios apps now too. It's not just a server world any more.
Visual studio, xamarin studio, and some of the java IDEs are in the latest jolt ide awards. They're all generally recognized as good.
This is why it bums me out that my company is spending so much developer time trying to move off of ms languages.
You don't actually. That's the point of open sourcing .net core, to really beef up mono. MS has a strong commitment to supporting mono, especially in vNext. You can write C# to target mono, ios, and android and ignore Windows deployment entirely
Which is probably more important than anything else. The benefit of open sourcing .net core is that mono will get better. So if you have a lot of existing .net code and want to get away from ms licensing, at least ms will keep the dev tool revenue.
Why? CDN companies like Akamai spend huge amounts on their server networks, and they are already local to you.
App inventor from MIT labs lets you preview on your actual mobile device.
Intellisense *almost* works flawlessly. The times when it doesn't show properties that I know exist drive me bananas.
The unit testing changes from VS 2010 to VS 2012 were quite confusing and a big step down in usability. Wasn't even at an ok level until update 2.
Depends on your context a bit. When dealing with automatically binding form fields to a view model like with an MVC .net project the convenience and speed pay off handsomely, even at the cost of having to have your form fields and properties identically named.
The syntactic overhead in C# is at least lighter than Java/C++. It's just Foo.Bar == 'something' or Foo.Bar = 'thing', you just have to declare Bar with a {get; set; }
No good reason I shouldn't be able to shoot laser beams out of my eyes either. But I can neither change how an attribute is accessed in Java/.Net nor shoot laser beams out of my eyes.
About the only thing a getter and setter offers is an advantage of doing something before / after accessing the variable for a read / write operation... which breaks the objected oriented mentality.
How does it do that? A form might pass over [date] [time] [timezone] and my object might have [utc_datetime]. The setters for date, time, and timezone set private variables that i don't care about individually. And my getter for utc_datetime will stick date and time together, then look at the timezone and the date and figure out what amount of hours to add or subtract, and return the utc_datetime. But only in cases where the calling code actually ends up requesting it. Otherwise that calculation can be skipped.