HN user
I think the author means to say that it's kind of an all or nothing thing. You either go purely functional and get all the benefits, or you don't and barely get any benefits at all.
You could say that "almost functional" does not really exist, just like "almost secure" does not exist.
And yes, you can still program with a non-functional language just fine he does not refute that.
If anything, Haskell is based on lambda calculus. More particularly System F.
As in any lambda calculus, you can interpret the type system as a category where the objects are types and the arrows are functions. Classes like Functor and Monad are based on this interpretation.
Yes it's common to have software which can find plagiarism like that. However, if the student actually does these things (change all variable names and move code around) it will be hard for an examination board to decide whether this is a false positive or real plagiarism.
That's only for trains. For bus/metro/tram you only need 4 EUR on your card. See https://www.ov-chipkaart.nl/reizen/tarieven/instapenbasistar....
I think these results are fairly good. 'Just' some neuron loss at such doses. A lot of drugs can kill you if you take 20 times the recommended dose!
I'm surprised by the huge difference between those articles. Somehow i do find your article more believable. News outlets prefer to spin the story the other way because that kind of story is much more popular. It sheds light on a whole other side of what happened and i'm shocked to see how the posted article just lies about half of it.
Of course this is a sad story, no one should ever get hurt by drug violence, let alone a defenseless baby. But i think we should not rush our opinions on these things.
It's easy to get all emotional and be all upset when we read these things.
But we are supposed to be intellectuals right? We should not make judgements based on one sensationalist article. We can do better than that.
I think we should all just act a bit more rational. Don't make snap judgements. Read more about a subject before you condemn people.
In the end, i don't care what YOU think is the truth. Just make sure you know what you're talking about before you shout out your opinions.
PS: iambateman, this is not really meant for you of course ;)
People will probably misinterpret my post. In no way i mean to say that police and government don't share any blame. I'm definitely against the militarization of police. But i won't be sending money to that family either.
This idea of immutable infrastructure reminds me of NixOS [1]. A linux distribution where nearly the whole filesystem is immutable.
Definitely worth a look. I'm not sure if it's fit for production usage, but i think it's the future of operating systems :).
Make sure to watch the part before this video too: http://www.youtube.com/watch?v=ffwxaTpJTyI
I don't think the arrest was entirely unnecessary. The guy was really provoking the police right from the moment when he arrives. He knows he's messing with them and I think taking that dog out of the car was just another thing done to annoy them. He was asking for trouble and he got it.
Off course it's sad that the dog was shot. That was handled poorly. I guess people do stupid things in stressful situations where they don't have time to think.
A spelling error in the title is actually very easy to miss. You might read the main article an extra time before publishing, but the title is probably in a separate textfield which is not checked. It's always a bit painful to have a spelling error in the title, but don't make the assumption that the author just doesn't care enough.
Ah you're talking about the user comments under the article. Took me a few minutes to figure that out :)
Exactly. In a certain way, you could call jQuery UI effects a very limited physics engine.
I don't think the author is saying everyone should use a physics engine now. I think he means that we should use real-world physics as a guide to making more realistic animations, be it with a simple effects library or a full-fledged physics engine.
Simpler indeed. That's actually what stash does internally.
I usually don't make a separate branch, but just commit it in the current branch. Then you can rebase or amend later. You never need 'snapshot' if you know rebase -i.
This is the way that github recommends (https://help.github.com/articles/creating-project-pages-manu...).
A separate folder for the gh-pages branch makes sense because this branch has nothing in common with any of the other branches. It doesn't share any code or commits with your master branch.
The repository actually has two base commits and it's like two repositories contained in one. Thus needing two separate folders.
You make it sound like git is unsuitable for this, i disagree. I often use git for one-man projects, both with and without an external repository. Once you learn how to use it it works great. I would never want to return to svn/rsync/zip-files.
Yes. For the 0.7 chain, it's as if the 0.8 chain never happened. All transactions and all mining in that part of the chain is irrelevant now.
There's also referential transparency.
For programming languages, that means the result of a function is dependent on it's inputs ONLY. The function can not use any unspecified inputs like system time or an internal state.
In Nix, that means a package can only depend on dependencies which are specified beforehand. It's nearly impossible to use libraries or binaries which you did not specify.
That behavior makes it easier to reason about your whole system, like determining which packages are unused. This is similar to the advantages of referential transparency in functional languages
Yep S1 still exists. Nix does not do destructive updating. When you install or update a package, you'll always be able to revert to the previous state. The best explanation of that process can be found in the original paper:
Nix: A Safe and Policy-Free System for Software Deployment - http://www.st.ewi.tudelft.nl/~dolstra/pubs/nspfssd-lisa2004-...
I really hope nix will become standard practice, it has some significant advantages over existing package managers.
It fits in the Ruby philosophy and coding style to leave the `self.' out. But it might not be so evident for non-rubists.
Actually, new rubists might not even know that you can leave it out. In php you are required to use `$this->' for instance members.
Note that this is such a case where you've already got the pointer.
mdwrigh2 is totally right. I flipped the O(1) for linked list insertion with the O(n) for verctor insertion :).
I use emacs mode for bash, which is default on mac. Then i bind 'option cursor left' to \033b and 'option cursor right' to \033f. Voila, next and previous word using alt+arrow keys. Good enough for me :).
The author does an insertion sort in a linked list, of course that's going to be slow.
For a sorted insert you need to do 2 things: find the right spot for insertion and the insert itself. An insertion sort does this n times.
For a simple array/vector that's:
search: O(n)
insert: O(1)
total takes (O(n) + O(1)) x O(n) = O(n^2)
For a linked list:
search: O(n)
insert: O(n)
total takes (O(n) + O(n)) x O(n) = O(n^2)
There we go, the algorithm takes O(n^2) for both data structures. The theory already proves that a linked list has absolutely no advantage over an array when using this algorithm. On top of that, iterating over a linked list is slower than over an array for various reasons, even thought they are both O(n). So that's where the difference is coming from.
The example he uses is clearly a wrong use case for a linked list, it's plain wrong to conclude that the whole data structure should never be used.
I don't think this is unique to the US, and not unique to the last 10 years either.
Consider this: Of all the products made a 100 years ago, only 1% was made to last for a long time. Right now the other 99% is broken and thrown away and the 1% is still being used.
We only SEE old products which are well built. That doesn't mean all old products are that way.
There are still products being build which we can use for a long time, but they don't stand out and will only be noticed after a tens of years.