timtadh

Joined 17 years ago

Karma
2,028
Submissions
501
Member since
Oct 3
Researcher/Hacker from Case Western Reserve University. Now at Google. Likes to tinker and crunch crunchy looking leaves.

- 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 ]

View on Hacker News

Recent submissions

Comment · 8 years ago
It looks like v2.1 has fixed that.

Also, +1 this is awesome.

@dang if you are here: HN should do this natively!

Comment · 8 years ago
In response to several threads here: it is important to distinguish when scientists are self critical vs. when non-scientists are critical of the scientific method. For instance, there is a long history of scientists criticizing how the scientific process is currently conducted for the purposes of improving the scientific endeavor. That work is sometimes used by non-scientists who question the overall scientific method. However, such use is invalid as the scientific self-criticism

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."

Comment · 9 years ago
Comment · 9 years ago
Most people who criticize the Dragon (Compilers etc... by Aho et al.) book seem to focus on chapters 3 and 4 which are the chapters on lexical analysis and parsing. The book has 12 chapters. Whatever your feelings on the parsing techniques, the book covers WAY more than that. It has a really good introduction to code generation, syntax directed translation, control flow analysis, dataflow analysis, and local, global and whole program optimizations.

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!

Comment · 9 years ago
Where I live $80k is a significant portion of the cost of most houses. The price will be a significant barrier to entry for houses outside of hot real estate markets.
Comment · 9 years ago
> And there goes Shakespeare. On average there's 15,000 words per play. I bet most readers do not have the education to know every single word in that 15,000.

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).

Comment · 9 years ago
@suryabhupa How similar is this work to the Grammatical Inference field? There has been a lot of work over the years in specification inference which feels similar. Many of the studies in specification inference learn automata representations of object interactions. I know there have been other application grammatical inference in Software Engineering as well.
Comment · 9 years ago
I case people didn't click through it is an awesome comment by the original author of the IE5 DOM Tree explaining how it was implemented.
Comment · 9 years ago
Comment · 9 years ago
I guess I live in a small world because I have no idea how to type an umlaut on a US Qwerty keyboard but I can easily type Paul Er\"{o}s.
Comment · 9 years ago
+1 for admitting to snobbery it is an important step!

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)

[2] (https://www.lri.fr/~filliatr/ftp/publis/puf-wml07.pdf)

Comment · 9 years ago
I have do (academic) work [1, 2] on finding semantic code duplication. Two points that I have learned about code duplication:

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...

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton