Also, +1 this is awesome.
@dang if you are here: HN should do this natively!
2,028 karma · joined October 3, 2009
- http://hackthology.com
- https://github.com/timtadh/
- https://twitter.com/timtadh/
- https://plus.google.com/u/0/109232399292705173597
- https://scholar.google.com/citations?user=n_se9mMAAAAJ
[ my public key: https://keybase.io/tadh; my proof: https://keybase.io/tadh/sigs/ec8yqyArGNcSDjXNT5rSoYRp-H0vMM3lxVmlY4bpcUQ ]
Also, +1 this is awesome.
@dang if you are here: HN should do this natively!
1. assumes the validity of the scientific method
2. relies on the scientific method as its critical lens
Whereas those who critique science as a whole:
1. assume that the scientific method does not work and does not arrive at "truth"
2. then use scientists being self critical to prove #1.
Such a "proof" does not work as there is its uses the assumption "the scientific method arrives at truth" to derive the contradiction "the scientific method does not arrive at truth". See for instance comment: https://news.ycombinator.com/item?id=16859200
In reality, work on reproducibility is about improving the practice of science overall. It does not in itself show that science is inherently untrustworthy. What it does show is that scientific discovery is difficult and it takes a lot of effort and new findings should be treated critically. What does critically mean in this context? It means with in the boundaries of science analyzing the theoretical basis, hypothesis, method, and experimental results for potential flaws. It does not mean to be skeptical as a default because science "doesn't work."
- https://github.com/timtadh/data-structures ## I wrote this one.
- https://github.com/Workiva/go-datastructures ## this one is also popular.
- https://github.com/golang/go/wiki/Projects#data-structures ## big list here.
As someone who has quite a few books on compilers, program analysis, type theory, etc... I find the Dragon book an irreplaceable reference to this day. It has a breadth of content shared by very few other books. For instance, Muchnick's classic "Advanced Compiler Design and Implementation" is really good for analysis and optimization but neglects all front end topics. The only area where I believe the Dragon book is inadequate in is type theory (I recommend Types and Programming languages [TAPL] by Pierce and Semantics with Application by Nielson for a gentler intro).
As to parsing, its chapter on parsing (4) is not as "hip" has some people want. However, it is solid and will teach you how to do parsing. There are newer and fancier techniques not covered in Chapter 4 but in general most people would benefit just having a solid understanding of recursive descent parsing!
In English (as I assume in Chinese) you can usually figure out what is being said in Shakespeare even if you don't know the exact definition of the word. You also can usually pronounce it correctly (at least for the modern pronunciation).
Different problems (and people) have different solution domains. For instance, the Union-Find algorithm [1] is straight forward to implement in an imperative language with mutation. It is significantly harder to achieve an optimal immutable version as demonstrated by a paper from 2007 [2].
There are real trade-offs between features in terms of what is easy to express. Your favorite way to program may be more difficult in Go. You think Go's features are in "poor taste." However, it is totally reasonable that different people with different problems might actually like the language. I myself have programmed in many other languages including SML and Scala and believe that for my current problems Go is a good fit.
That said, whenever I have to do even a little bit of numerical work (as I currently am doing) I miss a language with good numerical options (Python, R, Matlab, Julia, ...). Go stinks for numerical work and none of your criticisms have anything to do with why it stinks. Not having a nil pointer would not suddenly make Go a great language for numerical work.
Language choice is once again about trade-offs. I will happily take the trade-off of poor numerical support (less than 1% of my code) for concurrency primitives, compilation to native code, easy C integration, memory safety, and garbage collection. There are things to like about go and things to hate. I do hate the way errors are dealt with, poor support for writing collections, etc... But, just because I don't like those things doesn't mean it can't "get the job done."
[1] (https://en.wikipedia.org/wiki/Disjoint-set_data_structure)
1. There is are a lot, A LOT, of code regions that share similar constructions when analyzed in terms of dependencies. Dependencies only consider data flow and control dependencies. Where a statement X is control dependent on another statement Y (usually a if-condition or loop-condition) if Y decides whether X executes.
In my studies I have found modestly sized Java programs (~ 75 KLOC) have > 500 million patterns representing duplication in their dependence graphs.
2. Not all dependence structures which are "duplicate" would be considered duplicated by a human programmer [2]. It takes discernment by someone familiar with the code base to decide whether or not regions are actually duplicated.
I would argue you can draw similarities using automated metrics between disparate code bases. Those similarities are not evidence of copying. To decide whether similar regions are actually copied you would need to do further and subjective analysis. Without directly evidence of copying it would be very difficult to make a solid claim one way or the other. But, given the vast amount of similar code regions that exist (and assuming most code is not copied) I believe it should be given the benefit of the doubt.
Note: I have not studied density of duplicated code between different projects. The above is merely an conjecture based on my experience.
[1] http://hackthology.com/rethinking-dependence-clones.html [2] http://hackthology.com/sampling-code-clones-from-program-dep...
Save time. Support having good laptops and good drivers. Buy pre-installed. Paying the "windows tax" and installing a Linux on a windows laptop isn't just more work, it is bad for the ecosystem.
I agree with you that ASLR, NX, and CFI are the most important system level defenses to employ.
In contrast, while I don't want to paint a rosy picture of academic conferences, you always get detailed feedback on your paper/talk that you submit. It may be biased, it may be frustrating, but at least you can tell that someone at least looked at your paper/talk and gave you some feedback. Industry conferences never do this.
1. You can suffocate the baby by breathing on their face while you are asleep. The baby will not cry and will not wake while this is occurring.
2. You can crush your baby by rolling on to them while you are asleep.
3. Your baby can suffocate from their nose and mouth being covered by a blanket or pillow or even the soft mattress if they are get rolled over.
These very sad infant deaths happen frequently even in the US where co-sleeping is not as common as elsewhere in the world. Here are some recent news articles: http://www.nola.com/health/index.ssf/2016/04/co-sleeping_dea... , http://woodtv.com/2015/06/05/mom-hopes-babys-co-sleeping-dea...
Co-sleeping advocates will tell you "as long as you do it safely you can sleep with your newborn." This is false. There is no safe way to sleep with a newborn. Newborns cannot turn their heads away if you breath on them. They cannot move if you get too close. While, many parents sleep with their babies and the babies do not die that does not mean that it is safe.
Update: The mayo-clinics prevention guide for SIDS: http://www.mayoclinic.org/diseases-conditions/sudden-infant-... . TLDR; Newborn babies should sleep by themselves on their back in a crib with no stuffed animals, pillows, or "crib pads."
Another note: http://thescientificparent.org/crib-notes-is-cosleeping-real...
The point of the article wasn't that I am poor you should feel sad for me. The point was: look the Bay Area is so expensive that it is impossible to afford unless you are making an extremely high salary. A good salary isn't enough, a high salary isn't enough, it has to be extreme otherwise you will need to make life style sacrifices to live in the Bay Area.
In general, using struct embedding to simulate sharing code and data is pretty limited. I rarely use this feature in my own code. However, having structs which automatically implement interfaces is awesome because you can "say what you need." You can also compose the interfaces together by embedding them. For example of that, checkout the Map type in my data-structures repository: https://godoc.org/github.com/timtadh/data-structures/types#M...
> The Humble Programmer - E. W. Dijkstra
Which is actually the title of that essay by Dijkstra! http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EW... I guess this guy really doesn't think much of that essay?