In the subject of Artificial Intelligence it says:
> Theorem: No AI will bother after hacking its own reward function.
and then goes on:
> The picture [263] is that once the AI has figured out the philosophy of the “Dude” in the Cohen brothers movie Lebowski, also repeated mischiefs does not bother it and it “goes bowling”. Objections are brushed away with “Well, this is your, like, opinion, man”. Two examples of human super intelligent units who have succeeded to hack their own reward function are Alexander Grothendieck or Grigori Perelman.
They put up a paywall a second after loading so bots can scrape the data and advertise their site as providing answers when really they hide it behind a paywall.
Google won't do that. They're already in trouble for stealing content from the sites they crawl, especially news sites. Google goes out of their way to enable paywalls so they don't look like they're anti-copyright or out to destroy news and content sites.
By reading the stream of comments on the PR, and from my own experience, I feel that it is extremely cumbersome to do code reviews on Github. Atlassian's Fisheye/Crucible looks like a better solution. Does anyone think otherwise? I think Github has a large room of improvement in this regard; a PR is not the same as an issue.
On GH I can see the files that are changed and make/read comments that are inline on the files as well. This has been sufficient for my needs. What is it that Fisheye/Crucible brings to the table that you think would be desirable on GH?
I guess that for some people, and particularly in small reviews, it is enough with the list of files and inline comments.
I would like to have a tree view where I can see all the files at a glance, and, more importantly, switch back a forth between them. I find it hard to follow the code in Github's UX.
Also, Fisheye/Crucible gives you more flexibility to edit the review, by allowing you to remove files, and add or remove commits. Github PRs are based on branches, while Fisheye/Crucible code reviews are based on commits; it is an entire paradigm shift that gives the user more control. For example, I can create two separate reviews from the same branch on Crucible; that's impossible on Github.
I don't feel like GH is really meant to be a code review platform. It does PRs, but I assume that review should be done offline (like in other tools, like Crucible).
We have used GH as a review platform for an open-source project, but they tend to be relatively minor PRs. If they got hairier, we'd probably find something else.
Personally, I really don't like having a gazillion different tools. If we can use one tool for several purposes, then that's what I prefer. If the tool becomes too cumbersome, then I'll work with something more specialized.
Is there a good self-hosted open source platform for this? I’m new to all this, even though I’ve been computing since I was in grade school. Coding is a new discipline for me, and it’s hard to know the territory without a guide. I’ve seen you around and would trust a recommendation from you.
I have used and enjoyed Upsource (JetBrains code review tool) particularly for trunk development where you often need to be able to cherry-pick randomly-ordered commits into a review.
I honestly don't know how much our org paid for it though.
I've been using GitHub for code review (both open-source and commercial projects) for about 5 years. It's improved a little bit, but for PRs with >100 files changed it's obviously lacking good UX.
For me, the biggest improvement would be the tree-view you get in Fisheye/Crucible. It's so hard to get a grasp on large refactoring PRs on GitHub.
This extension [1] makes code reviews more bearable, I highly recommend it. I don't understand why Github hasn't shipped this years ago. They've been improving the UX since their acquisition but there's still a long ways to go.
I wonder how one does manage a PR with >100 files changed. I realize these are sometimes unavoidable, but shouldn't we strive for smaller PRs? No tool will help you with exploding complexity...
Usually with massive PRs of that sort I’ll have several smaller PRs to a separate branch that get reviewed so that everything in the massive PR to the main branch has already been reviewed and the big one is just a cursory look. But this approach probably isn’t as feasible with open source projects.
It's not just git. I have yet to see a platform which does PR code reviews in a way I like.
If it's small PR or PR's from trusted sources it's not an problem but once it's bigger and from a third party reviewing it can easily become much more annoying then it should.
Besides UX aspects on major offender IMHO is the text based diff algorithm. I had to often changes where you could have created a easily readable diff but non content aware git diffs just produced total garbage.
I spent four years working at a company that uses stash/"bitbucket server". Coming back to GitHub I was shocked at how much worse their PR workflow is.
I agree whole-heartedly (against both Github and Gitlab code reviews for serious large changes), but from what I've heard Crucible is apparently EOL now?
I love essays in commit messages! They can be very useful, especially when they describe why the change is being applied, instead of what is being done, which is usually the case.
Why was this particular "fix" chosen, instead of perhaps a more obvious alternative? (If I can choose only one thing to improve, it'd be this one! Had I gotten a penny for every head scratching "fix" that seems unnecessarily complicated or not a fix at all...)
What steps have been taken to avoid this in the future? New validations? Have new exceptions been introduced? New log rules? New monitoring rules? And if not, then why not?
Are these corresponding changes in other repos or this one? Is this change part of a larger series of changes?
There's so much more you'd like to know when you stumble on a commit like "fix missing css". Yes, some of this info is probably in the ticket. Yes, there is probably a discussion in the pull request. But likely not, if we are to be honest about it. And if it is, then all the easier to summarize in the commit message.
I'm one of those persons that read more code than I write nowadays, git log -G is my favorite command, and commit messages like the above hurts me daily.
I've already made a similar comment elsewhere in this discussion but I really don't get why most of these things is better stored in a commit message than, say, as a comment in the code itself, which will always be here even if I'm just browsing through the code by following a call stack or if the file gets copied into another project for instance.
I don't "git blame" all the code I read all the time, and even if I did one small refactor or variable renaming is enough to make it tricky to track the original change back. Comments are forever.
Comments and commit messages are complementary. The commit message describes the changeset and includes things like the above, the whys and the necessary context to understand the change. The comment describes the actual code as it is, and should describe how it works and how it interfaces with other code. Comments tend to be, as you say, forever while the code changes.
Both are well worth the time to write. Nicely written ones might even take a full minute or two to write, but how many cleaned-up and rebased commits does one produce in a day? A few, at most, unless they are absolutely trivial. Those minutes per workday are well spent.
> I'm one of those persons that read more code than I write nowadays, git log -G is my favorite command, and commit messages like the above hurts me daily.
-G just looks for changes in the patch so the commit message would not be relevant save possibly once you've reached an interesting-looking revision, do you mean `--grep`?
That quote about hating Erdos is interesting. I think my professor for UCLA undergraduate honors seminar from years ago, hated Erdos (he at least express dislike for a colleague of Erdos who operated similar). My impression is Erdos appeared to operated as something like a whirlwind of chaotic fact and theory finding whereas at least some other mathematicians aim to build larger unifying structures. It's a sort of Erdos versus Bourbaki divide (not to say who's right).
Yes that is it, thank you! I like that it clears things up like -
> According to municipal reports and the testimonies of 31 residents
and 28 visitors, the bat was never a food source in the city, and no bat was traded in the
market.
I've worked in a lab and Occam's razor for me says the lab that is 280 meters away and studied bat viruses is a lot more plausible than it originating in a wet market. People make stupid mistakes handling waste all the time. There was no need for the Chinese government to throw the wet market under the bus or for people to imply Chinese people ate bats or some other racially motivated theory and there was no need to believe the chinese government created a bioweapon. Most likely is that it was just a horrible mistake and careless handling of biohazardous waste/animals.
> I've worked in a lab and Occam's razor for me says the lab that is 280 meters away
Yeeaah, about that... I looked more myself last time when I mentioned this and couldn't find the reference I originally saw (it was more than a month before my comment a month ago), instead found this:
According to Google Maps and Translate, the pin in the image in that PDF that says "Wuhan Center for Disease Control & Prevention" is actually on a building labeled "New Century Home Appliances Collection and Disposal Station".
Snopes reports that it contained numerous errors, and the authors themselves have said they had no direct evidence for their claims. (Note that it was never peer-reviewed or even accepted for publication anywhere. They just pasted it up on a social media site.)
> Theorem: No AI will bother after hacking its own reward function.
and then goes on:
> The picture [263] is that once the AI has figured out the philosophy of the “Dude” in the Cohen brothers movie Lebowski, also repeated mischiefs does not bother it and it “goes bowling”. Objections are brushed away with “Well, this is your, like, opinion, man”. Two examples of human super intelligent units who have succeeded to hack their own reward function are Alexander Grothendieck or Grigori Perelman.
Grothendieck abandoned the mathematical community after modernizing an entire field and eventually secluded himself in France. He is considered one of the greatest mathematicians https://en.wikipedia.org/wiki/Alexander_Grothendieck#Retirem...