The history of 'zero' remains unsettled - <AUTHOR> https://www.nytimes.com/2017/10/07/opinion/sunday/who-invented-zero.html <comment><USER2> Indian mathematicians like Aryabhatta have never been given the same credit as western ones, it all stems from the British invading India and seeing a civilisation that was much older than what the Bible stated (4000 years). Now the hardline Christian invaders couldn't have any of that, people that are older than their own religion would have thrown doubt into their own people. So they gave India very little credit.

</comment><comment><USER3> It's a bit odd to intermingle talk of a _written_ symbol for zero with the use of binary by computers. If I chisel open my Xeon, I don't think I'm going to find 1 and 0 symbols, and likewise the vast majority of the source code for what's running on it won't contain binary literals either.

The "ones and zeros" way of talking about computers to a general audience is a bit of a cliche at this point IMHO.

The squirrelly nature of zero in a purely physical sense is interesting to focus on. e.g. if you use the fingers on your hand to count, then zero can be represented by either a closed fist, or by the absence of the hand altogether (unary numbers). No need to involve bleep-bloop-computers or even a sheet of paper.

I'm coining a phrase: "Unary is the native number system of the eyeball."

</comment><comment><USER4> I expected something actually substantial, but apart from the opening gambit, the remainder of the article is somewhat in jest.

<comment><USER5> Somewhat, yes, I suppose it's just making the point that 'the west' doesnt have a monopoly on foundational intellectual achievements.

<comment><USER6> Much of math's foundation isn't from the west. Even our numerals aren't from the west. They came from India by way of Arabia.

Also, I'd probably pick a different source if I were expecting deep commentary about science or math. That's not intended as a slight, it's just about the target audience.

</comment></comment></comment><comment><USER7> I would use the word "discovered" rather than invented.

<comment><USER8> Found the mathematical realist! I'm more of a formalist myself, given the uncertain nature of where mathematical objects have to live if they are not just a useful tool we came up with to understand our surroundings.</comment></comment>


More Pupils Are Learning Online, Fueling Debate on Quality - <AUTHOR> http://www.nytimes.com/2011/04/06/education/06online.html

<comment><USER2> "Mr. Hamilton, who had failed English 3 in a conventional classroom and was hoping to earn credit online to graduate, was asked a question about the meaning of social Darwinism. He pasted the question into Google and read a summary of a Wikipedia entry. He copied the language, spell-checked it and e-mailed it to his teacher."

If the goal of the school improvement program is defined as increasing high school graduation rates, there will be strong incentives to allow this kind of academic misconduct. Only if the goal of the school improvement program is to improve student learning outcomes will there be any chance of checks and balances being put into place to make sure the students can think independently. Even at that, those checks and balances will only be in place if the authorities evaluating student learning are not the same authorities running the program. The program has to be evaluated on the basis of independent evidence gathered directly from students in monitored conditions.

That said, I am very happy about the ALEKS online courses

<http://www.aleks.com/>

my three younger children are currently using to study mathematics in a homeschooling setting. I can look in on their work from time to time, and they can also use the software independently, from quite a young age because they can read well, to focus exactly on the mathematics they need to learn next. The problems are open-ended and reasonably well designed. The theory behind the "knowledge spaces" model for the ALEKS course design

<http://www.aleks.com/about_aleks/Science_Behind_ALEKS.pdf>

is quite elegant. Based on recent posts here on HN, my oldest child still at home is now delving quite a lot into Khan Academy lessons. I am still making my mind up about how well I like the exercises that go with the Khan Academy videos, which are still undergoing further development.</comment>


The Cost of Cooperating - <AUTHOR> https://www.edge.org/conversation/david_rand-the-cost-of-cooperating <comment><USER2> Rand spoke at the LSE about cooperation recently. [http://www.lse.ac.uk/website- archive/newsAndMedia/videoAndAu...](http://www.lse.ac.uk/website- archive/newsAndMedia/videoAndAudio/channels/publicLecturesAndEvents/player.aspx?id=3672)

"Strategic cooperation is extremely important; it explains a lot of real-world cooperation. From an institution design perspective, it's important for people to be thinking about how you set up the rules of interaction—interaction structures and incentive structures—in a way that makes working for the greater good a good strategy."</comment>


Stanisław Lem doodle - <AUTHOR> http://www.google.ru/?hl=en

<comment><USER2> You can get some debugging information using:

[http://www.google.com/?lem-debug&lem-show- performance](http://www.google.com/?lem-debug&lem-show-performance)

If you press [N] you can skip the scene. [T] simulates a hit in the canon scene. [Space] fast-forwards.

Source (readable after using a beautifier):

<http://www.google.de/logos/2011/lem.2.js></comment>


Why do people criticize the performance of Java, but not other JVM langs? - <AUTHOR> A lot of the Java jokes and criticisms make fun of the perceived poor quality of the JVM. For example, the JVM is used to cook a barbecue in this comic: https://www.reddit.com/r/ProgrammerHumor/comments/8res2s/no_problem/
However, criticism of the JVM seems to be forgotten in the context of JVM languages that are not Java. For example, I've never seen people make a joke about Scala's or Clojure's performance. Java seems to be very popular to bash, with the JVM being one aspect of its unpopularity, yet other languages that target the JVM receive positive attention and may even be trendy.
Why is this so? I know that people see Java as "uncool" or "corporate" due to its verbosity and emphasis on sometimes over-engineered object-oriented design. Other JVM languages may be better than Java in this regard. However, the JVM also tends to be cited in Java criticisms e.g. jokes, even though criticisms of it also affect "trendier" languages.
At the risk of saying an unpopular opinion, maybe the criticism of the JVM's performance is irrationally tied to an association with Java, an "uncool" language, and when a "trendier" language uses the JVM, people don't care, because they really dislike Java, not the JVM?
Or maybe people do criticize the JVM in the context of languages such as Scala, Clojure, and Kotlin, and I just haven't been paying attention? <comment><USER2> Not sure about the speed criticism. Usually it's memory usage by the JVM that's a turn off. Out of the other languages you mentioned Clojure is for sure slower but if you're working with that or another JVM language like Kotlin you're so happy to not be writing Java you don't care about the other issues. I often say I wish I learned Java first so I did not know any better. It's generally pretty unpleasant compared to most other languages I'm used to.

</comment><comment><USER3> Slow is relative. Java was originally an alternative to C++, which is much closer to the metal and can be significantly faster than the JVM allows.

If you're deciding to use Clojure or Kotlin, the alternatives you're considering are probably Java and Scala, or maybe even a web-friendly scripting language - not C or C++.</comment>


TimeHub. Create invoices from Github commits - <AUTHOR> http://timehub.net

<comment><USER2> As the resident "I want my commits to be beautiful" purist around here, I have to say that I really, really dislike this idea. Commits are rarely exactly bound to a specific billable item on an invoice.

Implementing a feature could and often does cause mutliple commits.

A system like this either encourages to mush everything together into one commit (bad) or it creates basically empty or non-related commits after implementing the feature so it appears on the invoice.

But this is just me. I see how this could be useful for people who are not such purists as I am. On the other hand: In my SVN times, I would have used a service like this in a heartbeat. Even in my early git days.

But after learning about optimizing commits and about the beauty of a clean history, I now changed my mind about this. So ask yourself: Is there any chance you might shift in your thinking about the commit history? If yes, do you really want to have commits in your history that you might at one day consider to be really bad ones?

<comment><AUTHOR> I know that most of the times (ok, all of the times) you'll have more than one commit for any feature you develop.

We'll have a small gem or something to do that. You'll start your work and we'll track your time and at the end make a commit with the time stamp (or use git notes to keep the commits clean). All the commits you do in that time will be "ignored".

We don't have this now because we didn't have the time to do this (48 hours is not that much you know).

Thanks for the feedback anyway. Well have your comments in mind when developing v2 and the gem.

<comment><USER2> > We don't have this now because we didn't have the time to do this (48 hours > is not that much you know).

I didn't intend to bash on your project. I'm sorry if my comment read that way.

I was just saying that I, personally, would not want my commits to be tied to an invoice that is most likely going to be read by a non-coder because that would severely hamper the quality of my commits.

I do believe though that for other people this might not be as much of an issue - heck it probably wouldn't for me if I were working on different stuff than I'm working on right now.

I just wanted to inform the people here not to jump to conclusions but think what this integration might (or might not - depending on their situation) do to their commits.

I LOVE it when people like you have a cool idea and follow through; whether the result is usable for me or isn't.

<comment><AUTHOR> Oh no, no "offense" taken. We really appreciate feedback (all of it).

Having people disagree with the app forces us to make it better.

About the messy commit messages, that's why git notes may help (keeps your commits clean, but you still don't have to write the invoice entries again and again).

Thanks! :-)

</comment></comment></comment></comment><comment><USER3> This is awesome, and came at just the right time for me!

Last February, in my last semester of college, I heard about an iPad contracting job. I had never done any freelance work before, so I thought it would be a good opportunity to see what it was like. I gave the client a whole-project quote based on some conservative time estimates and an hourly rate a little below the market.

After that I didn't really track hours since they were paying per feature milestone, so when the project was over I had no idea how much time I had actually spent on it. I had planned to write a utility to estimate the time from my Git commits. You beat me to it! (Turns out I'm faster than I thought. :-))

I just finished writing my own time tracking tool, but I may use this instead for projects that can be represented entirely by their git repository.

Some comments:

\- I have a _lot_ of repositories, most of them small personal projects or other people's open source projects. Can you let me only import a couple, maybe preferring private and recent repositories?

\- The design is very nice

\- Can you separate the time estimation from the cost calculation? I'm sure a lot of people are interested in that functionality by itself.

\- If I'm going to back-fill estimates, I want to see the diff, but the links to the commit diffs are on the page before you can enter the estimates. Add links to the page where you can enter your own estimates!

<comment><USER4> This doesn't seem like it estimates anything - just searches for a particular pattern in the commit messages and does some simple arithmetic.

</comment></comment><comment><AUTHOR> This is my entry for the Rally on Rails (Rails Rumble for latinamerica) contest.

Please check it out and if you like it, vote for us.

Thanks

<comment><USER5> Incredibly strange timing; I just released my gem, Big Bucks No Whammies, that essentially does the same thing as your service. <https://github.com/aantix/big_bucks_no_whammies>

It has some advanced features like estimating the time spent on each line item based on number of commits or number of source changes.

For more accurate invoicing, you would utilize an app like TimeSink to record your computer's activities and then BBNW can cross reference that time spent with your git commits and figure out the billed activity that way.

Nonetheless, absolutely great job on the implementation! I had no idea anyone else was working on the same problem. If you're in the Bay area, I'd love to collaborate.

</comment></comment><comment><USER6> Nice work. Simple idea and well executed.

Two quick things came to mind.

An option to only select commits with entered times would be handy rather than having to deselect the estimates and non value commits (maybe this is implemented but I didn't create a commit with a time value).

Think someone else mentioned this, but the ability to override or add time to estimated and/or non value commits.

</comment><comment><USER7> It's a great tool, calculated the same value that I charged.</comment>


Hillary Clinton and Electoral Fraud - <AUTHOR> https://medium.com/@spencergundert/hillary-clinton-and-electoral-fraud-992ad9e080f6#.nsfpqoq75 <comment><USER2> This article from 2012 talks about how incorrect exit polls have been in the past and a little bit of the why:

[http://www.theguardian.com/commentisfree/2012/jun/06/outrage...](http://www.theguardian.com/commentisfree/2012/jun/06/outraged- wisconsin-exit-polls-so-wrong)

From WaPo: [https://www.washingtonpost.com/news/the- fix/wp/2016/04/22/ho...](https://www.washingtonpost.com/news/the- fix/wp/2016/04/22/how-exit-polls-work-explained/)

Another good one: [http://www.mysterypollster.com/main/2004/12/what_is_the_sam....](http://www.mysterypollster.com/main/2004/12/what_is_the_sam.html)

</comment><comment><USER3> Nonsense. Results have matched extremely closely with polls coming in. Discrepancies with exit polls are small AND exit polls have always favored more ardent supporters and younger supporters.

People who are more enthusiastic about their choices are more likely to do exit polls. Get over it. Hillary Clinton is going to win this nomination because she won (by far) the most votes. That doesn't mean you have to like her, like the way this system works, or want her to be President. I support her out of all the candidates running and I don't like ANY of those things! But let's stop the conspiracy theory nonsense and move on to things that matter.

</comment><comment><USER4> Looks like some picking and choosing of data. I hate Hillary, but You need better data than this if you want to be taken seriously when accusing a candidate of voter fraud.

<comment><AUTHOR> For a comprehensive analysis of the voting data I would recommend to have a look at the blog of Richard Charnin: [https://richardcharnin.wordpress.com/2016/04/20/ny- democrati...](https://richardcharnin.wordpress.com/2016/04/20/ny-democratic- primary-more-frustration/) as well as the research paper on electronic vote flipping by Francois Choquette and James Johnson: [http://madisonvoices.com/pdffiles/2008_2012_ElectionsResults...](http://madisonvoices.com/pdffiles/2008_2012_ElectionsResultsAnomaliesAndAnalysis_V1.5.pdf)

</comment></comment><comment><USER5> Conspiracy theory nonsense.

</comment><comment><USER6> Democracy is _far_ too important to be left in the hands of the people, it would seem.

How would others here on HN suggest implementing a trustable voting system? What problems do you forsee it having?

<comment><USER7> > Democracy is far too important to be left in the hands of the people, it > would seem.

Very contradictory, and some would say elitist. Many of the problems with our democratic republic system (we don't live in a democracy) arise due to the entrenched oligarchic power structure and excessively lenient campaign finance laws, which basically give the power of the purse to corporations and executives. The people are not to blame when political parties only choose to push candidates who have wholly existed within this power structure and are completely out of touch with the needs of the country as a whole.

If a government represents its people within constraints (avoiding discrimination or prejudice and avoiding harm to people by way of a Millian criminal justice system), those people should logically be happier.

Examples: marijuana legalization, welfare, basic living income, civil liberties, non-interventionist foreign policy, checks and balances on law enforcement.

If the government couldn't be trusted with the masses, voter suppression laws would be successful at turning the tides of the country away from unrest and inequality and unhappiness. They haven't, and to suggest otherwise is a laughably elitist and ridiculous sentiment.

<comment><USER8> > Very contradictory, and some would say elitist.

No, not elitist. It recognizes that the will of the people must be done, but... not so fast. The problem is the will of the people can be really immoral and can cause rampant chaos and riots. Beheadings, storming the castle, all that.

The whole idea is for the electoral college to dampen the swings. Stability benefits all.

Sure, change. Progress. But deliberate change. Slow change.

Take one example: Gay rights. Clinton the 1st passed "don't ask, don't tell" in .. what? 1993? And then we let the whole issue simmer for a generation. Because that's what it takes. It takes old people dying off, for the population to come around to a better way of running things.

(Dying off without being murdered)</comment></comment></comment>


Ask HN: Does anyone have something negative to say about RISC-V? - <AUTHOR> There seem to be (deserved) unanimous love for RISC-V, but are there thing that could have been done better? or choices without a clear best answer on which there is still some debate?<p>I believe that learning where a technology is weak is a necessary step to learning where it is strong <comment><USER2> It's hard to critique a design that's mostly hypothetical (implementations exist, but those parry critiques such as "it is slow" or "it doesn't have vector instructions" with "it's only the first version").

So, the only thing one can readily critique is the instruction set. Here, they made trade offs that some would argue are bad. For example

\- They deliberately choose to leave parts of the instruction space open. That's good for extensibility, but must have a negative effect on code density.

\- They are extremely liberal in allowing implementations to mix and match instruction set extensions. There already are 13 different extensions, potentially allowing for 8,192 different instruction sets (many of them quite silly), and they are already thinking on how to handle over 26: _"Since single letters will run out someday, it is currently discussed to use a new naming scheme with Zxxx for standard instruction extensions and Yxxx for non-standard (vendor specific) instruction extensions"_ ([https://en.wikipedia.org/wiki/RISC-V#ISA_Base_and_Extensions](https://en.wikipedia.org/wiki/RISC-V#ISA_Base_and_Extensions))

<comment><USER3> First of all, the ISA does not need implementations to be non-hypothetical. The ISA is defined and frozen and that includes most of the extensions.

There have been 100s of tap-outs from different RISC-V chips. So clearly its not hypothetical in that sense either.

> \- They deliberately choose to leave parts of the instruction space open. > That's good for extensibility, but must have a negative effect on code > density.

and

> \- They are extremely liberal in allowing implementations to mix and match > instruction set extensions.

That's not a problem that is a feature. It was specifically designed to extendable and to have many different extensions so implementers could pick and choice of what they want.

RISC-V is designed to work for close to sensor tiny chips all the way to super-computers and everything in between. To be able to handle that with one instruction set you can not force every deeply embedded chip to implement all the features.

To combat the explosion theoretical ISA the foundation defines profiles. Profiles are designed to select standard configurations for specific applications or groups of users. For example, RISC-V for Linux uses 'RV64GC' and all Linux software uses it.

However if you use RISC-V internally you can pick whatever you like for your needs.

<comment><USER2> Early Bluetooth had (and probably still has) profiles, too. I don't think it is a slam dunk to say they were a net benefit.

Similarly, USB-C cables may or may not allow USB 3.1 (doubles speed to 10Gbit/s), power delivery, or alternate mode (sending video signals over some of the pins). That makes it easier for suppliers to create such cables, but does it help adoption?

Further back, the first phones running java featured so many profiles that programs were barely portable between phones.

</comment></comment></comment><comment><USER4> There's nothing particular interesting about RISC-V. It's a simple, clean, boring MIPS-like ISA.

A lot of their freedom to keep it simpler and cleaner than older RISC ISAs comes from the fact that they aren't responsible for engineering real implementations; whereas the MIPS and SPARC and ARM folks ended up with delay slots and register windows and conditional execution because it helped them get high speed CPUs out with the processes of the day, the RISC-V people just say "well, those eventually turn out to be bottlenecks for high speed- implementations, so we won't have them" \- never mind that these hypothetical high-speed implementations will require enormous engineering efforts and will require piles of money to actually build. We're not quite talking "Sufficiently Smart Compiler", because the technology does exist - but it's not totally far off.

People have been comparing it to Linux, but it's just an instruction set, not an implementation of one - so it's really more like POSIX - just a theoretical standard of compatibility that'll allow an ecosystem to build around it.

The problem is that, as Someone mentions in this thread, there's lots of officially codified extensions, and no restrictions (as far as I know?) to keep implementors from devising their own. We'll see how this turns out; my guess is, if RISC-V catches on, we're going to end up with mutually incompatible extensions, balkanization, and proprietary extensions becoming accepted "standards" in the "embrace, extend, extinguish" style.

<comment><USER3> > A lot of their freedom to keep it simpler and cleaner than older RISC ISAs > comes from the fact that they aren't responsible for engineering real > implementations;

So David Patterns doesn't understand anything about implementations?

They designed and tapped out many chips including out-of-order cores before they froze the ISA and they are confident that it works for simple and high- performance implementations.

You seem to imply that 'delay slots and register windows and conditional execution' might not be needed for high performance but maybe that RISC-V does not have them harms them if they don't have 'high-speed implementations' but that is not correct. RISC-V is competitive or better compared MIPS, SPARC, ARM on the low end.

<comment><USER4> I don't mean to suggest that the involved parties don't _know_ about microarchitectural implementations. Names aside, it's clear from reading the RISC-V documents that they do. And I don't mean to imply that they're wrong about the various "unclean" elements of other RISC ISAs being bottlenecks, either.

All I mean to say is: as academic designers of a license-free ISA in the 2010s, to whatever extent they're incentivized at all, they're incentivized towards designing a "simple" and "elegant" ISA regardless of the concrete impact on performance or die space in a way that the MIPS, SPARC, and ARM teams in the early 80s - designing for commercial production and profitability using the processes of the time and their limited resources - weren't.

That's not necessarily a criticism - but the consequences of their decisions on performance and adoption are harder to say. You're claiming otherwise, but without further evidence and based on my personal understanding of architecture and microarchitecture design I believe that ceteris paribus a low-end RISC-V implementation is likely to perform worse and use more silicon than the corresponding MIPS, ARM, or SPARC implementations. A high-end speculative, out-of-order, modern process, etc RISC-V implementation would likely be able to outperform a similar one for those architectures with less silicon. The question for me is whether we get to the point where the market builds one, and whether those potential performance improvements would (alone or in tandem with RISC-V's other benefits) justify adoption.

<comment><USER3> I see your point about intensives.

However I have to disagree on your opinion on the hardware. RISC-V was specifically designed to be able to do low end very well. The whole encoding for example is optimized to a tiny amount of space. The overall instruction set again is designed to use minimum amount of space as well.

There is a whole project about 'ultra low power processors' at ETH Zürich [1]. They have specifically selected RISC-V because it fit their needs so well and they produce cores that beat available ARM and MIPS cores specially on energy. IBM selected a RISC-V core for their project in 'Next-Generation Edge Computing' [2].

So it seems to me that small and simple really does pay of when going to very tiny cores.

[1] [https://www.pulp-platform.org/](https://www.pulp-platform.org/)

[2] [https://content.riscv.org/wp- content/uploads/2018/05/16.10-1...](https://content.riscv.org/wp- content/uploads/2018/05/16.10-16.25-Seiji-Munetoh-IBM-Japan.pdf)

</comment></comment></comment></comment><comment><USER5> I have been following the main RISC-V ISA design mailing list for a while, and of course there has been criticism of some design decisions there.

My personal criticism would be that there are still missing parts: the B extension (bit operations like count leading zeros/count trailing zeros/popcount/byte swap), the V extension (extensible vector operations), and the P extension (packed SIMD) aren't ready yet. If your problem domain needs these, you'll have to either wait until they're specified, or use a non- standard extension (of course, a benefit of the RISC-V ISA design is that it makes easy to use non-standard extensions when you need to).

Other criticisms I've seen in the mailing list:

\- As already mentioned by someone else here, the RV32 and RV64 variants (32-bit and 64-bit registers) are incompatible, that is, code written for RV32 won't run on RV64, while with some small tweaks to the instruction encoding, it could;

\- Some have argued that the C extension (compressed 16-bit instructions - normal instructions are 32-bit) could have been done in a better way;

\- All Linux distributions have converged on RV64GC as their base ISA, which includes the C extension, and some have complained about this choice;

\- There have been some complaints of possible interrupt latency on embedded systems due to having to save/restore registers without hardware help.

</comment><comment><USER6> Integer divide by zero does NOT raise an exception.

From the Spec: We considered raising exceptions on integer divide by zero, with these exceptions causing a trap in most execution environments. However, this would be the only arithmetic trap in the standard ISA (floating-point exceptions set flags and write default values, but do not cause traps) and would require language implementors to interact with the execution environment's trap handlers for this case. Further, where language standards mandate that a divide-by-zero exception must cause an immediate control flow change, only a single branch instruction needs to be added to each divide operation, and this branch instruction can be inserted after the divide and should normally be very predictably not taken, adding little runtime overhead.

<comment><USER7> Is this a genuinely bad decision? The spec makes a good job arguing why it's not.

</comment></comment><comment><USER8> It is not really something negative (because it will have to be seen in the future), but to me the biggest point about RISC-V is whether it will deliver its promise of eventually giving birth to completely open and high quality CPUs. The experiments so far are interesting and the people and firms working on it seems (to me) to be trustworthy, but the implementations so far are still lacking: the HiFive Unleashed board has a lot or proprietary IP inside and I am told that it has some stability problems. I understand and agree that things take time, but in the end we will have to see if a good and open ecosystem develops around RISC-V or not.

<comment><USER9> Moreover, no one is releasing the gate-level netlists nor the LEF and DEF nor mask data. Without those you can't have security unless you build your own.

</comment></comment><comment><USER9> What I have negative to say has more to do with those producing implementations than the architecture or RTL. In order to have the security afforded by being open, every part of the process must be open from the spec to the silicon. The entities producing RISC-V devices are simply passing forward the RTL along with their additions and changes. They are not releasing the work product of any of the steps between there and silicon. There are many differences between RTL and the gate-level representation, many of which represent potential security issues (testability features, for instance.) Between gates and physical design more changes can be made and between physical design and mask, even more. Some of those could result in sloppy security holes or some could even be maliciously introduced security holes. With any of the current providers there is no way to know or test for these potential issues.

</comment><comment><USER10> Note that the following are just my impressions from reading though the spec about a year ago. I did not do any deeper investigation beyond that and might misremember some details.

* IMO they were a bit too generous with using up 32-bit instruction encodings, only 3 of 28 major opcodes (blocks of instructions) are still reserved, though there is still some space for individual instructions within several of the used blocks. Using 4 major opcodes for 4 different sign variants of fused multiply-add seems particularly wasteful. (Of course there is still plenty of space in 48-bit and longer instruction spaces)

* Integer overflow handling code is quite verbose and might also result in lowered performance (at least in simple implementations). I'm unhappy that many languages choose silent wrapping over trapping on overflow out of performance concerns (e.g. Rust and C#), so efficient overflow checking is quite important to me. (Efficient overflow checking is also useful for seamlessly switching to big integers on overflow, which is my preferred approach for high level programming languages)

* Their approach to atomics is elegant but also unconventional. This might make porting existing code difficult. In particular the lack of double wide compare-and-swap looks like a pain point.

* Their approach to SIMD/vector instructions only seems a like a good approach for floating point arithmetic, but might struggle with common integer tasks. For example I'm not sure how shuffles fit into their variable length vector model.

* I don't like their choice of sign extending unsigned integers in the ABI.

<comment><USER11> > * IMO they were a bit too generous with using up 32-bit instruction > encodings, only 3 of 28 major opcodes (blocks of instructions) are still > reserved, though there is still some space for individual instructions > within several of the used blocks. Using 4 major opcodes for 4 different > sign variants of fused multiply-add seems particularly wasteful. (Of course > there is still plenty of space in 48-bit and longer instruction spaces)

Along the same vein, the FPU also uses three bits per instruction to provide for static rounding modes. Almost nobody even touches the rounding modes, and those that do only do so dynamically because that's what ARM, Power, and x86 give you. Its as if the designer wanted to get rid of the floating-point status and control register. The experiment failed, but the legacy cruft is still there.

<comment><USER12> Rounding modes aren't going away, so adding them to the instruction encoding is IMO cleaner, since it gets rid of ambient state that alters the semantics of instructions. It no doubt simplifies the internal implementation, since there are no implicit dependencies between every FP operation and the status register. Fewer dependencies == more parallelism.

<comment><USER11> The trouble is that rounding modes need to be dynamically specified in order to enable debugging of suspicious floating-point programs. See William Kahan's rants about debugging tools for floating-point arithmetic for a detailed explanation of it, which I will attempt to summarize.

If you have in hand several algorithms A, B, and C, and one or two of them produce results that differ significantly from the other, how do you tell which one is more likely to be in error? Kahan has a tool that helps: The method which is more sensitive to roundoff error will have its results perturbed worse by directed roundings, and is more likely to be the method in error.

So, you run each of the suspect codes in three modes: Round to nearest even (the default), round to +inf and round to -inf. The code whose results don't change the least under directed roundings is more likely to be correct than the others. In practice, the difference can be pretty dramatic.

This method just helps to point the arrow of suspicion, it isn't foolproof. But it is a useful debugging tool. Static rounding modes don't help for a broad class of problems without recompilation. Good luck running some slice of a Python program rounded three ways, for example. It also requires the ability to control which portion of the program is affected, since decimal -> float parsing code only works correctly in the round to nearest even mode.

That's the crux of my argument: IEEE754 requires dynamic rounding, the numerical analyst needs dynamic rounding, and dynamic rounding subsumes static rounding. Given all that, burning three bits per opcode is pretty damn expensive, especially when you're cramming FMA4 into 32-bit opcodes. Its a mistake at least as bad as branch delay slots. But since its hiding in the floating-point portion of the ISA, it isn't as obviously wrong to the common programmer.

</comment></comment></comment></comment><comment><USER13> 1\. It fully subscribes to the Stanford Orthodox RISC propaganda. (E.g. "RISC is the best, CISC sux ") and this leads to some rather questionable ISA choices, e.g. No condition codes, poor vector instruction implementations, excessive architectural registers, bad code density, too many ISA extensions, lack of exceptions on many things, etc.

The other general point I really dislike is their focus on ISA as if that matters so much compared to uArch.

<comment><USER3> > poor vector instruction implementations

All I have heard is that the people who know about vectors absolutely love the extension. Why is your problem with it?

> bad code density

That is just plain false. Its actually extremely good, RV32C and RV64C easily beat every other ISA. Even without the 'C' extension the difference to the other ISA are minimal.

See: [https://www.youtube.com/watch?v=Ii_pEXKKYUg](https://www.youtube.com/watch?v=Ii_pEXKKYUg)

> The other general point I really dislike is their focus on ISA as if that > matters so much compared to uArch.

You don't like that the people who are designing an ISA focus on the ISA? That seems an incredible strange argument.

It is well known and the RISC-V people often repeat that ISA don't matter much for performance. That's why it makes 0 sense not to have an open one that is not restricted so that you can have competition and open source implementations.

</comment></comment><comment><USER14> As I understand it, if you are going to go out of order, a large number of architectural registers is actually a handicap; it costs more resources to map them to physical registers.

Given that, was it the right choice to go with thirty-two architectural integer registers? Sixteen registers would be mostly adequate, and would seem to make it easier to implement out of order. What am I missing?

<comment><USER12> > As I understand it, if you are going to go out of order, a large number of > architectural registers is actually a handicap; it costs more resources to > map them to physical registers.

Hmm, I doubt it. You need at least as many hardware registers as reorder buffer entries, which these days is 100+. The only thing I could think of would be extra space for checkpoint entries inserted into the ROB slot having more bits, and generally more bits to encode register indexes. Besides that, more hardware registers means more ILP available to the compiler before it starts spilling to the stack, which is overall a good thing, since it gives the OOE more instructions that have explicit data dependencies through registers rather than implicitly through spill slots.

</comment></comment><comment><USER15> rv32 and rv64 are incompatible. this is unfortunate, and it's not clear to me what the tradeoff for that is.

<comment><USER16> What kind of compatibility are you thinking of? Running 32 bit code in 64 bit mode?

<comment><USER15> yes. [https://groups.google.com/a/groups.riscv.org/d/msg/isa- dev/e...](https://groups.google.com/a/groups.riscv.org/d/msg/isa- dev/eOQ6xN9pzrs/63-QG6xcAgAJ) has a long thread about this. it's not the worst thing in the world, but I think the choice is confusing when it seems easy to sidestep. this is the only negative thing I have to say about RISC-V and it's not very major.

</comment></comment></comment><comment><USER17> I question if RISC-V went far enough.

Having human readable and understandable instructions seems unnecessary in the days of optimizing compilers.

Instead, the CPU should have a bunch of hardware, and then allow the compiler to define it's own instruction set via a large control blob. Each software binary should begin with "here are all the instructions I'm going to use, and here is what actions should be taken for each".

The mapping the applications desires for each possible instruction to the actual hardware should then be left to some OS component which is easily upgradable. It is the component which will have by far the biggest performance impact.

</comment><comment><USER18> The only thing I have against RISC-V is that I do not have a real RISC-V server up and running.

There is this 'SiFive unleashed'[1] but there could be something more real than that. I am ready to put down a lot of money on getting myself some real hardware. I am totally fed up with x86, its management engine and insanely bloated ISA. It is time for open hardware to take over my server closet.. and desktop.. and laptops.. and so on.

Now, not later!!!

[1]: [https://www.crowdsupply.com/sifive/hifive- unleashed](https://www.crowdsupply.com/sifive/hifive-unleashed)

</comment><comment><USER19> I work for one of the big semicon and there is effort in the industry/our company to replace ARM with RISC-V. It is currently in the trial phase right now where I think the low-end would be tackled first to do a pipe-cleaning of the design flow and as a proof of concept. Once that's done (don't know how long) the big desktop cores will probably follow and then server. I don't know if it will play out that way but that's probably how it's being sold by VPs in order to get funding.

</comment><comment><USER20> Well, compared to Intel's chips it lacks a lot of advanced tech like SGX, TSX, MPK etc.

Compared to the Mill it's a rather boring design that doesn't try to do anything new. The Mill is even more hypothetical than RISC-V but at least it is a genuinely interesting architecture.

<comment><USER3> RISC-V started with the simple core to bootstrap software and cover many initial workloads.

But RISC-V will add extensions for more advanced features because many core will need them.

Saying that RISC-V is boring is a bit unfair because there is lots of interesting work done in terms of the Privilege Architecture, Vector unit, trusted execution and so on. Those will all be part of the RISC-V standard.

SGX/MPK see:

\- [https://keystone-enclave.org/](https://keystone-enclave.org/)

\- There is a TEE working group in the foundation: [https://content.riscv.org/wp- content/uploads/2018/05/09.00-0...](https://content.riscv.org/wp- content/uploads/2018/05/09.00-09.45-Security-Task-Group-8th-RV-Workshop- May-9-2018.pdf)

\- There is lots of work on tagged memory (see LowRisc/Shakti)

</comment></comment><comment><USER21> RISC-V is a something one might even learn somethings from, maybe. But it will never be a viable commercial alternative.

\-- ARM

</comment><comment><USER22> There is no RISC-V-based computer commercially available.

<comment><USER3> What's your definition of a 'computer'?

<comment><USER11> I need to be able to buy it in quantity 1 without talking to a salesman. For embedded, that pretty much means Digikey, and for general-purpose compute that means Newegg.

There are plenty of economically interesting use cases where neither of those things are true, but I don't consider any of them to be computers in and of themselves.

</comment></comment></comment><comment><USER23> Yes, I do.

Turing completeness means that instruction sets simply do not matter. In fact, you cannot buy a "native" x86 processor today. Every modern x86 processor actually has hardware to run some highly optimized microcode instruction set, plus an x86 emulator in software that runs on top.

ARM is the current viable alternative to x86. You could put an ARM chip in a desktop and it would be cheaper and faster than RISC-V for the foreseeable future. RISC-V is even more experimental than that and it has nothing to offer even in theory. The only standard for an ISA is performance. Any other features can and should be built on top.

I set the bozo bit on anyone crowing about RISC-V. Don't get me started on the Mill, it's just a shitty GPU.

<comment><USER13> Please explain why you feel the Mill is "just a shitty GPU"

<comment><USER23> GPUs are the state of the art in massively parallel processors. If you are building a parallel processor, it should be evaluated as a GPU to see how it stands up. For example, Larabee was tried as a GPU and found wanting.

<comment><USER24> Uh... not really.

Historically, the design of GPUs are essentially about having extremely high data-parallelism of relatively tiny, simple codes (shaders) that all operate on the same massive data unit but have very little communication. The tradeoffs that get involved in making this code means that GPUs are effective at speeding up only certain kinds of computations. Workloads that are memory- latency bound or communication heavy--such as a BFS graph traversal--turn out to be utter crap on GPUs, and you can only claw back some of that performance with epic engineering effort.

Larrabee and its successor Xeon Phi concepts were actually fairly well- received in terms of giving you something that could tackle non-GPU-amenable problems. What caused Larrabee to suffer was that Intel basically tried to flog a "just write C/C++/Fortran and the autovectorizer will take care of everything" model for programming which, well, didn't work (as many compiler people could have predicted for you before you started). Nvidia also made sure to do a massive push to get CUDA working in terms of library support, educational cooperation, and language flogging to get people interested into CUDA, which Intel didn't attempt for Xeon Phi.

<comment><USER25> >What caused Larrabee to suffer was that Intel basically tried to flog a "just write C/C++/Fortran and the autovectorizer will take care of everything" model for programming which,

This reminds me of the story of ispc [1] One guy wrote a compiler based on SPMD while the rest of the company was focused on the doomed auto vectorization.

[1] [http://pharr.org/matt/blog/2018/04/30/ispc- all.html](http://pharr.org/matt/blog/2018/04/30/ispc-all.html)

<comment><USER24> That was one of the sources I used for the comment.</comment></comment></comment></comment></comment></comment>


A Newbie's Guide to Startup Compensation (or "Stock Options will Make Me Rich") - <AUTHOR> http://www.tonywright.com/2008/a-newbies-guide-to-startup-compensation-or-stock-options-will-make-me-rich/

<comment><USER2> Excellent write up!

One point I would add: Options do expire, and at least where I work, the expiration is tied to when you leave the company. So, if I quit, I have 60 days to exercise my (vested) options. In plain terms, that means I have 60 days to buy the stock at strike price set in the options agreement. Until I read the agreement, I didn't realize that to make use of the stock options, I would have to spend my own money to buy the stock.

I suppose this is obvious to anyone in the know, but for a first-timer like me, it took a little time to wrap my mind around. I just thought stock options were like coupons I could turn in for gold coins or something :)

<comment><USER3> Yeah, you technically need money to buy options, but in most cases you're buying the stock only to immediately sell it again at its current (higher) value. If there's no buyer for your stock you can probably safely let them go, since the market (private as it may be) has determined they're worth nothing.

<comment><USER4> Not so fast. You also buy stock options when you quit the company, but want to keep the equity you worked 4 years to vest into. Many options plans will require you to buy them within 30-60 days of leaving the company.

For obvious reasons, the majority of options purchase scenarios could fall into this bucket, and not the "sure thing" of selling your in-the-money liquid options after an acquisition.

Another caveat about this is that there are plenty of horror stories about what happened to people with startup common shares that left their company before acquisition. You are, as you probably know if you're been reading here for awhile, last in line in a liquidity event.

</comment></comment></comment><comment><USER5> This is why I would never be an employee with a measly .5% unless: a. I wasn't ready to do my own startup or 2. I _really_ thought the company could be the next Google.

I do think this part is a bit wrong: _"If you're getting paid market value, then… Well, there's no risk– and you shouldn't be expecting much reward."_

I don't think that's the right way to look at it. Working for a startup at your market rate is not the equivalent risk to working at an established company at your market rate. The floor can fall out at any point for almost any reason.

Also, a really great hacker doesn't have to settle for market rate salary alone. He could be at some other startup that's very early stage or simply values him highly enough to pay a market salary and give him a generous equity allotment.

<comment><AUTHOR> I disagree on one point: I don't think startups are that much more risky than more "established" companies these days.

Established companies seem to fail or downsize reasonably frequently these days. The real question is if/when this happens, is it easier/harder to find the next opportunity if you've been a career "big enterprise" kind of person or have been working for startups?

<comment><USER6> You are right on the perception of risk, it doesn't matter if it's a startup or a bigco. The difference is you are working 60+ hours at a starup whereas you are working 20 hours of actual work if you are lucky at a bigco.

</comment></comment></comment><comment><USER7> Well, of course, standard venture model option grant percentages do not make sense in case of a small exit ($50M) which takes 4 years. They are designed for an exit of 5 to 10 times the size. So, if you are setting up an options pool, you should account for target exit size and time. Incidentally, the interests of full salary employees with stock options are much more closely aligned with those of VCs than founders.

In Silicon Valley as an experienced engineer working for a startup you should be getting about $150k/year + stock options. Some startups will have good exits. Expected total return per year is about $300k/year long term. But you are forced to save 1/2 of your compensation, and get tax advantages -- both good. And you get to play the become-really-rich-on-stock-options lottery. If you are hiring engineers here the packages should somehow be competitive with that.

<comment><USER4> At 150k/yr, to make 600k in a liquidity event, you would need to be holding .5% of a company that sold for $115MM --- or about 5.5 times as much as Flickr. In what valley job do you get a full half point of the company for a 150k dev job? How many companies have sold over the past 5 years for more than $100MM?

<comment><USER8> [http://startup.partnerup.com/2008/01/02/2007-acquisitions- we...](http://startup.partnerup.com/2008/01/02/2007-acquisitions-web-internet- technology/)

More in 2007 than I woulda guessed, but still... I think your points are dead on.

150k seems awful rich for a startup job. Job boards seem to agree: <http://www.indeed.com/q-python-l-ca-jobs.html> (check the pay box out on the left)

<comment><USER7> I really meant _good_ experienced engineer. Such a person is worth much more than $150k/year, but you can't get much more cash as an employee in a startup (for good reasons). Also, at that level you are getting at least 10% target bonus, and that's included in the number.

<comment><USER9> Engineers do not make $150K a year at a startup. If you happen to run across this rare event, take the job, live on $40K and bank the rest (i.e. don't buy a BMW). Then, 6-18 months later when the company goes down in flames, you will have more than enough money to start your own company.

If you aren't a founder, the best job to get at a startup is some sort of "VP" role after the series A round. These guys DO get paid $150-$175K a year, get the same number of options as the early stage engineers, and don't have to do as much work. As far as I can tell, their only role is to go to meetings with each other. That said, the mere existence of these employees signals almost certain doom for the startup.

My apologies to the YC founders looking for employees, but being an early stage engineer (not a founder) at a startup is for suckers. You get paid paid $10-$50K less than you could at a big company, and your options are going to be worthless or worth far less than you could ever imagine. If you have an entrepreneurial bent, your best bet is to take the higher salary somewhere else and save money until you start your own thing.

<comment><USER8> "My apologies to the YC founders looking for employees, but being an early stage engineer (not a founder) at a startup is for suckers."

This is a pretty broad statement that I'd disagree with.

First of all, plenty of startups pay market rate (or close enough to it).

Second (and way more important) most BigCo jobs are woefully bad at preparing you to spin up your own thing. Don't believe me? Come to Seattle sometime and watch how fast all of the Ex-Microsoft entrepreneurs hire "program managers" and VPs. Working in a small startup can teach you a lot about what works (and what doesn't) on a small team with limited resources.

Third, it gets you into the game. You meet other folks who like startups who can be useful later (from co-founders to future hires to investors).

<comment><USER9> I'm talking about really early stage people... the guys brought on for peanuts and options, pre series A.

\- Pre series-A, startups can't really pay market rate, unless they have huge angel investment or the founder is rich and financing the thing himself.

\- BigCo jobs probably do encourage the entrepreneurs to do things the same way they did at the BigCo. However, in your example the Ex-Microsoft entrepreneurs are _hiring program managers and VPs_. Thus, they have enough money to pay these sorts of employees. Which means they got rich at Microsoft or their MS resume point convinced investors to give them money.

\- Working in a small startup CAN teach you a lot about what works, but the same thing rarely works twice. Note I'm talking about engineers. All the stuff I learned about server scaling in 1998 wasn't as important in 2008.

\- It does get you into the game, but so does being employee number 30 with a comfortable post series-A salary and free backrubs.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> I see his last point here:

      He's buying a work environment that is comparatively bullshit-free. Little bureaucracy, few meetings, flexible work schedule/environment, etc. If you've ever had an environment like this, you know how addictive it is and how elusive it is in larger companies.

... as the most important.

<comment><USER11> ...plus 10-12 hour workdays.

<comment><USER12> ...plenty of 'established' companies have developers working 10-12 hour workdays.

<comment><USER13> ...with bonuses, promotion, more holidays, better health benefit (you and your family need this).

<comment><USER12> I'll agree with everything but promotion.

</comment></comment></comment></comment></comment><comment><USER14> Interesting to note that most people I've met will barter over the number of options or compare competing offers by number of options... but rarely does anyone ask how many shares are outstanding.

<comment><USER7> There are good and bad reasons for this. You really should ask. But there is a common standard for how many shares you should have, so the # shares is normally comparable between different companies. Sometimes you do get this crazy company with 100M shares post round A. That's a bad sign in itself.

<comment><USER15> Really? What is this "common standard"? I'll agree that there's a range, but the high end is 2-5x the low end, so if you don't know the exact number for different, you can't reasonably compare companies.

VCs always ask and they're constantly evaluating investments. Why do you think that the less-practiced should wing it?</comment></comment></comment>


Swift Evolution acceptances: The big three - <AUTHOR> http://ericasadun.com/2016/03/03/swift-evolution-acceptances-the-big-three/ <comment><USER2> Swift is changing fast. Chris Lattner has stated that Apple will have a good migration solution to update current Swift code. If Apple does it right, Swift will be a major cross platform language within a few years.

You can argue that Rust, Nim, or Go are better, for example, but the community and support Apple give Swift give it a big advantage. Simply look at the number of Swift books published in the first 18 months:

[http://www.h4labs.com/dev/ios/books](http://www.h4labs.com/dev/ios/books)

<comment><USER3> If anything, I'd argue that we're in the middle of a fantastic time for languages. I have at my disposal Go, Rust, Swift, and Nim, not to mention a re-emergence of Erlang (and birth of Elixir), Clojure on the JVM (and what the heck, Java)...

There's so much happening in languages now, it's a wonderful time to be a developer! People will always argue about which is the best, why Go needs generics, etc., but when you're a "right tool for the job" kind of developer, your toolbox is looking pretty sweet right about now.

<comment><USER4> We are indeed in a great space right now.

At QConLondon next week, I'm hosting the "Modern Native Langauges" track which will have presentations on Rust, Go, Pony and Swift:

[https://qconlondon.com/track/modern-native- languages](https://qconlondon.com/track/modern-native-languages)

The presentations are being recorded and will be published at [http://www.infoq.com/qcon-london-2016/](http://www.infoq.com/qcon- london-2016/) over the next few months (you can see last year's conference content at [http://www.infoq.com/qcon-london-2015/](http://www.infoq.com/qcon- london-2015/) if you're interested).

It's certainly a great time to be a developer with an interest in languages!

</comment></comment></comment><comment><USER5> I recently did a game jam with my brother where we wrote a small OS X game in a weekend in Swift using SpriteKit. It was quite fun, and Swift was really pleasurable to write in.

These changes look great and will really improve the clarity of the standard API, and are just good coding guidelines in general.

I write web applications all day, and no current web language is as fun to write in as Swift.

</comment><comment><USER6> Big things missing from Swift IMO:

\- Higher-kinded types

\- Strictly-typed "throw"

I'm not sure about dropping "Type" from protocols because it's pretty commonly used to separate the protocol definition (which is extended to provide most of the implementation) from the concrete base implementation, e.g. RAC's SignalProducerType/SignalProducer.

<comment><USER7> Would you have an example for someone who doesn't know anything about higher- kinded types?

<comment><USER6> Both Optional and Array have flatMap, i.e.

        T?.flatMap(T -> R?) -> R?
        [T].flatMap(T -> [R]) -> [R]

However, you cannot write a protocol for "things that can be flatMapped", because you cannot refer to a Self<T> specialized with a different type (Self<R>). With HKTs, you can do that, which would let you write something like this:

        protocol FlatMappable
        {
            typealias Value
            func flatMap<R>(Value -> Self<where Value == R>) -> Self<where Value == R>
        }

That's not useful on its own, but it means that you can now write functions and extensions that reason about the general concept of _anything_ FlatMappable (this is most of the way to what is known as monads, FWIW).

</comment></comment></comment><comment><USER8> Link was down for me here is the google cached version [http://webcache.googleusercontent.com/search?q=cache:B3qA4jq...](http://webcache.googleusercontent.com/search?q=cache:B3qA4jq- nwMJ:ericasadun.com/2016/03/03/swift-evolution-acceptances-the-big- three/+&cd=1&hl=en&ct=clnk&gl=us&client=safari)

<comment><USER9> What's the alternative? I actually thought databases were the cutting edge. Or maybe I've been out of the loop.

<comment><USER10> Databases are fine, but blogs change infrequently and mostly serve the same static content. Caching the database-generated pages, or just serving static files, if much more efficient, especially when a crowd comes.

<comment><USER2> Can better blogs be built on top of Google's App Engine? I've been building on top of it with Go but I don't use app engine's data store, and I'm not sure that I want to. My little database is a pregenerated Go variable.

[http://www.h4labs.com/dev/ios/swift.html](http://www.h4labs.com/dev/ios/swift.html)

I'd like to add more features but I don't want to reinvent everything. Anyway, Go and App Engine handle the load well and so far it has been free.

<comment><USER10> You can run a blog on a cloud platform, set up auto-scaling, and withstand a reddit / hn / slashdot crowd.

You will likely run out of the free tier and into significant spending during the spike pretty soon.

If you ran a highly interactive page that required a lot of non-trivial server-side processing, I'd understand.

But blogs serve the same static content to almost every request. I don't see why burning a whole lot of CPU and IO on it by running python/php/ruby and hitting a database many times is worth it. Serving a set of static files automatically generated by a blog engine (like Jekyll) seems much more reasonable to me.

Regarding comments: Disqus or something like that could help. Or you could turn the comments off during a spike: seeing the content without comments is a much better user experience than seeing a 500 Server Error page.

</comment></comment></comment></comment></comment><comment><USER11> I'm basically glad to see the Type suffix removed from the standard library protocols. I'm hoping that they'll have a solution to make it so writing a function over a generic sequence isn't such a mouthful.

I'm a little flummoxed by the new effort for first argument labels. Function names often imply the meaning of their first arguments very effectively and the new splits in function names seem arbitrary at times. Labeling subsequent arguments is an excellent feature of Swift but first argument labels often seem to complicate the syntax, especially labels like of: which don't always imply much about the meaning of the argument by themselves.

<comment><USER12> The function name often includes the name of the first argument just by virtue of it being spelled out. Current Swift function names are usually two parts, one part for the function itself, and one part that indicates the meaning of the first argument. For example, consider removeAtIndex, substringWithRange, or joinWithSeparator.

To me, it makes a lot more sense to just call these remove, substring, and join, and label the first argument to express what's removed, substringed, or joined with. This makes the first parameter consistent with subsequent parameters, and makes the actual function name purely about the function's, uh, function.

<comment><USER13> In my brief experience with Swift the first argument convention struck me as a little weird. I ended up adding labels anyhow as it made more sense to me. Glad to see this being embraced.

</comment></comment></comment><comment><USER14> Meta Commentary: that people are still serving blogs out of a database boggles my mind (as I write this the blog is down because of database issues).

<comment><USER15> What's the alternative? The blog (according to the HTML source) is pretty stock WordPress, which is database-backed.

<comment><USER16> Just a regular github.io page, or if you wanna be a bit more fancy [https://hugotunius.se/2016/01/10/the-one-cent- blog.html](https://hugotunius.se/2016/01/10/the-one-cent-blog.html).

<comment><USER15> There's a pretty massive difference in the amount of effort needed to publish a post with either of those approaches vs. just typing it into the WYSIWYG editor on WordPress. If your time is worth $60/hour then you're looking at around ~$10/ _post_ in additional time spent. You also lose a bunch of features: comments, trackbacks, RSS, etc.

<comment><USER16> Git commit and push takes a minute or two tops I fail to see how that is less efficient than clicking save in a WYIWYG editor. The setup time between the two options is probably very similar.</comment></comment></comment></comment></comment>


Why Exaggeration Jokes Work - <AUTHOR> https://www.theatlantic.com/science/archive/2018/12/biological-phenomenon-why-wit-works/578842/ <comment><USER2> There is a reason that it became common practice for an introduction to give a broad overview of the topic. It seriously detracts from the writing when the first paragraph plunges you into deep background, and you don't get a hint as to the supposed topic until halfway through.

<comment><USER3> This has been how storytelling has been done for centuries, it's a a mark of thoughtful feature writing. The Atlantic is over 100 years old and extremely prestigious, it's resonable to assume that at least from a technical writing standpoint they know what they are doing and do it on purpose.

It's not writing intended for a textbook or academic paper. It's a story. You're supposed to read it and get introduced to things and discover the themes of the story gradually.

I see a variation of this criticism of a long form feature about every week or so on HN. It's sort of equivalent to a person walking into a modern art museum and asking why the artists didn't just paint the pictures so they look exactly like the thing the artist was looking at when he painted the picture.

<comment><USER4> As someone who's first language is not English it comes off more as a mark of pedant writing. Some folks might enjoy the "storytelling", but it's really annoying when the author goes in circles and gets nowhere until you've read more than half of the text. Like that joke that goes on forever and ends without a punchline, that some people tell when they just want to pull your leg. And whether it's done by the centuries-old extremely-prestigious my-dad- is-very-important The Atlantic or some random person's blog it's just as annoying.

<comment><USER3> There's certainly no judgment made, in the sense that I think people should consume whatever media they prefer. If you don't enjoy long form feature writing in English you shouldn't read it.

My comment is intended to point out the genre. The comments on this article are like people complaining that rap music doesn't have enough melody, or jazz music isn't catchy enough, or whatever.

It's an unwillingness to understand the concept. Some of us are pretty damn glad The Atlantic, Harpers, and The New Yorker, among others, are still around. The world isn't running short of thinly narrated to-the-point content.

</comment></comment></comment></comment><comment><USER5> I felt like this article over-promised and under-delivered. There was a lot of ink spilled on the animal kingdom, and a weak/unconvincing analogy to human humor.

<comment><USER6> All articles that purport to explain how some aspect of the human mind works (in this case, why exaggeration jokes trigger the emotional response they do) inevitably fail miserably. This is simply due to the fact that science has basically nothing meaningful to say about human experience, other than to draw vague correlations between it and fMRI scans or lesion studies. For god's sake, we don't even know why/how Ibuprofen works...what kind of moronic hubris makes an Atlantic writer think they can illuminate anything worthwhile about something as complex as humor?

<comment><USER7> > _For god 's sake, we don't even know why/how Ibuprofen works..._

I bet physicists also assert that bumblebees cannot possibly fly, right? For God's sake...

" _NSAIDs such as ibuprofen work by inhibiting the cyclooxygenase (COX) enzymes, which convert arachidonic acid to prostaglandin H2 (PGH2). PGH2, in turn, is converted by other enzymes to several other prostaglandins (which are mediators of pain, inflammation, and fever) and to thromboxane A2 (which stimulates platelet aggregation, leading to the formation of blood clots)._ "

<comment><USER6> You just explained my point for me by giving a perfect example. We have no idea why any of these correlations hold or why they would lead to any particular change in pain experiences. For god's sake indeed.

This explanation of "why" ibuprofen works is as good as the article's explanation of "why" exaggeration jokes work. It's so unfortunate that otherwise rational people have been made incurious by modern education, enough to believe that "there is a change in the level of one neurotransmitter" is a good explanation for "why a pain medicine works".

<comment><USER7> You defend your claim that "we don't even know why/how Ibuprofen works" by pretending that Wikipedia's incomplete description of COX mechanics are proof that we "have no idea" how any of this works. You're not pointing out meaningful gaps in our knowledge. You're passionately arguing that incomplete knowledge is equivalent to complete ignorance.

Boo. This is lazy and anti-intellectual, akin to "debunking" climate change by claiming that since we don't know everything that influences climate, we don't know anything at all. Someone who complains of "incuriousity" should do better than this.

<comment><USER8> I guess they mean that there is still the gap between molecules and perception. There is no concept for pain and thus no explanation of how Ibuprofen changes the perception of pain. That said, how do you exactly point out that an explanation is not sufficient? It's like describing a hole, you can only point at the borders.

<comment><USER7> "There is no concept for pain" is only true if you believe that human experiences do not map to the physical world. Otherwise pain is entirely a manifestation of physical chemical interactions. Pain is actually a pretty well understood phenomenon. Perfectly understood? No, but that's typical of most things.

As for pointing out that an explanation is not sufficient, it is perfectly reasonable to point out the gaps in our knowledge. If those gaps are extremely large, it's reasonable to call that out as well. It's not reasonable to claim that the knowledge we do have is meaningless simply because there are still gaps in our knowledge. We don't understand the origin of the universe, and yet we still manage to fly rockets pretty well. We managed to predict eclipses with perfect accuracy long before modern astronomy existed. The gaps in our knowledge don't prevent the existing knowledge from being useful or accurate.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Very weak article, as pointed out by other comments. There isn't even the beginning of a proof of a connection between wit and exaggeration, and the examples don't help.

</comment><comment><USER10> 1000% if my jokes are exaggeration jokes.

<comment><USER11> 97.471% of my jokes are about pedanticy.

<comment><USER12> I think you mean "pedantry".

<comment><USER13> Meant

<comment><USER14> Do they no longer mean "pedantry"? Seems that they meant it and mean it.

<comment><USER15> All of you have a mean pedantry going on.

<comment><USER16> a mean pedantry is not necessarily a median pedanticity

<comment><USER17> But both are preferable to a mean pediatrician.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> So jokes share much with sex even when they're not sex jokes. An instinct to focus on supernormal stimuli would also help explain the fascination with over sized and contrasting genitalia, makeup to exaggerate signals of arousal, various modes of sexual harassment, etc. They're variations on Tinbergen's stickleback mandible spots.

</comment><comment><USER19> The article is not great but the Buster Keaton scenes the author links to are great, especially the second one.

[https://www.youtube.com/watch?v=FZSTM3knaao](https://www.youtube.com/watch?v=FZSTM3knaao)

</comment><comment><USER20> If you enjoyed the article, you'll probably also really enjoy this comic titled "Supernormal Stimuli" [http://www.stuartmcmillen.com/comic/supernormal- stimuli/](http://www.stuartmcmillen.com/comic/supernormal-stimuli/)

</comment><comment><USER21> > The same principle is at work in verbal wit. The English film director > Anthony Asquith, for example, once introduced Jean Harlow, the platinum- > blond 1930s Hollywood star, to his mother, Lady Margot Asquith, the author > and wife of the longtime British prime minister Herbert Henry Asquith. > Harlow mispronounced Lady Margot's first name, sounding the final t, as in > forgot. "The t is silent, my dear," Asquith snipped, "as in Harlow." Lady > Margot isolated and exaggerated the significance of the simple t, just as > Tinbergen isolated and exaggerated the herring gull's orange spot, thereby > dramatically enhancing its impact.

Is that a way of saying "she called her a harlot" that went over my head? Or did the author not catch that she called her a harlot?

At any rate, I don't see the wit there (a smart person wouldn't betray their pettyness, cruelty and insecurity like that at "hello"), and I noticed how it's all in the setup, in "platinum-blonde" vs "the author and wife of longtime prime minister".

[https://en.wikipedia.org/wiki/Margot_Asquith](https://en.wikipedia.org/wiki/Margot_Asquith)

> she accused her shell-shocked stepson Herbert of being drunk.

Jesus Christ.

[https://en.wikipedia.org/wiki/Jean_Harlow](https://en.wikipedia.org/wiki/Jean_Harlow)

... hey _wait_ a second ... I don't know these people. But neither did the author, so here goes nothing:

> A totally different principle is at work in psychological abuse. The English > film director Anthony Asquith, for example, once introduced Jean Harlow, the > young, beautiful and warmhearted 1930s Hollywood star, to his mother, Lady > Margot Asquith, a woman of a remarkable lack of any endearing features, who > had developed an especially cruel looking mouth. Harlow mispronounced Lady > Margot's first name, sounding the final t, as in forgot, though she meant > nothing by it. "The t is silent, my dear," Asquith snipped, "as in Harlow.", > marking the beginning of an evening that to the young people felt like > trying to have a picnic while being harrassed by a flock of old sea gulls > that seemed more intent on shitting on the food than stealing any.

> They didn't talk back, laughed politely, because it seemed clear Margot was > not just unhappy, she didn't even remember happiness, and this was her way > to get back at all what that had broken her heart when she was younger. > Harlow knew Margot _think_ she meant her, but that she didn't, didn't even > see her, couldn't see her, saw only the light playing on her hatred for > herself... so she came to feel deep compassion for this person. In the > picnic analogy, she simply decided that they weren't going to get to eat a > bite anyway, and that they may as well watch the acrobatics of the shitting > birds... for even the ugliest human is beautiful, if you look at them > careful enough, listen well enough. What seems ugly, what seems like chaos, > is just as causally ordered, that order is just hidden from casual glance. > Beauty is symmetric, and that's sublime, but uglyness is complex, and that > is sublime too, and sneaking these kind of bald claims into stories is > probably what makes writing them so fun.

> Later that night, when they were alone, Harlow said "you said it was bad, > but I had no idea" and made sweet pity love to Anthony Asquith, which > totally blew his mind.

[actually looking at his bio he was homosexual, which both makes that ending unlikely, and gives the scene a whole other level of oppressive atmosphere, at least in my mind: his mother calling a person she literally just met a harlot for being pretty and an actress, makes it seem unlikely she would have approved of his homosexuality, so maybe they were _relieved_ she called her harlot, since that meant she had no clue of his homosexuality and they gladly played along]

<comment><USER22> Yes, she was implying harlot. It was just a joke, I don't know how you turned a throw away one liner into a blog post...

<comment><USER23> You don't think it's rude for an elderly lady to respond to a young woman mispronouncing her name by "jokingly" calling her a prostitute?

There is some dispute about whether this famous insult actually happened though, [https://www.telegraph.co.uk/culture/books/11193714/Meet- Marg...](https://www.telegraph.co.uk/culture/books/11193714/Meet-Margot- Asquith-aprime-ministers-wife-who-was-more-vilified-than-Cherie....html)

<comment><USER22> It's savage as fuck...still funny though

<comment><USER21> Such savagery is born out of weakness. To respond like that to a honest mistake is like slapping someone in the face for no reason at all. It's like a child saying something wrong to an adult and the adult just throwing it across the room, for no reason. There's no such thing as "no reason" though, and in this case it seems pretty easy to guess at the rough shapes of those reasons, and I find it _hilarious_ that it seems to escape thousands, millions of people. I guess that is just one more pebble pointing to the wider alliance of the obedient with sociopaths that Arno Gruen described.

</comment></comment></comment></comment></comment><comment><USER24> Jokes are "absurd associations". Our brain thinks in patterns. When you put together two patterns(ideas) that don't belong together, it creates the feeling of absurdity, the less patterns belong together, the less they fit together, the more absurd they will feel. ("A man on a bicycle" is not absurd, "a man on a unicycle" is a little bit absurd, "Hitler riding a unicycle" is very absurd, "Hitler riding a unicycle while wearing a white dress and juggling fish" is absurd as fuck). Comedy is the art of finding connections between patterns. You "connect the dots" between two ideas, find an overlap(an association) between two patterns that are far apart, and you put them together. The more absurd(less compatible) the two ideas are, and the stronger the connection(the more it makes sense), the funnier the joke will be.

A longer post on this:

[https://medium.com/@rayalez/comedy-theory- fd142076657e](https://medium.com/@rayalez/comedy-theory-fd142076657e)

\----

I can analyze about 80% of the jokes this way and find two different patterns with clear connection between them, remaining 20% are what I call "purely absurd" jokes, they don't have two connected patterns, they're just ideas that make as little sense as possible. I don't know how to explain both types with some common underlying mechanism.

Just as an example, here's a "dot-connect" comedy sketch:

[https://www.youtube.com/watch?v=AT6jS_X4NaY](https://www.youtube.com/watch?v=AT6jS_X4NaY)

(Pattern 1 is clouds, common recognizer is "cloud that looks like a mushroom", pattern 2 is nuclear explosion).

And here's a "pure absurd" comedy sketch:

[https://www.youtube.com/watch?v=dQfvSLxTsEs](https://www.youtube.com/watch?v=dQfvSLxTsEs)

(no two distinct but connected patterns that I can discern, just an absurd idea that makes as little sense as possible)

\- Puns are the simplest example of dot-connect jokes ("this word sounds like this other word"). Pranks too (the same situation means one thing to the person who's doing the prank, and another to the person who's being pranked).

\- Metaphors are associations that aren't absurd enough to be funny, if a metaphor is absurd/weird enough it becomes a joke.

\- Exaggeration/reversal jokes are closer to "pure absurd" jokes, you're taking a normal idea and making it make less sense by exaggerating a part of the pattern, or replacing it with it's opposite.

\----

Animals seem to laugh when playing, another way to put it - "fake fighting". Play makes sense evolutionarily because kids are practicing fighting, and laughter seems like a signal that "I'm not actually trying to hurt you". I couldn't figure out how to reconcile it with the idea of absurdity, they seem vaguely similar, but I can't expain how comedy works from evolutionary standpoint.

[https://en.m.wikipedia.org/wiki/Laughter_in_animals](https://en.m.wikipedia.org/wiki/Laughter_in_animals)

To understand humor from evolutionary perspective, it would be interesting to analyze the jokes babies and kids find funny. Why do babies laugh at peekaboo?

Here's a fascinating video about the first jokes Hank Green's kid has came up with:

[https://www.youtube.com/watch?v=3q9AEu27NAg](https://www.youtube.com/watch?v=3q9AEu27NAg)

Interestingly, two of them are "pure absurd" jokes (blue baby, police bus), and three of them are "dot-connect" jokes(mam-da, papa pants, coconut baby).

\----

Laughter and humor are not the same thing. Tickling isn't funny, "social signaling" laughter isn't funny (like when girl giggles when she's attracted to a guy).

\----

It would make sense if brains evolved to reward novelty. When you learn something insightful about the world, you get a pleasant dopamine hit. If comedy is "supernormal stimuli", it could come from people learning to hack this mechanism, making the sensation more intense.

The way people add more sugar/fat to the food to make taste more intense, or learned to masturbate to fake sex, maybe people found a way to trick their minds into feeling they've learned something super insightful? But what does that have to do with laughter?

Some sort of error-correction process? When you learn a new idea, your brain corrects your old wrong world model, "erasing" mistaken beliefs. Another way to describe absurd is an "obvious error". Maybe there's something to it...

\----

It's easier to make jokes on taboo subjects because there's an absurd gap between the seriousness of a taboo subject and a lighthearted goofiness of a joke.

<comment><USER25> I have wondered at times if it would be possible to have a whole academic field of study in 'humor theory'. I personally termed it as the unexpected is part of what makes things funny.

A professor giving a lecture on medieval economics in a hall or an exotic dancer dancing at a bachelor party isn't funny. The exotic dancer giving a lecture on medieval economics at a bachelor party or the professor dancing at a lecture hall? Funny.

<comment><USER24> Awesome examples!

I think all jokes are surprising, but not all surprising things are jokes ("you have lung cancer" is surprising but not very hilarious). Surprise seems more like a side effect of comedy, instead of an explanation. The trick is to figure out what, aside from surprise, creates comedy. What kind of properties apply to _all_ the funny things, and _only_ to funny things.

There's a "benign violation" theory - they say that things are funny when they're surprising but harmless, but that's also not true. Plot twists, scientific inventions, new insightful ideas - there are plenty of surprising harmless things that aren't funny.

</comment></comment></comment><comment><USER26> light on content, not sure what the point of the article is besides filler (I stopped reading half way through), so I'll go by the title. This must be a story about a guy with a liberal arts degree, who exaggerated on his resume, got hired as a joke, didn't get the joke (due to lack of iq), and just started writing crap.

James Geary mesdames et messieurs. Calling his work and career a joke would be an exaggeration.

</comment><comment><USER27> For just once could we not downvote jokes here? The topic is humor. One HN thread of jokes won't turn this place into reddit.

<comment><USER28> That's what they all say.

You let one joke in, and the next day you have to scroll through thousands of pictures of Pepe the Frog on a bloated app that tracks your every scroll.

If you want to avoid that, you have to nuke all humor from orbit. That's the only way to be sure.

<comment><USER29> Don't worry, if Pepe shows up, I'll call in Gritty to take him down a peg or two.</comment></comment></comment>


Gmail Ending? Google Starts Migrating Users - <AUTHOR> http://www.forbes.com/sites/gordonkelly/2015/12/05/google-ending-gmail <comment><USER2> Site has an anti-adblocker wall, which was responsible for [https://www.techdirt.com/articles/20160111/05574633295/forbe...](https://www.techdirt.com/articles/20160111/05574633295/forbes- site-after-begging-you-turn-off-adblocker-serves-up-steaming-pile-malware- ads.shtml) in the recent past.

<comment><USER3> Site fails to load in Firefox on Ubuntu in private mode with no ad blocker.

</comment></comment><comment><USER4> Email has been one of the last holdouts of "services that purely distribute", in an era where Facebook, Twitter, search results, job postings are all tailored/processed by an algorithm before reaching the end user.

In addition, of the things that dominate the finite amount of our "attention" (FB/IG/Google), only email hasn't been fully monetized.

When Inbox first launched, there was a lot of discussion on the end of email as a commodity. However, email's customer today is no longer the user (you and I) but the advertisers' (e.g. context-driven ads in Gmail).

With Inbox, instead of passively showing context-driven ads, Google can take it to the next level similar to what Facebook has done with its newsfeed. From inserting ads/call to actions within the Inbox 'timeline', to forcing advertisers/publishers behavior when it comes to how Inbox interprets/filters/classifies an email (remember the addition of the "Promotions" tab?).

I'd also like to recommend a recent article which talks about how Inbox is the trojan horse for your personal AI which goes into some other points: [http://solveforinteresting.com/inbox-is-the-trojan-horse- for...](http://solveforinteresting.com/inbox-is-the-trojan-horse-for-your- personal-ai/)

<comment><USER5> What timeline? For me Inbox is just Gmail with better UI which categorises my shit automagically.

<comment><USER4> By 'timeline' you can think "list whose order is determined by an algorithm", or however you so choose to interpret your automagical categorization of stuff.

<comment><USER5> But like they are there just for a second, then you just archive them. Or are you actually storing emails in your inbox?

</comment></comment></comment></comment><comment><USER6> So if you use Inbox regularly but still go through GMail to get there, eventually it starts taking you to Inbox directly? Seems like good design to me.

</comment><comment><USER7> Wow, timely news. (Not). Article posted December 15th, 2015.

<comment><USER8> December 5th, actually.</comment></comment>


Xkcd: Ineffective Sorts - <AUTHOR> http://xkcd.com/1185/ <comment><USER2> I must be psychic. Just yesterday I had an idea and made <https://news.ycombinator.com/item?id=5359592>

Maybe Randall just gets all of his comic ideas from failed HN posts.</comment>


TauCharts: Data-focused JavaScript charting library - <AUTHOR> http://blog.taucharts.com/taucharts-data-focused-charting-library/ <comment><USER2> At the [http://taucharts.com](http://taucharts.com) it says "Free open source D3.js-based library" but in the tutorial at [http://api.taucharts.com/tutorials/5min.html](http://api.taucharts.com/tutorials/5min.html) it says "free for non-commercial use". At GitHub it is sporting Apache License, Version 2.0 which - if I am not mistaken - allows commercial use. Could you please clear that up for me? Am I allowed to use it in commercial products (like a website made for one of my clients) or not? Thanks.

<comment><USER3> It is free for commercial use, the site will be fixed, it is a mistake in the 5min page.

<comment><USER2> Great, I see that you already fixed it, thank you - I can add "provider solving problems quickly" to my personal list of reasons to use the app.

</comment></comment></comment><comment><USER4> I still find charting tools that do not allow interaction with the a group of charts to enable further filtering very lacking. The gold standard I evaluate any charting library against is [http://dc-js.github.io/dc.js/](http://dc- js.github.io/dc.js/)

My reasoning is that most dashboards should be designed to enable data to tell a story and enable users to interact and create their own story.

<comment><USER5> As a taucharts developer, I would give you a "best comment" award :) Actually taucharts is moving to this direction. We want to simplify API for dashboards and composite charts to allow users create "visual stories". Stay tuned :)

<comment><USER4> I think the reason dc.js works so well is that it is tightly coupled to crossfilter ([http://square.github.io/crossfilter/](http://square.github.io/crossfilter/)). This manages the multi-dimensional views that dc.js leverages to render charts.

When developing, the chart bit is usually the easiest bit to implement. Getting the data set into the views you need is where you spend a lot of time.

Good luck with the chart engine!

</comment></comment></comment><comment><USER6> Please don't use the combination of red and green as early option for category colors. Many people have color vision problems and that combinations is very problematic for them.

<comment><USER5> Thanks for notice, we will think about that. Actually chart API allows to configure color brewer and I hope we will have several themes soon.

</comment></comment><comment><USER7> This is a rather minor nitpick, but I think the documentation and TauCharts website as a whole could use some editing by a native English speaker.

That said, the content and goals for the project really are quite cool! I'm looking forward to where TauCharts can go in the future.

<comment><USER8> If your goal is to express ideas and get someone to contribute/download/convert, I don't think that's a minor nitpick at all. It was pretty painful to read certain parts.

<comment><USER5> As well documentation for taucharts is open sourced: [https://github.com/TargetProcess/taucharts- docs](https://github.com/TargetProcess/taucharts-docs). You can help a project.. just send pull requests with corrected grammar.

</comment></comment></comment><comment><USER9> What makes it better than Vega? I like how straight forward it is, much like highcharts. I'll explore it more tomorrow.

<comment><USER5> Actually I personally like the concept of Vega but in my humble opinion the protocol is too academic, implementation goes too slowly so I doubt that Vega suits for real world application.

<comment><USER10> It seems interesting for learning purpose.

</comment></comment></comment><comment><USER11> So, if I get this right, being 'data-friendly' sums up to using data in the form [ {val1: 1, val2: 2}, {val1: 2, val2: 3}] and then mapping x: 'val1', y: 'val2' instead of something like {x: [1,2], y: [2,3]}. The former assumes that the input data comes in a csv or a similar format. This makes charting computed data (à la MATLAB or numpy/matplotlib) rather awkward.

<comment><USER5> You've got it right. Also I have an idea to make an API that joins data processing and plotting like tauCharts.data(#).aggregate(#).plot(#)

</comment></comment><comment><USER12> I like this. A 20 second glance at the JavaScript in the first example was all it took for me understand how this works.

</comment><comment><USER13> What I want with such charting solutions is something to export or copy and paste data from excel and put it into a chart. Just that. No need to manually edit a javascript file or html code beyond customising the appearance once the data is in there. Is this available somewhere?

<comment><USER14> [https://plot.ly/](https://plot.ly/)

<comment><USER15> Some of our biologists use plot.ly. They seem to like it.

Those that know it still are using ggplot2 and R. This grammar of graphics plotting library really seems to gold standard of plotting.

</comment></comment></comment><comment><USER2> My first impression could not be better - it seems to be simple to use and it looks good. BTW, when you click on the Facebook button at the bottom of the page, the sharing box is under that disqus box - you might want to fiddle with z-index or something.

<comment><USER5> Thanks for positive feedback. FB button is already fixed

</comment></comment><comment><AUTHOR> I wonder how this compares to VarianceCharts - [https://variancecharts.com/](https://variancecharts.com/) (besides the license). They both claim to get inspiration from the grammar of graphics.

<comment><USER5> As far as I understand from quick review the projects are quite similar. But variancecharts don't have facets and not free for commercial use. Difference in API doesn't matter. Taucharts can be wrapped to webcomponent and described on the page using tag as well.

</comment></comment><comment><USER16> What's most astonishing about all this is that the AMC Rebel gets 0mpg!

<comment><USER5> I'm happy you noticed that :) Obviously this is a corrupted row in a data so you can try "exclude" feature of tooltip plugin to remove this record from the chart in one click

</comment></comment><comment><USER17> Any plans for spider chart? Geo charts?

<comment><USER3> Basic Geo charts are already there, but not documented so far.

In future we are going to support all type of visualizations from Grammar of Graphic, so it includes spider chart as well. In fact it is Polar Parallel chart and it will be possible to create it when support of polar coordinates will be added.

<comment><USER18> Given that you called them facets, I'm going to assume you're familiar with ggplot2. In retrospect, I thinking adding non-Cartesian coordinate systems was a mistake. They are a huge amount of work and only make a handful of charts easier (and most of which, like the radar chart, are not that useful).

</comment></comment></comment><comment><USER10> how much data you can visualize with TauCharts? And on the first glance couldn't see how many different types of chart you can make.

<comment><USER5> Friendly speaking, we didn't make a performance or optimization research yet. I can only share an experience we've got from using taucharts in our main product - "Targetprocess". So we setup a limit to 1000 rows (+/-50%) which seems to be acceptable performance / usefulness balance to draw a chart within a 0.5 seconds. Also it depends on chart type. Drawing huge facet with more than 100 cells in it can be painful while plain scatter plot on the same data works fine.</comment></comment>


Ask HN: What's Your Vote Worth? - <AUTHOR>

What with one story about hackers trying to spoof the HN voting system through CSRF and another story today about some guy wanting to pay to get on the front page, I was wondering: what's your vote worth?
Everybody has a price. If I were to offer you a dollar to vote for my story -- let's say it's completely off-topic and anathema to HN -- would you upvote it for a dollar? Five dollars? Ten?
How about a hundred bucks? At what point does your interest in making HN a good site cease and your interest in making a buck begin?
I think my price is around a hundred bucks. Not sure though. It might depend on the topic. I'd have a hard time upvoting "Britney Spears goes panty-less in visit to Queen!"
This is an interesting question (to me) because it drives at the question "What's your reputation on a social site worth?" <comment><USER2> I guess it depends on what you are talking about paying for. $100 for the front page seems cheap, $100 for my one up vote seems to high. So far as I can tell, me voting a story up or down in no way effects my reputation( I can't tell who voted an article up or down and I don't get points for it.) It is my comments that carry both my recorded reputation and my actual what my peers think about me reputation. However moving what appears on HN to a money basis would effect how I view the site or more likely stop viewing the site. The signal to noise ratio would change for the worse.</comment>


How Airbnb scaled to 24/7 support (including phone) in 1 month - <AUTHOR> http://www.uservoice.com/blog/entries/how-airbnb-scaled-to-24-7-support-in-one-month/

<comment><USER2> > _"Within one month, Airbnb had 24/7 support up and running. 8 months later, > the system is running smoothly...."_

Implied: there were some rocky bits in the intervening 7 months.

I'd love to hear about those! This certainly isn't a judgement on their success---scaling to 24/7 in a month is impressive even if there remained bugs to work out. (It's also not a judgement of the OP, which explained what it set out to explain, i.e. the initial one month.) So I guess, consider this a request for an interesting follow-up post. :)

<comment><AUTHOR> I wasn't necessarily trying to imply that, though I'm sure it is true. :)

Based on what they told me, it sounds like the scheduling was the hardest part. Second hardest was probably finding the right phone system that worked perfectly for them.

If you have any specific questions, I recommend you tweet <http://twitter.com/jessemaan> directly...I'm sure she'd be happy to answer if she can!

</comment></comment><comment><USER3> Would love some more technical details, in particular about the "fancy" phone system. I was expecting some useful information based on the title.

<comment><AUTHOR> Sorry about that, I guess I was more interested in the process! :) You should ping <http://twitter.com/jessemaan> about the system...I'm sure she'd be happy to share.

</comment></comment><comment><USER4> I wish Heroku would do this :)

<comment><USER5> I wish Google would do this.

<comment><USER6> If offering support was in any way required for Google's business model, they would consider it.

As it's not it would only be a waste of time as people calling as Google "customers" would ask about their search difficulties or Gmail formatting concerns.</comment></comment></comment>


The tragedy of FireWire: Collaborative tech torpedoed by Apple - <AUTHOR> https://arstechnica.com/gadgets/2017/06/the-rise-and-fall-of-firewire-the-standard-everyone-couldnt-quite-agree-on/ <comment><USER2> This is just plain wrong. FireWire was part of what made the first iPods so great, but the runaway iPod success made Apple an iPod company and PC users who dominate tech markets wanted USB iPods because it is what they had and critically because USB was cheaper. If anyone is to blame then it is Microsoft and PC makers for not adopting FireWire, but their customers did not want a more expensive alternative.

<comment><USER3> The article covers this. Intel was going to build FireWire into their chipset which would make the technology ubiquitous but at the time Steve Jobs swapped the licensing model from a flat fee to pricing per port which pushed Intel away. If Intel had bought into FireWire PCs would have the port.

</comment></comment><comment><USER4> There was a lot of collateral damage too, small firms hitchng their wagons to FW tubed out, or pre-93 developing alternatives to USB for the same ends (just bad timing). It was up-front expensive, and while technically superior to USB addressed primarily issues that were rooted in processor speeds of the time. If you could make the silicon. I have stories if interested.

</comment><comment><USER5> Did the title of this article change after it was published here? It says "torpedoed by corporations" now.

<comment><AUTHOR> It was 'torpedoed by corporations' when I submitted it; that title doesn't really align with my reading of the article.</comment></comment>