timtadh
Joined 17 years ago
Joined 17 years ago
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...
- 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 ]