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."
I too wish there was more standard containers available in Go's standard library. However, I don't think there will be a collections package unless and until generics make it into the language. That said, there are some pretty good libraries out there:
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!
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.
> 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).
@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.
+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."
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.
That is a reason to use the AGPL when working on free software. Using a BSD license gives you (the creator) zero protection from bad commercial actors who want to use the software without contributing back. The AGPL is not the right choice for every project but I do believe it is a good choice for software which can be trivially setup as a service. For instance, an open source web application, an open source database, an open source irc server, etc... I think Linus did the right thing going with the GPL for Linux and sticking with version 2.
Linux laptops: buy pre-installed. If you want linux and you want to be sure everything is functional, AND you don't want to devote lots of time to a "project" buy a pre-install. Dell Developer Edition laptops (XPS 13, 15) make great laptops. I hear good things about system 76 and purism as well.
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.
Going from $500 - $700 to $100 is a pretty big depreciation in my book. I guess it is better than going to $0 if that is what you are comparing it to. However, if you compare it to a durable good I do not imagine it compares well. (Example durable good: well built wood furniture)
From a purely practical standpoint it means it is more tractable to solve large instances exactly. You can always wait for an answer but if you need more memory than you have you are out of luck. For instance, let's say before you had a problem of size 64. 2^64 bytes in gigabytes is 10^10 gigabytes. That is more ram than I have. However, a constant multiple (say 1,000,000,000) gives only 64 gigabytes. That takes an intractable problem to a tractable problem on a server with a large amount of memory. Yes, you still have to wait for the solution (maybe a long time) but at least you would have a hope of actually solving it.
It is actually called Delta Debugging and was pioneered by Andreas Zeller (https://www.st.cs.uni-saarland.de/dd/). His first paper on it ("Yesterday, my program worked. Today, it does not. Why?") used essentially the technique above to isolate the failure inducing change. Surprisingly, techniques like this work very well and doing better is sometimes very difficult especially for large programs. For instance, in theory, using "Concolic Execution" which combines symbolic execution, constraint solving, and concrete execution one can do better. However, such systems have their own limitations with respect to program complexity. See also the tremendous effectiveness of AFL (American Fuzzy Lop) http://lcamtuf.coredump.cx/afl/ . AFL uses a straight forward technique to mutate code. It doesn't use any fancy program analysis and has been able to find lots of bugs in real programs.
Also, +1 this is awesome.
@dang if you are here: HN should do this natively!