The Elements of Typographic Style Applied to the Web (2005) - <AUTHOR> http://webtypography.net/ <comment><USER2> I read the paper version while I wrote my thesis because learning about typography and making my thesis pretty was a great distraction from actually writing the thesis. It was a fantasy book with one major, glaring flaw. The book was printed with wide outer margins and very narrow inner margins. This may have satisfied some concept of design, but it made it very hard to read the letters closets to the middle of the book. It turns out that paperbacks need a certain amount of inner margin to compensate for the fact that they don't open quite all the way.

I don't know whether this was a typographic faux pas or a defect in my particular copy.

<comment><USER3> I have the paperback, and that stood out as a glaring flaw to me also.

I had to compare it to my other paperbacks, which were all made with ample center margins to account for the stiff binding. But they didn't look nearly as nice although not due to the center margins.

In fairness, the author (Robert Bringhurst) probably didn't have final say over the paperback, at least as it was bound in final form. The binding is just too stiff for the form factor which is unusually narrow and tall for a paperback.

There are less stiff paperback bindings. Dover used to produce paperbacks with pages stitched into signatures, but that was a more expensive binding.

<comment><USER4> I noticed this too!

> In fairness, the author (Robert Bringhurst) probably didn't have final say > over the paperback, at least as it was bound in final form.

I'm guessing he had a LOT of influence over the printing. The paper is extremely high quality, there's red color type every so often, etc. If there's any book where the author would control the printing, it's this one.

I'm guessing he's either optimizing for a mathematically or historically "correct" ratio over the reader experience, or we're supposed to "break in" the book more before reading:

[http://booksville.blogspot.com/2009/12/how-to-break-in- new-b...](http://booksville.blogspot.com/2009/12/how-to-break-in-new- book.html?m=1)

<comment><USER3> > If there's any book where the author would control the printing, it's this > one.

I agree. My point is that the final, bound form is probably not available for approval. The author sees and approves pages before they are bound. He probably did not have a bound paperback in his hands until the first print run. Only then could you judge how the choice of center margin did not work with the other choices.

He may have had approval over the method of paperback binding, but a number of variables are conspiring to make the final spine stiff enough that the pages kind of disappear into the binding. Some of those were the variables the author apparently approved - the paper choice, the page dimensions, the margins.

I will add that the layout really looks like a hardback layout. I think that was forefront in the author's mind.

<comment><USER4> The hardback theory makes sense

</comment></comment></comment></comment></comment><comment><USER5> The original book and its ilk are akin to programmer code style guides: whether to indent four spaces or two, put the brace on the same line as the if-statement or below it, etc. Just as a non-programmer is likely to stare at you, lost, that you would care about whether to use two spaces or four, so we are likely to look at professional typesetters when they wax philosophic about their preferences. But just like all those code preferences, these typographic tidbits have a subtle effect, making a printed page look more professional, elegant, easy on the eyes, etc.

As some have pointed out, however, you have to be careful when translating rules from page to screen. For example, Jakob Nielsen was probably right when he said you just leave links alone, let them be blue and underlined. Typophiles especially hate to underline words. They will go through all sorts of acrobatics to decorate links any other way (bottom borders that don't touch the descender thingies on the letters g and y and so forth) or even background images of a line. Thankfully Chrome at least as started to support underlines that by default cross under those descenders.

Typophiles also don't care for colored text much and will likely try to color their links black if they could get away with it. Colored text reminds them of children with crayons or their mother making a flyer. Serious type is understated, like a little black dress.

I myself am a typophile and come from a background in studying fonts and all that before I got into web design. I have slowly come around to be more like Jakob Nielsen, and I prefer those low-brow unstyled sites by professors and old open-source projects over most "designed" sites these days. But I still prefer a nice serif over sans-serif, and a max-width of about 50em, thank you.

<comment><USER6> As a typofile I'd say we could prefix links with a symbol and then indicate them with color on hover :) What I'd police would be free-form links; links are good when it's a name or some other term ([Hermann Zapf], [Monotype]) not just [random words] that [happen] to be [a link to something]. Also, colored text is good when colors are sparse. Think of black with red accents.

</comment></comment><comment><USER7> Is that page supposed to impress me with superior typesetting? I'm no expert, I can admit that. But I find that page much less easy to read than a typical Google site, or Twitter, or Wikipedia.

For example, on the landing page the navigation links are on the bottom right, which requires a large eye/mouse movement from the "origin" (top left) where the title is.

<comment><USER8> This website taught me there are upper- and lower- case numbers.

[http://theworldsgreatestbook.com/book-design- part-3/](http://theworldsgreatestbook.com/book-design-part-3/)

<comment><USER7> It doesn't say anything about upper case numbers. Just old style vs lining, and tabular vs proportional.

</comment></comment></comment><comment><USER9> Also good: Practical Typography ([https://practicaltypography.com/](https://practicaltypography.com/)) by Matthew Butterick

<comment><USER10> I first came across that author via his other book/site [https://typographyforlawyers.com/](https://typographyforlawyers.com/)

</comment></comment><comment><USER11> As a lot of folks have noticed, this is from 2005; I think the complaints are mostly valid, but it's also interesting to see what's changed in web design in the intervening 13 years. (Type tended to be smaller than the norm now, "mobile-first" design simply wasn't a thing, etc.)

It's worth noting the project this site turned into: a book called _Web Typography._ It has its own subdomain at [http://book.webtypography.net](http://book.webtypography.net) and it looks markedly more modern and responsive.

</comment><comment><USER12> A classic! I studied the original book heavily when I got into web design, and fell in love with this website when it first came out. A must-read for anyone who cares about words on the web.

</comment><comment><USER13> Honestly didn't know what to do when I arrived at this website. Couldn't scroll down, and didn't look like there were any links. Took a moment to figure it out.

</comment><comment><USER14> Damn, I thought another post in [https://typesetinthefuture.com/](https://typesetinthefuture.com/) was being linked.

Genius, that guy.

<comment><USER15> Bank Gothic! I remember using that font so much in the 90s when I was a kid trying to make super futuristic digital art. Then I joined a company that used Eurostile for everything, left there and swore to never use it again, and forgot Bank Gothic ever existed.

</comment></comment><comment><USER16> From 2005. Also posted several times before. [https://news.ycombinator.com/from?site=webtypography.net](https://news.ycombinator.com/from?site=webtypography.net)

<comment><USER17> Thanks, we'll add the year above.

</comment></comment><comment><USER18> Seems good so far, but it's annoying that the author needlessly sniped at double-spaced sentences. He even admits that whitespace collapsing makes it a meaningless distinction, but rather than focus on the actual information of "if you really need them, here's the vaious Unicode spaces" he spends over half the section harping on something that winds up making no difference.

<comment><USER19> 'white-space: pre' is what I learned there. Never knew such a thing could be possible. This means no need to do a 'nl2br' on the content if it contains no HTML, this is a common scenario, I am going to see if 'white-space: pre' just makes everything magically look okay.

<comment><USER18> The trick with that is that it also prevents wrapping except on new lines in the source. Looking at the potential values, I'd recommend pre-wrap instead, which at least allows avoiding horizontal scrolling, at the cost of requiring you to write the entire contents in a single line of markup. Annoyingly, it doesn't seem like there's a way to avoid multiple spaces being collapsed without also giving special meaning to keeping the source less than 120 characters (or whatever other measure) wide.

</comment></comment></comment><comment><USER20> Guarantee someone is gonna nit-pick and find a fault somewhere on that website that "violates" the style they're talking about.

<comment><USER21> You got downvoted, but currently the top-voted comment does exactly what you predicted.

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


Holding VCs accountable to commitments made to Black startups and founders - <AUTHOR> https://www.iafrikan.com/2020/08/30/denisha-kuhlor-on-startups-music-and-technology/ <comment><USER2> Is there perchance a text transcript of this?

<comment><AUTHOR> In a week's time</comment></comment>


Ask HN: Is there any tech event/conference/seminar I can view online? - <AUTHOR> Due to the spreading of Covid-19, many events/tech conferences are switching to online this year. Could you share with me some links so I can view right now. <comment><USER2> Women in Tech Slack Group is tracking some in a google doc:

[https://docs.google.com/spreadsheets/u/1/d/1IKXAcDoYnWNpuFaD...](https://docs.google.com/spreadsheets/u/1/d/1IKXAcDoYnWNpuFaDYkn_aplDZ5fRI0bJNWah0rGFO5E/htmlview#gid=0)

<comment><AUTHOR> Thanks, this is a great list for me.

</comment></comment><comment><AUTHOR> Hashicorp has a virtual seminar day on 7th April: [https://www.hashicorp.com/webinars/hashicorp-virtualdays- apa...](https://www.hashicorp.com/webinars/hashicorp-virtualdays-apac- april2020/)

</comment><comment><USER3> All Day DevOps is happening on 17 April: [https://www.alldaydevops.com/spring- break](https://www.alldaydevops.com/spring-break)

</comment><comment><USER4> Neuromatch was a resounding success a few days ago. Yoshua bengio had a talk too. You can find the recordings on youtube</comment>


Self‐inflicted cesarean section with maternal and fetal survival - <AUTHOR> https://obgyn.onlinelibrary.wiley.com/doi/abs/10.1016/j.ijgo.2003.08.018 <comment><AUTHOR> A summary discussion of this woman's amazing feat:

[https://www.rd.com/true-stories/survival/woman-performed- own...](https://www.rd.com/true-stories/survival/woman-performed-own-c- section/)

"Perez took several swigs from a bottle of hard liquor to dull the pain and grabbed a knife with a six-inch blade. She had no medical expertise, but she relied on her experience butchering animals to operate on herself. Instead of making the customary horizontal cut along the bikini line, she made three separate incisions in her abdomen, cutting vertically next to her belly button while squatting. Later, doctors would later show that this technique kept her from damaging any of her internal organs—and likely kept her alive. After about an hour of grueling work, she was able to pull the baby boy out of her own womb. The baby began breathing immediately, and Perez grabbed a pair of scissors to cut his umbilical cord before falling unconscious."</comment>


Qualcomm Puts Aside $1.5B in Funds Required to Enforce iPhone Sales Ban in DE - <AUTHOR> https://www.macrumors.com/2019/01/03/qualcomm-posts-bonds-for-german-iphone-ban/ <comment><USER2> Requiring a bond during the appeals process seems like a fair way to handle this. Interesting to see Qualcomm so confident they will come out ahead.

</comment><comment><USER3> DE = Germany/Deutschland, not Delaware. (The original article title specified Germany. The abbreviation may be read differently by Americans).</comment>


Electron Is Cancer - <AUTHOR> https://medium.com/p/b066108e6c32 <comment><USER2> VS Code is the hallmark of electron done well.

Does it use more resources than vim or sublime? Yes.

But it's fast enough to be a workhorse for gobs of devs. And it's core + community development outstrips every other IDE.

Would I prefer saving $20 of RAM? Sure. But what I really like is best in class $LANG support. (In my case, Typescript.)

<comment><USER3> Why is it that VS Code works well and nothing else does? I just started using VS Code with Python after using Visual Studio almost exclusively for 20 years with C++ and then C#/Typescript/JavaScript.

I actually like VSCode better than PyCharm and I am usually a fan of JetBrains products.

</comment></comment><comment><USER4> Worth noting that Electron and native apps both only need to run at the frame rate of your monitor, and do the actual work within your users' expected response times.

The quality of your applications is primarily determined by what you care about, not by what tools you build them with.

</comment><comment><USER5> I liked these kind of articles better when they were called, "X considered harmful"...

</comment><comment><USER6> > You are not your end-users, and you if you are a developer most likely do > not run average hardware.

Well, in that case (Atom) end users were developers.

<comment><USER7> I believe this is implying that developers take Atom (and other Electron apps) working fine on their computer and believe Electron app products they build will also work fine on any computer their end user may be using. So that particular line doesn't apply to the original "which editor is faster" article, but it does apply to the context of this article.

</comment></comment><comment><USER8> My counterpoint to the frequent "electron is worse than Hitler and aids combined": what's the alternative? Especially when it comes to commercial software where certain open source licenses are a non-starter and there just aren't a lot of resources for writing desktop apps.

<comment><USER9> > there just aren't a lot of resources for writing desktop apps.

Can you elaborate on what you mean by this? I develop primarily for macOS, and I've very rarely been unable to find resources for what I need.

As far as alternatives for cross-platform, one possibility in many scenarios is to write your core functionality in a language that can target multiple platforms (e.g. C, C++, Rust, Swift) and then write platform-specific wrappers around it.

(I don't personally think Electron is the end of humanity, but it does irk me when people call it "native".)

<comment><USER2> > Can you elaborate on what you mean by this?

I'm 100% certain the OP meant "resources for writing cross-platform desktop apps".

> write your core functionality in a language that can target multiple > platforms...write platform-specific wrappers around it

This is nearly always suggested by someone who has never attempted this.

There is a reason there are mountains of Windows-only or Mac-only software out there.

<comment><USER9> > This is nearly always suggested by someone who has never attempted this.

Oh, I've done it, and seen it done many times—it all depends on what the application is attempting to do. If the goal is something platform-specific enough that this approach doesn't work well, then something like Electron generally doesn't seem to either.

</comment></comment></comment></comment><comment><USER10> This article cannot be posted enough. :)</comment>


Extracting ROM constants from the 8087 math coprocessor's die - <AUTHOR> http://www.righto.com/2020/05/extracting-rom-constants-from-8087-math.html <comment><USER3> The 8087 emulation did not work exactly as described in footnote 1. Instead of writing 8087 instructions, the compiler wrote INT (software interrupt, often used for system or runtime calls) instructions. The first opcode of 8087 instructions only has eight possible values so you could for example use eight software interrupt vectors to encode the opcode into the second byte of the INT instruction.

If an 8087 was present, the interrupt handler simply patched in place the INT instruction, replacing it with an 8087 instruction. If the math coprocessor was absent, instead, the interrupt handler decoded the subsequent instruction bytes from the instruction stream and performed software emulation. All this was needed because the 8088 and 8086 didn't have undefined opcode exceptions!

</comment><comment><USER4> The 8087's microcode ROM is very unusual because it stores two bits per transistor for higher density. The ROM uses four transistor sizes so each position outputs one of four voltages, which are converted to two bits.

(This is separate from the constant ROM, which is a normal one-bit-per- transistor ROM.)

<comment><USER3> Ken, could the two 10^18 constants have two different signs? The signs must be stored somewhere like the exponents. Since most bits are zero for both signs and exponents, does it make sense for them to be coded as Boolean functions instead of being stored in a ROM?

<comment><USER4> I actually wrote that idea (two different signs) in the post but took it out :-) My thinking is that the hardware must support negation, so it would save space to have one constant and negate it instead of two constants with different signs.

I'm still investigating the chip, so I hope to find the exponent ROM (or Boolean logic as you suggest) and solve this puzzle.

</comment></comment></comment><comment><USER5> What's ln(2)/3 used for?

Back in EE school in 1991, I installed an 8087 in my PC. The speed-up running Micro-CAP 3 was amazing, as a simple BJT CE amp sim only took a few minutes. Of course then I moved to a 486 and that same sim was finished before the mouse button lifted.

There has been an amazing amount of progress since then, but my PC is still too slow, as the simulations only get larger.

<comment><USER6> There was an instruction to load ln(2) onto the x87 stack. It didn't do anything else; it just pushed ln(2) onto the stack. ln(2) is to compute the natural log. The x87 log instruction had an additional scale factor; if you gave it ln(2) as the scale factor, it computed the natural log instead of the base 2 log.

I don't know what ln(3) would be used for. My guess is it's used as somewhere in the algorithm to compute log2(x). Probably as a fixed point in CORDIC, or possibly as a boundary condition: if the intermediate value is above ln(3), do a bitshift, and add a constant to the result. But I don't know.

The fact that the x87 is a separate processor is a key part of what made Quake what it was. Because math on the FPU ran concurrently with the main CPU, you could do integer math physics calculations on the x86 and floating point math graphics calculations on the x87. So you'd have a significant speedup by interleaving everything together. Must have been a nightmare to write that code. Some x86 clones were clever, and used the same circuitry for everything. I think Cyrix chips for instance didn't separate the circuitry for x86 and x87 instructions. So x86 heavy code ran similarly between Cyrix and Intel, and x87 heavy code did also, but Quake (which combined x86 and x87 instructions relatively equally) ran like garbage on Cyrix chips. At the time, this gave Cyrix chips a terrible reputation. These days, Intel and AMD put fairly little effort into making x87 instructions fast, because code that cares about floating point performance use AVX instructions.

<comment><USER7> >These days, Intel and AMD put fairly little effort into making x87 instructions fast, because code that cares about floating point performance use AVX instructions.

AFAIK x87 instructions were removed/deprecated in x86_64

<comment><USER8> AMD64 (x86_64) can still execute x87 instructions. Not much point, though, unless you need 80-bit precision.

SSE / AVX just performs so much better.

<comment><USER9> _Not much point, though, unless you need 80-bit precision._

Precisely what it's good for.

</comment></comment></comment></comment></comment><comment><USER10> > I'm a bit puzzled why the 8087 doesn't need the constant log2(1 + 2-1), > which is used by that algorithm.

Not necessarily. For example, the algorithm for 2^x with x between 0 and 1 just has to subtract the largest value in the table from x and perform the corresponding shift-and-add on the result. So for large enough x, they may have just done shift-by-2-and-add multiple times on the result, subtracting the corresponding log multiple times from the operand.

Though that still leaves the question of why they left out this particular table value and not any others. It may have been a balancing act of overall accuracy and performance vs table size vs microcode complexity.

</comment><comment><USER11> "After more thought, I determined that the rows do not alternate but are arranged in a repeating "ABBA" pattern." ... which differs from Konami develops, who used a "BA" pattern in their roms.

Sorry, couldn't resist. My brain did a thing.

</comment><comment><USER12> Seeing this reminded me of how cool it felt when I got an Intel coupon for a free 80287 with the Intel AboveBoard memory expansion board I bought to add extended memory (DIPs!) to my 80286.

</comment><comment><USER13> > while others (such as log2(3)) are more puzzling.

> I'm a bit puzzled why the 8087 doesn't need the constant log2(1 + 2^-1)

log2(3/2) = log2(3) - log2(2) = log2(3) - <USER2>

Problem... solved?

<comment><USER4> That would explain it, but, unfortunately I mixed up that constant. I meant ln(2)/3\. log2(3) isn't a constant in the 8087. Apologies for misleading you.

</comment></comment><comment><USER9> The exponents may be implied by how the microcode uses them, somewhat like how fixed-point maths assumes the position of the decimal(binary) point.

<comment><USER14> Also, the first bit of the mantissa is always 1 (except for the number 0), so they could have left it out.

<comment><USER4> In its external representation, the 8087 omitted the leading one for the reason you suggest; it is redundant.

Your suggestion could apply to the ROM; they could have hard-coded the first bit to 1, saving a row in the ROM. I think they could have avoided a few transistors by doing this.

</comment></comment></comment><comment><USER15> >"The die photo above shows the "engine" that ran the microcode program; it is basically a simple CPU. Next to it is the large ROM that holds the microcode."

[...]

The chip's data path consists of 67 horizontal rows, so it seemed pretty clear that the 134 rows in the ROM corresponded to two sets of 67-bit constants. I extracted one set of constants for the odd rows and one for the even rows, but the values didn't make any sense. After more thought, I determined that the rows do not alternate but are arranged in a repeating "ABBA" pattern.7 Using this pattern yielded a bunch of recognizable constants, including pi and 1. Bits from those constants are shown in the diagram below. (In this photo, a 1 bit appears as a green stripe, while a 0 bit appears as a red stripe.) In binary, pi is 11.001001... and this value is visible in the upper labeled bits.

[...]

"The basic idea of CORDIC is to compute tangent and arctangent by breaking down an angle into smaller angles, and rotating a vector by these angles. The trick is that by carefully choosing the smaller angles, each rotation can be computed with efficient shifts and adds instead of trig functions. Specifically, suppose we want to find tan(z). We can break z into a sum of smaller angles: z ≈ {atan(2-1) or 0} + {atan(2-2) or 0} + {atan(2-3) or 0} + ... + {atan(2-16 or 0}. Now, rotating a vector by, say atan(2-2), can be done by multiplying by 2-2 and adding. The key thing is that multiplying by 2-2 is just a fast bit shift. Putting this all together, computing tan(z) can be done by comparing z with the atan constants, and then doing 16 cycles of additions and shifts, which are fast to perform in hardware.13 To make the algorithm work, the atan constants are precomputed and stored in the constant ROM.14

[...]

Some of the constants (such as pi) are expected, while others (such as log2(3)) are more puzzling."</comment>


Assertions in Production Code? (2008) - <AUTHOR> http://www.drdobbs.com/architecture-and-design/assertions-in-production-code/228700788 <comment><USER2> I recently discussed this with an engineering manager for a notable consumer iOS app with tens of millions of downloads. In discussing how to better reduce their crash rate, there was a debate on his team about whether to enable assertions in their production iOS app. As any iOS developer knows, even if you have a great crash reporter and database there are a lot of crashes that are hard to figure out.

One faction believed you should never intentionally crash the app, while another faction believed the app was going to crash anyways or maybe do something worse.

They decided to test it out and during a sprint that was already mostly about bug fixes where they would do extra testing before release, they enabled asserts, and closely monitored their crash reporter.

What they found was that the number of crashes did not change much, but the cardinality went down, significantly. The learning was code executing past a disabled assertion may be in one of n different bad states, each of which might lead to a different type of crash. They now had better high-level information about what was causing crashes (knowing which asserts were wrong) and it helped them reduce their crash rate much more than raw crashes without asserts (including cases where the crash was in iOS code, not app code).

<comment><USER3> That's a really interesting results. Those are the kind of thought you may have but knowing that it actually worked on a production app that's massively used is a really valuable thing.

Anyone else had similar experience ?

<comment><USER4> I work in visual effects for film writing internal tools. Usually they're tools that take data from department to department or the department uses internally; fairly short processes that serialize data in between.

One place I worked had a team that was very adamant about not really having much error checking. Not much of any qc process, either. Wait for someone to complain about bad data and respond. Honestly, this worked really well for small, skunkworks type projects that needed to be nimble. As you would expect, when errors did happen it was because of bad data from further up. You really had to know the system well to be productive (the cynical of us thought the developers liked this because they could look like heroes).

I prefer to error early and clearly and I got a lot of push back. To be fair to them, often times the errors would be irrelevant to the specific thing they needed and it would have been preferable to ignore and carry on. It felt like I was imposing a bunch of bureaucracy and yak shaving. But bringing on new people and scaling the amount of data going through would have been impossible without more structure.

<comment><USER5> I find it sad that there seems to be no conventional wisdom in the software business about the proper way to do this. Everyone starts from scratch and tries to learn it the hard way.

</comment></comment></comment></comment><comment><USER5> If you want some fun (fun as in ruining your day, don't try this without backing up first) fill up your system disk to near capacity, then try to run various apps and system utilities.

All kinds of bizarre things start happening, usually bad. The cause is simple, most of these are written in C and C programmers rarely check to see if writes to the disk succeed.

For example, a few months ago, my Windows box would crash every time it would auto-update. I did a lot of cursing about this, as how could Microsoft do this? I eventually realized that the disk was nearly full. Cleared out a few gigs, and the auto-update started working.

This is 2018.

It's not specific to Windows, either. It happens with every OS I've ever tried it with, including Linux. No message like "disk full", or "failed to write file". Just erratic random behavior and weird things happening.

I always try to keep at least 10% of disk free.

<comment><USER6> I suspect it's the same with memory, nobody checks that malloc doesn't return 0.

<comment><USER5> That's right, but at least these days you'll get seg fault if you try to use it.

Back in the bad old DOS days, NULL pointers pointed at the interrupt dispatch table, so running out of memory (awfully common on a 640K machine) meant you trampled all over the operating system. It was so bad that I'd defensively reboot my machine constantly while debugging.

DOS extenders saved the day, because they ran code in protected mode. I never developed code in real mode again, I just ported fully debugged code to it.

</comment></comment></comment><comment><USER5> Author here. AMA. My other two articles on the topic:

Safe Systems from Unreliable Parts [https://www.digitalmars.com/articles/b39.html](https://www.digitalmars.com/articles/b39.html)

Designing Safe Software Systems Part 2 [https://www.digitalmars.com/articles/b40.html](https://www.digitalmars.com/articles/b40.html)

</comment><comment><USER7> There's a good approach to asserts I adopted years ago for your typical low- risk CRUD/web/mobile app that I'm guessing ~90% of us are working on (as opposed to aviation software like in the article): Use asserts as you normally would, but in production have it fire an event to google analytics or some such. This is particularly useful for those middle-ground situations where a full app crash isn't justified because things will probably chug along fine, but nonetheless you want to know something's screwy.

For debug/testing mode I usually pop a toast or dialog so the tester knows to report something to me even if the app is otherwise working fine.

You often say to yourself "Well I _know_ this assert will never trigger but I'll put it here just in case". Then you check your analytics next day after release and get humbled.

<comment><USER8> >You often say to yourself "Well I know this assert will never trigger but I'll put it here just in case". Then you check your analytics next day after release and get humbled.

That is exactly what asserts are for: checking for things that "cannot happen" \- but do sometimes happen.

</comment></comment><comment><USER9> Software development often does seem like a struggle between reliability/robustness and safety/correctness. Figuring out what to do with asserts falls in this debate!

For embedded development I have often had ASSERTs log out to a serial port with the function name/line # and continue operating - this can then be connected to any logging device. This makes the system a little more robust (it won't crash, right away at least) but less correct/safe.

During development testing we often had complaints of machines freezing due to asserts, which always increased the priority of those bugs! Definitely a good thing in the long run to fix those bugs and make the system more correct. Stopping all executing may not be the correct 'safe state' for an airplane though!

<comment><USER5> > Stopping all executing may not be the correct 'safe state' for an airplane > though!

It absolutely is. It's a (literally) disaster to allow code that has entered an unknown state to control aircraft functions. There is NO WAY such a design would EVER be certified by the FAA.

<comment><USER10> In a fly-by-wire design (which is de rigeur now), stopping all operations would be way worse than continuing.

<comment><USER5> That is certainly not how fly by wire systems are designed. The FAA would never certify a design that relied on allowing software in an unknown state to access critical flight controls.

Here's how it's done:

Assertions in Production Code [https://www.digitalmars.com/articles/b14.html](https://www.digitalmars.com/articles/b14.html)

Safe Systems from Unreliable Parts [https://www.digitalmars.com/articles/b39.html](https://www.digitalmars.com/articles/b39.html)

Designing Safe Software Systems Part 2 [https://www.digitalmars.com/articles/b40.html](https://www.digitalmars.com/articles/b40.html)

<comment><USER11> I've never written written safety critical software, but I believe the point is that "stop all execution" is not always an adequate response to an unknown state; this does not imply that "proceed as if nothing went wrong" is an acceptable response. I would imagine the response to an unknown state would be "return to a known state". This could be accomplished by rebooting (returning the software itself to a known good state), passing control to a redundant system (possibly done by halting all execution of the affected system, but the design needs to consider more than that), falling back to some form of a safe mode, where the bad state is not present, but safety critical functionality can continue.

<comment><USER5> When you're at 30,000 feet, nobody wants to go experimenting with a system controlling critical flight operations that has gone into an unknown state.

The pilot often has the option of rebooting the system and trying it again, but that's dangerous. On an episode of "Aviation Disasters", I don't remember the exact details, but the pilot got a warning of a failed system. After a consult with the ground, they told him to reboot it. After a while, it failed again. They told him don't worry about it, reboot it again.

It (the airplane, that is) crashed.

Aircraft systems are designed to be decoupled from each other as much as possible, so failures do not propagate. In particular, they must not propagate to the backup system, or the "safe mode". The engineers do work hard at this, and sometimes they don't get it right, and another bitter lesson is learned.

The "safe mode" system must be physically and electrically decoupled from the normal system.

An example of getting it wrong is I've seen demonstrations on TV of people hacking in through the wireless key locks on a car to take control of the brakes. That's seriously bad engineering - not so much the vulnerability to hacking because ____happens, but the fact that the door lock system is connected to the brake system. It 's cowboy engineering at its worst.

<comment><USER11> Keeping systems isolated is an orthogonal concern. The question is weather rebooting the system is safer then shutting it off. The fact that shutting it off should be safe is a separate concern. At a minimum, shutting it off reduces your redudancy; and it the system fails again (even in an undetected way), that should be fine, because you (should) have enough redundancy to handle an arbitrary system fail in unexpected ways.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> At my work (hosted enterprise webapp), both the frontend and backend have both an `assert` function and an `assertAndContinue` function. `assert` always crashes on failure, and `assertAndContinue` crashes in dev and logs an error and keeps going in prod. Each time we want to verify a runtime assumption, we decide which type of assert to use. We prefer `assertAndContinue` (and I push for it in code review), but there are reasons to use plain assert:

• In some cases, crashing is a better user experience than proceeding in an unknown state. Usually this is on the backend when data integrity is at risk, but could be on the frontend when we're at risk of making a server call with the wrong arguments. But usually, pretty much anything that doesn't crash is better than crashing.

• `assertAndContinue` requires that you have a reasonable fallback. If code is going to crash the next line anyway, there's no point in `assertAndContinue`. In most cases, it's easy, but sometimes it takes real engineering, like building in an error state into the UI component that skips downstream code. When there isn't an obvious fallback, using `assertAndContinue` is a judgement call based on the difficulty of implementing a real fallback, the likelihood of the bug actually happening, and severity if the bug does trigger.

<comment><USER13> I have a difficult time imagining anytime that assertAndContinue makes sense. If a fallback is necessary and recovery possible, I would have asserts throw and use normal exceptional handling for that.

<comment><USER5> Recovery is never possible if the program has entered an unanticipated and unknown state.

<comment><USER14> So assertAndContinue makes no sense, right?

On my side I don't really see its point anyway. If the code is actually ready to handle such failures, this is merely an error trace, so it should just be called that.

<comment><USER5> > assertAndContinue

I would never allow such a construct in any code I was in charge of.

<comment><USER15> > assertAndContinue

OTOH, it's the perfect title for a sequel of _Halt and Catch Fire_.

</comment></comment></comment></comment></comment></comment><comment><USER16> I completely agree with the approach outlined in the original post. (It's also called defensive programming.)

Not failing fast and hard when the application is in unexpected state (which is what assert should check) is robust only on the surface.

I think we have the debate because it's not just about adding asserts. If you want to add asserts to existing codebase, essentially making it to fail fast and hard, you need to have a system architecture that is capable of dealing with said failure. If your codebase isn't architected as such, you will probably make things worse for the user by adding extra asserts.

I think that's what the people who are against asserts fear of, and rightfully so. But the answer shouldn't be do not use asserts, the answer should be make the system more resilient to failure first.

</comment><comment><USER17> In my view asserts are just a way of defining the contract of an interface that cannot be specified to the compiler/runtime any other way. They are a workaround of limitations of those systems, or rather the extend a system with infinite flexibility.

For example the NaCl "randombytes" function has the prototype:

        void randombytes(unsigned char *buffer, unsigned long long length);

It has no way to report an error -- its contract is that it must fill the buffer with high quality random bytes before returning.

And the OpenBSD function "arc4random_buf" has the prototype:

        void arc4random_buf(void *buf, size_t nbytes);

So we have a potential type difference between the two interfaces for the amount of data that we can generate.

If you wanted to back randombytes() by arc4random_buf() you have several options: 1\. Handle the case within randombytes() where the (unsigned long long) value exceeds the maximum value of (size_t) by making repeated calls to arc4random_buf(); 2\. Assert, at compile time, that (size_t)'s range falls within (unsigned long long) and there can be no problem (since arc4random_buf() similarly cannot fail); 3\. Redefine the contract of randombytes() such that specifying a buffer length that exceeds (size_t)'s maximum value is invalid -- this is really the same as #2 but instead of failing to compile if (SIZE_MAX < ULLONG_MAX) the program will compile and run fine as long as the contract is not violated; The assert in this case is a guard against the violation that should never occur and helps to enforce the contract during development

With regards to production use of assert, catching a contract violation there means a lot of things have gone wrong. How likely things are to go wrong and how much damage they do when they do go wrong can vary from contract to contract. Various asserts may be used based on the such things, from compile- time to run-time debug to run-time production to an inline debugging framework. There are trade-offs and no answer for all cases.

</comment><comment><USER18> It is important to note that the use of assertions is one of the few development practices that has empirical evidence support: [https://www.microsoft.com/en- us/research/publication/assessi...](https://www.microsoft.com/en- us/research/publication/assessing-the-relationship-between-software- assertions-and-code-qualityan-empirical-investigation/)

</comment><comment><USER19> The larger a codebase the bigger the value of a crash 'close' to the root cause of the error. Assertions help you to get - sometimes substantially - closer to the root cause of a problem and any assertion that does not hold would lead to a crash - or worse, silent data corruption - any way, so by all means, leave them on.

</comment><comment><USER20> The article argues in favor of assertions in production code but acknowledges that the author's experience is from a very specific field with very specialized constraints and extensive design around recovering from aborted components.

This advice is not obviously applicable to different kinds of programming with different constraints and different environments. As with so many things: one solution does not fit all problems.

<comment><USER21> You're gainsaying, but others have dropped empirical evidence on the other side, averring a low to no downside; and my experience is all on the other side too. It would help if you gave some lived examples.

</comment></comment><comment><USER22> I think part of what is argued is that people need to look at their software and determine what failure modes are not acceptable. It is impossible to design a system that won't fail so the focus should be on designing parts that detect and handle failures. For those parts you may want to pull in techniques from aerospace such as command monitor setups, assertions, fail-safe modes, and force restarts.

Clearly not all software is flight critical but a lot of software could be improved by treating some parts of it as such.

</comment><comment><USER23> > High reliability is not achieved by making perfect designs, it is achieved > by making designs that are tolerant of failure. Runtime checking is > essential to this, as when a fault is detected the program can go into a > controlled state doing things like

Very good point. That's is exactly the philosophy behind Erlang (the language and its VM, also extends to Elixir and other BEAM languages).

It has isolated process heaps and process hierarchy supervisors. That is the most critical part of the deal because it means crashes and failures are controlled and only a small part of the system would be affected, without it spidering out and putting the rest of the system and put it in an unknown state.

Microservices or just using OS processes instead of threads can kind of emulate that. But you can only have so many OS processes as they can pretty heavyweight. And with Microservices there whole other stack of stuff involved as opposed to just the language environment.

> I find these options far preferable than going into an unknown state and > praying.

The idea of avoiding "unknown" state is key. That's also where crashing and restarting comes in - to get back to a known state. Of course you'd also want to log the failure so someone can eventually fix it. But, if a system is well designed, someone won't have to do it at 4am in the morning. I've seen systems crashing and restarting for weeks. Sounds terrible at first, but the alternative would have been having a service that's down completely and waking someone up in the middle of the night to fix the issue.

</comment><comment> Const-me In my code, most asserts become log messages in release builds. This helps a lot when troubleshooting problems, customers don't have debuggers installed. I often work on desktop software, unfortunately it's impossible to achieve avionics level of reliability because I don't have a luxury of controlled hardware and software environment.

</comment><comment><USER24> It doesn't fix everything, but judicious use of private data constructors and custom types can go a long way towards reducing the need for asserts. They can bubble up potential violations of preconditions and force handler code to be written.

Some Scala examples, but they're hopefully quite language agnostic:

[https://m.youtube.com/watch?v=Csj3lzsr0_I](https://m.youtube.com/watch?v=Csj3lzsr0_I) [https://m.youtube.com/watch?v=keTId618iOs](https://m.youtube.com/watch?v=keTId618iOs)

</comment><comment><USER25> Most people don't know that Python has a '-O' optimize CLI option:

        $ python -h
        usage: python [option] ... [-c cmd | -m mod | file | -] [arg] ...
        Options and arguments (and corresponding environment variables):
        ...
        -O     : optimize generated bytecode slightly; also PYTHONOPTIMIZE=x
        -OO    : remove doc-strings in addition to the -O optimizations
        ...

It does two things (that I know of):

1.) Assertions are removed. The assertion code does not appear in the bytecode.

2.) Any code guarded by a "if __debug__:" statement is also removed.

YMMV

</comment><comment><USER26> By default macOS apps do not terminate on certain assertions within certain event handlers, because exceptions are caught by the framework. The app just does weird stuff after this happens. This is terrible. Once I figured out how to make it crash I fixed a handful of bugs and the number of reports of inexplicable behavior went way down.

<comment><USER27> I'm sure you're aware of this, but you can change this with NSSetUncaughtExceptionHandler: [https://developer.apple.com/documentation/foundation/1409609...](https://developer.apple.com/documentation/foundation/1409609-nssetuncaughtexceptionhandler). By default Cocoa registers an exception handler that swallows exceptions and asks the user whether they want to continue after the exception is raised.

</comment></comment><comment><USER28> The biggest problem with assertions in Python code is that they throw a generic AssertionError when you should be throwing a custom exception class instead. You can't catch the right error (and nothing but the right error) that way.

</comment><comment><USER29> The one time that it's actually a good idea to intentionally crash an app in production is if failing the assert could e.g. cause irreversible corruption of important data or worse, lead to a security vulnerability/exploit.

e.g. situations where you're writing to a buffer/disk, dealing with raw pointers, etc. (which should hopefully shouldn't happen with good design, but sometimes unavoidable)

<comment><USER5> My work is cut out for me :-(

</comment></comment><comment><USER5> Famous Last Words: "It's just a buffer overflow, nothing to worry about."

</comment><comment><USER30> Soft assertions. They crash under test and in development, but log in production. Monitor the occurrences in production and alert if they go above some threshold rate. The assertions should have an owning team, and potentially DRI. This info should be a required argument to the soft-assert function. Otherwise you're just making a mess.

Hard assertions, for things that should never ever happen, or where crashing is preferable to continuing.

</comment><comment><USER31> Assertions, throws, and try-catch are code smells. Really bad design choice considering we have more elegant solutions like monads.

<comment><USER16> There are three main ways to reduce errors in code: tests, asserts and abstractions. All three have advantages and disadvantages and generally deal with different classes of errors.

In this thread, we discuss asserts, not abstractions. Monad is an abstraction. (On the other hand, many people only see tests and forget about two other solutions, which are as important.)

<comment><USER31> Tests are good of course, but that assumes the tests are valid. I'd rather trust compiler to ensure runtime safety.</comment></comment></comment>


Electronic Arts is using Erlang - <AUTHOR> https://github.com/Eonblast/Emysql

<comment><USER2> Inspires confidence in a language when drivers for a major database are side projects released on github?

This is one of the main reasons I just walked away from erlang, the ratio of buzz vs its supportive environment for the real world is very high.

I remember the last time I had to connect to mysql from erlang I had to download a few library files from some company nice enough to release them and dump them into my projects directory.

<comment><USER3> This is a very real problem with many "hyped" languages. Sure, they might seem more powerful and elegant, but if you got to spend tons of time re- implementing basic networking/web libraries, then what's the point in using them for web development.

<comment><USER4> I am a coauthor of the original emysql. I wouldn't recommend using Erlang for your average web application. I would recommend it when the problem you're solving thrives on an idiomatically distributed and fault tolerant platform.

</comment></comment></comment><comment><USER5> EA is no longer using Erlang, at least none of the code related to this project. I was engineering manager for the rupture team at the tail end of our time at EA. Our entire backend was built using Erlang, and ufortunately the existing MySQL drivers were less than stable, forcing us to build our own.

</comment><comment><USER6> EA bought Shawn Fanning's company Rupture a few years ago and they used Erlang.

<comment><USER7> Exactly. And there has also been a position open at EA for Erlang to deal with the inherited tech:

[http://erlang.2086793.n4.nabble.com/Open-Erlang-developer- po...](http://erlang.2086793.n4.nabble.com/Open-Erlang-developer-position-at- EA-td2115133.html)

That link is not working anymore, but that Erlang position was still open when I left EA in December. So it was unfilled for a month shy of 2 years.

<comment><USER8> There are a number of Erlang devs out there looking for projects - I know because I run erlanginside.com and they often send me their CVs - so not filling a position like that is for some other reason than that there are no talented devs w/experience.

<comment><USER4> I was a hiring manager at Electronic Arts for a team that exclusively used Erlang. It's very hard to find Erlang talent.

Many candidates have used Erlang in an exploratory capacity and have no real experience supporting a production Erlang application under load or troubleshooting concurrency problems in a distributed system.

That said, it was great to see a lot of passion for Erlang. I enjoy writing it, and hope the language and community continue to evolve.

</comment></comment></comment></comment><comment><USER9> Wow, a couple of years ago it would have seemed unthinkable that a company like EA would release some of their code as open source. Only very few major game companies released code back then (I can think of only id and Insomniac).

<comment><USER10> They opened up EASTL a while back too.

[http://www.open- std.org/jtc1/sc22/wg21/docs/papers/2007/n227...](http://www.open- std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html)

<https://github.com/paulhodge/EASTL>

<comment><USER11> That's not all of EASTL, unfortunately. Much of it is still behind closed doors.</comment></comment></comment>


Every startup launch video ever - <AUTHOR> https://www.youtube.com/watch?v=yeiYJ57DrH4

<comment><USER2> Making the world a better place through <insert bs product>.</comment>


Meet-O-Matic: The World's Simplest Meeting Scheduler - <AUTHOR> http://beta.meetomatic.com/calendar.php <comment><USER2> Thx ernesth: I presume that when you say step 1 didn't work, you mean that you left the (required) email field blank, so therefore you got the alert. Technically speaking, you're correct, though it's interesting that with hundreds of thousands of meetings created, we have never received a complaint like this. On the other hand, you're right that step 1 should REALLY fully specify "Choose your possible dates (and fill in the required meeting name/email fields), then press 'Go!'", so we'll have to think about this tradeoff of compact wording (with some poetic license) vs 100% fidelity to the fine-grained details (which can then be construed to be more than 1 step)! Many thanks for commenting.

All the best,

-Marc on behalf of the Meetomatic Team

</comment><comment><USER3> If a step by step is provided, it'd better work. When I follow point 1, I receive a "Invalid email address" alert.

<comment><AUTHOR> Have you told them?</comment></comment>


I increased paid conversions by 2.13% by sending personalized videos - <AUTHOR> https://www.loom.com/blog/welcome-video-messages-doopoll <comment><USER2> Maybe I'm not the target market but personally if I get an unsolicited message and it's just text I may still read parts of it. If the message includes a link (to a video in this case, but could be anything) I am not clicking it, both for time reasons (I don't have time to watch your video and the environment might not be suitable - it's an office and my headphones are away, etc) as well as security reasons (is it really a video or is it malware and is it going to track the fact that I clicked, letting the sender know that I am reading their spam?).

For me this seems worse than a standard text-only message.

<comment><AUTHOR> Yeh, to be honest, it was surprising to me too.

But we're competing against a super dominant industry leader (SurveyMonkey) so doing weird stuff that they wouldn't ever do often increases engagement.

In this case, it worked.

<comment><USER2> I wonder if there's any metrics on the "quality" of that engagement. I'd expect the people higher up in the company (those that you want to reach) would also have both less time to watch a video and might be less likely to click on links in unsolicited email due to security concerns.

</comment></comment></comment><comment><AUTHOR> Adapted an idea that Tom from Makerpad came up with for my product. Turns out, people convert at a higher rate when receiving personalized welcome videos.

Started this in a totally unscalable way with no set format, no set email template and sending the emails 100% manually each time, then automated away little parts of the process.

Really looking forward to seeing how the personalized landing pages I set up to be generated with Airtable data will perform.</comment>


Ask HN: Why incompetent people get paid more at big companies and continue? - <AUTHOR> Over last 4 years I have worked for 2 most talked companies these days ( hint stock is down for both).
I felt that amount of incompetent people at these companies are as large as it can get.
There are managers, analysts who are sitting on their job for 3 or 4 years yet hardly know business functionalities, programming and other stuff that's making news everywhere.  Both companies sucked a lot when it came to speed.  Amount of approval, mediocre mountainous tasks I had to go through was un-parallel.
I have seen employees at both of these companies playing video games at work hours , people getting drunk during work hour, calling names, closed groups , politics and much more.
There are managers and directors who simply don't know what the fuck is going on.  They exist to draw salaries.  Most of these managers, directors and  people with 3 to 4 years have form closed circles that refuse to let any person ( even acquihires ) to mix with them.  All acquihires I know have left company ( including me ).
Another trend I have seen is fake engineers coming out of training academies such as HackBright and many more.  In 3 months they claim to know stuff that have taken 4 years of engineering and numbers of years to master for others.  I have conducted number of interviews and our suggestions were turned down by hiring committee at both companies for political correctness. I have seen people spending 8+ months on a product launch only to discover that it is not working as it intends to.
Now, worst part of all is these people are getting paid 150K+ to 200K+ per year.  Heck, even hackbright graduates are getting paid more than hard working engineers.
Why is that US companies are openly axing their own future ?  I feel bad for what is going on. <comment><USER2> The managers and analysts that you are labelling as incompetent may be not incompetent. It will be naivety to say that those people are just sitting and playing video games for hours at work. Have you delved into their past careers/performances etc? What you are seeing is just tip of iceberg and if you are not aware of that then all your prediction and calculation can go wrong.

I agree some managers and directors can be clueless as in large companies there are frequent shuffles among departments and projects but that can't be their fault in entirety. If it is a large ship then there will be some people who can relax and still the ship will move with few other's contributions. Large organizations are like that. Do not expect all employees to contribute evenly and that is 8 hours of diligent work. That does not happen. I guess not even in at G or Y or A or F. But if you are in a canoe(startup) with one or two other guys then you have to paddle.

</comment><comment><USER3> I feel you. Most of the world today is fake. Fake people, fake news, fake products.

I recently saw a company sell a product for over USD15,000 that was just Joomla ecommerce that I could do in a day. What makes things even worse is that 5 people were working on it. At least that is what "sales person" told the client. It made me sick. They had 2 months for this and it should be up by New Year. It's still in "development phase" because they don't know how to redirect from Paypal to shop once the payment is made. That's those fake engineers you are talking about. They took money from small business and sold them a solution that will never work properly and for big money. Fake people, fake engineers, fake product.

</comment><comment><USER4> I had the same thought but after closely working and observing what they do on day to day basis, here I have come up with few reasons:

1\. They understand the day to day Operations of the company better.

2\. Non-IT people find it easier to deal with them.

3\. They're easy going, less demanding in terms of the Company culture and technologies used.

4\. They tend to stay for long time in the company - that means Loyalty. Most companies appreciate and reward Loyalty.

5\. They aren't Incompetent. They are just good at what they do, for long time, which new comers might dispute as being lazy, not passionate about technology.

Lastly, most of the jobs don't require you to be genius.

<comment><USER5> > 5\. They aren't Incompetent. They are just good at what they do, for long > time, which new comers might dispute as being lazy, not passionate about > technology.

I'm fairly sure I would fall in OP's "incompetent" bucket, but this point of yours nailed it. I'm not among the oldest people around and I haven't been that long at the company I work at, but I definitely don't have the passion and drive of the single, early 20s guys in my team.

Give me a task and I'll do it well. But don't expect me to be 100% of the time on social media promoting the product, and don't expect to see me voluntarily working nights and weekends just because the product is really cool (which it really is, but it's still work). I have 1) a family and 2) multiple other interests outside of work.

</comment></comment><comment><USER6> You seem to be describing at least 2 things:

Rising to a level of ineffectiveness: Employees rise through an organisation until they're ineffective at their job, but just enough effective to keep/justify it. This is career peak and moving stops. I'm sure there's a Dilbert on it, or perhaps that is the whole of Dilbert. This is not bad people, just people that have found comfort on a decent salary.

>fake engineers Not sure what you mean about "our suggestions were turned down by hiring committee" best not to have a hiring committee, sounds like avoiding accountability for hiring. Have the hiring manager make the decision for who they want.

>There are managers and directors who simply don't know what the fuck is going on. They exist to draw salaries.

Yes. And staff manipulate them. Like a small child tests parents, seeing what's possible and what's not. Often not incompetent, but competent enough.

<comment><USER7> _" Employees rise through an organisation until they're ineffective at their job"_

That is the Peter principle ([https://en.m.wikipedia.org/wiki/Peter_principle](https://en.m.wikipedia.org/wiki/Peter_principle)), not the related Dilbert principle ([https://en.m.wikipedia.org/wiki/Dilbert_principle](https://en.m.wikipedia.org/wiki/Dilbert_principle)) _" leadership is nature's way of removing morons from the productive flow"_.

</comment></comment><comment><USER8> An observation after working in big and small companies.

Speed is slower in larger companies, usually nothing to do with ability or red tape, but because you have users or paying customers already. To push something out that isn't functioning has an impact either with reputation or cash.

As a result you need to make sure quality is extra high and nothing else is impacted.

Something with few or 0 customers does not have this issue by nature.

</comment><comment><USER9> It's called corruption. As engineers we can see real work that each person is doing. When someone who is a diversity hire hasn't written any code for months after starting it is obvious but management will look the other way. People want money and tech pays more than almost every other job. Once a bad seed criminal type gets into management they can do a lot of damage. They will slaughter anyone who might expose them in order to stay employed. When you read about companies with one year average tenure and can't understand it, this is why. They want people just smart enough to do a little bit of work but not smart enough to expose the corruption. The company will just get sold or go out of business like thousands have before. Some would say it's even part of the dying process of a company.

<comment><USER5> > When someone who is a diversity hire

What are you trying to imply here?

<comment><USER9> I'm not implying anything. It means what is says.

<comment><USER5> That "diversity" you put there is really snarky. You seem to be implying that non-diversity (which you're very likely thinking of as white males) hires all perform well and only diversity hires underperform.

<comment><USER9> Nope. The original post is about fake engineers hired due to political correctness against recommendations, i.e. diversity hires. I made no statement or implications about non-diversity hires.

</comment></comment></comment></comment></comment><comment><USER10> couple things to consider: 1) Most people prefer comfort to challenge.

2) Most organizations suffer from varying degrees of misaligned incentives. Especially in publicly owned companies where even the c level execs don't have much stake in the outcome of the company.

Combine 1 and 2 and you get most of what you're observing from rational actors who are competent at maximizing their own outcomes. Good luck trying to solve these problems.

Now consider this:

As corrupt/incompetent/lazy as the US system is, it's still several orders of magnitude better than anywhere else in the world. And those 2 companies you worked for are better than most US companies.

Imagine a 3rd tier company in Europe/Asia/wherever, ie. where the majority of the world's population works, and you'll start to get an idea of how deep the rabbit hole goes.

</comment><comment><USER11> I feel your view is rather narrow and missing something (or a lot).

Clearly these companies are making money somehow?

</comment><comment><USER12> >hard working engineers

How exactly do you measure that? Sisyphus obviously works very hard.

</comment><comment><USER13> I believe Scott Adams wrote a book, "The Dilbert Effect" about this.</comment>


XBMC 11 is released - <AUTHOR> http://xbmc.org/natethomas/2012/03/24/xbmc-11-0-eden/

<comment><AUTHOR> For those people that don't know - XBMC started off as a hack for the original XBox that made it into a media centre.

It's since become a stand-alone media app, installable on everything from the Apple TV to Linux. It plays everything you throw at it, keeps track of where you were up to when you last hit pause, and happily interconnects with all sorts of sources.

<comment><USER2> Speaking of pausing, one of my favourite features is how it works with the Android XBMC remote. If somebody calls my phone it will pause whatever is playing, show a notification on the TV and resume playing when I hang up. Always surprises me.

<comment><USER3> I did not know this. Thanks so much! I was going to actually buy a standalone IR remote for my HTPC.

<comment><USER4> Piece of advice: get the standalone IR (or BT) remote. Not only you will have haptic feedback mentioned by skeletonjelly, but the battery will last months and, the most important thing, you can wake up the HTPC from sleep (yes, you can use WOL with the Android remote, but it takes too long).

Another alternative is to get HDMI CEC-USB adapter and use remote from your telly for control. Pricewise, they are about the same as remotes.

<comment><USER5> Another option is Flirc , cross between a uSB IR reciever and a programmable remote. You can teach it any existing IR remotes you have and it appears to the system like a USB keyboard.

<http://flirc.tv/>

Note that despite the name, it has nothing to do with lirc.

</comment></comment></comment></comment></comment><comment><USER6> I picked up an Apple TV for Airplay use with my iPad, but was disappointed that I couldn't play my movies on my media server. Luckily I found out XBMC runs on it, and it works quite well. I've been using the Eden beta on my ATV for a month or two now, good to see it's been released.

$100 Apple TV + Jailbreak + XMBC == Awesome.

<comment><USER7> The $100 AppleTV + XBMC really is one of the best HTPCs you can have. For playing digital media it's not only one of the best options but one of the cheapest. Can't wait for AppleTV3 to get a jailbreak.

<comment><USER8> But it won't play 1080p, correct?

<comment><USER9> 2nd generation AppleTV will play 1080p content, but only output 720. The new AppleTV will output full HD.

<comment><USER8> I didn't even notice there's a new AppleTV. Superb news!

</comment></comment></comment></comment></comment><comment><USER2> Eden is a great version. I used to have version 10 crash on me all the time - which was horrible (in a first world problems way) that I had to find a laptop, shell in and restart XBMC, or make it non-windowed, or just reboot the machine. Congratulations to the team!

</comment><comment><USER10> I'll give this a shot, but I'm not optimistic. I have an Nvidia Ion graphics card in my HTPC, and h.264 acceleration doesn't work with anything other than MPC-HC (I tried XBMC 10). It's really too bad, because the Ion chipsets are wonderful for HTPCs, and XBMC has a great UI. A combination of the two has the potential to be a great HTPC that actually plays _everything_ (instead of the half-assedness of Apple TV or Roku).

<comment><USER2> Optimistic? You're in for a surprise. It works perfectly on my Asrock ION 330 with the Ion graphics card. Can play 1080p flawlessly without hardly affecting the CPU thanks for the VDPAU acceleration [http://wiki.xbmc.org/index.php?title=HOW- TO:Install_XBMC_on_...](http://wiki.xbmc.org/index.php?title=HOW- TO:Install_XBMC_on_an_ION_based_machine)

<comment><USER11> The only problem with it is that it doesn't do interlacing without stuttering quite badly. I haven't tried it with 11 though.

<comment><USER2> Weird. I've never had problems with TV media in any version (10 or 11)

</comment></comment></comment></comment><comment><USER12> I've been running Plex (originally a fork of XBMC) because it has support remote clients (ie, displaying the UI remotely and playing video)

I can start a video on my Samsung TV, stop it, then pick up from where I left it on my Android table (I believe there are iOS client apps too).

That's a killer feature, and I don't think XMBC has it. I'd love to be wrong about that though...

</comment><comment><USER13> A feature I've been looking for in a media player is the ability to run a custom script against a file from the media player's file browser. I have a script that I use to mark a file as watched, which I currently run as an Automator Action from the OS X Finder after watching the video.

Has anyone come across a way of doing file-level 'actions' within a full screen media player?

<comment><USER14> Why do you need a script to mark a file as watched? On Plex and XMBC you can easily toggle a file's watched/unwatched status from the navigation interface.

<comment><USER13> I store this watched status on a server that other people created. It is used to collect statistics of how many people watched a particular file. It also allows me to see what files I've already watched as I use multiple devices.

<comment><USER15> There is a mymediadb plugin for xbmc that does this. Can probably borrow code from there if you have your own backend thingy. <https://github.com/netbrain/mmdb-xbmc-addon>

</comment></comment></comment></comment><comment><USER16> I've been running XMBC on Linux on a dedicated for several years now. I built a custom box using a mini-ITX (9"x9") board, and dual 2TB drives using LVM for 4TB of storage. It's become a great entertainment box for the kids. I keep all their movies/TV shows on there and it's simple enough that even the wife can turn on a movie for them!

</comment><comment><USER17> I still remember the days of using T3CH builds on my original XBox, using IRC to find certain files, etc, etc...

<comment><USER18> I first used XBMC back when it was XBMP and I was looking around for better dashes than evoX on my xbox. Good times getting those t3ch builds and pushing them to the xbox, occasionally messing it up and needing to drop back to the bootloader to fix it :)

It is incredible how this project has kept on pushing out great features and support for new platforms. I talk to people at work who have discovered this and now use it on their mac mini/htpc, and are completely disconnected from the whole Xbox aspect of it.

This team has a great idea when they initially tried getting builds working and usable on windows and linux. I wouldn't have imagined at the time how far this project would come.

</comment></comment><comment><USER19> So I haven't been keeping up to date on the media center software packages, is XBMC still beating MythTV?

<comment><USER20> Is it beating Boxee?

<comment> mike-cardwell Personally, I moved from Boxee to XBMC when I noticed that Boxee was calling back to boxee.tv every time I watched a video, telling them what I was watching. Even if it was just a local video file. With no option to turn that off. And with them ignoring my emails asking for information when I contacted firstname.lastname@example.com.

[https://grepular.com/Boxee_TV_Helps_Its_Self_To_Your_Viewing...](https://grepular.com/Boxee_TV_Helps_Its_Self_To_Your_Viewing_Habits)

<comment><USER21> Well, that's sort of the entire purpose of Boxee. Or at least, it was. It was the "Social Media Player", that allowed you and friends to see what each other were watching, etc. I think they've moved on from that a little now that they've seen that people don't particularly want that.

</comment></comment></comment></comment><comment><USER20> This is great. Has anyone managed to jail break the Apple TV 3 to get XBMC on there? Or would you need to downgrade the Apple TV firmware to the 2 version to be able to jailbreak?

<comment><USER22> Can't downgrade signature checks are in place and the internals changed, you'd need a jailbreak designed for the device.

</comment></comment><comment><USER23> xbmc also has builds for the iOS. You'd need a jailbroken iDevice to get it to run, but you get the full XBMC experience (with apps, themes, weather etc) instead of just a remote to control your "other" instance.

See [http://wiki.xbmc.org/index.php?title=HOW- TO:Install_XBMC_on_...](http://wiki.xbmc.org/index.php?title=HOW- TO:Install_XBMC_on_iPad/iPhone/iPod_touch) for more details on how to install it on an iPhone, iPad or iPod touch

</comment><comment><USER24> Just wondering, how would XBMC fare on a Raspberry Pi? I've been thinking about setting up an ultra-cheap media center.

<comment><USER25> Very well, apparently.

<http://www.raspberrypi.org/archives/571>

</comment></comment><comment><USER3> The only thing XBMC is missing is HD audio support. My hope is that 12 will have it. Then I can ditch PowerDVD

</comment><comment><USER26> I've been following XBMC for ages. Glad to see you guys are still getting work done!</comment>


Naomi Klein argues climate change is a battle between capitalism and the planet - <AUTHOR> http://www.irishtimes.com/opinion/naomi-klein-argues-climate-change-is-a-battle-between-capitalism-and-the-planet-1.2647166 <comment><USER2> Totally agree</comment>


Wine 1.3.4 Adds New Features, Supports ARM - <AUTHOR> http://www.phoronix.com/scan.php?page=news_item&px=ODY0NQ <comment><USER2> Wait, ARM support? Can someone explain how this is possible? The changelog isn't very forthcoming. Are they saying that they support Windows apps that have been compiled to work on ARM?

<comment><USER3> Phoronix are being misleading with their headline. If you review the original release announcement you'll see that the actual feature is winelib support for ARM, which just means you can recompile Windows applications if you have the source (and can get them to compile with winelib) and have them work on ARM.

<http://www.winehq.org/announce/1.3.4>

<http://www.winehq.org/site/winelib>

</comment></comment><comment><USER4> Mostly what I want is 64 bit wine. 32 bit wine on 64 bit systems just gets impossible. Little things break especially around DRI support.</comment>


Toyota Announces Segway Competitor - <AUTHOR> http://blog.wired.com/gadgets/2008/08/toyota-announce.html <comment><USER2> Very cool, especially the video of the hands-free gracefulness.

The small size is also cool, but I suspect these research/demo models have terrible _battery_ life... _EDIT_ it gives 3 miles, at 3.7 mph [http://www.sfgate.com/cgi- bin/article.cgi?f=/n/a/2008/08/01/...](http://www.sfgate.com/cgi- bin/article.cgi?f=/n/a/2008/08/01/financial/f082734D47.DTL)

bet: they pay no patent royalties to Segway.

Also, why not have a seat on them? Seems like so much work, having to stand all the time. :)

<comment><USER3> _bet: they pay no patent royalties to Segway._

Hardware is actually vastly more difficult to patent than software. As its explained to me, you can't just patent "a two wheeled balancing scooter" the same way you seem to have been able to patent "buying stuff, but on the _interwebs_!" You have to patent novel gear systems, a _unique_ balancing system. (Balance is actually a very simple 3 term formula that can be made without even a computer using just a few $0.14 op amps. I'm sure Segway has added considerable flair to this well known concept.) With mechanical systems, there are literally hundreds of years of prior art.

Toyota couldn't make a scooter that looks just like a segway, but they'll have no problems with a two wheeled balancing scooter. (Provided a teardown doesn't reveal a "borrowed" circuit board or gear train.)

I'm not generally a big fan of the patent system as it operates today but I think its still quite functional in the mechanical device area. Segway spent a lot of time setting up a good gear/motor/balance system. They should be protected from somebody just pulling it apart and making castings of the internals to produce a cheap knockoff. They should _not_ be able to prevent some one else from doing their own engineering to produce a competing scooter.

<comment><USER2> I agree: don't make the concept/idea patentable, only the specific implementation. The specific light bulb; the specific telegraphy system.

OTOH, I kinda like the idea of Segway owning the concept - it was a cool idea, and a lot of work to pull it off. But I don't like the world that owning concepts so generally would create. I think it's good to encourage many people to search for ways to do it, and they get to own what they find. If someone finds the best way, they win big. I think that's great.

I find it interesting that Morse's original patent seemed pretty much along the lines you say - but then, several years later, he tried to amend it to cover _any_ way of accomplishing telegraphy. The courts upheld the original, but not the amendment (if memory serves). The amendment seems to be the style of patenting software today.

I see no reason, in principle, why patent law can not operate in the same way in the software world as it does for mechanical systems - despite software being more abstract.

<comment><USER3> I think that software patents have failed us because code is still magic to the USPO.

One computer that, for example, calculates large prime numbers looks exactly like another that does the same. The patent system considers the one a copy of the other, It cannot understand that there are radically different ways to calculate large primes. In short they actually _don't_ understand software at all and try to treat computers like gear filled machines.

<comment><USER2> You're right. In a sense, that's also true of comp sci academics and professionals. The field isn't a _disciplined_ field (unlike mechanics). I think it's partly immaturity (mechanics is older); partly massive opportunity (everyone just reinvents everything); and partly the mathematical nature of comp sci...

In my research, I've seen mathematical models reinvented with different technologies a decade later: e.g. first SGML and OODBMS; now XML and Java. The later writers are unaware of the earlier writers.

There's very little knowledge of what's been published. It's hard to find, and hard to recognize because of different terminology. It can be very hard to recognize in a deeper sense, whether two domains (and algorithms operating on them) are actually equivalent (e.g. languages recognized by automata vs. languages generated by regular expressions).

BTW: Ken Thompson patented his method for searching with regular expressions (expired 1988). [http://www.google.com/patents?id=Cx9xAAAAEBAJ&printsec=a...](http://www.google.com/patents?id=Cx9xAAAAEBAJ&printsec=abstract&zoom=4&dq=3568156#PPA5,M1)

As far as understanding the fundamentals of computer science, I think we are very poor at it - much of the mathematics is about very simple and basic stuff (though the mathematics itself is usually not so simple...).

Mechanics can also be described by mathematics - arguably, _is_ mathematics in a sense. I don't think that being mathematical is a killer for computer science patents.

</comment></comment></comment></comment></comment><comment><USER4> It seems like a nice step up from the current Segways.

A lot of work must be done in making these socially acceptable. Segway definitely failed at that. I think Toyota has the capital and brand to take it to the next level.

Hopefully they put the resources towards it because I'd like to see what happens with this.

<comment><USER5> Step up? It has 1/4th the speed and 1/8th the range. I dig the no-hands version, but at that speed and range it would be much quicker to just walk.

<comment><USER6> I agree. The "stick" version actually makes the Segway look cool. The no-hands version moves pretty well, although it kind of looks like a ThighMaster on wheels.

C'mon Toyota! Still waiting for my hover wing like the Hobgoblin had!

</comment></comment></comment><comment><USER7> The actual title is "Toyota Announces Segway Killer". It's kind of like saying "Toyota Announces Apple Newton Killer".</comment>


Ask HN: Are you aware of any banks that offer a consumer API - <AUTHOR> I'm looking for a place to put my money that offers an API that I can consume with my own scripts. I don't want to make a scalable app with something like Plaid. I just want to be able to pull down current balances and transaction history; I don't want my API key to be able to transfer money external. Bonus points if I can open unlimited sub-accounts and make internal transfers between them. I'm happy to pay a modest fee for this service. Double bonus for existing mobile UI. Does something like that exist? <comment><USER2> This doesn't exist in the US, as far as I know. It's now mandated in some parts of Europe.

You don't explain why you don't want to use Plaid, though. It would work well for what you're describing, except for the internal transfers. I've never heard of an API for initiating transfers, though you could probably set this up in an afternoon using headless Chrome interacting with a Zelle web UI.

</comment><comment><USER3> In Europe yes, but you don't state where you are.

<comment><USER4> I'm not the OP but I'd like to know if this exists in Australia.</comment></comment>


Practical Evaluation of the Lasp Programming Model at Scale - <AUTHOR> https://speakerdeck.com/cmeiklejohn/practical-evaluation-of-the-lasp-programming-model-at-scale <comment> a-saleh Sounds like trying to build a real programming language out of propagation networks [1]

[1] [http://web.mit.edu/~axch/www/phd- thesis.pdf](http://web.mit.edu/~axch/www/phd-thesis.pdf)

</comment><comment><USER2> Is there a quick start guide for LASP somewhere on the web?

<comment><AUTHOR> For now, the best information we have is here:

[https://lasp-lang.readme.io/](https://lasp-lang.readme.io/)

That said, Lasp PG is being used as the underlying infrastructure for the Erlang port of Microsoft Orleans, erleans.

We have several companies using our scalable infrastructure replacement for Distributed Erlang, partisan.

Additionally, our previous work has been inspirational for gen_stage in Elixir (Lasp's gen_flow) and Phoenix channels (riak_pg, replaced by lasp_pg later.) There are several papers outlining out work and designs at Erlang Workshop (co-located at ICFP.)

<comment><USER2> That's awesome :) thanks for the great work!</comment></comment></comment>


The Quackwatch guy is exposed as a fraud - <AUTHOR> http://subversivethinking.blogspot.com/2008/12/skeptic-stephen-barret-of-quackwatchorg.html

<comment><USER2> He may well be, but I will investigate elsewhere, I think. The tone of this article gives me very little confidence in the substance of it.</comment>


The stickiness of UK newspaper sites compared - <AUTHOR> http://onlinejournalismblog.com/2009/08/05/newspaper-stickiness/ <comment><USER2> I found this interesting. Especially when compared with the BBC's stats. At 4.85 pageviews/user and 35.7% bounce rate they are substantially better than even the Sun.

<http://alexa.com/siteinfo/bbc.co.uk></comment>


Virginia Health Commissioner says he'll mandate a Covid-19 vaccine - <AUTHOR> https://www.wric.com/news/virginia-news/virginia-commissioner-of-health-plans-to-mandate-coronavirus-vaccinations-once-available-to-public/ <comment><USER2> I'm just imagining the class action lawsuit that ensues for a myriad of reasons.

</comment><comment><USER3> While we all want this to end, this isn't going to win people over.

</comment><comment><USER4> Update: Virginia Governor said he's actually not going to mandate the vaccine.</comment>


Amazing visual search coming to iPhone in June - <AUTHOR> http://gizmodo.com/381352/visual-search-engine-coming-to-iphone-in-june

<comment><USER2> Very similar to Lincoln from MS Research <http://lincoln.msresearch.us/Lincoln/Logon.aspx>, including the example of a video in a videostore. And it's 1 year old!</comment>


Mathematician Claims Proof of Connection between Prime Numbers - <AUTHOR> http://news.yahoo.com/mathematician-claims-proof-connection-between-prime-numbers-131737044.html

<comment><AUTHOR> Relevant discussion at mathoverflow.net [http://mathoverflow.net/questions/106560/philosophy- behind-m...](http://mathoverflow.net/questions/106560/philosophy-behind- mochizukis-work-on-the-abc-conjecture)</comment>