tomkludy

I got the first battery replaced at just under the 3 year mark.

I had a friend with a 2012 Leaf that experienced similar degradation. It was a problem with the early model year and Nissan's choice to use passively cooled batteries.

Yes, the Leaf uses passive battery cooling as opposed to Tesla and others with active cooling. Their first-gen battery chemistry was also worse in hot climates. The newer battery is a different chemistry that has held up better.

The 2011/2012 Leafs had major problems with battery degradation in hot climates so much so that Nissan was forced to offer a free battery replacement. So I got it replaced for free. The newer battery is lasting better, but still not great. I think Nissan screwed up by sticking to passive battery cooling.

For reference I live in southern Florida so we have hotter than average climate.

I own a 2012 Nissan Leaf which has had major battery degradation (first battery went under 70% in only 33k miles, second battery currently around 85% at 45k miles = 78k miles total on both). But on this site, the 2012 Nissan Leaf has less than 2 years of data and shows zero degradation during that time. So it seems like the data is questionable.

Every discussion or article I have read on dependent types assumes that the reader is a mathematician. I usually make it only a few paragraphs in before I am completely lost.

Right now the only thing that seems clear is that dependent typing adds significant mental burden on the programmer to more thoroughly specify types, and to do so absolutely correctly. In exchange for that burden, there must be practical (not theoretical) benefits but they do not come through clearly. All of the examples I've seen are about "index of a list is guaranteed in bounds". That is such a minor and infrequent bug in practice that it does not justify the additional complexity. There must be more, that I'm just not seeing.

Is there a "Dependent types for non-mathematicians" article out there somewhere, where I can learn about patterns and practical applications?

I love this tool, have been using it obsessively on football sunday :)

Question (or suggestion): would it be possible to choose the desired outcome? By that I mean, my team (the Lions) is already in the playoffs, so all changes I make show 100's in all columns. But what I'm really trying to narrow down is whether they will win the division, or whether they will have home field advantage throughout. Perhaps once a team has met a particular goal (i.e. 100% chance of making the playoffs for example) the remaining games could be ranked vs. their percentage chance of reaching the next-higher goal?

I've been playing with it some. It's nice, but I still prefer Haskell. I want to be able to separate pure from impure code, but F# doesn't seem to enforce that. (Unless I'm missing something?)

I'd like something running on the CLR. Not because I think the CLR is very special; just because I really like Haskell but I have to work within a large ecosystem of existing .NET code.

Frankly, I've had to maintain a huge C++-only codebase, and that's why I hope to never write another app in C++.

Yours is an argument for a high-level, typesafe, compiled-to-native and compiled-to-javascript language. But IMO the argument falls down when applied to C++, because it is not high-level, it is only marginally typesafe, and it doesn't compile to javascript well at all (tradeoff of either massive performance, or missing basic functionality like 64 bit ints).

It is very possible that no language will fit this role exactly for some time to come. But, to me at least, it is very clear that C++ is NOT the language for the job.

IMO the root problem is that A) we have too many identities, B) those identities are rarely protected properly (sites don't hash/salt, don't have password expiration policies, don't use 2-factor auth), and C) managing those identities over time is nearly impossible.

I use lastpass, and it's great. But I didn't always use it; before I started, I used a couple of passwords everywhere. Recently some site which I haven't even used in years was compromised, and as a result, one of my "frequently used passwords" was potentially compromised. I had to spend hours going to dozens of websites and changing my password. Every site has a different way to change your password, and different policies for acceptable passwords, and most don't even make it easy/obvious.

I think something like Mozilla Persona is a good start, but not quite complete. Give me one, central place to manage my identity. The ability to control which sites have access to my identity. The ability to allow, or not allow, different sites to correlate my identity with each other. The ability to have my identity independent of my email address. Good two-factor auth for establishing identity, and good password management policies. Single-sign-on, even across independent sites, with just a click.

So the problem is that a proposal like this encourages people to do the wrong thing; i.e. ask me for a username and password - without two-factor auth, without considering whether I will be able to manage yet-another-password, without considering whether they should even be in the business of authentication themselves.

Wish I could leave a flower for G+

Unfortunately it is a zombie, dead but doesn't realize it yet.

MVC 4 also allows non-blocking IO. Mark your controller as "async" and use async calls within your controller method.

The evented IO model is nice, but nothing earth shattering. Same can again be accomplished with async IO calls, which are trivially easy in .NET 4.5.

I personally find those "helpful" things to be truly, well, helpful. For example the input validation, anti-forgery token validation, simple cache control, etc.

Again, not saying you can't do these things in node. The two technologies can easily accomplish the same goal. But if your primary concern is avoiding JS, why would you choose a technology that is built entirely upon it?

Node.cs might make more sense, I agree. I have a feeling the existing ecosystem might bring its own problems with the author's approach, because your C# code may have trouble integrating with those existing libraries, if the underlying generated code does not behave as the Javascript library expects.