What git is not - <AUTHOR> http://gitready.com/beginner/2009/02/19/what-git-is-not.html <comment><USER2> The reason I think git is complicated isn't because it's complicated conceptually. It's because the commands are intentionally different from other SCMs, which is highly annoying when you know what you want to do but can't figure it out.

For example, how do you revert a file in your working directory?

Oh, git checkout HEAD file -- obviously!

<comment><USER3> You seem to think that other version control systems don't have this problem.

Let's consider subversion. Let's say you want to revert commit 1234. You just say "svn revert 1234", right? No. svn revert does something completely unrelated.

In git, "git revert 1234" _does_ revert changeset 1234.

So you see, you actually have to _learn_ about the version control system, regardless of which you choose.

You can't just make stuff up and expect the computer to understand what you mean.

<comment><USER2> Agreed! But I already know SVN, and Linus intentionally made git different than the other SCMs because he thinks they suck.

I think that's annoying.

And there's no way you can tell me that the git command set is more discoverable than, say, Mercruial's. Many common, every day commands in git are very difficult to figure out without a lot of searching and reading. This is not true with Mercurial.

<comment><USER4> Between `git help -a` to see all the available commands, and `git help <command>` or `man git-<command>`, I don't see how Git is any worse than any other VCS tool. Git is extremely well-documented, and even goes so far as to provide ASCII-diagrams in the docs to help you visualize what certain commands do.

Or are you just being picky because Git doesn't name everything exactly the same as other tools do?

<comment><USER5> I started with cvs, years ago, moved on to subversion when it was good and stable, and am now starting to fiddle with git. I like it a lot, but it _is_ "fiddly" feeling. I'm sorry I can't describe it better than that, but it's just a feeling I get from it. Maybe this covers it: I don't get the feeling that it's going to much effort to "make the easy things simple and the hard things possible". We know it can do the latter, but the former is not always true.

<comment><USER3> _"make the easy things simple and the hard things possible"_

Well, it's Git, not Perl :)

 _I like it a lot, but it is "fiddly" feeling._

To assuage this feeling, I recommend reading the source code for both Git and Subversion. After you realize the flaky shoestring-and-chewing-gum model that holds all your data in subversion, you won't worry at all about Git's UI :)

</comment></comment></comment></comment></comment></comment><comment><USER6> These always (fail to)address the same old issues. I switched to SVN for some specific features. I've looked and not been able to get definite answers if git supports these. In fact I've mostly gotten "if you don't do it/use it our way you're stupid, go away".

proper directory move/rename history

proper binary handling(that is no merging, newest file wins)

proper line ending handling (that is default to convert to local system's standard but overrideable per file/file pattern)

proper permission handling (track permissions and set them on check out/update/whatever you call it)

git seems focused solely on source code and heavily towards the Linux Kernel development process.

I use svn for website deployments, tracking changes to servers' filesystems(parts thereof), and occasional source code. I don't use anything close to the Linux Kernel dev process.

<comment><USER7> I think in this case the word "proper" means "the way that seems intuitive to me". This is not bad, but other people have made different technical decisions. Adding the word "proper" tries to make these into quality judgments into opinions, but that's still what they are.

I hope you find a system that works as you prefer.

<comment><USER6> Yes I agree. I meant and hoped that the (explanation in parens) would be interpreted as my opinion on what was proper. Believed the construct "proper ... (that is ...)" was clear, guess not. Oh, and thanks for not answering any of my questions and ranting off topic.

[an aside; I don't believe in "proper", there is no proper there is only "proper for me", never "proper for you." One should reject others' attempts to inflict "what is proper" on them. Good job btw. My use was to alter people's thinking or simply make them think, even subconsciously. Language is a virus.]

</comment></comment></comment><comment><USER8> For someone who doesn't have much experience with SCMs, is it worth learning Git or should I learn SVN? I get the general idea behind both - just not sure what I should dive into.

<comment><USER9> Contrary to what seems like the prevailing view right now, Git is not strictly better than SVN. Some reasons to use SVN are at <http://blog.red- bean.com/sussman/?p=90>.

It sounds like you want to use SCM in a personal (not collaborative) capacity. I think both SVN and Git are suitable for this purpose, but maybe Git has the edge because its philosophy doesn't privilege a repository.

<comment> old-gregg I believe Git _is_ strictly better than SVN even for one-person-never-share style of development simply because of much, much, much better branching/merging.

Being able to maintain and merge multiple branches _without any effort_ is a huge, in my opinion. I don't think you can get away without using at lest some branching features in any project: at the minimum you'd need to maintain tags for released versions and keep "latest stable" from "development/experimental" code separated. And this is where Git shines.

I'm not saying SVN can't do branches or tags, I'm saying _it takes more effort_ , and tools in general are supposed to make hard things easy.

<comment><USER5> I'd say git is better for that situation because it's so simple to set up. That's one thing it really does well. Tons of branches and other stuff are likely to be less of an issue on small, personal, non-shared projects.

<comment><USER10> I don't see why you shouldn't leverage branching in any small, personal, non- shared project. I got in the habit of making a branch any time I want to try anything out, after all most of my small projects are experimental in nature, and branching is perfect for experimenting with changes and ideas that you might otherwise be afraid to try using a single, linear history.

<comment><USER11> I don't get the argument that git is better for branched projects. I worked this way in subversion for _years_ \-- svn copy and svn merge work just fine. You can branch! You can merge! Huzzah!

Granted, git is a bit _faster_ for branching (it can take svn a few seconds to set up a branch, especially if you're doing it remotely), but that slight time savings is more than offset by the time you spend reading man pages, only to learn that the various git commands really don't mean what you _think_ that they mean (and don't get me started on the quirks and inconsistencies and bugs in git...)

I am not a fanboy -- just a guy who doesn't want to think about his version control, any more than he wants to think about his toothbrush.

<comment><USER12> It's not just that Git is faster at branching. The concept of a branch in Git is conceptually different to a branch in Subversion. In Subversion, a branch is analogous to a directory, and creating a branch is essentially a cheap and efficient directory copy. In Git, a branch is more akin to a reference or pointer to a particular piece of historical data.

The Git idea of a branch is somewhat more flexible than the Subversion idea of a branch. For instance, say I'm hacking away at a new feature, but I haven't thought ahead and created a new branch for my commits. A user then comes along and asks me to fix a bug. In Git, this is no problem, because branches are just references. I first assign a branch to my current work:

        git branch new_feature

Then I rewind my master branch back to before I started working on the new feature, 4 commits ago.

        git reset --hard HEAD~4

I then commit and push the bug fix:

        git commit -am "Bug fix"
        git push

Now the user is happy and I can continue working on my feature. But now I'd like the bug-fix to be included in the history of my branch, since I've pushed the bug-fix but not my new feature. So I change the 'base' of my branch using rebase:

        git checkout new_feature
        git rebase master

Now I can continue working on my branch as if nothing had happened.

Using Git is a bit like having a time machine you can use to alter history so you didn't forget your wallet this morning.

<comment><USER11> Golly. That took six commands, history unwinding, a rebase, and a few obscure flags. I'm beginning to see your point...how in the world would the lowly subversion user surmount such a catastrophically complicated conundrum without the raw power of git to save him?

Hmm....

svn copy ./my_code ./my_new_feature; cd ./my_new_feature

 _...hack hack hack...

(user interrupts! a bug! oh noes! must fix!)_

cd ../my_code

 _...fix fix fix..._

svn commit -m "fixed a bug! i rock!"

cd ../my_new_feature; svn merge -c HEAD ../my_code

 _...hack hack hack..._

Oh well. Guess it wasn't that hard, after all. Nevermind.

<comment><USER12> I think you're missing the point. In your workflow, you create the branch _before_ you started work on your new feature. In my Git example, I created the branch retroactively.

If you were to attempt the same feat in SVN, it would get a little messy. You'd have to first roll back the repo:

        svn merge -r HEAD:96 http://server/my_repo
        svn commit -m "Reverted last 4 commits"

Then create the branch and merge in the previous commit:

        svn copy ./my_code ./my_new_feature
        svn merge http://server/my_repo/my_code@100 my_new_feature
        svn commit -m "Imported reverted commits to new_feature"

Then make your changes:

        svn commit -m "Fixed bug"

Then merge your change into the new branch:

        cd ../new_feature
        svn merge -c HEAD ../my_code
        svn commit -m "Merged bug fix"

And once you've done all that, your commit history looks like:

        A
        B
        C
        D
        Reverted last 4 commits
        Imported reverted commits to new_feature
        Fixed bug
        Merged bug fix

Whilst in Git:

        Fixed bug   <- master
        A
        B
        C
        D           <- new_feature

Now, obviously you'd never actually do all this in SVN if you were sensible, but that's exactly my point. The Git concept of a branch being a reference to a commit is more flexible than the SVN idea of a branch being akin to a directory. Things that are perfectly natural to do in Git are rather more complex to do in SVN, and leave behind a messy history of merges.

<comment><USER11> I'm not missing the point -- I'm saying that your point is silly. You're fixated on doing everything in the same directory, when in fact it's far easier _not_ to do it that way, and the only argument you're making for doing it that way, is that it's more "flexible". But flexibility is not a virtue, unless you _need_ the flexibility!

 _"obviously you'd never actually do all this in SVN if you were sensible"_

Exactly. You'd never do it. You don't _need_ to do it. You can _get the job done_ without doing it. And that's what matters.

Git fanboys are hilarious sometimes...every argument is made from the position that none of the rest of us really understand git, and that if only we did, we'd fall in love with git in all of it's fiddly glory. What they miss is that many of us _hate_ complexity, and we avoid complexity that doesn't justify itself with true functional advantages.

I like simple tools that get the job done. Git makes my life harder; I have to think about _more_ things to do the same, basic tasks that were made trivially easy in subversion. That's the point.

<comment><USER12> I'm not claiming that Git is better than Subversion, or that you should use it. I'm merely pointing out that branches in Git have other advantages as well as being faster.

The fundamental problem with Subversion branches, at least in my view, is that you have to know ahead of time that you want a branch. Perhaps this isn't a problem for you, but it is for me. Sometimes I find myself thinking, "Hang on, is this really the right way to solve this problem?" In Git, I can save my current work in a branch, trot back a few revisions, and try a different approach.

In contrast, Subversion encourages a largely linear style of development. I expect some people, like yourself, prefer this approach, finding it conceptually simpler. And that's fine; I'm not saying that's wrong or bad, or that you should stop using Subversion. That's clearly what you're most comfortable with.

But a linear development model isn't for everyone. Those of us who like to experiment and backtrack tend to develop in a tree-like fashion, branching off shoots all over the place and pruning the ones that turn out to be a dead end. For this style of development, Git's branching model is significantly better than Subversion's.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> The only thing I worry about with git is getting really raw developers who have never, _ever_ used version control up and running in a semblance of a reasonable manner of operation.

I mean, I know people who were resistant to using subversion because they didn't understand how it was supposed to work. I sort of shudder to think about the mental reaction to being dropped into git. Because of this I originally supported Darcs. I still would if they could clean up some of the patch resolution problems that they have and the Darcs GitHub-like got halfway decent (maybe with Camp).

Source Control is one of the fundamental tenets of development and getting newbs trained on it is so incredibly important. We, collectively, can't afford for it to be a tough thing to get a handle on. Even if it takes time to really understand, it needs to be easy to get going and using the tool in a good semblance of the proper manner.

</comment><comment><USER14> And what about bazaar? Is it better or worse than git?

<comment><USER7> Both.

(Your question is too broad.)

</comment></comment><comment><USER15> i detect bias :)

</comment><comment><USER16> Just to reference another HN discussion "My web is text based" (here <http://news.ycombinator.com/item?id=488030> ) - this is the sort of topic where I think video and screencasts would be helpful.

Not a screencast of someone typing DVCS commands into a shell, mind you, or a video of someone talking about DVCS that could be transcribed to text with no loss of explanatory power whatsoever, or, $deity forbid, a video of someone reading inaudibly from illegible slides.

A decent _animated_ introduction to distributed version control explained by characters worthy of Pixar, set in a world of fantasy physics where things can pop into and out of existance.

DVCSs do things which are non linear, text and talk are extremely linear. Text and audio shouldn't be the only two forms of media on the web, video explanation shouldn't mean linear explanation.

<comment><USER17> There's <http://gitcasts.com/posts/railsconf-git-talk>

It helped me to actually get git (incidentally that's also the talk's title).

Don't let the "rails" in the URL mislead you, it's mostly about git and you can easily skip the part about Rails.</comment></comment>


Tarsnap Support for Bitcoin Ending April First - <AUTHOR> http://mail.tarsnap.com/tarsnap-announce/msg00042.html <comment><USER2> It's notable that Colin Percival pioneered memory-hard key derivations functions with Scrypt for tarsnap. Scrypt became the proof-of-work function for asic-resistant cryptocurrencies suchs as Litecoin and influenced Ethereum's ethHash. (Besides many other applications).

In this post Colin casually speaks out against proof-of-work, without taking any credit for his significant indirect influence on it.

<comment><USER3> I can't exactly take credit for litecoin (and others) using scrypt, given that they did it without my knowledge, endorsement, or advice. (If they had talked to me I would have pointed out that limiting scrypt to using 1 MB of RAM eliminated the entire point of scrypt.)

</comment></comment><comment><USER4> I wonder how much Colin made from the Bitcoin rise. It seems amazing that one could have made a little fortune by just deciding to accept Bitcoin as an experiment few years back.

<comment><USER5> That makes no sense, businesses that have been accepting Bitcoin generally charge the USD price at the current exchange rate and convert that back to USD not long after the transaction, for fear that Bitcoin would turn into funny money. We're talking business here, not investment.

<comment><USER6> Yeah, business. So about those transaction fees... you can save money by grouping your transactions and clearing them in blocks.

Now you're dangerously close to figuring out that you can make more money by waiting for the best time to clear the block.

Once you've crossed that bridge, if your business has any margin at all, it's not hard to imagine that keeping some of the exchanged crypto currency back from each clearing block until the next block, or even longer, during any bullish run (that we've seen on more than one occasion) can result in a measurable margin increase with a fairly low (or at worst, quantified) risk profile.

<comment><USER7> That would still be investing, business would pay taxes on the Bitcoin value at the time of purchase as revenue, regardless of conversion to fiat in whole or part.

<comment><USER6> I know, so you pay your taxes and now you might as well have been a day trader for the levels of complexity that adds to your tax accounting burden.

Not sure what my point was really — that's just about exactly how this plays out.

</comment></comment></comment></comment></comment><comment><USER8> Stellar is looking very good for lots of use cases. That's the only one I follow though. What else is good from tech as well as how the coin has been performing?

<comment><USER9> One fundamental problem at this point is that coin sponsors and the enthusiastic coin owner-boosters want massive price growth so they can strike it rich. But as a medium of exchange price stability is a very nice property.

In terms of price stable crypto-currencies there's tether, which is looking very much like a scam, and some kind of complicated ethereum contract token the name of which slips my mind at the moment.

The stellar network is supposed to be able to be used to make payments without necessarily involving stellars (except to fund the transaction). But the anchors and trust web needed to do that don't exist (yet?)

<comment><USER10> You are looking for the « DAI token » maybe?

<comment><USER9> Not sure why this is grayed out, that's what I couldn't think of.

</comment></comment></comment></comment><comment><USER11> Time for other cryptocurrencies to shine. "Starbucks Chairman Says Cryptocurrency Will Be Big — Just Not Bitcoin" \- [http://time.com/money/5121644/starbucks-chairman- bitcoin/](http://time.com/money/5121644/starbucks-chairman-bitcoin/)

<comment><USER12> Too bad they're not creating their own coin, star _bucks_ would be a pretty catchy name.

<comment><USER5> Is there a cryptocurrency equivalent of "buy 10 drinks get one free" yet?

<comment><USER13> Burger King introduced WhopperCoin in Russia: [https://www.cnbc.com/2017/08/28/burger-king-russia- cryptocur...](https://www.cnbc.com/2017/08/28/burger-king-russia- cryptocurrency-whoppercoin.html)

</comment></comment></comment></comment><comment><USER14> Possibly the Lightning Network on Bitcoin will help with these kind of problems, once its up to speed. See discussion on the stripe announcement thread:

[https://news.ycombinator.com/item?id=16218056](https://news.ycombinator.com/item?id=16218056)

</comment><comment><USER15> 1st of April is a strange date to stop or announce anything. April Fools, really?

<comment><USER16> April 1st is the first day of the second quarter for businesses whose fiscal year is the calendar year.

It generally makes sense for changes that affect accounting to start on the first day of a quarter.</comment></comment>


Using the IOMMU for Safe and Secure User Space Drivers [pdf] - <AUTHOR> https://www.net.in.tum.de/fileadmin/bibtex/publications/theses/2019-ixy-iommu.pdf <comment><USER2> I actually went straight to one of their references ([https://gianniantichi.github.io/files/papers/pciebench.pdf](https://gianniantichi.github.io/files/papers/pciebench.pdf)) which was an amazing find. I should keep up more with the academic conferences, I guess.

The most interesting / surprising thing about this paper is how damning it is for the Intel IOMMU.

<comment><AUTHOR> Yeah, this paper is amazing; anyone considering using the IOMMU or interested in performance at the PCIe level should read it.

We can also confirm their result about the IOMMU TLB size of only 64 on the CPUs we have here. (Yes, the TLB size is completely undocumented and there are no performance counters...)

</comment></comment><comment><USER3> This is best complemented with a multiserver, microkernel architecture. With an IOMMU, and with near everything including drivers running in userspace, all of this can be achieved:

[https://en.wikipedia.org/wiki/MINIX_3#Reliability_policies](https://en.wikipedia.org/wiki/MINIX_3#Reliability_policies)

With a monolithic kernel such as Linux, the reliability benefits of running some drivers in userspace are negligible, as the TCB is still millions of LoCs with no proofs.

Fuchsia, Genode and HelenOS are relatively active, promising open source operating systems with a microkernel, multi-server architecture and drivers running as unprivileged processes.

<comment><USER4> If comprehensive static proofs are in the picture, there's little benefit to running trusted code in user mode. It's just adding a protection boundary to something that could already be proven as safe via static analysis. IO-MMU however could still be useful since it somewhat obviates the need to trust the device itself, and devices are much harder to characterize properly.

<comment><USER3> >If comprehensive static proofs are in the picture, there's little benefit to running trusted code in user mode. It's just adding a protection boundary to something that could already be proven as safe via static analysis.

Try seeing it the other way around. It minimizes what needs proving (it isn't cheap) by having the microkernel (small and proven) enforce separation.

Capabilities (not to be confused with POSIX capabilities, which are something else) do help massively here. Refer to the Genode Book[0] introduction chapter for an introduction to capabilities.

In the driver example, running the driver unprivileged means the damage a faulty driver can be contained. In combination with a iommu, it can be made so that the hardware can only talk to the driver, to complete the protection. This is only possible if the kernel itself can be trusted, which would mean the kernel has to be proven, and that's unrealistic unless it's a microkernel, as it is a very costly process that doesn't even scale linearly with LoC.

The alternative is to make all drivers part of the TCB, which isn't realistic for the same reason. Unfortunately, on top of this, driver code quality is known to be particularly bad.

[0] [https://genode.org/](https://genode.org/)

</comment></comment></comment><comment><USER5> I love where this work is going and I really enjoyed your ixy project.

I see no mention of Dune [0] in the bibliography. Given the narrow focus of this research I think it is required.

Once processors are tuned for cloud workloads, they will have the affordances that will make full blown operating systems optional.

[0] [http://dune.scs.stanford.edu/belay:dune.pdf](http://dune.scs.stanford.edu/belay:dune.pdf)

</comment><comment><USER6> This paper doesn't cover BPF or XDP, which is the future of high speed networking in the kernel. If you need to do user space processing and XDP can't meet your requirements, you can now use AF_XDP. DPDK was always a way of circumventing the kernel, now we have kernel approved methods for line speed network processing.

</comment><comment><USER6> This paper doesn't cover BPF or XDP, which is the future of high speed networking in the kernel. If you need to do user space processing and XDP can't meet your requirements, you can now use AF_XDP. DPDK and other user space networking was always a way of circumventing the kernel, now we have kernel approved methods for line speed network processing. XDP programs are actually safer than using Rust, because XDP programs are statically analyzed byte code that is guaranteed to finish executing, among other checks.

<comment><AUTHOR> XDP is completely orthogonal to this work and would not have been a useful performance comparison. "Using AF_XDP" vs. "using a user space driver with IOMMU" is just apples vs. oranges.

The goal we are trying to achieve in this project here is to show that drivers can (and should) be written in better languages to improve security and safety. Note that one of the drivers in the thesis is written in Rust.

And regarding XDP being safer than Rust: Yes of course. But it's also very limiting; you can't write a driver in eBPF. (It currently just prohibits jumps with negative offsets but there's some ongoing work to allow for at least some bounded loops). We are interesting in making drivers themselves safer, not applications building on top of them.

(As advisor of the thesis I however agree that XDP should have been mentioned; I'm not super happy with the length of the thesis but quite happy with the implementations)

<comment><USER6> XDP is already being used to replace DPDK and IPVS use cases, so I don't see how its Apples to Oranges. It's generally not a good idea to circumvent the kernel, and in this case the kernel developers are providing better and better tooling for high speed networking to the point that user space driver implementations are no longer attractive compared to using the XDP ingress hook points. In industry I see rapid adoption of XDP (BPF in general is THE topic in Linux right now), and it's enabling all sorts of fascinating new use cases. I would be very interested to see a paper on iommu perf from the XDP perspective.

<comment><AUTHOR> This isn't about performance of user space drivers but about safer/better drivers. Whether that driver offers an XDP interface or something else is irrelevant. Also, your kernel driver running XDP should also use the IOMMU for both safety and security (e.g., Thunderclap).

(The thesis features a performance evaluation to show that it doesn't get slower when used properly: hugepages are absolutely required; this is very different from non-IOMMU drivers where hugepages only boost performance by ~1-3% in the best case. Also, performance is simple to quantify so it makes for a great evaluation.)

Some context for this thesis/what I'm working on at the moment:

C as a programming language for drivers has failed from a security- perspective. Cutler et al. [1] analyzed 65 security bugs found in Linux in 2017 allowing for arbitrary code execution, 40 of them could have been prevented if the driver was written in a safer language. I've looked at these 40 bugs and found that 39 of them are in drivers.

I disagree with their conclusion that you should therefore consider to write the whole operating system in Go (that's just unrealistic in the near future). But we can at least start to write drivers in better languages as they seem to be the weakest point gaining 97% of the improvement for ~40% of the work. Getting a high-level language driver upstreamed in Linux is of course unrealistic, so user space drivers it is.

Network drivers are particularly interesting because user space drivers are already quite common there and there's a trend towards having network stacks in the user space anyways: QUIC is user space only, iOS runs a user space TCP stack. (Somewhat related: the future API between applications and the network stacks is TAPS instead of sockets, TAPS is also more friendly towards user space stacks as it's finally a modern abstraction for the stack.)

[1] [https://www.usenix.org/system/files/osdi18-cutler.pdf](https://www.usenix.org/system/files/osdi18-cutler.pdf)

<comment><USER4> > Getting a high-level language driver upstreamed in Linux is of course > unrealistic, so user space drivers it is.

There's work being done on source-level translation from Rust code to C (mrustc is part of this of course, but nowhere near complete), so I'm not sure why this should be seen as unrealistic.

<comment><USER7> I don't see why using mrustc to generate C code would make Rust drivers more upstream-able in the Linux kernel? As far as I understand it, the main thing is that the team (Linus at least) does not want to maintain source code in multiple languages.

I do like the mrustc effort though.</comment></comment></comment></comment></comment></comment>


Website Testing Tools from Beginners to Pros - <AUTHOR> http://www.testing-web-sites.co.uk/

<comment><USER2> Seems to be an emphasis on testing a website from a 'quality checking' rather than 'quality assurance' point of view. That is to say, it's more for a website been built and gone live (or at least pushed to a staging server) rather than things you'd use during the build process.

To test during development, I use nightwatch.js (a front end test suite on top of Selenium web driver - [http://nightwatchjs.org/](http://nightwatchjs.org/) ) to test in all the main browsers at a variety of resolutions for responsive checking. That way I can get a report on browser differences whenever I push some code, and fix things as I go.

</comment><comment><USER3> Please, please stop using a custom scrollbar. It makes navigating sites way to hard. Other than that, thanks for sharing!

</comment><comment><USER4> The scrolling on this site makes it really hard to read...

</comment><comment><USER5> Thanks for sharing! Plenty of useful and new tools.

<comment><USER6> No sockpuppet comments on HN, please.</comment></comment>


Myspace founder lied about his age (-5 years) to make site seem cooler - <AUTHOR> http://www.newsweek.com/id/62330?gt1=10547

<comment><USER2> Now we know why so many successful startups seem to be founded by people under thirty.

</comment><comment><USER3> BREAKING NEWS: Older person attempts to seem younger!

UP NEXT: Blogdogs.com not actually written by dogs! Rumored human involvement!

<comment><USER4> It's not unusual for people to try to seem younger, but this is the first case in my knowledge of a startup founder lying about his age.

</comment></comment><comment><USER5> This calls for an EMERGENCY MARKETING MEETING:

<http://homestarrunner.com/sbemail164.html>

<comment><USER3> lol, great find ;)

"Are you telling me the nightly nacho cheese masks aren't working?"

</comment></comment><comment><USER6> If the audience is shallow enough to like a site more based on the founder's age, it's only fitting that he should lie about it. Caesar's to Caesar.

</comment><comment><USER7> Again, it's a trust thing. Communities are based entirely upon trust, and no one wants to trust an old geezer.

Plus, it probably helped him pick up the ladies.

<comment><USER8> Yeah, it's better to trust a liar than a "geezer". What is this, the freaking Cultural Revolution?

P.S. That was something that happened before 1985.

<comment><USER9> Never trust anybody over 30, man :)

</comment></comment></comment><comment><USER10> Next: Tom is not the founder of MySpace.

People should read up the history of MySpace.

</comment><comment> patrickg-zill Just like Omidyar and eBay, where they floated the story about him just wanting to sell his girlfriend's Pez collection or whatever it was that the PR firm dreamed up.

<comment><USER11> Or YouTube and the dinner party story. Plus it had three co-founders, not two.

</comment></comment><comment><USER12> I'd lie about my age to for $510 million dollars.

<comment><USER13> could have sworn it was $580?

</comment></comment><comment><USER14> Myspace is from LA. If I moved to LA, I'd probably subtract 5 years from my age, too. It's local custom.

</comment><comment><USER15> F+%$ it. It worked.</comment>


Why I Hope to Die at 75 - <AUTHOR> http://www.theatlantic.com/features/archive/2014/09/why-i-hope-to-die-at-75/379329/?single_page=true

<comment><USER2> [https://news.ycombinator.com/item?id=9131946](https://news.ycombinator.com/item?id=9131946)

</comment><comment><USER3> Don't say that.

My mother is 75. So is her twin sister.

Ever see the movie "Harold and Maude"?</comment>


Digital Ocean Management Interface Down - <AUTHOR> https://cloud.digitalocean.com/login <comment><USER2> The new alerts system they rolled out yesterday must have been a little too much of a good thing

[https://www.digitalocean.com/company/blog/introducing- monito...](https://www.digitalocean.com/company/blog/introducing-monitoring/)

</comment><comment><USER3> We're working to fix it, status page should reflect this soon.

</comment><comment><AUTHOR> On [https://status.digitalocean.com/](https://status.digitalocean.com/) they report everything working and suggest to open a ticket, but [https://cloud.digitalocean.com/support](https://cloud.digitalocean.com/support) is down, too.

<comment><USER4> Status page is throwing a 406 now, too. Looks like my site on DO is up and running, though, so it's just their tools that are down

<comment><AUTHOR> Yeah, my containers are humming along nicely, too.

<comment><USER5> DO has containers? I thought Droplets were Xen VMs.

<comment><USER6> He probably meant droplets, they are KVM VMs.

<comment><AUTHOR> Containers in my droplets ;)

</comment></comment></comment></comment></comment></comment><comment><USER7> I think I broke it

<comment><USER8> Damn you

</comment></comment><comment><USER9> Switch to firefox today on my office machine and was amazed to see developers tools opened instead of a page, lol.</comment>


Scala macros that won't kill you - <AUTHOR> http://blog.safariflow.com/2013/12/20/scala-macros-that-wont-kill-you/

<comment><AUTHOR> Scala macros personally scare the pants off of me. Way to much power for me to manage. For instance, I recommended a scala email validator macro that would send an email to the email address string in question and then throw a compilation error if the email could not be delivered.</comment>


The Bootstrapper Bible by Seth Godin (103 pages) - <AUTHOR> http://www.slideshare.net/SiliconValleyST/the-bootstrappers-bible-by-seth-godin

<comment><USER2> This is a book written by someone whose livelihood is motivational marketing. I would urge anyone interested in building a product to spend their time doing that instead of reading these kind of self-help books. There's no signposted path to success, and the more you rely on stuff like this, the less likely you are to find an unexplored route of your own.

<comment><USER3> Yes. Also, I don't know if you would agree, but I think any hacker bootstrapping a startup should instead read this book: [http://www.amazon.com/Start-Small-Stay-Developers- Launching/...](http://www.amazon.com/Start-Small-Stay-Developers- Launching/dp/0615373968/) It's written by a developer (a real one, who can actually code, not just talk about startups) who has really done it on his own - filled with valuable advices and thoughts. Every time I see someone talks about some startup book written by a marketing guru, I can't help but recommend this one instead.

As a side note, I'd like to point out that a lot of scam books appeared on amazon in the marketing and startup sections lately. The worst thing, they all got fake 5 star reviews, so it's not always clear right away this is a scam.

<comment><AUTHOR> snitko, eh eh. Hacker News is home of very smart people and I don't expect The Bootstrapper Bible to be their only book.

Btw, the fact that you suggested that book made me understand how much the current way Amazon suggest you books doesn't really take in consideration your goals or background.

It should actually ask you "Why are you buying this book?" Me "Because I want to make a startup" AMZ "Oh cool, what's you background?" Me "I am hacker" AMZ "Oh ok then with Seth Godin you are going a little bit too businessy. Try Start Small, Stay Small"

Sorry guys, early morning thoughts.</comment></comment></comment>


CPU-based Morphological Antialiasing source code - <AUTHOR> http://software.intel.com/en-us/articles/mlaa/?cid=sw:graphics270

<comment><USER2> Is there a better video of this anywhere? It's really hard to see what difference it makes when the video is so lo-res.</comment>


The Paradox of the Proof - <AUTHOR> http://projectwordsworth.com/the-paradox-of-the-proof/ <comment><USER2> This is a great article. The writer has obviously spent a lot of time speaking to Mochizuki's colleagues, and has explained the whole strange situation in a way that is layman-friendly without being wrong. It's interesting that it's part of an experiment in donation-funded journalism: I was sufficiently impressed that I donated a few dollars, but I fear that is not likely to be a common enough response to be a viable way of funding this sort of time- consuming journalism. I would love to be wrong about that.

There are interesting parallels and contrasts with Thomas Hales's proof of the Kepler conjecture. In that case, as far as I know Hales did everything possible to help his colleagues understand the proof, but even so it was so long and involved that the referees declared themselves unable to be certain it was correct. Since then, he has been working on a formal machine-verifiable version of the proof under the banner of the Flyspeck Project: <http://code.google.com/p/flyspeck/>

<comment><USER3> I wonder what would happen if, say, I allocated $10 per month to compensating articles and journalists I enjoyed.

And then it was distributed evenly by time I spent on the page, every single day. So if I spent 30 minutes reading this article, 10 minutes reading another, 2 minutes on 10 others, this author would get $0.16 ($0.33 per day, times (30 mins, out of 60 total mins of time = 0.5)).

That's really not that much. With 10,000 people all following this same path, the author would "only" get $1600. Readership is likely to drop off exponentially after the initial publicity. Publishing two articles of similar quality per month would get the author a nice living wage; not too bad, but only if they can reach an audience of 10,000 interested readers who are in on this compensation system. Slim chance.

Perhaps it works as a supplementary reward system. Another question: does this incentivize the right things? Will such metrics lead to longer articles which aren't necessarily interesting to read, but just take a long time? Does it disincentivize quality in any way?

More questions: how much would people be willing to contribute—$10 per month? $30 per month? How is it distributed—manually or automatically, by time or by rating? Is the small bit better than nothing? Does this incentivize people to a) produce good content, or b) pay for its consumption? Would people voluntarily buy into this system, or does it need to be a restrictive thing where only contributors can read articles?

Just thinking.

<comment><USER4> There is a micro-payment service called Flattr [1] which does something like this. It was founded by Peter Sunde, one of the pirate bay founders.

It's actually quite successfull in the German web community especially for podcasters. There are German podcasters which earn about 1000 Euro per month via Flattr.

[1] <https://flattr.com>

<comment><USER5> Someone actually mentioned Flattr to me today as a way to take donations for my own writings; I've always begged off because I've never wanted to take the time to set it up and clutter my site (more), but now here I see Flattr brought up again... Is there any way of even roughly estimating how much Flattr might bring in?

<comment><USER6> > Is there any way of even roughly estimating how much Flattr might bring in?

Of course: you try it, write up a massive future post about the results, and voila! But that probably wasn't the answer you wanted. I have no idea how many people are using it, but the idea sounds pretty great and if there's a good crowd to try it out on then HN readers wouldn't be a bad bet. I don't think anyone would mind another small button between PayPal and BTC.

<comment><USER5> > Of course: you try it, write up a massive future post about the results, and > voila!

~-~

> I don't think anyone would mind another small button between PayPal and BTC.

Yes, fair enough... I think I may just be making excuses at this point to not try it out.

<comment><USER7> Just put it in my website footer [0]. Flattr is very flexible. You can use various methods with more or less or no JavaScript. Also you can link stuff like Github, so starring a repo leads to flattr compensation.

[0] <http://beza1e1.tuxen.de/articles.html>

<comment><USER5> Yeah, I just added it to <http://www.gwern.net/> . At first I was all 'o.0 you expect me to load a bunch of JavaScript just to add a button' but then I spotted that there was a purely static version and added it without a problem. We'll see how it goes.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> This reminds me of something I witnessed when I worked at Google. There was this long-standing problem, I don't want to go into details but it had to do with websearch indexing and it had gone unsolved for years though it was regularly affecting search results in a negative way.

Then one guy solved it. The changelist he prepared wasn't even that long but it was crazy complex. Helpful comments contained links to a 100-pages long academic paper on top trees. Since it had been long established on the team that the guy was (a) a genius and (b) hundred percent reliable, it was generally assumed that the solution would work, however all code changes at Google need to be reviewed and nobody was able to review that CL. A number of people tried but they all dropped out, even though, unlike the ABC Conjecture professor, the author was absolutely willing to answer any questions you had.

Eventually the powers that be decided to trash the CL, not because there was any doubt regarding its correctness, but on the principle that you can't let anything that only one person can comprehend enter the codebase.

<comment><USER9> As someone newly entering the workforce, this is a really depressing view into how bureaucracy can squash innovation.

<comment><USER10> Do not be depressed, at least because of this. Few people will ever write anything that is correct, can not be meaningfully simplified, yet incomprehensible and essentially unreviewable. The only other thing that comes to mind are the top-grade encryption algorithms. (They are reviewed, but even after extensive, extensive review by the very smartest people in the field, there's still an irreducible part when selecting an algorithm where everyone still just has to sort of hope there isn't some fatal flaw in there somewhere. Often, years and years later, there is.)

<comment><USER11> > Do not be depressed, at least because of this. Few people will ever write > anything that is correct, can not be meaningfully simplified, yet > incomprehensible and essentially unreviewable.

You don't have to write something that is essentially unreviewable to end up in the scenario described earlier. You just have to work with a team that isn't prepared to learn new things and rejects thing that they don't understand.

I've been studying functional programming lately and can easily imagine being told my code is "incomprehensible" because I wrote it in a functional style instead using loops and variables.

</comment></comment></comment></comment><comment><USER12> Don't get me wrong, but from what I've seen of the world of science, the only people who exhibit this type of behaviour are frauds and delusional pseudoscientists.

All the warning signs of pseudoscience are there: "I couldn't possibly explain it" as a response to lecture invitations, working on something for extended periods of time without sharing results, using lots of obscure terminology which is not standard for the field, one long and obfuscated paper instead of building toward the result incrementally, etc. Using the title "Inter- universal geometer" instead of calling yourself a mathematician is also strange.

The natural way for a mathematician to behave after seemingly solving an important problem is exactly the opposite of what this guy is doing. And the only rational reason to do so is if there is actually something wrong about the work.

I lack the know-how to arrive at my own opinion by reading the paper, but this situation is definitely fishy. And it's not like a bona-fide scientist losing it and becoming an pseudo-scientist obsessed about a topic is completely unheard of.

<comment><USER13> Also making claims about typical mathematicians and attempting to apply them to those already determined to be atypical is a bit dodgy in and of itself. Perelman was not your typical mathematician and he behaved atypically as well. I'm not certain but I don't think he travelled and lectured on his proof of the Poincaré Conjecture. He even turned down a sizable award size. Just because an atypical scientist behaves atypical doesn't make their work any less valid.

I agree it seems odd but even in my limited exploration into Pure Mathematics I have seen alternative proofs made with ideas not native to the field. Why must that necessarily make this proof invalid?

<comment><USER12> I'm far from claiming that the proof is invalid based on my feelings on the subject.

My only issue is that in the article, and in other writing on the subject, nobody is even contemplating the possibility that Mochizuki's work might be unreadable for reasons other than it being too brilliant to grasp.

I wanted to present an alternative possibility which seems to be disregarded at the moment in favor of the attractive "eccentric genius" narrative.

On the topic of Perelman - he did reject the Fields Medal. However, he did give a series of talks at MIT, Princeton and other places a year after publishing his proof.

<comment><USER13> I must have read the article differently from you. I sensed there was a positive attitude towards him, but I didn't feel they were trying to say he had proven the theorem or was so brilliant no one else could grasp it. On the contrary, it seemed like they were saying "This person has been brilliant for quite some time, but this 'proof' seems entirely nonsensical even to the experts in the field."

So to me, that read more as, this is a curiosity that has a deep and interesting past and an even more interesting present.

> I wanted to present an alternative possibility which seems to be disregarded > at the moment

That is entirely fair and valid. I just misread your comment as more along the lines of "Does no one else see how obvious it is that this guy is crazy?!" My fault.

> On the topic of Perelman

Yes I was already corrected. I couldn't remember with certainty whether he did or didn't. I thought he had, but then what I remembered about his personality made me reconsider that.

</comment></comment></comment></comment><comment><USER14> If a programmer locked himself away for 14 years and then emerged and announced he'd written a completely bug free OS, there would be skepticism. Code needs to be battle tested by other people to find the bugs.

Mathematics is the same, to an extent; one guy working alone for 14 years is likely to have missed ideas and perspectives that could illuminate flaws in his reasoning. Maths bugs. If he's produced hundreds of pages of complex reasoning, on his own, however smart he is I'd say there's a high chance he's missed something.

Humans need to collaborate in areas of high complexity. With a single brain, there's too high a chance of bias hiding the problems.

(Repost of my previous comment <https://news.ycombinator.com/item?id=4829806>)

<comment><USER15> It's a shame that you've disregarded all of the replies to your original comment. tl;dr there are degrees of bugs and many are easily fixed.

edit: more constructively, Imagine that you're working on the NYT crossword and I come along and point out that 45 across is wrong and tell you what the answer should be. Do you then throw away the rest of your work? No, you fix the part that's wrong and then check the rest of the puzzle to figure out the scope of the error.

<comment><USER14> I don't really accept the notion that inconsistencies in a giant mathematical proof will always show themselves. That does happen sometimes, but if you're breaking new ground (as Mochizuki seems to be) its much more likely that things will seem consistent to you, but are actually inconsistent because you made a mistake somewhere.

<comment><USER15> Right, that's why other people are trying to verify the proof and aren't just taking it on faith. They're almost certainly going to find errors, the question is whether or not those errors are easily fixed, difficult to fix, or fundamentally impossible to fix.

</comment></comment></comment></comment><comment><USER16> > For centuries, mathematicians have strived towards a single goal: to > understand how the universe works, and describe it.

Um, no. Mathematics itself has _absolutely nothing_ to do with "describing the universe". Mathematics is purely abstract. It has no inherent relationship whatsoever with reality.

That certain mathematical constructs can be used to model certain aspects of the real world is basically a lucky coincidence, but not very interesting to mathematicians - that's what physicists do.

<comment><USER17> I think there's a reasonable argument to be made that mathematical constructs are _part of_ the universe.

David Deutsch has a method for ascertaining whether something can can be said to exist or not - ask whether it "kicks back" when you interact with it, in the sense that simulating the response of the thing you're considering in a totally convincing way would involve an effort as large as building a new universe for that thing to exist in.

Rocks "exist" because, if you wanted to build a totally convincing simulation of a rock, you'd need to include all of modern physics as we currently understand it.

Other minds "exist" because simulating them convincingly would basically require you to construct a true articificial intelligence (strong AI).

Mathematics "exists" because giving someone the genuine experience of doing mathematics when they really weren't would involve a simulation of almost unfathomable complexity.

There is a very real truth in the statement that '1 + 1 = 2', or the statement that there are arbitrarily long arithmetic progressions of prime numbers, or any number of other mathematical results. The world of mathematics is a very real part of the universe, that "kicks back" by constantly surprising us when we think about it.

So I don't think the article, which is very well written and researched, deserves the middlebrow "Um, no" scorn that you treated it to.

<comment><USER16> > I think there's a reasonable argument to be made that mathematical > constructs are part of the universe.

Well, one could say that we "create" them using our minds, which certainly are, but that's deep into philosophical territory.

> Mathematics "exists" because giving someone the genuine experience of doing > mathematics when they really weren't would involve a simulation of almost > unfathomable complexity.

Sounds to me like a misapplication of the method - the complexity arises from simulating the response of a person to math, not from simulating math. By that standard, all fiction is "a very real part of the universe".

> So I don't think the article, which is very well written and researched, > deserves the middlebrow "Um, no" scorn that you treated it to.

That concerned on one statement, not the entire article (which I found fascinating as well). Yes, I have to admit that this is rather smartassy, but I actially feel that, quite independant of this article, it is an important and amazing realization that few people make.

<comment><USER18> " _By that standard, all fiction is 'a very real part of the universe'._ "

Strangely, I believe that statement supports crntaylor's argument, being the point of fiction as far as I can see.

</comment></comment></comment></comment><comment><USER19> I actually read the whole article word-to-word. May be this personality of Shinichi Mochizuki appeals to me or may be i find maths more interesting than i admit. But i dont know which.

Also, i find it quite surprising that the proof for problems in domains as elementary as number theory, should have to be so complex, sort of baffles me. I hope i can rise up to the level to begin to understand this lingo or that someone brings it down to the level where i can find it interesting to read, like this article :D

<comment><USER20> > Also, i find it quite surprising that the proof for problems in domains as > elementary as number theory, should have to be so complex, sort of baffles > me.

One reason for this is that primes are defined by their multiplicative properties. There aren't many easy connections between primes and the additive properties of numbers, and so proofs that try to relate additive things to primes tend to involve deep and complicated things.

</comment></comment><comment><USER21> In case anyone wants to give it a try, here is the paper: [http://www.kurims.kyoto-u.ac.jp/~motizuki/Invitation%20to%20...](http://www.kurims.kyoto-u.ac.jp/~motizuki/Invitation%20to%20Inter- universal%20Teichmuller%20Theory%20\(Expanded%20Version\).pdf) and it looks like he is about to give a lecture in Tokyo: <http://www.kurims.kyoto-u.ac.jp/~motizuki/news-english.html>

And here is a FAQ on the theory: [http://www.kurims.kyoto-u.ac.jp/~motizuki/FAQ%20on%20Inter-U...](http://www.kurims.kyoto-u.ac.jp/~motizuki/FAQ%20on%20Inter- Universality.pdf)

</comment><comment><USER22> Wow! That was an amazing read! These old articles might be of some interest as well:

[http://today.uconn.edu/blog/2012/10/the-mochizuki-theorem- wh...](http://today.uconn.edu/blog/2012/10/the-mochizuki-theorem-when-youre- so-smart-nobody-can-check-your-work/)

[http://mathbabe.org/2012/11/14/the-abc-conjecture-has-not- be...](http://mathbabe.org/2012/11/14/the-abc-conjecture-has-not-been-proved/)

</comment><comment><USER23> It's a good tradition in math that you as the author have to convince others that your theorem is correct. If you cannot convince other fellow colleagues then you can't claim you have a proof.

That's why a lot of mathematicians are sceptical against computationally constructed proofs such as state space exploration. Or, at least, they don't like the taste of it :)

</comment><comment><USER24> As a completely uneducated simpleton, it seems bizarre to me that addition and multiplication are considered "different" in the deeper explorations of math and number theory.

It seems like multiplication is just an extension of addition. How many times do you want to add numbers together? The result is multiplication. Similarly, addition can be used to represent multiplication. You want to multiply, which can be represented as adding things a certain number of times.

Of course, the conjecture introduces rules about prime numbers, and then says "ooo" now we see that prime numbers being added together (with rules of what kinds of prime numbers are allowed in the equation) results in "predictable" rates of incidence.

I guess it's a little late to go back and be born again with a life of education centered around number theory so I could see and comprehend the complexity!

<comment><AUTHOR> This really deserves a longer and better answer, but I'm struggling to explain. It's a pretty deep conceptual thing, but I'll try.

        As a completely uneducated simpleton, it seems bizarre to me
        that addition and multiplication are considered "different"
        in the deeper explorations of math and number theory.

        It seems like multiplication is just an extension of addition.

You're not alone in this, but as you go on in advanced math you find more and more that multiplication is not really repeated addition, it just happens to coincide with repeated addition when that makes sense. The problem/opportunity is that multiplication still makes sense when repeated addition doesn't.

It might be easier to think of this with regard powers. People teach that A^5 is just AxAxAxAxA. You then deduce that A^a x A^b = A^(a+b). From that you start to assign meanings to things like A^0. And A^(-1). But what does it mean to multiply together -1 copies of a number? That doesn't make sense!

And what about A^{\pi} ? How can you have a transcendental number of things multiplied together? It doesn't make sense!

As you get deeper into math you need different definitions of powers, and of multiplication, and you find they they coincide with repeated multiplication and repeated addition, they may have originated with those ideas, but that's not really the best way to think about them, and it's not, in some sense, what they "are".

A poor analogy might be this. To an outsider, Smalltalk and Haskell will kind of look the same. They're programming languages, they do the same things. But they are really very different animals. So multiplication is really a very different animal from repeated addition.

</comment></comment><comment><USER25> This situation reminds me of one of my favorite stories about Plato [1]. He gave a lecture in Athens on The Good, and lots of people showed up, but the whole talk was about mathematics! I hope some folks somewhere will take the time to understand Mochizuki's world. The part about Yamashita studying with him privately is encouraging.

[1] described in this paper: [http://www.jstor.org/discover/10.2307/4182081?uid=3739856...](http://www.jstor.org/discover/10.2307/4182081?uid=3739856&uid=2129&uid=2&uid=70&uid=4&uid=3739256&sid=21102197047651)

</comment><comment><USER26> I think this points out the necessity to develop better proof assistant systems [1], in particular for automated proof checking [2]. However, I have never interacted with such systems and thus don't know whether it will be possible to just feed Mochizuki's formidable constructions into it.

[1] <http://en.wikipedia.org/wiki/Proof_assistant>

[2] <http://en.wikipedia.org/wiki/Automated_proof_checking>

<comment><USER27> I would not expect so. Mechanized proof systems tend to require a lot more detail than one would put into a proof meant for humans to read. There's been a lot of work in automating part of the generation of a proof, but that still requires a human to look at what the automation came up with and intervene to guide it in the right direction.

</comment></comment><comment><USER28> Mochizuki has this 1 page pdf posted on his website that tries to explain Inter-universal Teichmuller Theory through analogy to a Japanese animation: [http://www.kurims.kyoto-u.ac.jp/~motizuki/sokkuri-hausu- link...](http://www.kurims.kyoto-u.ac.jp/~motizuki/sokkuri-hausu-link- english.pdf)

I wish I could find the animation itself, but that link is broken.

<comment><USER6> Song from the album: <http://youtu.be/feOLbipVGEU>

If you find a copy of his explanation in Japanese I'll try to see if he's referring to a literal animation or not. I couldn't find one and he doesn't really refer to anything beyond the theme/concept and the girl's theta-like eyes.

Edit: Something else I found (<https://www.jstage.jst.go.jp/article/essfr/6/3/6_160/_pdf>).

<comment><USER29> Is that article written by Mochizuki? Can you make sense of it?

<comment><USER6> It is not written by Mochizuki (望月新一), but rather by Shiraki Yoshinao (白木善尚). You can see his profile here: <http://www.sci.toho-u.ac.jp/is/lab/shiraki_lab/shiraki.html>

I didn't really get much from it even with some assistance, but the very first part is a quick dialogue about a universe king and a neighbor universe king exchanging New Years gifts. Section 7 is about the そっくりハウス and goes with the page you linked, but ends by saying something about the multiplicative and additive rotational properties have something to do with the different universes seeing each other. He compares the girl's excitement to Mochizuki's upon discovering the identical house inside of a house.

Someone with better command could give a much better summary, but I'd personally be more interested in the lecture Mochizuki gave himself on it IUTeich last week (according to his site).

</comment></comment></comment></comment><comment><USER30> (ok, rant ahead)

I think mathematicians have a weird way of thinking about problems.

First-order logic for example: <http://en.wikipedia.org/wiki/First- order_logic>

It's quirky to think, for example, on the natural numbers that 'exists an operation + and a null element under that operation 0'

This is "very understandable" by humans, but very difficult to compute.

As such as this conjecture is stated in a way that looks qualitative (but has a good definition), still, usually it seems that proofs are even harder for theorems defined like that

<http://en.wikipedia.org/wiki/Abc_conjecture>

<comment><USER31> If you want general results, you need to abstract away from standard preschool algebra and build up models that then let you get said general results. That might appear 'weird', but I don't see how else you could get even to calculus, not to mention, for example, the algebra driving a sensible description of quantum mechanics or differential geometry.

You called it a rant, but could you maybe still make a suggestion on how to _better_ think about problems?

<comment><USER30> " you need to abstract away from standard preschool algebra and build up models that then let you get said general results"

Yes, of course.

" but could you maybe still make a suggestion on how to better think about problems?"

And that's what I meant. Thinking about problems in a different way (but still provable, and still working in a similar way)

For example, for Peano arithmetic you have that equality is symmetric (and transitive)

Now, there are several ways to explain that, and it's usually explained more or less by "for all X and all Y, if X = Y then Y = X"

Now, it would maybe be interesting to have a 'different explanation' that is as powerful as first order logic but works differently (and maybe easier to compute)

For example, it may be possible to write Peano arithmetic as a grammar (so zero would be ' ', one would be I, two would be II, etc)

<comment><USER31> And after you spent ten years reformulating basic maths in your fancy new logic, people will look at your papers and won't understand a word, which appears to be more or less what happened to our poor protagonist in the OP.

Furthermore, I have to admit I don't see the immediate advantage such a reconstruction would bring with it.

<comment><USER30> Well, the OPs reinvention looks like something more high level

Well, there may not be immediate advantages, but in math you never know. There are several hard problems in one domain that are trivial in another domain, for example.

An example from physics: <http://en.wikipedia.org/wiki/Hamiltonian_mechanics>

<comment><USER31> > There are several hard problems in one domain that are trivial in another > domain, for example.

Certainly, and this is pretty much what OP did, invent a new domain to solve a problem – Hamilton aka Lord Kelvin merely reformulated the problem slightly, and while I personally love Hamiltonian mechanics, I don't think it is comparable to 'inter-universal geometry' or replacing first order logic with something else.

So, yes, a different field may provide a different perspective and hence easier solution, but if you want to replace first order logic, you're not looking at a different/new field in maths, you're looking at rebuilding maths.

</comment></comment></comment></comment></comment></comment><comment><USER32> The first section of this article reminds of the film Proof.

<http://www.imdb.com/title/tt0377107/>

</comment><comment><USER33> "The point is not to prove the theorem," explains Ellenberg. "The point is to understand how the universe works and what the hell is going on."

School failed at conveying this to me in so many domains.

<comment><AUTHOR> The point I often finish with when I give talks is this:

        People tell you that the point of being good at science
        and math is to help you understand the universe, and to
        understand what's going on.

        This is only the first step.

        The real reason for being good at math and science is to
        BEND THE WORLD TO YOUR WILL !!

The kids seem to like that ...

</comment></comment><comment><USER34>
      "For centuries, mathematicians have strived towards a
      single goal: to understand how the universe works, and
      describe it."

I cannot resist engaging that loaded premise. It is a thought that I've wanted - for some time - for someone to skilfully dissect and lay bare for easy comprehension.

The closest I've come to seeing it, is the following - a concise and accessible yet well-rounded explanation of the relevance (or lack thereof) of mathematics to the fabric of our reality.

Alex Knapp, a science writer at Forbes :

      In the midst of a rather interesting discussion of the
      notion of Aristotle's Unmoved Mover, Leah Libresco went on
      a mild digression about the philosophy of mathematics that
      I couldn't let go of, and feel compelled to respond to.

      She says:

        I take what is apparently a very Platonist position on
        math.  I don't treat it as the relationships that humans
        make between concepts we abstract from day to day life.
        I don't think I get the concept of 'two-ness' from
        seeing two apples, and then two people, and then two
        houses and abstracting away from the objects to see what
        they have in common.

        I think of mathematical truths existing prior to human
        cognition and abstraction.  The relationship goes the
        other way.  The apples and the people and the houses are
        all similar insofar as they share in the form of two-
        ness, which exists independently of material things to
        exist in pairs or human minds to think about them.

      The notion that there's something special about math –
      that it has some sort of metaphysical significance – only
      makes sense if you ignore the history of how we uncovered
      math to begin with. It was, despite Leah's protestations,
      exactly just the abstraction of pairs and triplets and
      quartets, etc. The earliest known mathematics appear to be
      attempts to quantify time and make calendars, with other
      early efforts directed towards accounting, astronomy, and
      engineering.

      Mathematics is nothing more and nothing less a tool that's
      useful for humans in solving particular problems. Math can
      be used to describe reality or construct useful fictions.
      For example, we know now that the spacetime we live in is
      non-Euclidian. But that doesn't make Euclidian geometry
      useless for everyday life. Quite the contrary – it's used
      every day. You can use mathematics to build models of
      reality that may not actually have any bearing on what's
      real. For example, the complicated math used to describe
      how the planets moved in the Ptolemaic model of the solar
      system – where everything orbited in circles around the
      Earth – actually produced very accurate predictions. But
      it was also wrong. There aren't actually trillions of
      physical dollars circulating in the economy – there are
      just symbols for them floating around.

      The bottom line is that human beings have brains capable
      of counting to high numbers and manipulating them, so we
      use mathematics as a useful tool to describe the world
      around us. But numbers and math themselves are no more
      real than the color blue – 'blue' is just what we tag a
      certain wavelength of light because of the way we perceive
      that wavelength. An alien intelligence that is blind has
      no use for the color blue. It might learn about light and
      the wavelengths of light and translate those concepts
      completely differently than we do.

      In the same way, since the only truly good mathematicians
      among the animals are ourselves, we assume that if we
      encounter other systems of intelligence that they'll have
      the same concepts of math was we do. But there's no
      evidence to base that assumption on. For all we know,
      there are much easier ways to describe physics than
      through complicated systems of equations, but our minds
      may not be capable of symbolically interpreting the world
      in a way that allows us to use those tools, any more than
      we're capable of a tool that requires the use of a
      prehensile tail.

      Math is a useful descriptor of both real and fictional
      concepts. It's very fun to play around with and its
      essential for understanding a lot of subjects. But it's
      just a tool. Not a set of mystical entities.

This explanation is very satisfying yet disillusioning at the same time.

In short, his explanation allows for some (or a very large number of) mathematical truths (according to the consensus of mathematicians and what appeals to their logic) to be just that -- figments of numerical imagination that neatly sit in the confines of our logic.

Nothing necessitates all mathematical truths (much less conjectures) to be corresponding to some aspect (however minute or however large) of our reality.

Some truths might (purely out of happenstance), but nothing mandates that all math truths correspond to some facet of our physical reality.

So, some (or a lot of) math is just hocus pocus.

Non-mathematicians will never know owing to the very nature of peer-review and the consensus-building aspect of modern research and scholarship.

A few questions:

What other conclusions can be drawn if one were to find this explanation appealing?

Are there other explanations of the relationship between math and our reality, that you've found appealing?

Is there a consensus among mathematicians as to what higher-order math, essentially is in pursuit of or should be in pursuit of?

Is it an exercise of random shooting of darts hoping that some "mathematical truth" sticks and corresponds to some observable phenomenon?

Source:

Does Math Really Exist?

[http://www.forbes.com/sites/alexknapp/2012/01/21/does- math-r...](http://www.forbes.com/sites/alexknapp/2012/01/21/does-math-really- exist/)

Edit: Clean-up and rewrite.

<comment><USER35> It's cool that "Alex Knapp, a science writer at Forbes" has solved one of the major issues in the philosophy of mathematics by, erm, just asserting that Platonism is false. Of course, maths is a tool, but that doesn't mean that it is _just_ a tool, and Knapp doesn't provide any arguments for that conclusion. I can use a rock as a tool, but that doesn't mean the rock has no existence independent of my mind. In fact, the only reason the rock works as a tool is because it has an independent existence (I can hit things with it); the same might be true of maths.

Now, there are arguments for positions like Knapp's, but they're more complicated and contested than Knapp's facile post suggests. See, for instance, this Stanford Encyclopedia of Philosophy article: <http://plato.stanford.edu/entries/fictionalism-mathematics/>

<comment><USER36> Seriously. At least Leah Libresco had the intellectual clarity to declare herself a Platonist, as in, literally, a believer in or adherent to some part of Plato's philosophy.

Knapp latches onto a lack of empirical evidence for a Platonist viewpoint (though narrowly defines evidence as apparently needing to be extra-human to be valid, which isn't a well founded definition, but, then again, definitions are the fundamental problem here), and so he concludes that it must therefore be false, completely missing his own point.

Sorry. While there is a wealth of interesting discussion to be had on philosophy of mathematics, and even more discussion (and certainly more concrete discussion) to be had on the difference between how mathematics is actually created and how it is then defined in proofs and literature, this passage misses the boat.

Also, spitx: while fair use covers quoting from and discussing articles quite well, quoting the full article, even with discussion, could be problematic and certainly should be considered poor form. Take some quotes and then link to the rest.</comment></comment></comment>


Changes I would make to Go - <AUTHOR> http://sitr.us/2017/02/21/changes-i-would-make-to-go.html <comment><USER2> > First, functional programming is particularly difficult in Go. In fact the > language discourages functional programming.

Then it seems that Go isn't the language for you. With that Go nor any language, unless intended, is suppose to be a one-all solution for every problem. We can accomplish a majority, if not all, problems in a language, but this shouldn't assumed that a language is intended to do so.

<comment><USER3> While I understand the argument for simplicity and agree with the premise in most cases, I find it pretty hard to argue for this code:

        ys := []byte{}
        for _, x in xs {
          ys = append(ys, f(x))
        }

over something like this code, which is more obvious, less error-prone, and, though it relies on an additional concept, it's an extremely broadly-known concept:

        ys := collections.map(xs, f)

I don't think a proper collections library would require very invasive runtime changes -- though, once you start down this path, you and up at "but what if `f` returns `(myType, error)`, and then you're wishing for Option/Maybe types (which is another feature that I believe Go should have implemented, but is more obviously outside of the apparent mandate).

 _EDIT: It would make static analysis significantly more complex too._

<comment><USER4> Go can't do this, because you can't define `map` as returning "a collection of whatever `f` returns".

If they build a collections API like this now, without generics, and they then add generic types later, they will be in the same position Java found itself in - lots of painful API migrations.

While the generics debate is legendary in go, it does still seem very much like the intention is to eventually include it. Given that, I think it makes perfect sense to wait to introduce more special cases (like `append`).

In the meantime:

        func Map(in []interface{}, f func(interface{}) interface{}) []interface{} {
        	out := make([]interface{}, len(in))
        	for i, v := range in {
        		out[i] = f(v)
        	}
        	return out
        }

:)

<comment><USER5> It looks like you're making the same point as burke and the original article: Go lacks common-sense features that would make writing safe, simple code easy.

<comment><USER4> I guess we're agreeing on the fact that Go lacks generics. I don't know that I agree that those makes "writing safe and simple code easy". As we both know, simple and easy are two very different things.

Generics do make a lot of problems easy, but I don't think they inherently make problem solving simple. I absolutely miss them in Go - but I also remember how confused my high school programming teacher and I both were about them.

So far, Go seems to err on the side of Simple, if a choice has to be made. And, so far, the proposals for generics in Go seem to force that decision. I'm glad to see how seriously the Go authors take weighing the design and decision to include them.

<comment><USER5> Well I guess I misread your comment, then. I had assumed your code sample for a type-unsafe implementation of Map, followed by the smiley, was a recognition of the major lacking on Go, not just of generics but of the ability to operate on collections. I read burke's comment as suggesting a privileged collections library that doesn't go all the way to user-space generics, but perhaps I misread that, too.

I would strongly disagree with the definition of "simple" that you seem to be using. I don't think it's important for a language designed for software professionals to have only features that are easy for high schoolers to understand. It's far more important that experienced developers be able to write a common idiom like map with as little cognitive overhead as possible, that's the meaning of simple that I find valuable in this context.

</comment></comment></comment></comment></comment></comment><comment><USER6> OK, go will never have generics (except that it does in "make", "range", "chan", ok whatever...). That's fine with me. But including even just a few suggestions in the parent article would make Go a more approachable language to everybody.

* Pattern matching is intuitive and can be extremely powerful. * It's pretty clear that Null should not exist anymore. * Multiple return values, but no tuples?!

The go designers seem to not have a problem with special cases so why didn't they include special cases for an Option<T> and Result<T,E>, two things that, with pattern matching, would fit right into Go's explicit error checking philosophy.

<comment><USER7> > OK, go will never have generics (except that it does in "make", "range", > "chan", ok whatever...). That's fine with me. But including even just a few > suggestions in the parent article would make Go a more approachable language > to everybody.

The current position is that the core team will only include generics if they can find a design that satisfies them. Which has sounded a lot like "no, never" but Russ Cox has said that he wants to look into implementing generics again this year.

</comment></comment><comment><USER8> I really want to love Rust, but it's so visually unappealing :/ I love how clean Go looks. I know it's vain..

<comment><USER9> Like all things superficial, the more time you spend looking at something, the more the visual appeal (or lack thereof) normalises to average.

I think one tangibly good thing about Go though is how readable it is and how easy it is to grok, even with all the error handling boilerplate. I'd argue that Rust is also very readable though, and if the features of the language appeal to you I'd suggest giving it some time to get over the visual hurdle.

From a personal standpoint having spent years working in both languages, it's rare I'll choose Go over Rust nowadays purely for practical reasons. I'm roughly equally productive in both, but the end result tends to be much more performant, maintainable and robust on the Rust side.

<comment><USER8> Thanks for the encouragement!

</comment></comment></comment><comment><USER10> These are the changes that if made Go wouldn't be language it is. Go is simple, straightforward if little verbose. To me Go fits perfectly for business apps that I write currently in Java.

<comment><USER11> I'm not sure - I've been writing Go for 4 years in a production setting, when we switched our API service from Python to Go at the release of Go 1.1. Since then our default language is Go, and I write Go everyday. Things like Generics I haven't been really bothered by.

But where I thought he brought up really good points are

1\. nil. He's right compared to more recent languages, nil is awkward. I've been bit multiple times by the 'nil checks sometimes fail.' concept. Option/Sum types are so much cleaner, and having non-nullable types make a lot of things easier to reason about.

2\. error checking. My main gripe is when you are writing a process that involves calling multiple functions that could return errors. You then need more boiler plate in order to stay sane and DRY - and I've admittedly bitten myself with the 'err' shadowing that happens sometimes.

I don't think a Maybe type would have made Go more complex, and I think it would have fit in nicely with the 'Zero Value' concept.

<comment><USER12> Maybe/Option/Result types don't work without generics, because you significantly reduce the type checking.

<comment><USER13> I'm not a Go programmer, but from what I understand, things like Go's map implementation in the standard library are usable as if they're generic. Couldn't they add a few more types like this (e.g. Option and Result) in the same way without exposing generics as a language feature?

<comment><USER14> I program some Go - I believe you are talking about the 'empty interface', e.g. map[string]interface{} The problem with that is that you instantly lose compile-time type checking, and have to check/assert the types yourself at runtime after accessing the map. In a strongly-typed language this kinda goes against the grain, and is a PITA. (Although it still can be useful at times). My 2p.

<comment><USER15> The point is that a map can be type safe because it's built into the language, and that the designers could do exactly the same with a maybe/option/result feature.

</comment></comment></comment></comment></comment></comment><comment><USER16> Like C, Go is a small language. Given that the creators of go like its smallness and simplicity, all those features are never going to be added to Go.

When Bjarne Stroustrup wanted to add OO features to C, he created C++, initially as a translator that output C. If someone wants to add features to Go, they can create a "Go++" to Go translator, with pattern matching, generics, tagged unions. Clearly it's guaranteed to be very popular! /s

<comment><USER17> It's the approach Robert Griesemer (member of the Go core team) chose to prototype implementation of operator methods in Go: [https://github.com/griesemer/dotGo2016](https://github.com/griesemer/dotGo2016)

<comment><USER16> Actually it looks like he forked and modified the go compiler itself.

</comment></comment></comment><comment><USER18> > First, functional programming is particularly difficult in Go. In fact the > language discourages functional programming.

Well, if I were the king of the forest, I'd move functional programming from Rust to Go. With Rust, there's a lot of this higher level stuff in a supposably lower level language that would be more at home and useful over in the two letter language.

<comment><USER19> > _there 's a lot of this higher level stuff in a supposably lower level > language_

I feel like you're suggesting that "high level stuff" is bad because it's "high level stuff."

In my opinion, the goal of low level languages is to operate under certain constraints. If you can operate under those constraints and still include "high level stuff," then you should.

</comment></comment><comment><USER20> For Go people: How (learning) Go made you better programmer?

I haven't written any of these two languages but I have read Rust doc few times in depth and I constantly miss many of it's features in my daily .net work since then.

Example: -Optional over null -Union types -Trait implementation is independent from source and target models

<comment><USER21> Go made me appreciate static typing and a compiler.

Before picking up Go around the 1.0 release, the last time I spent any significant time with those tools was 10 years prior as an undergrad using Java. Java really made me hate those things. I spent the years in between with languages like Ruby, JavaScript, and Python.

Now I actually prefer using compiled, statically typed languages, Rust being the most recent one for me (and I still dislike Java).

<comment><USER20> Welcome to the dark side =)

I am not a Java fan either but I felt dynamic languages even worst. Since then I have loved to modern static type systems like in Rust (in theory) and Elm/Haskell.

</comment></comment></comment><comment><USER22> This article should be called, "Things I'd like to see in Go from Rust".

<comment><USER23> Rust is really a language that pulled a lot of concepts that were done elsewhere, into a really solid nice package.

Go is unusual in the new language space in that in eschewed many of these modern techniques. Swift comes to mind as a comparison, which has many of the features that the author misses.

Personally I like the examples offset by a single other language as it's less context switching.

<comment><USER24> That's the feeling I get when using Rust: all of the bits of the language appear to work well together. People clearly thought about how all of the features in Rust would interoperate; it was _designed_.

Go, on the other hand, continually feels like a language that wasn't designed as much as it accumulated. None of the parts seem to work in concert. Nil by itself was a bad idea, but when combined with actually-nil-but-not-really interfaces, it leads to subtly broken code. Tuples feel bolted on as second- class citizens, and tuple-based error patterns combined with sometimes- nonsensical zero values for types makes it uncomfortably easy to accidentally use invalid values when you have a typo in error-handling. Implicitly implementing interfaces makes sense until you type-switch on interfaces at runtime, and then through edits elsewhere one interface becomes a distinct subset of the other interface — depending on how they're ordered, you may never hit the other code.

Some of the decisions made in golang make sense in isolation, but in concert they lead to confusion, subtle bugs, and copy-pasted code everywhere.

<comment><USER25> I feel the exact opposite... Go is a bold design, if not an elegant one, yet powerful. Rust is a design-by-committee language, built from accretion and removal. Its origins as a managed language, pivoted and is now a second system C++ replacement -- the only one, to be fair.

<comment><USER26> Elegant is.. not the first word I'd use to describe Go. Maybe the core of the language is, but in practice it is anything but, between the error handling, PRY (please repeat yourself), relative inability to create abstractions, and neutered type system.

</comment></comment></comment></comment></comment><comment><USER27> It seems to me golang and Rust are often being compared with each other. Given that Swift starts to be used on server side, I would love to see some comparison between golang and Swift, or Rust and Swift.

</comment><comment><USER28> Crystal would be a great choice for the author.

</comment><comment><USER29> Do language debaters all think every human should speak one language?...

<comment><USER30> Yes. And it should be Lojban. ~

<comment><USER31> I'm not sure I understand. Could you please translate your comment into Lojban?

</comment></comment></comment><comment><USER32> Just another generic complaint about Go's lack of bloat. It's all completely naive, never understanding why Go doesnt want generics beyond a simple "b-b- but look, the pattern matching of Rust is simple too!" No it isnt simple just because you say it is. It is the opposite of simple. I've read the Rust docs on it several times and I still dont have a clear mental picture of how to read a match statement out loud. "match result with Some(number) .. then do..? But match HOW?" I've been thinking of a clearer syntax/naming for match and in my humble opinion it should literally just be called 'if' and any inconsistency that doesnt align with that be removed from the language. Calling 'match' match is haskell programmers gone wild. Programmers in the real world dont have a clue how to read 'match'

<comment><USER33> If you have the time and inclination, I'd love to know if the second edition of the book makes it more clear to you [http://rust- lang.github.io/book/second-edition/ch06-02-match...](http://rust- lang.github.io/book/second-edition/ch06-02-match.html)

</comment></comment><comment><USER34> I can't believe you can look at that ugly colorscheme whole day working in even uglier language which rust really is.

</comment><comment><USER35> Here we Go

<comment><USER36> _Here we Go_

We're rewarding these posts with attention. I guess on some level, these language wars are gratifying.</comment></comment>


Ask HN: Who is making passive income? - <AUTHOR> <comment><USER2> s/Ask HN: Who is making passive income?/Ask HN: Tell me how you're making some extra cash so I can head into direct competition with you./g

</comment><comment><USER3> How passive are you looking for here?

There's a biiiiig difference between genuinely passive "no work required; cash just turns up", 1-4 hr a month maintenance-mode businesses, the classic 4 hour work week, and even (I've seen people refer to this as "passive income") 1-2 hours a day side-businesses.

<comment><AUTHOR> I am for 1-2 hours a day side business.

<comment><USER4> That is called a second job.

</comment></comment></comment><comment><USER5> I made an app (in a weekend) to view upcoming train schedule for my country public train service, been earning averagely $0.50 everyday without doing anything at all. Not a life changing amount but it covered my website domain/hosting cost.

<comment><USER6> Web or phone app?

<comment><USER5> Native phone app on both iOS/Android platform</comment></comment></comment>


XKCD Plots in Matplotlib: Going the Whole Way - <AUTHOR> http://jakevdp.github.io/blog/2013/07/10/XKCD-plots-in-matplotlib/ <comment><USER2> And if you want XKCD-style in gnuplot:

[http://rfonseca.github.io/xkcd-gnuplot/](http://rfonseca.github.io/xkcd- gnuplot/)

</comment><comment> stargazer-3 Looks like xkcd functionality will soon be moved to its own style: [https://github.com/matplotlib/matplotlib/issues/5992](https://github.com/matplotlib/matplotlib/issues/5992)

</comment><comment><USER3> Some of these lines look too sinusoidal to me. I would want more randomness for the "hand drawn" look.

<comment><USER4> Agreed. A bit too much uniformity and not enough noise.

<comment><USER5> But you don't want to distort the message either. How do you know that you will not infer the wrong conclusion on another chart if you bend the curves, think of a chart showing two curves, one being slightly higher than the other.

</comment></comment></comment><comment><USER6> How to tell when your comic has made a real cultural impact: 101.

</comment><comment><USER7> Quite a nice look. It's interesting how Physics and geometry problems are often best indicated with rough hand-drawn diagrams. If you draw a freehand triangle with chalk on a board, you can't help but seeing it as an idealised triangle - an indication of some symbolic representation engine in the brain.

</comment><comment><USER8> Does anyone else think there is a period to the borders? I looked for it to be more apparently unpatterned.

<comment><USER9> Yes, likely it's just sin()... Looks too regular to my eyes.

<comment><USER10> It just needs some random noise to be perfect!

</comment></comment></comment><comment><USER11> I've drawn graphs by hand (using a pen-tablet), it's fun and looks nice. But then I realized I had a bug in the data. fuck!

<comment><USER12> If you use a pressure-sensitive vector drawing program, like Adobe Illustrator, you can go back in and edit your lines afterwards.

</comment></comment><comment><USER13> By no means to I want to sound like a party-pooper (truly, I love this stuff and plan to use it), but this feels like this is the "Comic Sans" of graphing. In an essence, we know better than to use it in a serious sense, but someone, somewhere might use it incorrectly, then suddenly, poof, everyone's XKCDing their graphs

<comment><USER14> Just like Comic Sans, I'm not really sure there is an appropriate use for XKCD style outside of the actual XKCD comic and similar-style comics. It's a cliche that has no functional purpose.

<comment><USER15> Why does everything need to have a functional purpose? Can't hacking be just for fun, playing around, and seeing what you can do?

</comment></comment></comment><comment><USER16> Related: [http://cmx.io/](http://cmx.io/) for markup-based xkcd-style comic generation, this old thread on xkcd-style graphs, which includes some d3 examples: [https://news.ycombinator.com/item?id=4597977](https://news.ycombinator.com/item?id=4597977), and [http://xkcdgraphs.com/](http://xkcdgraphs.com/)

</comment><comment><USER17> Do log plots (with scientific notation) work yet?</comment>