I find these results very questionable. They're based on an automated assessment tool http://www.aspiringminds.com/technology/automata There are only sparse details on how that works. They also appear to be basing it on "known" good coding techniques, without any listings, and despite the rest of us always arguing about what is good and bad.

While the situation may not be good, this study is completely untrustworthy. It's just a company trying to sell their questionable HR product.

It's not functions that eventually work that are causing software to crash, security breaches, and other data corruption.

The article is meant to serve as an anchor, and reference, for other discussion about error handling. Given that errors can happen all the time a language, and libraries, should be designed so that programmers don't need to think about errors all the time.

Sorry about that, I do try to pay attention to these things. I fixed it and hope you will continue reading now.

Yes. I'm trying to create a language that is very modern and without suffering from backwards compatibility overload.

I know it isn't always interesting to all people, but I try to give a bit of background to such things before jumping into my actual code. A lot of people are not likely familiar with Newton's method, or this type of iterative processing at all.

Yes, I'm happy with how I got the initial guess. I was reading up on how to do that step and didn't see that approach (I'm sure it must be known, given it's obviousness, just that I didn't read enough). Given that the numbers are stored in base 2, with a normalized significand, this initial guess is amazingly close to the correct value allowing a very low number of iterations.

It's all of course tentative syntax at the moment. I thik most of what is there will be similar in the end, but I'm leaving it open to change whatever I want. :)

Signed distances fields are used pretty much this way to render text nicely in a 3D environment. You produce a font atlas by rendering fonts at a very high resolution, then producing a reduced distance field version. This basically looks like a gradient by the edges of all the text. You then use this to draw the text, not directly, but to calculate the distance. Then you can use the same technique from my article to draw either exact on/off borders or antialiased borders (likely more desired for text).

The trick is that even through bileaner filtering each pixel gets a single distance to the edge, and this distance is quite accurate for the pixel on the screen. Obvioulsy it has its limits, but it does a really good job of producing readable text with a fixed texture atlas.

There's quite a bit about this use of signed distance fields available online.

It may differ from team to team, but several I've worked on even the programmers did not much care about the code. We were invested heavily in process, like unit testing and use driven development. A primary motivator was showing that the features were actually working. The actual code was kind of secondary, so long as it was working we were okay with it. It's actually kind of liberating for programmers knowing that nobody really needs to care about your code -- I don't want somebody micromanaging details and nitpicking small choices.

I'm going to put a big "however" on this, and it's something I mention in the article as well, I'm assuming a certain base-line of competant coding and workmanship. Crap code is unnaceptable everywhere; it's also very unlikely to actually implement the desired feature. The article is a counter to over-engineered results and needless perfectionism. It's about finding a good balance and focusing on the priorities of the project as a whole.