HN user
Great article, and terrible idea. Wonder why the UI guidelines were bent here.
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...
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.
How can you write an article about this without mentioning that you should use a Decimal type for working with currency calculations?
- https://dzone.com/articles/never-use-float-and-double-for-mo... - https://husobee.github.io/money/float/2016/09/23/never-use-f... - https://husobee.github.io/money/float/2016/09/23/never-use-f...
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.
Likewise!
FYI the actual paper is https://ieeexplore.ieee.org/document/8425212 and you can get the PDF here: http://pdinda.org/Papers/ipdps18.pdf
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:
https://dzone.com/articles/never-use-float-and-double-for-mo...
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.
People still use Perl?
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.
"Yet another 'academic' claims to have cracked part of the Voynich code but doesn't realise how much they still don't understand"
Fixed that for you.
It's not a bug - it's a feature: reserved filenames which have special features and functions. And it has been preserved through DOS, and Windows over the years as part of Microsoft's philosophy of "compatibility at all costs".
There are many, many examples of similar (mis)features. Not sure why this particular one is getting so much attention. But yeah, if you know the history, it's not really surprising.
For anyone interested in this sort of software archeology, have a look at Raymond Chen's blog https://blogs.msdn.microsoft.com/oldnewthing/ which is full of this stuff. Very interesting reading.
Good grief, what a loaded headline. It's not a "tax" for a start. It's a fee. And what does the fee cover? PCI DSS Credit card processing services, secure web hosting, worldwide CDN-cached downloads, sales and download analytics, listing in the premier app catalog with many millions of users, marketing exposure for popular/successful apps, and more.
How much would it cost for developers to do all this themselves? Every single individual developer? People seem to forget what things were like before the App Store.
Now one could question the percentage itself, and ask if it is a reasonable number, but when you consider the time and effort and investment that would otherwise be required,
Unfortunately, the majority of technical details on the web on implementing VU meters in the digital domain is misleading, of not outright wrong.
A while back, I implemented VU meters for some professional AV software. I started with the available references, but quickly discovered that it was well-intentioned but incorrect/inaccurate. I ended up sourcing the original specification for the analog meters, and then devising digital filters to replicate the same ballistics. This matched perfectly with the reference, (pro hardware).
TL;DR don't believe what you read on the web. Go to primary sources!
So imagine Apple starts to show warning messages saying "your battery cannot hold sufficient charge and is EOL - you should replace it now".
We would have a different spin on Batterygate where Apple is greedily telling people to replace their batteries when they allegedly still work just fine, because all they care about is selling more batteries and making more profit.
I developed on the Aibo years ago for Robocup robot soccer, writing software for object recognition, navigation, locomotion, etc. Much fun!
It's surprising to see its return after a long hiatus, as Aibo has had several ups and downs in the market. And despite such a long period when it could have been enhanced, it looks like it is not significantly changed from the last generation.
Such a disappointment. Wunderlist was the best in a very crowded market. It would have been ok if they had launched with something comparable to what it intends to replace. But this is missing so many key features (yes, many are planned) that it is a huge let-down to long-term paid-up users.
It's impressive what you can achieve in under 16kB:
https://www.youtube.com/watch?v=ZaVo-OffZD8CMake, Scons, Ninja, Gyp
There are many more, but these are more viable alternatives to auto tools.
https://en.wikipedia.org/wiki/List_of_build_automation_softw...
CMake actually does platform probing (test compiling with code fragments to identify platform features and quirks) in a similar manner to autotools. But it is much easier to work with, and significantly better documented. I find the syntax shouty and verbose but it does the job, and has proven its mettle in many large, complex cross-platform projects.
As for CPython extensions, I can relate also. Though the cffi makes some of it redundant, and Boost::Python is brilliant for wrapping C++ projects.
Yes, indeed. There are so many anachronistic features that bog it down with baggage and complexity and slowness.
It is easier now than ever before to port code between the major platforms, and especially with frameworks such as Qt.
This documentation and video is good if you want to use autotools. But in 2016, you should really be asking yourself if autotools is the right choice. It is rather baroque, and there are many other choices these days that provide similar functionality for less developer time and effort.
Mercurial has to be one of the best examples of incredibly high quality Software Engineering out there. It is very well-designed, reliable, fast, easy to use, well-documented and has a great community behind it. Matt deserves huge kudos for his enormous effort and commitment over the years. And like a true gentleman, he is leaving in style to ensure the transition is smooth.
I've tried using many different online tools for tracking software projects and work (including Todoist, Trello et al) and eventually settled on Asana.
It's not perfect, but it most closely matches the workflow I need. It's flexible without being overly generic (Trello) yet doesn't impose or constrain your workflow too much as some other tools do.
There certainly are some quirks though, and my biggest peeve is the 'empty task' problem described in the original article. If I could vote for one fix, it would be that!
Decided to give it a try, and very impressed so far. Easy to set up, nice and clean interface. Most important of all, a fast workflow for processing email.
I encourage everyone to support high quality indy projects like this.
Not only is text durable, but plain text data is universal.
Take a document written in the word processor du jour 20 years ago. It is highly unlikely you could mount the physical media, let alone import the data with high fidelity. But plain text can be read by just about any tool, whereas binary/proprietary formats are limited by the longevity of the hardware/software that created them.
Ah great, ok. I'm really enjoying them, and would really like to finish both!
This is awesome! Except - I haven't finished the Matasano CTF yet! Too many flags, not enough time. :/