619 karma · joined January 16, 2010
http://www.joegaudet.com http://www.matygo.com http://hackernewsers.com/users/joegaudet.html
Ask your self, how against the democratic platform do you need to be in order to justify affirming this guy?
Spoil your ballot.
http://stackoverflow.com/questions/20918650/what-are-the-ben...
IntelliJ is a pretty complete suite of a tools, a pleasure to use (has VIM mode too :P)
Set a breakpoint in the code, refresh the browser, and all the variables in the scope will be annotated with their value at break time.
This is really what you're after when you're println debugging - it has the advantage of showing you everything in a minimally intrusive way which is helpful when you don't know what you're looking for exactly.
A lot is an interesting question, especially given this (https://en.wikipedia.org/wiki/List_of_countries_by_military_...) which if you sort by percentage of GDP puts the US below Russia.
Is it that surprising that the country with far and away the highest GDP has the highest military spending in real dollars?
Really hard not to break Godwin's law here...
My thoughts go out to her and her family.
Really cool visualization of the missions.
One of the things I absolutely HATE about scala is operator overloading - and the excessive abuse of it. I ran into it just now using some library that used ==.
A Case:
List(1,2) == List(1,2); true Array(1,2) == Array(1,2); false
The reason for this is obvious, list implements equals and does a deep compare. While Array.equals is a pointer compare (like how java do).
This would be obvious in Java because that would look like.
ArrayList<> a = ArrayList<Int>(); ArrayList<> b = ArrayList<Int>(); a.equals(b); // equal because it's a value compare
versus
int[] a = new int[5] int[] b = new int[5] a == b; // obviously false because it's a reference compare.
The lack of a universal idea about what == means is pretty dangerous IMO.
*edited for spelling
We've been running scala in production for 4 years, and had our share of NPEs in our code and in the libraries we host. My point I guess was just that it's not entirely true that they will not boil to the surface on occasion.
One problem, which is also one of the advantages of scala is that the interop with Java often means that all your Option[] etc code can still get NPEed by some offending Java Lib you've decided to use.
As the fidelity and ubiquity of pure scala libs improves this will hopefully go away to a some extend.
Would be cool if we could do it for translucent toolbar etc.
Porting code written for VM a to VM b by some rubric hardly seems like a fair comparison.