Pair Programming is a complete crock of shit. If you hire someone to do a job, either they can do their job, or they cannot. If you cannot trust someone to perform and deliver work up to a certain standard, do not hire them. Is there any other industry where you hire two people to do one job?!
Now there are certainly times when it is very valuable to do collaborate, such as rubber duck debugging https://en.wikipedia.org/wiki/Rubber_duck_debugging or mentoring or simply doing a 'desk check'. But these are the exceptions, not the rule. Having someone breathing down your neck or be a back seat driver all day is at best a waste of productivity, forcing the driver to think at the pace of the observer, and at worst, a complete waste of time and effort.
Sorry, but I remain skeptical. The same people who use `float` for financial calculations are probably the same people who don't understand how/why to do the rounding described to avoid these problems. Way too many programmers think that they are working in base 10 when using float. Why not just make them use it, and keep them out of trouble.
Also, I wonder what the overhead of rounding every operation is? Comparable to the cost of using a proper Decimal class?
"if you are doing some financial math that does not need to be accurate to the penny, just use floating point numbers."
I would argue that financial math by definition needs to be accurate to the penny. Where is "pretty close" financial calculations considered acceptable? Having worked at a bank, I know how seriously this sort of thing is taken.
From experience, working in scientific applications and numerical computing, summing large numbers of floats is fraught with accuracy problems too.
The core is simple, small, cheap or even free, requires few resources, has plenty of tool support, is well-understood and well-documented, and is easy to debug and deploy. The 8051 is perfectly sufficient for many simple embedded applications that only require an 8-bit micro.
It's the instruction set that has been retained, not the silicon design. The variants these days are more power-efficient and powerful in terms of MIPS and peripherals, and have indeed benefited from years of R&D.
What a damn shame. I use git when I have to, hg when I get to choose. The usability and ergonomics are just so much better. I've never had any performance complaints. I chose Bitbucket over Github specifically because of Mercurial support. Unfortunately it's a business decision and they had to make a tough call.
Great points. I agree - the performance hit is simply the cost of being accurate and having predictable behaviour.
I'm not suggesting we replace all our current HW with chips that implement posits (let's fix branch prediction first!!). More that FP should be opt-in for most HLLs.
> Sorry, but you actually sounds like one those people who dosen't really know how FP work.
LOL, sure ok. Worked on banking systems for 2 years and been doing scientific computing for many more. Pretty comfortable with fixed and floating point.
> [error bounds] Likely irrelevant for most e-commerce.
Those bounds are theoretical, and there are plenty of occasions I have come across in the past when rounding errors were observed. It was forbidden in the bank to use floating point! We went to enormous lengths to ensure numerical accuracy and stability across systems.
I think this article has a pretty good explanation:
> Nonsense. If you do any scientific computation you have likely have Boost, GMP, MPFR installed in your system. They support arbitrary precision arithmetic with integer (aka fixed point), rational and floating point.
Yes, absolutely right; I have used several of those 3rd party libs myself, as well as hand-rolling fixed point code (esp for embedded systems). I didn't write what I intended. I meant to say that very few languages have first-class fixed point in their standard library. So long as the simple `float` is available as a POD, people will (mis-)use it.
I think in a general purpose HLL, a fixed decimal type should be the default, and you should have to opt in to IEEE-754 floating point.
Very few developers truly understand floating point representation. Most think of it as base-10, and put in horrific kludges and workarounds when they discover it doesn't work as they (wrongly) expected. I shudder to think how many e-commerce sites use `float` for financial transactions!
So as far as I'm concerned, whatever performance cost these alternate methods may have, it would be well worth it to avoid the pitfalls of IEEE floats. Intel chips have had BCD support in machine code; I'm surprised nobody has made a decent fixed point lib that is widely used already.
IMHO SCons had some nice ideas but it falls down in practice in non-trivial projects. Wrestling with eels is easier than doing cross-platform builds in SCons. And while I do love Python, I think using a fully-fledged language is a mistake.
I think a declarative DSL with scripting hooks behind it is a better model. Having used many, many build systems over the years, I've never found one I thought truly got things right (though several came close).
I actually think the ideas behind bjam ought to be revisited. It had a declarative style, with scripting to support it. The implementation was awful sadly; the tiniest mistake or typo would send the parser into a tailspin and the documentation was truly confusing. Any errors were presented to the user at the scripting level, which was even more confusing. But the idea of having toolchains defined separately, and having traits and features was brilliant. There's a lot to learn from there.
It's astonishing how many web designers have no idea about the difference between inclusive and mutually exclusive options.
I see checkboxes used all the time when they should be radio buttons. It's not rocket surgery. https://www.nngroup.com/articles/checkboxes-vs-radio-buttons...