Surely this should have been a plug-in for Kerbal Space Program. Fly your rocket in the game, order the real thing. Not holding my breath for same-day delivery though...
At that point, the ability to use this to replace DRAM becomes much more reasonable. If it were really just 1000x the writes of NAND, it would be far too short-lived to act as normal RAM... but if it's *really* the typical lifetime, things could get very interesting indeed...
Well, DateTimeOffset isn't a class to start with - it's a struct. But it's still not the panacea some people seem to think it is. There are plenty of situations where what you want *isn't* a DateTImeOffset. Its inclusion was definitely an *improvement* on the state of the date/time API in.NET (as was TimeZoneInfo, for sure) - but that doesn't mean it brings it up to a decent state, IMO.
"It either works or it doesn't" - or it works for all but one or two hours of the year, around a time zone transition. Or it works so long as you're in a time zone which doesn't skip 00:00 when it transitions forward by an hour. Or it works so long as you're not in time zone which skipped a whole day once. How sure are you that all your code works in all of those conditions? How *clear* is your code in terms of which values are meant to be local, which are meant to be in UTC, and which are meant to be local in some other time zone?
You say that date manipulation in.NET is really not hard - but I've seen an *awful* lot of subtly-broken code using DateTime, and even correct code isn't always *obviously* correct, mainly because `DateTime` doesn't represent one single concept.
I looked at the.NET DateTime functionality *very* hard before deciding to write Noda TIme - and now, 5 years later, I'm still convinced that it was the right thing to do.
Glad you've liked Noda Time - but if you could drop a line to the mailing list or raise an issue for any "Java-isms" you've found, I'd be grateful. I've tried to make it as idiomatic to.NET as I can, other than where doing so would be harmful.
I thought I'd get that in before too many other people do. I have better justification than most, as I *am* Jon Skeet. I saw the list yesterday, and we've been gently laughing about it at work.
Somewhere, the difference between fame and accomplishments has been lost. Don't get me wrong, I'm not a bad coder. I'm pretty knowledgeable about C# as a language, although details of writing *applications* in C# is a different matter. I'm pretty good at expressing technical concepts, and that's really useful in various contexts (Stack Overflow, books, screencasts, and of course work). But none of these are a patch on what some of the others on the list have accomplished.
As a Googler, I know a *bit* about what Jeff Dean and Sanjay Ghemawat have done - and it's obvious I'm not in the same league. The code I'm probably proudest of is Noda Time (my.NET date/time library) which has a few thousand users, if that. I hope I've had an impact everywhere I've worked, but it just isn't on the same scale as many of the other members of the list (let alone the many thousands of other notable programmers).
It's pretty clear I'm not actually on the list because of my coding skills - it's just due to Stack Overflow reputation. That indicates *something*, but it's definitely not the kind of measure you'd sensibly use to compare two programmers. Just as I'm proud of Noda Time, I'm proud of being able to help a lot of people on Stack Overflow - but I'm not under the delusion that even that's on the same level of impact as an awful lot of other coders.
For what it's worth, if I could substitute one other name for mine, it would be Eric Lippert. I'm not sure he's really be in the "top 14" or even whether that's meaningful - but I'd say he's at least *more* worthy of being there than I am.
It's not always "in your current time zone" - it depends on the "kind" of the DateTime. If you use DateTime.Now you will indeed get a value which is in your current system time zone. And I think you meant either DateTime.UtcNow or DateTimeOffset.UtcTicks rather than DateTime.UtcTicks...there's no such property as DateTime.UtcTicks.
When it comes to using the system time zone, It's not about "those iron age societies" using daylight saving - it's more about DateTime basically always representing some sort of "local" date, either in your local time zone, UTC, or an unspecified time zone. That's a very broken design, but not (IMO) in the way that you claim it to be.
Likewise it's entirely reasonable IMO to ignore "the" Julian/Gregorian shift in 1752, partly as it happened in different years depending on the place(and Sweden is particularly strange in this regard). All kinds of aspects of a date/time become weird if you swtch calendar system - and the DateTime type *only* represents the Gregorian calendar system. (If you give it a different one in the constructor, it effectively translates the value into the Gregorian calendar.) Again, I view that as a broken design - but not because of "the" 1752 shift.
So yes, there are plenty of valid criticisms of.NET's date/time handling, but yours didn't quite hit the mark for me.
The support for date and time handling in.NET is deplorable too, in my view. If it weren't, I wouldn't have bothered to create the Noda Time library (http://nodatime.org) which I'd like to think does a rather better job.
There's an obvious potential correlation between high scores and plenty of questions being available though.
Hitting the rep cap (200) each day is relatively straightforward, which leaves only accepted answers (and bounties). If there aren't many questions in your area of expertise, you could easily end up with only 260 per day despite being incredibly savvy.
I'm lucky that my two areas of "reasonable competence" (I wouldn't quite go as far as expertise) are Java and C#, both of which have plenty of questions available. Whilst there's obviously more competition in those topics too, it's a fairly "target rich environment" so to speak.
Can I ask how much experience you actually have of LINQ, and which aspects of it (which providers etc)? Which area of performance are you talking about?
I have a certain amount of LINQ experience, and all I see is it making me more productive, with little to no performance hit. (Yes, separating out projection from filtering etc is a little more expensive than hardcoding it all in one foreach statement, but not significantly - and the resulting code is *much* cleaner.)
My thoughts exactly. Was this a case of 19,000 pencils and then a few PCs?
Re:C# isn't a language...
on
Head First C#
·
· Score: 1
From C# 2: o There's nothing directly like iterator blocks in Java. If you want to implement Iterable/Iterator, you're on your own. Furthermore, there's no safe way of using non-memory resources in an iterator.
o Java generics are very poor compared with those in.NET.
o Anonymous methods are much leaner and more flexible than anonymous inner classes. That's why there's so much discussion about how to bring closures to Java 7:)
o Nullable value types don't exist in Java (we're not talking autoboxing here). Of course, Java doesn't have user-defined value types in the first place...
o Partial types don't exist in Java at all
C# 3 introduces a whole raft of new features. The links were only very brief introductions to the new features. C# 3 *definitely* allows more readability than Java. I know both languages pretty well, and now that I'm back to writing Java commercially, I really miss the expressiveness of C# 3.
I take two laptops to work every day - my company one, and my Eee (which I'm using to write this post). I don't want to use my company one on the train for various reasons, hence the need for a second one. So, space and weight is at a premium.
Given that most of my time on the train is spent browsing or blogging rather than doing anything *hugely* taxing, I don't mind having a lower power machine.
My current Eee is a 701G, but I may well treat myself to a 1000 some time next year, mostly for the larger screen but also for the improved battery life and more power when I want it.
C# is gaining features much faster than Java, and there are no signs of slowing down.
Agreed on the first part, but not the second. The C# team have acknowledged that they certainly can't keep adding features at the rate of the last few years. C# 3->4 is likely to be a much smaller change than 1->2 or 2->3.
Of course, aside from language there's the matter of libraries/technologies - MS has released vast amounts of technology in the past few years, and it's really too much to keep up with completely. I think we'll see more and more specialization. That's not necessarily a bad thing, and some of the technologies themselves are great - but it is a concern.
Hence my comments of "and no need for an explicit break".
(Not that you always have to have a break, of course - you just have to make sure that the end of the case isn't reachable.)
Jon
Re:Another recipe book
on
Head First C#
·
· Score: 1
Oh dear:
"Reference types, like objects and arrays, are passed by reference." (P67)
Any book propagating that myth instead of explaining reality (the references are passed by value, which is a different thing) gets little respect from me, I'm afraid. There's a *bit* of explanation on P75, but not enough - and when talking about "ref" it explicitly talks about using it for value types, as if it can't be used for reference types:(
(Yes, I went looking for that specifically. I've found that checking how a book describes parameter passing is quite a good first step for judging its accuracy/quality.)
Still, nice to have a free ebook available, I'll admit.
I use 2.0, so the extension method thing doesn't effect me (or at least doesn't yet).
Fair enough.
I rarely, if ever, use enums
Perhaps that's because they're so weak in C#? Being able to specify behaviour (and state - though usually immutable) makes them so much more appealing in Java.
and I've never had a problem with immutable types
The problem is that the compiler doesn't help you with them. It doesn't help you to write them (and prove you've done it correctly); it doesn't help you to implement simple equality/hashing except for anonymous types; there's no way in.NET of declaratively marking a type as immutable to make it clear at a glance to both developers and tools. Oh, and C# 3's object initializers aren't really designed to work with immutable types:(
I do understand what you mean with the switch/case thing. Who the hell decided that requiring a break for each case was a good idea? What's wrong with designing some cases to fall through into the next case?
Ironically, that one piece is what they got right IMO. If you really want fall through, just use "goto" to do it explicitly. However, I'd have preferred a mandatory block for each case (aside from multiple cases for the same block, if you see what I mean) and no need for an explicit break. Introducing a new block would also help with variable scoping. However, there are other things I would like to see improved, like pattern matching (see Scala, Groovy, F# etc).
Jon
Re:C# isn't a language...
on
Head First C#
·
· Score: 2, Informative
Um, the features listed by my post's parent.
I don't have time to describe them all in detail here (or, more importantly, how they can improve readability of code) but here are a couple of URLs which give a bit more information:
In what way? Bear in mind that the question was about the language rather than the.NET framework. Certainly some parts of the framework are Windows-biased - but the language itself isn't.
but that's about all I find wrong with it.
Oh there are things wrong with C#, undoubtedly. Or at least things I'd change. For starters:
Making methods sealed by default is a good start. Classes should be sealed by default too though.
More support for immutability would be very welcome.
C# enums are just named numbers. Java has a much more OO way of working with enums, although there are rough edges there which could be improved too.
switch/case could be significantly improved.
The way extension methods are discovered by the compiler in C# 3 is really bad. A separate directive (e.g. "using static") which works with classes rather than whole namespaces would improve matters a lot.
There's more, but that's a start. Having said all this, it's still my favourite language at the moment. Any language you can't see flaws in is probably a language you don't know well enough;)
Re:C# isn't a language...
on
Head First C#
·
· Score: 2, Insightful
Mandatory generics, iterator yield, implicitly typed variables, 'object initializers', extension methods, embedding C++ and SQL directly into the code, operator overloading, implicit conversions, conditional compilation, etc -- none of those C# features actually helps you write better programs, and a lot of the so-called improvements in C# just make it a complicated mess.
I couldn't disagree more. Leaving aside your mischaracterisation of LINQ as "embedding SQL directly into the code" all of these features can *hugely* improve the readability of code.
Having used both Java and C# extensively, I know which language I prefer by a long chalk. Happily Java 7 will (eventually) gain at least some of the nice features of C#, but unfortunately not all - and it won't get rid of checked exceptions...
I now use Java professionally, but I'm constantly missing the features of C# which consistently allow me to write readable, reliable code.
Given that Peter Sestoft was Beta tester on C# 2.0 you can take it for granted that the book covers C# 2.0 as it was at the time of release.
No it doesn't. The behaviour for boxing changed after the book was published. It was changed in the the August 2005 CTP, I believe.
C# 2.0 was finally released as part of.NET 2.0 in November 2005, over a year after the book was published - which means it's more likely to be about 15 months since the final copy was written.
If you find anything that is inaccurate in the book I am sure the author would appriciate the feedback:-)
I suspect the authors aren't that bothered at this point, given that the book is coming up to being 4 years old.
Mind you, judging by the table of contents, there's very little about nullable types - the chapter looks like it's only two pages long. That's not going to be enough to cover lifted operators and conversions, boxing etc.
Slashdot Mirror
Surely this should have been a plug-in for Kerbal Space Program. Fly your rocket in the game, order the real thing. Not holding my breath for same-day delivery though...
At that point, the ability to use this to replace DRAM becomes much more reasonable. If it were really just 1000x the writes of NAND, it would be far too short-lived to act as normal RAM... but if it's *really* the typical lifetime, things could get very interesting indeed...
Well, DateTimeOffset isn't a class to start with - it's a struct. But it's still not the panacea some people seem to think it is. There are plenty of situations where what you want *isn't* a DateTImeOffset. Its inclusion was definitely an *improvement* on the state of the date/time API in .NET (as was TimeZoneInfo, for sure) - but that doesn't mean it brings it up to a decent state, IMO.
"It either works or it doesn't" - or it works for all but one or two hours of the year, around a time zone transition. Or it works so long as you're in a time zone which doesn't skip 00:00 when it transitions forward by an hour. Or it works so long as you're not in time zone which skipped a whole day once. How sure are you that all your code works in all of those conditions? How *clear* is your code in terms of which values are meant to be local, which are meant to be in UTC, and which are meant to be local in some other time zone?
You say that date manipulation in .NET is really not hard - but I've seen an *awful* lot of subtly-broken code using DateTime, and even correct code isn't always *obviously* correct, mainly because `DateTime` doesn't represent one single concept.
I looked at the .NET DateTime functionality *very* hard before deciding to write Noda TIme - and now, 5 years later, I'm still convinced that it was the right thing to do.
Glad you've liked Noda Time - but if you could drop a line to the mailing list or raise an issue for any "Java-isms" you've found, I'd be grateful. I've tried to make it as idiomatic to .NET as I can, other than where doing so would be harmful.
What has Eric Lippert done, as far as programming?
A lot of work on the C# compiler, while he was still working for Microsoft.
I thought I'd get that in before too many other people do. I have better justification than most, as I *am* Jon Skeet. I saw the list yesterday, and we've been gently laughing about it at work.
Somewhere, the difference between fame and accomplishments has been lost. Don't get me wrong, I'm not a bad coder. I'm pretty knowledgeable about C# as a language, although details of writing *applications* in C# is a different matter. I'm pretty good at expressing technical concepts, and that's really useful in various contexts (Stack Overflow, books, screencasts, and of course work). But none of these are a patch on what some of the others on the list have accomplished.
As a Googler, I know a *bit* about what Jeff Dean and Sanjay Ghemawat have done - and it's obvious I'm not in the same league. The code I'm probably proudest of is Noda Time (my .NET date/time library) which has a few thousand users, if that. I hope I've had an impact everywhere I've worked, but it just isn't on the same scale as many of the other members of the list (let alone the many thousands of other notable programmers).
It's pretty clear I'm not actually on the list because of my coding skills - it's just due to Stack Overflow reputation. That indicates *something*, but it's definitely not the kind of measure you'd sensibly use to compare two programmers. Just as I'm proud of Noda Time, I'm proud of being able to help a lot of people on Stack Overflow - but I'm not under the delusion that even that's on the same level of impact as an awful lot of other coders.
For what it's worth, if I could substitute one other name for mine, it would be Eric Lippert. I'm not sure he's really be in the "top 14" or even whether that's meaningful - but I'd say he's at least *more* worthy of being there than I am.
It's not always "in your current time zone" - it depends on the "kind" of the DateTime. If you use DateTime.Now you will indeed get a value which is in your current system time zone. And I think you meant either DateTime.UtcNow or DateTimeOffset.UtcTicks rather than DateTime.UtcTicks...there's no such property as DateTime.UtcTicks.
When it comes to using the system time zone, It's not about "those iron age societies" using daylight saving - it's more about DateTime basically always representing some sort of "local" date, either in your local time zone, UTC, or an unspecified time zone. That's a very broken design, but not (IMO) in the way that you claim it to be.
Likewise it's entirely reasonable IMO to ignore "the" Julian/Gregorian shift in 1752, partly as it happened in different years depending on the place(and Sweden is particularly strange in this regard). All kinds of aspects of a date/time become weird if you swtch calendar system - and the DateTime type *only* represents the Gregorian calendar system. (If you give it a different one in the constructor, it effectively translates the value into the Gregorian calendar.) Again, I view that as a broken design - but not because of "the" 1752 shift.
So yes, there are plenty of valid criticisms of .NET's date/time handling, but yours didn't quite hit the mark for me.
The support for date and time handling in .NET is deplorable too, in my view. If it weren't, I wouldn't have bothered to create the Noda Time library (http://nodatime.org) which I'd like to think does a rather better job.
Having a single type (well, two with DateTimeOffset) to represent all kinds of different concepts is simply a bad idea. See my rant about this for more details:
http://noda-time.blogspot.co.uk/2011/08/what-wrong-with-datetime-anyway.html
There's an obvious potential correlation between high scores and plenty of questions being available though.
Hitting the rep cap (200) each day is relatively straightforward, which leaves only accepted answers (and bounties). If there aren't many questions in your area of expertise, you could easily end up with only 260 per day despite being incredibly savvy.
I'm lucky that my two areas of "reasonable competence" (I wouldn't quite go as far as expertise) are Java and C#, both of which have plenty of questions available. Whilst there's obviously more competition in those topics too, it's a fairly "target rich environment" so to speak.
From the summary: "in fear of being on the brink of another nuclear [sic] WAR."'
From the article: "in fear of being on the brink of another nucliar [sic] WAR".
It would help if posters didn't correct spelling for words which are followed by [sic].
Joe Duffy (of the .NET Parallel Extensions team) has an excellent book due to be published very soon:
Concurrent Programming on Windows
Can I ask how much experience you actually have of LINQ, and which aspects of it (which providers etc)? Which area of performance are you talking about?
I have a certain amount of LINQ experience, and all I see is it making me more productive, with little to no performance hit. (Yes, separating out projection from filtering etc is a little more expensive than hardcoding it all in one foreach statement, but not significantly - and the resulting code is *much* cleaner.)
My thoughts exactly. Was this a case of 19,000 pencils and then a few PCs?
From C# 2:
o There's nothing directly like iterator blocks in Java. If you want to implement Iterable/Iterator, you're on your own. Furthermore, there's no safe way of using non-memory resources in an iterator.
o Java generics are very poor compared with those in .NET.
o Anonymous methods are much leaner and more flexible than anonymous inner classes. That's why there's so much discussion about how to bring closures to Java 7 :)
o Nullable value types don't exist in Java (we're not talking autoboxing here). Of course, Java doesn't have user-defined value types in the first place...
o Partial types don't exist in Java at all
C# 3 introduces a whole raft of new features. The links were only very brief introductions to the new features. C# 3 *definitely* allows more readability than Java. I know both languages pretty well, and now that I'm back to writing Java commercially, I really miss the expressiveness of C# 3.
Someone who wants a small form factor. Like me.
I take two laptops to work every day - my company one, and my Eee (which I'm using to write this post). I don't want to use my company one on the train for various reasons, hence the need for a second one. So, space and weight is at a premium.
Given that most of my time on the train is spent browsing or blogging rather than doing anything *hugely* taxing, I don't mind having a lower power machine.
My current Eee is a 701G, but I may well treat myself to a 1000 some time next year, mostly for the larger screen but also for the improved battery life and more power when I want it.
Try deserializing your object in Java or Python later... or easily adding more fields to it and still being able to deserialiize old files.
(And if you want C# support, just wait a while. I'll see what I can do - and frankly if I don't do it, I'm sure someone else will.)
Jon
C# is gaining features much faster than Java, and there are no signs of slowing down.
Agreed on the first part, but not the second. The C# team have acknowledged that they certainly can't keep adding features at the rate of the last few years. C# 3->4 is likely to be a much smaller change than 1->2 or 2->3.
Of course, aside from language there's the matter of libraries/technologies - MS has released vast amounts of technology in the past few years, and it's really too much to keep up with completely. I think we'll see more and more specialization. That's not necessarily a bad thing, and some of the technologies themselves are great - but it is a concern.
Hence my comments of "and no need for an explicit break".
(Not that you always have to have a break, of course - you just have to make sure that the end of the case isn't reachable.)
Jon
Oh dear:
"Reference types, like objects and arrays, are passed by reference." (P67)
Any book propagating that myth instead of explaining reality (the references are passed by value, which is a different thing) gets little respect from me, I'm afraid. There's a *bit* of explanation on P75, but not enough - and when talking about "ref" it explicitly talks about using it for value types, as if it can't be used for reference types :(
(Yes, I went looking for that specifically. I've found that checking how a book describes parameter passing is quite a good first step for judging its accuracy/quality.)
Still, nice to have a free ebook available, I'll admit.
I use 2.0, so the extension method thing doesn't effect me (or at least doesn't yet).
Fair enough.
I rarely, if ever, use enums
Perhaps that's because they're so weak in C#? Being able to specify behaviour (and state - though usually immutable) makes them so much more appealing in Java.
and I've never had a problem with immutable types
The problem is that the compiler doesn't help you with them. It doesn't help you to write them (and prove you've done it correctly); it doesn't help you to implement simple equality/hashing except for anonymous types; there's no way in .NET of declaratively marking a type as immutable to make it clear at a glance to both developers and tools. Oh, and C# 3's object initializers aren't really designed to work with immutable types :(
I do understand what you mean with the switch/case thing. Who the hell decided that requiring a break for each case was a good idea? What's wrong with designing some cases to fall through into the next case?
Ironically, that one piece is what they got right IMO. If you really want fall through, just use "goto" to do it explicitly. However, I'd have preferred a mandatory block for each case (aside from multiple cases for the same block, if you see what I mean) and no need for an explicit break. Introducing a new block would also help with variable scoping. However, there are other things I would like to see improved, like pattern matching (see Scala, Groovy, F# etc).
Jon
Um, the features listed by my post's parent.
I don't have time to describe them all in detail here (or, more importantly, how they can improve readability of code) but here are a couple of URLs which give a bit more information:
http://csharpindepth.com/Articles/General/BluffersGuide2.aspx
http://csharpindepth.com/Articles/General/BluffersGuide3.aspx
Shameless plug: for a lot more detail, read C# in Depth... (there are sample chapters available at http://manning.com/skeet)
It's very windows orientated
In what way? Bear in mind that the question was about the language rather than the .NET framework. Certainly some parts of the framework are Windows-biased - but the language itself isn't.
but that's about all I find wrong with it.
Oh there are things wrong with C#, undoubtedly. Or at least things I'd change. For starters:
There's more, but that's a start. Having said all this, it's still my favourite language at the moment. Any language you can't see flaws in is probably a language you don't know well enough ;)
Mandatory generics, iterator yield, implicitly typed variables, 'object initializers', extension methods, embedding C++ and SQL directly into the code, operator overloading, implicit conversions, conditional compilation, etc -- none of those C# features actually helps you write better programs, and a lot of the so-called improvements in C# just make it a complicated mess.
I couldn't disagree more. Leaving aside your mischaracterisation of LINQ as "embedding SQL directly into the code" all of these features can *hugely* improve the readability of code.
Having used both Java and C# extensively, I know which language I prefer by a long chalk. Happily Java 7 will (eventually) gain at least some of the nice features of C#, but unfortunately not all - and it won't get rid of checked exceptions...
I now use Java professionally, but I'm constantly missing the features of C# which consistently allow me to write readable, reliable code.
Given that Peter Sestoft was Beta tester on C# 2.0 you can take it for granted that the book covers C# 2.0 as it was at the time of release.
No it doesn't. The behaviour for boxing changed after the book was published. It was changed in the the August 2005 CTP, I believe.
C# 2.0 was finally released as part of .NET 2.0 in November 2005, over a year after the book was published - which means it's more likely to be about 15 months since the final copy was written.
If you find anything that is inaccurate in the book I am sure the author would appriciate the feedback :-)
I suspect the authors aren't that bothered at this point, given that the book is coming up to being 4 years old.
Mind you, judging by the table of contents, there's very little about nullable types - the chapter looks like it's only two pages long. That's not going to be enough to cover lifted operators and conversions, boxing etc.
Jon