10-60TB hard drives coming to tablets, notebooks, desktops by 2016 - <AUTHOR> http://vr-zone.com/articles/cloud-computing-10-60tb-hard-drives-coming-to-tablets-notebooks-desktops-by-2016/15981.html

<comment><USER2> It's funny how everybody's reading this backwards. It's a press release, guys, take it with a grain of salt. "Look, 1184305% increase! wow!". If you take 30 seconds to put drives capacities in a spreadsheet, you can't miss this actually announces a _huge drop_ in the speed of HDD size increase.

From 1990 to 2005, HDD size (and density) roughly quadrupled in 3 years. From 2005 to 2012, drive size grew by a mere factor of 2.66 every 3 years. And they dare triumphally announce that in the future, the multiplication factor will drop to 1,66 every three years, _that's_ a hell of an improvement indeed.

For those who'd point out that this is a report about platter density and not drive capacity, I'd say that 3.5" HDD have had at most 5 platters for twenty years, so platter density always reflect quite exactly maximum available drive capacity anyway.

<comment><USER3> Who exactly is reading this backwards? That's a bit of a straw man.

I think you're jumping the gun a bit ruling that storage capacity is already slowing down; I tend to agree it's just around the corner, but this chart definitely does not indicate a conclusive trend in already released drives:

[http://upload.wikimedia.org/wikipedia/commons/thumb/9/90/Har...](http://upload.wikimedia.org/wikipedia/commons/thumb/9/90/Hard_drive_capacity_over_time.svg/700px- Hard_drive_capacity_over_time.svg.png)

<comment><USER2> I'm counting only the highest available capacity drives in 3.5" format. If you mix various physical sizes it changes the overall tendency quite a bit. Until around 1999 (availability of 50GB 3.5" drives) the biggest available drives were 5.25" (up to 43 GB). 5.25" drives were also much more common than 3.5" drives during all of the 80s. That's why I'm counting starting in 1990, which flattens the curves.

</comment></comment></comment><comment><USER4> Hard drive sizes seem to be mostly driven by consumer devices which are mostly moving to smaller SSD. Not saying 60TB drives won't happen, just not sure there is actually going to be a consumer market for them.

</comment><comment><USER5> I think the article writer is getting confused with the units. Besides making a typo at one point, using Gpbs, they use the abbreviation tB - lowercase t. Possibly in the original report, it was Tb - ie Terabit - ie 60Tb = 7.5TB which sounds more likely.

</comment><comment><USER3> It doesn't explain why a 2.5x jump in areal density, by their own figures, will magically yield a 15x increase in drive capacity. What a useless article.

<comment><USER2> It's because iSuppli study absolutely doesn't say they'll reach 10 TB by 2016, but that 60 TB on a 3.5" is the absolute maximum attainable through the HAMR technology, in some unstated (but quite far away) future.

</comment></comment><comment><USER6> I think that in 2016 you will not be able to buy a tablet or notebook with a HDD, everything having been replaced by SSD.

<comment><USER3> Tablet definitely, but I suspect SSD + traditional HDD will be reasonably common, though in decline by 2016 (using the space freed up by removing the DVD drive).

</comment></comment><comment><USER7> By 2016 not a single tablet or notebook will have a hard drive.

</comment><comment><USER8> There is no mention of the cost per MB. There is however a statement that the process is patented by Seagate which has me thinking the price per unit of storage will be high. Hopefully, assuming the claims made are accurate, Seagate will license the technology at a reasonable cost.

</comment><comment><USER9> Will we need massive physical storage devices now cloud storage is becoming more accessible for all?

<comment><USER10> I'm guessing that most HDD space is used for music & video. If the anti-piracy campaigns continue (censorship, TPB blocking, MegaUpload), I expect most piracy to move "offline", to HDDs.

10 TB would be excellent, I would'n need to pick which of my favourite movies I want to save...

<comment><USER11> And take the case of a photographer who, with current equipment, can easily create 100-200GB of content _per shooting day_. (I'm thinking specifically of a wedding or event photog using a Nikon D800, Canon 5D Mk III, or similar class of camera. Besides the raw image files, there are the catalogs, processed/developed/retouched images, resized images for common print and display formats, album layout pages, and whatever else may be needed to provide the service offered.)</comment></comment></comment>


The Private Heisenberg and the Absent Bomb - <AUTHOR> http://www.nybooks.com/articles/2016/12/22/private-heisenberg-absent-bomb/ <comment><USER2> That's been a speculation for decades. Here's a more technical analysis of Heisenberg's calculation of critical mass.[1] He had a figure of tons of uranium. In reality, the bare-sphere critical mass of U-235 is 52Kg. The Hiroshima bomb, which was a very simple design, used 62Kg. With reflectors and compression, smaller amounts can be used.

Whether Heisenberg miscalculated this by intent or mistake remains unknown.

[1] [https://www.mpiwg- berlin.mpg.de/sites/default/files/p467_3.p...](https://www.mpiwg- berlin.mpg.de/sites/default/files/p467_3.pdf)

<comment><USER3> It's an interesting and somewhat romantic idea, but frankly I doubt that someone as intelligent as Heisenberg wouldn't have understand that whatever his calculation claimed, this wasn't going to stop with him.

<comment><USER4> But as the last part of the article explains, Heisenberg could probably count on his peers not looking too closely at whatever calculation he made, so long as it discouraged the project. And his peers, in this matter, at that time, were not many.

</comment></comment></comment><comment><USER5> Popp 2016: "Misinterpreted Documents and Ignored Physical Facts: The History of 'Hitler's Atomic Bomb' needs to be corrected" is obviously unknown to the author of this article:

[http://onlinelibrary.wiley.com/doi/10.1002/bewi.201601794/ab...](http://onlinelibrary.wiley.com/doi/10.1002/bewi.201601794/abstract)

"It is shown that until the end of the war the German physicists did not know that an atomic bomb can only be made with fast neutrons, except Heisenberg, who, however, discovered it rather late, did not communicate it clearly and did not study any bomb physics. The physically correct interpretation of the documents reveals that the German physicists worked unsuccessfully on a reactor, which would have been a prerequisite for a plutonium bomb. But they did not know how to build a bomb because they never worked on a realistic bomb theory."

<comment><USER6> I don't know whether Thomas Powers is acquainted with this particular paper, but the paper itself makes it clear that Mr. Powers is well acquainted with many of the documents that form the basis of the paper. Popp's paper and Powers' article are about two different, albeit related, issues: Popp's purpose is to show that the German scientists' grasp of bomb-making has often been exaggerated (though not particularly so by Powers, who has been criticized by Walker for the opposite), while Powers' article considers whether Heisenberg's recently-published letters to his wife shed any more light on his purpose and motives. While knowing what he knew (and thought he knew) of bomb-making helps in analyzing his words and actions, physics alone cannot resolve the matter.

</comment></comment><comment><USER7> It's fairly fictionalized but the play Copenhagen uses a visit between Heisenberg and Bohr to explore this topic. There's a decent BBC version.

<comment><USER6> My impression (recalled over a decade or more) is that the play uses the meeting to launch into an exploration of the moral ambiguity and - yes - uncertainty surrounding Heisenberg's wartime role. The fictional dialog is much longer than the actual meeting apparently was, and it refers to events that were subsequent to that meeting. IIRC, it followed the publication of Thomas Powers' book on the topic but preceded the publication of the Farm Hall transcripts. I thoroughly recommend it.

<comment><USER7> There's also a play (Operation Epsilon) based on the Farm Hall transcripts. It's perhaps a bit too literal and has a lot of characters. That said, while I don't think it's in the same class as a work of theater as Copenhagen, I definitely recommend it if it comes around.

</comment></comment></comment><comment><USER8> A lot has been said about Heisenberg's calculation of the critical mass of U 235. Many believe it to be his miscalculation. I think most people would agree that he was quite a 'good' mathematician and yet the analysis in the Farm Hall transcript is at a level one would expect from a first year undergraduate. No mention of 'Laplace transform into spherical coordinates', or more simply 'Fick Law' on diffusion. When he talks about 10 tons of U235, Hahn (a chemist) reminds him that he has told him that only 50 Kg is needed. And later when Hahn askes how the bomb works Heisenberg talks of 'each neutron begets two children' and that 1 ton is needed. A week later Heisenberg gives a very 'polished' lecture on the subject using the appropriate mathematical concepts. The question is did he work this all out in a few days or did he already know? Perhaps he had some ambivalence about putting such a weapon in the hands of someone slightly 'unhinged', a dilemma we have today!

<comment><USER8> As a foot note. Heisenberg was not the only one to foster the idea that the weight of such a bomb would be an impediment to its realisation. Both Heisenberg and Yoshio Nishina were students under Niels Bohr. Nishina went on to become Japan's eminent physicist and to work on Japan's own atomic bomb but even he had some ambivalence about such a weapon. As recorded in the minutes of the meeting on the 2nd July 1943 at Riken, Tokyo, after describing some technical aspects to Lt. Gen. Nobu-uji, Nishina adds " that is to say, the weight of this thing would be enormous and because of this, the opinion is that it would not be suitable (as a bomb)". すなわちボンブの重量甚大なるものとなるを以て、適当ならざるべしとの見解なり Sunawachi bombu no jyuryo jindai naru mono to naru wo motte tekito narazarubeshi tono kenkai nari."

</comment></comment><comment><USER9> "Heisenberg's War" is about the possibility that Heisenberg either didn't try very hard or perhaps deliberately sabotaged the German bomb effort. Very controversial, great read.

[https://www.amazon.com/Heisenbergs-War-Secret-History- German...](https://www.amazon.com/Heisenbergs-War-Secret-History- German/dp/0306810115/ref=sr_1_1?ie=UTF8&qid=1487032563&sr=8-1&keywords=heisenberg%27s+war)

<comment><USER10> Heisenberg is a smaller part of this book; gripping read: [https://en.wikipedia.org/wiki/The_Making_of_the_Atomic_Bomb](https://en.wikipedia.org/wiki/The_Making_of_the_Atomic_Bomb)

</comment></comment><comment><USER11> I think it would be horrible to be in a country with a leader like Hitler knowing a way to deliver them extraordinary power to do damage and destruction.</comment>


Ask HN: Opinions on the best PHP IDE? - <AUTHOR> Dear HN,
I'm having trouble finding an adequate IDE to use for my PHP development. I'm part of a small company that has a relatively very large project base. I've been going through the IDEs of choice, and haven't been able to pick one. Could you help me out?
Here are the requirements: -word wrap -remote debugging -easy integration with SVN or CVS -fast text suggestion -fast in general
I've tried the following IDEs so far: Eclipse, Netbeans, PhpED, Zend Studio 7.1, PDT. All have their issues - many don't have code folding, and stuff like Zend and Eclipse are fairly slow (at least when compared to PHPed. However PHPed has poor integration with Linux and is also the costliest of the bunch.
Any suggestions would be appreciated. <comment><USER2> If you have a Mac (fast Mac), Coda is very Mac-like and friendly. However it slows my 1 year old Macbook pro down quite a bit, so it's by no measure "fast". More of a text editor too, really.

<comment><AUTHOR> I wish I had a Mac. This is actually our main drawbacks - our company needs a somewhat unified system, which is why I'm asking for suggestions. Sadly, none of us have Macs, so while I'd love to use Coda (Seriously, I love that program. Using my friend Matt's Pro is simply a pleasure because of it) it's one of the programs I can't use.

</comment></comment><comment><USER3> Notepad++ works just fine. It has plugins for source control.

</comment><comment><USER4> [http://arstechnica.com/open-source/guides/2009/05/vim- made-e...](http://arstechnica.com/open-source/guides/2009/05/vim-made-easy- how-to-get-your-favorite-ide-features-in-vim.ars)

Seems relevant.

<comment><AUTHOR> Vim is, sadly, wholly inadequate for my needs. It kicks ass for speed, and I didn't know about the code completion, so that's a plus. But for integration with our current systems, it's just not enough.

Version control is much more difficult, and remote debugging is extremely useful to us. Quick project management is also more difficult with Vim, despite the rapid integration with the shell.

<comment><USER4> I have been using fugitive.vim for integration with git, I don't know about svn or cvs as I don't use them.

The thing is vim needs to be (but can be!) tailored to your needs.

</comment></comment></comment><comment><USER5> Komodo Edit is pretty good.</comment>


Ask HN: What are some good resources to learn electronics and hardware? - <AUTHOR> <comment><USER2> NAND2Tetris is a good start

[http://nand2tetris.org](http://nand2tetris.org)

<comment><USER2> And to add a similar ask from earlier in the year

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


No Silver Bullet (1986) [pdf] - <AUTHOR> http://worrydream.com/refs/Brooks-NoSilverBullet.pdf <comment><USER3> To this day this piece from 1987 remains one of the most wanted pieces of wisdom:

 _I still remember the jolt I felt in 1958 when I first heard a friend talk about building a program, as opposed to writing one. In a flash he broadened my whole view of the software process. The metaphor shift was powerful, and accurate. Today we understand how like other building processes the construction of software is, and we freely use other elements of the metaphor, such as specifications, assembly of components, and scaffolding.

The building metaphor has outlived its usefulness. It is time to change again. If, as I believe, the conceptual structures we construct today are too complicated to be specified accurately in advance, and too complex to be built faultlessly, then we must take a radically different approach. Let us turn nature and study complexity in living things, instead of just the dead works of man. Here we find constructs whose complexities thrill us with awe. The brain alone is intricate beyond mapping, powerful beyond imitation, rich in diversity, self-protecting, and selfrenewing. The secret is that it is grown, not built._

<comment><USER4> Cool quote. Maybe now we "grow" software, in the sense that any application consists of probably thousands of interconnected systems/libraries/frameworks that work together in a way that is organic or emergent.

</comment></comment><comment><USER5> I wonder if people don't take the wrong lesson from this essay. There might not be any single 10x productivity-enhancing technology, but there have been many modest improvements. I think it's fair to say that a good programmer in 2015 is probably 10x more productive than a good programmer in 1995.

Someone reading this today might be tempted to dismiss tools they just don't understand as "not a silver bullet". However, even modest improvements are worth striving for, and if you only adopt what is "industry standard", you'll always be behind your early-adopter peers. (Or at least, those of your early- adopter peers who have good enough taste to distinguish a good, useful technology from the next shiny new thing that isn't ready for production and may never be.)

Things that have been a boon to me have been getting into Linux back in the early days when it was new-ish, the arrival of Google, learning Haskell, learning to use source control (first svn, now git), and the availability of things like Stack Overflow and Wikipedia. If I had to go back to using the tools of the mid nineties (Borland Turbo C++ on Windows 3.1, NCSA Mosaic and a 14.4kbps modem, 33mhz processors, 8 megs of ram, etc...), I could still sort of get stuff done as a programmer but really we've come a long long way since then.

<comment><USER6> " I think it's fair to say that a good programmer in 2015 is probably 10x more productive than a good programmer in 1995."

I don't know about fairness, but definitively that's wrong. I was around then and the most I could believe is that we are 2x.

<comment><USER5> I think it depends on what you're doing, and what counts as productivity. I think lines of code per developer per day haven't gone up much, but it's a lot easier to deliver much more complex products now than it was then, in part due to the large volume of readily accessible library code. There's less need to write special-purpose code for everything, because someone probably wrote the generic parts already.

There are some software domains that haven't changed much at all since the 90s or earlier. Systems programming is still done largely in C and C++, and modern kernels work basically the same way they did then with a few minor differences. Scripting has changed dramatically, web frameworks have changed dramatically, business applications have changed quite a bit. C# is noticeably different from Java, which is different from C++ or Cobol or whatever it was people used to write business software in back then.

</comment></comment></comment><comment><USER7> And here's Brad Cox's rejoinder...

[http://virtualschool.edu/cox/pub/NoSilverBulletRevisted/](http://virtualschool.edu/cox/pub/NoSilverBulletRevisted/)

Planning the Software Industrial Revolution is also a classic...

[http://virtualschool.edu/cox/pub/PSIR/](http://virtualschool.edu/cox/pub/PSIR/)

</comment><comment><USER8> I remember how, as a young programmer, how hopeful I was that this technique (OO, RAD, "Components") or that language (Scheme, ML -- those two were the "ancient secret knowledge" that we "rediscovered" and our bosses had "overlooked" \-- C++, Ada) will change programming forever and make software development completely different, and how angry I was at the experienced developers who told me that the most approaches will fail, and the best few would only yield perhaps significant, but evolutionary rather than revolutionary advances. Now I'm the one saying this to others...

I think that two specific advances did end up yielding significant (though evolutionary) progress since that text was written: automatic garbage collection, and automated testing practices. Both were viewed with skepticism, the latter with some derision, but they have both helped us out of a real crisis of the software industry in the nineties, when too many projects just couldn't get off the ground (or, rather, continuously crashed).

<comment><USER9> Yes, the world would be a better place if young minds all stopped dreaming and accepted the wisdom of the elders. There's nothing left to explore. </sarcasm>

<comment><USER8> Boy, are you a pessimist! That's not at all the message. The message is about working towards progress rather than jumping from one fad to the next with blind faith that something will "save" us. It's a call for technological progress rather than an alchemist's semi-religious search for a way to turn lead into gold.

<comment><USER9> My first reaction after reading the paper was similar to yours. That I had fallen for the OOP hype train. Later when my boss cited it as an excuse to iterate our aging platform instead of attempting a redesign, my view of it began to change.

It's true many technologies have been overhyped, but it's far too early to throw in the towel. A little over optimistic youth fueled zeal, has let to some of our greatest advances. I think Bret Victor sums my views up best here:

[http://worrydream.com/dbx/](http://worrydream.com/dbx/)

<comment><USER10> Great talk. Alan Kay and others have said similar things.

We've squandered all the gains the hardware people have made on slower, more bloated software, resulting in computers whose response times are no faster - and sometimes actually slower - than their equivalents were 30 years ago.

And I don't see much youth fuelled zeal going into solving the problem, or even coming out with much in the way of innovation which might help. Instead, people are excited about "new" languages like Golang and Rust (which doesn't even have a garbage collector!), and rebranded copies of BSD and Linux.

People are incredulous when I tell them that while the trailing edge - <USER2> entering COBOL into IBM mainframes on punched cards - has advanced considerably, the leading edge has regressed. As Philip Greenspun put it: " These days, most former Lisp programmers are stuck using Unix and Microsoft programming environments and, not only do they have to put up with these inferior environments, but they're saddled with the mournful knowledge that these environments are inferior."

And don't get me started on AI.

<comment><USER11>
      > Rust (which doesn't even have a garbage collector!)

I think you need to take an actual look at Rust if you think that the lack of garbage collection is somehow a design flaw. :P You're free to deride the language as "just" an improvement on the state of the art of systems programming instead of attacking the fundamental underlying problem (which is that the underlying systems themselves are tremendous clusterfucks), but not only is that outside of the domain of a programming language, it is also the case that merely ignoring the status quo out of personal dissatisfaction does not succeed in moving the world forward.

<comment><USER10> "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." \-- George Bernard Shaw

AIUI Rust grew out of a dissatisfaction with C++, and it does have a few good features, such as type inference. But since Java was released, it's been unthinkable for a high level language to require programmers to do their own memory management. If Rust is aimed _solely_ at systems programming, to be used the way Algol 60 was used to implement MCP, PL/1 Multics, C Unix, and Oberon Oberon, then the lack of a garbage collection is understandable. But you can never guarantee your product will be used as intended: I've encountered people who think C is an acceptable choice for _everything_.

I'm not merely dissatisfied with the current status quo: I'm actively doing something about it. IMO we're doing practically _everything_ wrong, from hardware upwards. Fixing it requires systems very different from those in widespread use today.

<comment><USER12> As you say, Rust is aimed at being a C++ replacement mainly for systems programming, and having a garbage collector is a hinderance there. Sure people will use it for not-strictly-systems-programming things, but that's on their head: they evaluate the trade-offs (e.g. if they can do without a GC) and choose Rust. Compromising the core goal (memory safety without garbage collection) by including a pervasive GC just because some people might make a slightly silly choice and use Rust where some other tools is better is just _wrong_. It would make Rust inappropriate for the places where there is essentially no other choice like it, putting in into a class with many other alternatives (e.g. Haskell, OCaml, D etc.).

In any case, on one hand you complain about slow, bloated software, and on the other about Rust not having a GC. The unpredictability of a GC being a major component of bloat in a lot of software. Don't get me wrong: it is possible to write sleek software in a managed languages with GCs, but for many tasks this generally requires fighting against the GC, with things like object pools and buffers (basically reimplementing the standard techniques from non-GC'd languages), and, of course, it is definitely possible to write bloated software without one.

Rust is designed to make it easier to write code without a GC, by adopting many of the advantages that garbage collectors/managed languages bring to table (and more, e.g. static protection against iterator invalidation). There's been a lot of people from Ruby, Python, JavaScript (etc.) backgrounds adding lower-level/more-control programming to their toolbox via Rust, something that was too daunting previously. This means that they can write software (or at least, sensitive parts of their code) that doesn't suffer from the overhead/bloat of the managed languages.

Lastly, Rust's memory management is nothing like "manual memory management" in C (or historical C++), I mean, it compiles down to be essentially the same thing at runtime, but what the programmer writes is very different. The combination of lifetimes, destructors and generics mean that it is difficult to do it wrong: memory leaks are rare, and the compiler will tell you about any dangling pointers, etc.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> Open source is surely a silver bullet that increased productivity 10x at least, for most of us.

</comment><comment><USER14> I now believe there is one at least silver-alloy bullet: simplicity, painstakingly maintained and violently defended by well paid developers.

<comment><USER15> Everyone agrees with simplicity when stated in such general terms, but in practice, simplicity _where_?

Note that simplicity in one piece of software often leads to complexity in another. For example, a language with a minimal set of instructions may be considered "simple", but building software with it can be complex and unwieldy. A minimalist API may be elegant and concise, but lead to headaches when attempting to use it. Etc, etc.

<comment><USER14> I don't think there there is a good objective definition for simplicity, since a large component of what I'm getting at is subjective and context-dependent, and therefore involves "appropriateness". API design is different than app building is different than container building, etc. This is why good developers are so important.

Regarding APIs, I like them to be layered: [http://devblog.guidewire.com/2008/10/05/api- design/](http://devblog.guidewire.com/2008/10/05/api-design/) so that code built on top of them can be as simple as possible.

<comment><USER15> Agreed. That was my point, that simplicity is subjective, so while people seem to agree that simplicity is desirable, they often disagree about _where_ to simplify (which often comes with trade-offs).

</comment></comment></comment></comment><comment><USER16> I believe Brooks will eventually be proven wrong about AI and Automatic Programming. Granted, he has not been proven wrong yet.

It is interesting, perhaps even a little surprising, that reasoning about programs has proven to be one of the most intractable challenges for AI. Why, to take a simple-sounding example, when my program does something wrong, can I not simply ask the machine why it did it? Why do I have to go in with a debugger and find the problem myself? This wouldn't require solutions to any of the familiar bugaboos of AI: it doesn't need a massive database of facts about the world, it doesn't require visual image recognition, it doesn't require natural language understanding, it doesn't require robotics or simulated emotions or any of those things. It just requires logical reasoning. Can't computers do that?

Well, no, it turns out, they can't do it, not in its full generality. Despite all the things it doesn't require, general logical reasoning is still almost AI-complete, which is a cute way of saying we still don't know how to make machines do it.

And fully general reasoning is required to solve the problem. We have lots of static analysis algorithms that can answer specific kinds of questions about programs, but we're still not very close to being able to answer an _arbitrary_ question, even fairly simple ones. The spaces we would have to search are just too big; the branching factors are too high.

I think there is hope on the horizon, though. The so-called automated reasoning systems that have been built over the last few decades -- also called theorem provers -- have mostly not made use of any machine learning techniques. These two technologies are starting to be combined, and machine learning is of course a very hot area right now. I believe that eventually we will have Automatic Programming worthy of the name as a result of this combination.

</comment><comment><USER17> This is required reading for every promising young hacker. The more promising, the more required.

<comment><USER9> I couldn't disagree with you more. This paper offers no insight, only excuses to accept that software will always be buggy. If anything I'd encourage young engineers to explore technologies that have been not been explored to their fullest potential. Computer Science is a very young field and many unexplored paths such as flow based or some automated programming method that hasn't been dreamed up yet that may lead to far more reliable software.

I dread to think what today's CPUs would be like if an electrical engineering version of this was required reading for every EE in the 70s. We should just accept buggy CPUs because of the complexity in designing CPUS with 7 billion transistors.

<comment><USER17> > This paper offers no insight, only excuses to accept that software will > always be buggy.

The paper does not address the problem of buggy software, though it is related. It addresses the problem that software is complex.

And the insight it offers is that not all complexity is equal: there is accidental complexity (programming is hard because the way we have done things historically is not yet optimized) and inherent complexity (programming is hard because we are modeling complex stuff and it is inherently hard for human minds to juggle all the relevant details).

The excuses you complain about are really examples where people confuse one with the other. i.e. you cannot solve the problem of Requirement Gathering with better compilers because the problem is not technical, it is that stake holders are playing political games in the background, so if left to their own devices they'll give you vague, confusing requirements now with the tacit intention of leveraging those when the inevitable struggles come in the future.

> I dread to think what today's CPUs would be like if an electrical > engineering version of this was required reading for every EE in the 70s.

I am sorry to inform you that an EE version of this will be direly needed in the near future. As the Moore law keeps hitting more and more fundamental limits of physics, we need engineers who are able to work in the problems that matter and make hardware that gives us the best possible performance given the constrains available. It would not do to have each generation of young EEs to start yet another cargo cult every 5 years or so, wasting valuable resources in the attempt to pack twice as much transistors per wafer.</comment></comment></comment>


JustFab: The Billion Dollar Startup with a Dark Past - <AUTHOR> http://www.buzzfeed.com/sapna/justfab-the-billion-dollar-startup-with-a-dark-past#.wfgpk3DY5 <comment><USER2> This kind of billing scheme is actually incredibly hard to pull off these days. Although few laws have been passed to mandate anything, Congress has pressured Visa and MasterCard to crack down hardcore on chargebacks (disputed transactions). If you receive over 100 chargebacks in a month, current Visa/MC regulations stipulate that you must keep the chargebacks to less than 1% of your total transactions. If you go over that even for one month, you get fined an exorbitant amount for every single chargeback over 1%.

Getting fined is usually enough to get you thrown off your payment processor and added to something called the MATCH/TMF list, which you never want to be put on. Once you're on that list, you're completely and utterly fucked.

If you are terminated by one payment processor due to excessive chargebacks, and you try to get a new account with another payment processor, they first run a query on... you guessed it, the MATCH list. If you pop up on the list, every single legitimate payment processor will turn down your application "so fast it will make your head spin" (to quote a certain presidential candidate). How long do you stay on the MATCH list, you might ask? A minimum of 5 years, although I have heard from some people that you are on it for life. Basically, a MATCH listing blacklists you so you can likely never get a credit card processing account ever again.

HOWEVER... there are so-called "high risk" payment processors who "occasionally" will take MATCH/TMF merchants once you have been on the list for 6 months or more. But, it involves some luck and it will cost you.

Most mainstream payment processors like Chase Paymentech will charge you fees based on a pricing structure called "interchange plus," which is the base rate that goes to the credit card brands (Visa/MC) plus a padding fee of 25 basis points or less that goes to the processor (Chase). Depending on the types of credit card that your customers use, interchange ends up somewhere around 2 - 2.25%. But most "high-risk" payment processors won't even entertain the thought of giving you an account without charging at least 250 basis points plus interchange on a reasonably good account! But most of the time, they just abandon "interchange plus" altogether and charge you based on a 3 tiered structure (low, mid, and high rate). This allows them to pad the bill even more, of course. Not to mention that a whole mess of other fees are padded, as well, leaving you paying at least 6.5 - 7% per transaction when it's all said and done.

Oh, and I neglected to mention that if you expect to still accept Visa/MC, you still need to abide by their rules. So your options are: (a) get your chargebacks down to less than 1% of your total transactions, or (b) get less than 100 chargebacks per month. If you're a tiny operation, it's a little easier. You need to improve your customer service so that fewer customers dispute transactions. As long as the total value of your disputes is less than 3% of your total monthly revenue, you can usually fly under the radar. But if you're a small or medium sized company with 25,000+ transactions per month, you need to do some major surgery to your business model to stay at less than 1% chargebacks at all costs, and probably less than 0.75% so you have a little buffer in case your customers get a little trigger happy on the chargebacks in a given month. That basically takes subscriptions of any kind off the table, let alone "free trial" with autoship.

Which brings me back to my original point: a "free trial" with sneaky, fine- print autoship is actually INCREDIBLY difficult to pull off in this day and age. I am utterly baffled as to how JustFab, let alone Proactiv, the worst offender of them all, can pull this scheme off without getting MATCH listed. It especially makes no sense how JustFab has gotten away with this because it sounds like they have been sued left and right by private parties and the government for years. I can only postulate that they bring in such incredible amounts of revenue that Visa/MC and their payment processors simply turn a blind eye to it.

<comment><USER3> The way that these business's get past those regulations is pretty easy actually. They have multiple (and when I say multiple, i mean hundreds if not thousands) of payment 'accounts' (I think they are called pids) so if one of them gets killed it does not effect the entire business.

The other sneaky thing I heard some were starting to do was to determine if a card is a credit or debit card- You cant chargeback on a debit card so they treat those users worse.

The one thing I dont understand is the making it difficult for people to cancel via phone. Chargebacks cost money, so almost all of these guys give 100% refunds to anyone who calls. Not doing that seems stupid.

Its similar to back in the ringtone days how the providers would have hundreds of short codes, so that when some of them blew up, it wouldnt effect the entirety of the business.

<comment><USER4> Do you have any sources for: 'You cant chargeback on a debit card'?

<comment><USER3> Cant is the wrong word, my fault. 'much, much more difficult' would be appropriate.

<comment><USER2> That's not actually correct. The process of charging back on a debit card is very similar to charging back on a credit card.

</comment></comment></comment></comment></comment><comment><USER5> The last part of this complaint is really scary:

"I signed up to get these shoes and didn't realize that they charge if you don't 'skip the month'. The first time I called and they refunded my money and said emails are sent monthly to remind customers to skip the month. Well the emails came for a few months and then they stopped so of course I forgot and was charged. I tried getting a refund and they said no so I had to use the credit. I tried cancelling the membership and my call never went through and when I started an online chat and told the associate the reason for my chatting with her was to cancel she disconnected us so I couldnt. After that my bank froze my card for some fradulent activity and issued me a new card with a new number and everything and so I thought the nightmare with this company was over. Well they charged me again and I called asking how they got my card number and they said they have a contract with a third party member that is able to get the details of my new card and that I agreed to allow that to happen when I signed up. Needless to say I figured out how to bypass the long phone prompts and was able to finally stop my membership with this company. They are ridiculous and should be out of business with the way they run things. "

<comment><USER6> Had a similar thing happen with one of my cards that got stolen. My bank canceled the card and sent me a new one. While no more fraudulent charges went through after that, I was puzzled when my automatic charges continued without failure. My bank told me that since the account was not closed and reopened, they just sent me a new card with a new number on the same account, thus only updating the same account. When this happens some processors receive your new card details and automatically update their records. I know Stripe does, although I don't know if they do it for both the number and expiration date, or just the expiration date. Either way, it is scary flaw in the banking system. ([https://stripe.com/blog/smarter-saved- cards](https://stripe.com/blog/smarter-saved-cards))

<comment><USER7> It's definitely feature, not flaw; think of all the lost revenue from merchants/acquirers/issuers/associations/etc when a card needs to be legitimately replaced (e.g. updating your Netflix subscription is the last thing on your mind if you lost your wallet). Full disclosure: currently working on a product that does this very thing.

<comment><USER8> I can agree with your reasoning, and I see the value for all parties involved for a relationship to not be disrupted.

Personal story time:

Where I live, the local toll authority has a very bad reputation for their tactics of enforcement (surprise). Well, following the TJMaxx hack, my financial provider saw I shopped there during the window, cancelled the card and got me a new one. Very cool. I updated as many of my accounts as I could remember. Forgot the toll authority, whoops.

They send me a bill in the mail somehow turning 35 unpaid tolls into a fee of $700+ dollars. I wrote them explaning that in good faith I had it on auto pay, and I would be happy to pay the tolls, 1 late fee, and 1 processing charge. A total of ~$70.

They waited until the absolute last day to respond (according to postmark), which meant by the time I got their letter telling me "NO!" they had already sent my information to collections. Eventually a collection letter showed up. I responded in writing noting that the debt was not valid as written ($700+) and if they got the number right, I would pay it...never heard from them again, and it never showed up on my credit report.

Anyway, the feature you describe is good for businesses, but when some businesses act shitty like that toll authority, the feature benefits the consumer in a clear way.

<comment><USER9> Are you by chance a Texas resident? The Texas Tollway system is a mess, and they recently drew the ire of the government for it.

</comment></comment></comment></comment></comment><comment><USER10> In case anyone else was confused, JustFab is not in fact the same company as Fab (despite their similar names, founders named "Goldenberg" and "Goldberg" respectively, and unsound business models).

Fab: [https://en.wikipedia.org/wiki/Fab_(website)](https://en.wikipedia.org/wiki/Fab_\(website\))

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

<comment><USER11> Crazy. Was thinking the same.. "Fab is back alive now as JustFab?"

<comment><USER12> I thought they were the same company - Justfab & Fab.

</comment></comment></comment><comment><USER13> Businesses like this depend largely upon forgetful users and credit card rebills to be viable. Successful user acquisition comes down to how small/hard to read/hard to find that rebill disclosure can be made without getting sued by the FTC. Smartest thing these guys ever did was recruiting Kate Hudson to be a celebrity spokesperson for the Fabletics brand, which threw a lot of regulators off and bought them some initial air cover. But at the end of the day it's the same business and they will eventually be held accountable to reasonable standards.

<comment><USER14> Indeed. Another example:

[https://www.ftc.gov/news-events/press- releases/2014/11/ftc-i...](https://www.ftc.gov/news-events/press- releases/2014/11/ftc-illinois-ohio-stop-scheme-offered-free-credit-scores- then)

The FTC fines seem to be quite affordable to these players, who may just see them as a minor cost of doing business. Sensa for example had sales of $300m, fines of $26m. The example above has annual sales of around $250m. The profit margins on the sales numbers for these kinds of products are very high too.

</comment></comment><comment><USER15> _Sensa, oddly, is still hailed as a Goldenberg and Ressler success story on JustFab investor Matrix Capital's website_

In case you're wondering, I'll save you a trip to Archive.org; here's what Matrix Partner's website said before they memory-holed SENSA:

 _The pair became fast friends, and when Intermix was acquired by News Corporation in 2005, Don and Adam were quick to start their own company. In 2006, they created an e-commerce brand incubator platform called Intelligent Beauty. The company became the home to SENSA, a weight-loss system based on groundbreaking research from Dr. Alan Hirsch, and DermStore, a service created by a board certified dermatologist who wanted to provide accurate skin care information and qualified skin care products online._

</comment><comment><USER16> Here's a previous discussion about JustFab from a couple years ago when they accepted their series c funding. [https://news.ycombinator.com/item?id=6455391](https://news.ycombinator.com/item?id=6455391)

An investor even chimes in to defend the company.

Similar topics discussed in there as are in this one. This ride doesn't end.

<comment><USER17> Direct link to the subthread where the investor jumps in:

[https://news.ycombinator.com/item?id=6455575](https://news.ycombinator.com/item?id=6455575)

<comment><USER18> Amazing. He doesn't event really defend it - he flat out admits this is what they do. The only contention he has is that it should be obvious that it is the case that they'll charge you if you aren't careful to unsubscribe between certain days of the month.

</comment></comment></comment><comment><USER19> Is this the same company who about a year ago was copping a lot of flack because one of the founders was jetting back and forth between US and Europe first class every week to make sure he got / kept his United Global Services membership while they were laying off staff?

<comment><USER19> It's not - replying to myself. That was Bradford Shellhammer of Fab.com before it imploded.

</comment></comment><comment><USER20> Fraud plain and simple. The executives should be in jail. Fucking weasels. They simply pay the government off to keep defrauding people. The VCs are happy to take their cut and enable them as well.

</comment><comment><USER21> > [JustFab] was valued at $1 billion by investors, making it a "unicorn," > Silicon Valley's most coveted achievement.

Rookie mistake. The most coveted achievement is to _exit_ for over a billion dollars.

</comment><comment><USER22> Did these VC firms not do their due diligence on Goldenberg and Ressler or did they just not care? I find it hard to believe that they secured $300MM in funding with nobody noticing this.

<comment><USER23> I do due diligence on VC/PE projects for a living. Either their diligence partner is really poor or they simply ignored their advice. Despite having $300MM on the line, you'd be surprised how often either situation happens.

</comment></comment><comment><USER24> The writing seems sloppy. For example, calling TCV a "small shop" is flat out wrong. Not only is it not small, by some measures, it is the biggest!! Having raised over $10b including an 8th fund at $2.2b! And Matrix is no slouch either having raised $2.4b including a $1b fund and seed investing in AAPL.

</comment><comment><USER25> This media angency began as an "internet popularity contest in 2006". It rose to prominence by blog spamming and riding the coattails of the popular meme "clickbaiting". It gained notoriety for the amount fo javascript used to serve advertisiments, poor articles, limited content and tracking and selling user data. At one time it was the biggest clickbait and blogspam mill on the entire internet.

It has earned another distinction, as a unicorn. Having a value of north of $850 million, valued in an investment by silicon darling Andreesen Horowitz. Andreesen Horowitz partner Chris Dixon went on to proclaim that the company was a great investment and would be a legitimate media entity.

Buzzfeed, have you forgotten you are Buzzfeed. You can't write a quote like this, and be taken seriously:

In practice, that meant a factory of winking pop-ups, banner ads, advertorials, and landing pages everywhere from Yahoo Mail to AOL and MSN, displaying pictures of old women transforming into young ones and scales tipping to lighter numbers. The rapid A/B testing and modification of these ads has always been Goldenberg's strength

The irony is glaring and the funniest part is they don't realize it.

</comment><comment><USER24> BTW, did any of the Pando accusations against Beachmint pan out?

</comment><comment><USER26> To play devils advocate here, doesn't the individual always have a responsibility to read the fine print rather than blindly plugging their credit card details into an offer for cheap shoes?

<comment><USER27> You could, but it'd take an entire month out of your year [1]

[1][https://www.techdirt.com/articles/20120420/10560418585/to- re...](https://www.techdirt.com/articles/20120420/10560418585/to-read-all- privacy-policies-you-encounter-youd-need-to-take-month-off-work-each- year.shtml)

<comment><USER28> Obviously it'd be subjective, but important terms could be disclosed with the same prominence as features are marketed.</comment></comment></comment>


The ExoMars Spacecraft Approaches the Red Planet - <AUTHOR> http://www.nytimes.com/interactive/2016/10/16/science/space/mars-exomars-spacecraft-arrives.html?rref=collection%2Fsectioncollection%2Fscience&action=click&contentCollection=science&region=rank&module=package&version=highlights&contentPlacement=1&pgtype=sectionfront <comment><USER2> > The lander will attempt to touch down on Meridiani Planum, near the site > where NASA's Opportunity rover landed in 2004. It will study the local > environment for several days before running out of battery power.

How sad.

<comment><USER3> Well, the Europeans refuse to consider using RTGs (scary radiation!), which pretty much cripples any attempts to make a non-trivial rover.

<comment><USER4> From what I've read, that's not true - esa doesn't have a suitable supply of plutonium 238, and is developing equipment using an alternative radioactive source (americium).

[https://www.quora.com/How-does-ESA-plan-to-power-its- future-...](https://www.quora.com/How-does-ESA-plan-to-power-its-future-space- missions-if-they-dont-want-to-use-RTGs)

[http://www.space.com/692-esa-chief-europe-space-nuclear- powe...](http://www.space.com/692-esa-chief-europe-space-nuclear-power- options.html)

<comment><USER5> As far as I know even the US only has a very limited supply.

<comment><USER6> True, and production has been restarted. [1]

[1] [http://www.space.com/32890-nuclear-fuel-spacecraft- productio...](http://www.space.com/32890-nuclear-fuel-spacecraft-production- plutonium-238.html)

</comment></comment></comment></comment></comment><comment><USER7> There's an especially interesting picture in the article:

[https://static01.nyt.com/newsgraphics/2016/10/16/exomars- lan...](https://static01.nyt.com/newsgraphics/2016/10/16/exomars- landing/5b10909857e42b1a309ae39f2ddc8c3f989676d8/PIA08813-victoria.jpg)

Obviously anything about Mars is interesting, but this picture has a peculiar property. Look at the picture and imagine that the light is coming from the upper right -- when you do that, the crater becomes a dome. If instead you imagine that the light is coming from the lower left, it becomes a crater again.

I've seen this in other ambiguous terrain photographs, but this picture easily supports the ambiguity.

<comment> stable-point I can't get it to look like a crater, no matter where I pretend the light's coming from. It's always a dome for me.

<comment><USER8> Try flipping the image. Or turning off the light: if you have actual light coming from above you can't imagine it is coming from below.

</comment></comment></comment><comment><USER9> there is brittle base underneath the lander, when it drops that base breaks into pieces to absorb the shock, interesting.

</comment><comment><USER10> [http://www.esa.int/Our_Activities/Space_Science/ExoMars/Live...](http://www.esa.int/Our_Activities/Space_Science/ExoMars/Live_updates_ExoMars_arrival_and_landing)

[http://esamultimedia.esa.int/multimedia/publications/BR-327/](http://esamultimedia.esa.int/multimedia/publications/BR-327/)

</comment><comment><USER11> Am I missing something here? My calculator has solar panels! Why doesn't this thing have them too?

<comment><USER9> solar panels in mars did not turn out to be very efficient. After couple of days, all those panels get covered with dust, and you need a wiper to clean that up, which will again drain a lots of battery power.

<comment><USER12> False. Most probes on Mars are powered by solar. E.g. Opportunity is still going strong ([https://en.wikipedia.org/wiki/Opportunity_(rover)](https://en.wikipedia.org/wiki/Opportunity_\(rover\))). Other upcoming landers are also solar powered.

Mission design dictates whether solar power is enough to satisfy your requirements. For Curiosity, they wanted to go faster and longer with more power than solar would have given them considering the size of the rover (i.e. not much space to put solar panels on, which yields in lower power available).

</comment></comment></comment><comment><USER13> Why is the Trace Gas Orbiter black?

<comment><USER12> Probably thermal design contraints. A lot of black means high thermal radiation (both incoming and outgoing). The orbiter is intended to fly through the atmosphere, so to venture a guess, they want to radiate heat away quickly.</comment></comment>


Why is this C++ code faster than my hand-written assembly (2016) - <AUTHOR> https://stackoverflow.com/questions/40354978/why-is-this-c-code-faster-than-my-hand-written-assembly-for-testing-the-collat <comment><USER2> A couple of weeks ago I'd never heard of Peter Cordes. Now the linked article is the third time I've seen his work. He's doing a fine job of fixing Stackoverflow's low-level optimization knowledge. Not so long ago all I seemed to find there was people saying something like, "well, you shouldn't optimize that anyway", or, "modern computers are very complex, don't even try to understand what's happening".

<comment> mark-r If I ever see Knuth's quote "premature optimization is the root of all evil" in response to a question again, I think I'll puke. Not only is it hard for outsiders to know what's premature and what isn't, but sometimes it's nice to make a habit of doing things the faster way when you have two choices that are otherwise indistinguishable. For example I try to use ++x instead of x++, even though 99% of the time it makes no difference.

<comment><USER3> In my opinion, _any_ optimization done before taking the naive approach is usually premature optimization.

That might sound a little extreme, but in the past 5 years I've run into exactly 1 problem that was solved by busting out the profiler and optimizing. In that same time, I can't count on all my digits the number of features that didn't ship, estimates that were overshot, deadlines that were slipped, etc etc. I've even been part of a team that ran out of runway while popping open jsPerf to choose between !! and Boolean(). Our app was fast as hell -- too bad no one will ever get to use it.

If you're expending cycles choosing between ++x and x++ and you're not ahead of schedule, please stop.

<comment> mark-r That was my point, I'm _not_ expending cycles choosing between ++x and x++. I've just chosen a different default than most of the code I've seen, and you still need to realize when the default doesn't do what you want - but that's usually obvious.

Sorry to hear about your unsuccessful projects, that's a bummer. I hope that premature optimization wasn't a major part of the blame for any of them.

<comment><USER4> It's so irritating that golang has x++ but not ++x. I never remember until shit isn't compiling. Grr!

</comment></comment></comment></comment></comment><comment><USER5> TL; DR: > _If you think a 64-bit DIV instruction is a good way to divide by two, then no wonder the compiler 's asm output beat your hand-written code._

Once (maybe 25 years ago?) I came across a book on assembly language programming for the Macintosh.

The authors wrote a circle-filling graphic routine which internally calculated the integer square root in assembly language, drawing the circle using the y = sqrt(r * r - x * x) formula!

What is more, the accompanying description of the function in book featured sentences that were _boasting_ about how it draws a big circle in a small amount of time (like a "only" quarter of a second or some eternity of that order) because of the blazing speed of assembly language!

How could the authors not have used, say, MacPaint, and not be aware that circles and ellipses can be drawn instantaneously on the same hardware: fast enough for drag-and-drop interactive resizing?

<comment><USER6> Bresenham's line algorithms and the adaptation of the general principle to circles and arcs are absolute gems. I've used those over and over in the first two decades of my career and I never ceased to be impressed with the elegance and speed.

Surprising that people writing a book 25 years ago would not have been aware of this work.

[https://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm](https://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm)

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

<comment> mark-r Yes, it's absolutely brilliant. The line drawing algorithm is also applicable to other problems, whenever you need to interpolate between two integer values.

<comment><USER5> Bresenham is applicable to other conic sections and functions.

I proved this back as an undergrad: i used Bresenham to plot the y = K/x hyperbolic curve.

I had this idea that since 1/x can be interpolated with Bresenham without doing division, somehow that could be applicable to the perspective transformation when walking over texture maps in 3D rendering.

<comment><USER6> Hehe. That's so cool, this is something I did without knowing any of the formal math behind it when writing a small 3D game engine (after seeing Doom). It seemed to be the shortest path to a solution and it worked very well.

Then, after getting it to work I replaced the interpolator with a bunch of assembly starting from the intermediary representation the compiler output.

I unfortunately didn't date that source file but I do remember I was living in Amstelveen when I wrote it so this was about 23 years ago, summer of '94.

We made the textures with one of the first affordable and commercially available digital cameras:

[http://www.digicamhistory.com/1991.html](http://www.digicamhistory.com/1991.html)

</comment></comment></comment></comment></comment><comment><USER7> tl;dr -- the asm author used DIV to divide by a constant 2

More fundamentally: it's theoretically possible to at least match compiled code performance with assembly, because you could just write the code the compiler generates.

BUT, it requires a LOT of experience.

Modern compilers "know" a lot of optimizations (e.g. integer mult by fixed constant --> shifts, adds, and subtracts). Avoiding pipeline stalls requires a lot of tedious register bookkeeping, and modern processors have very complicated execution models.

It's almost always better to start with a compiler-generated critical section and see if there are possible hand optimizations.

<comment><USER8> In University computer architecture courses, we were challenged to write a quicksort routine in assembly. We were also asked to compare the assembly that we authored with assembly that was compiled from C++ (after we authored our own solutions, of course).

It was an amazing crash-course on just how good compilers have become at optimizing. Not a single student could hand craft assembly that was faster than the compiler output. The teacher of the course was able to generate assembly that was slightly faster, and he stated that in order to do so, he had to greatly exploit his in-depth knowledge of the processor's pipeline system. That was roughly year 2000, and I'm sure compilers have only become better at their job since then.

All in all, excellent learning experience. I've since encountered several instances where developers assert superior assembly skills, and by default I'm silently skeptical of their claims.

<comment><USER9> Gathering and exploiting in-depth knowledge of a CPU's internals has become more difficult over time, too, I think.

At least for x86/amd64 - with out-of-order-exection, branch prediction and whatnot one not only has to know the architecture, but one has to know the specific implementation the code will run on. And knowledge on the deep internals of CPUs made by Intel or AMD (or Via? are they still around?) is not easy to come by.

</comment></comment></comment><comment><USER10> >> Have you examined the assembly code that GCC generates for your C++ program?

A very polite way of saying, "why are you even using assembly, when you don't understand assembly?"

<comment><USER11> And why wouldn't they be polite?

The OP clearly does understand assembly enough to start doing project Euler type problems, which is a good way to learn basic programming in any language. They get a solution in assembler which is more than many people here would be able to do I suspect.

And they're looking to expand their knowledge by asking on stack-overflow about something they don't understand.

So why do you think they should they be met with rudeness and hostility?

<comment><USER12> Because apparently it's a rite of passage / hazing ritual to go on IRC / stackoverflow and be flamed for asking simple questions. It's been that way since the dawn of time.

<comment><USER13> The ritual isn't really complete until someone has complained about the people complaining about people asking simple questions and someone else has posted the ESR document about how to ask smart questions, a document so astonishingly, vastly patronising that it probably ought to be compulsory reading for every developer starting out, with the addendum, "If you've made it all the way through this soul-crushing drivel, congratulations! It can't get worse than this!"

</comment></comment></comment></comment><comment><USER14> The question was more interesting than the answer.

tl;dr version--the author's hand-written assembly was poor.

I guess the more interesting takeaway is "Just because it's assembly doesn't mean it's _good_ assembly."

<comment><USER15> That takeaway is more or less uniformly true, though. It also often comes up as saying that $LANGUAGE is slower than C or C++. Your algorithms aren't naturally faster just because you're writing in C++. You don't magically stop allocating and double-buffering all over the place just because you're writing C++. In fact, coming in from the likes of Java you're liable to underestimate just how much (relatively expensive) copying is going on if you're careless.

What C and C++ give you (and Assembly gives you even more of) is control. If you can, and know how to, capitalise on that control, you _will_ get more performance. But those requirements are non-trivial.

</comment></comment><comment><USER16> For fun I ported the C++ to Python and Cython without any kind of mathematical or programmatic optimizations. C++ was 0.5 seconds, then Python was 5.0 seconds. Cython, which was the same exact code as Python except sprinkled with "cdef long" to declare C types, was just 0.7 seconds.

</comment><comment><USER17> General comment and not aimed at this specific instance:

Just because you are writing in assembler, does not mean it is going to run faster than the same code in a compiled language. There has been decades of research and who knows how many man-years of effort that has gone into producing efficient compiled code from C, C++, Fortran etc.

Your assembly skills have to be of quite a decent order to beat a modern compiler.

BTW: The answer to the question on Stack Overflow by Peter Cordes is a must- read. Brilliant.

<comment><USER18> > Your assembly skills have to be of quite a decent order to beat a modern > compiler.

Start with compiler output, add intrinsics where you can see help is needed, benchmark, repeat.

Pathologically-slow ASM is pretty rare from modern compilers in my experience.

<comment><USER19> > Pathologically-slow ASM is pretty rare from modern compilers

Here are some I've found:

[https://stackoverflow.com/questions/45496987/gcc- optimizes-f...](https://stackoverflow.com/questions/45496987/gcc-optimizes- fixed-range-based-for-loop-as-if-it-had-longer-variable-length) (horrific codegen for known-size C++11 loops in member functions, all GCC versions prior to 8 which is not yet released)

[https://stackoverflow.com/questions/43651923/gcc-fails-to- op...](https://stackoverflow.com/questions/43651923/gcc-fails-to-optimize- aligned-stdarray-like-c-array) (SIMD opportunity squandered when C++11 features are used)

[https://stackoverflow.com/questions/42263537/gcc- sometimes-d...](https://stackoverflow.com/questions/42263537/gcc-sometimes- doesnt-inline-stdarrayoperator) (failure to inline trivial operators)

[https://stackoverflow.com/questions/26052640/why-does-gcc- im...](https://stackoverflow.com/questions/26052640/why-does-gcc-implement- isnan-more-efficiently-for-c-cmath-than-c-math-h) (C isnan() not efficient, for many years)

</comment></comment></comment><comment><USER20> The people who write "article answers" like this on SO are the real MVP's of the web.

</comment><comment><USER21> Apologies if this is somewhat off-topic for the thread, but I suspect this will be a fun puzzle for fans of low-level optimization. The theme is "optimized fizzbuzz".

The classic fizzbuzz will use %3 and %5 operations to test divisibility. As we know from the same source as OP, these are horrifically slow. In addition, the usual approach to fizzbuzz has an annoying duplication, either of the strings or of the predicates.

So, the challenge is, write an optimized fizzbuzz with the following properties: the state for the divisibility testing is a function with a period of 15, which can be calculated in 2 C operations. There are 3 tests for printing, each of the form 'if (...) printf("...");' where each if test is one C operation.

Good luck and have fun!

<comment><USER22> Good nerdsnipe.

I decided to reject your conditions and replace them with my own, for no apparent reason. Mine has some of the redundancy you wish to eliminate, but the loop body is completely branchless, aside from the call to printf, of course, which we're apparently ignoring.

        #include <stdio.h>

        #define NUM "\x06" "%zu\n\0"
        #define FIZZ "\x07" "Fizz\n\0"
        #define BUZZ "\x07" "Buzz\n\0"

        const char *x =
            NUM
            NUM
            FIZZ
            NUM
            BUZZ
            FIZZ
            NUM
            NUM
            FIZZ
            BUZZ
            NUM
            FIZZ
            NUM
            NUM
            "\xa6" "FizzBuzz\n";

        void fizzbuzz(size_t upTo) {
            for(size_t i = 1; i <= upTo; i++) {
                printf(x + 1, i);
                x += *x;
            }
        }

        int main(int argc, char **argv) {
            fizzbuzz(100);
        }

<comment><USER21> Good candidate for most evil use of the assumption that char is signed. Incidentally, that's not going to be true on arm[0].

[0]: [http://blog.cdleary.com/2012/11/arm-chars-are-unsigned-by- de...](http://blog.cdleary.com/2012/11/arm-chars-are-unsigned-by-default/)

<comment><USER22> Haha, whoops! At least it's easy to fix.

</comment></comment></comment></comment><comment><USER23> I know is it is not the point of the question, but that problem would benefit greatly from memoization. Calculate it recursively and memoize the result of every step. With all the neat trickery that they are doing with assembly they could easily go sub 10ms.

I whipped together a short poc in chezscheme, and it clocks in at about 50ms on my 4 yo laptop.

<comment><USER24> When everything is in cache and you're calculating sequentially, definitely, but equally why not just precompute the whole range and do a binary search? Once you're looking for better algorithms the whole problem just falls away!

That said, I do think it's neat that the fastest brute-force variant is a rough factor-2 from your naïve memoized version. It might even win if it was fighting a hyperthread for cache space! Just shows how much throughput modern CPUs have... if only they were used this well all the time ;).

<comment><USER25> > but equally why not just precompute the whole range and do a binary search?

what do you mean?

<comment><USER24> The code finds the longest Collatz sequence below N, where N is a 32-bit integer. There are only ~1k longest sequences possible, so just list them all. Given N, search for the largest N below that and return its corresponding iteration count.

</comment></comment></comment></comment><comment><USER26> tldr: compiler replaces /2 with a shift.

<comment><USER27> Which makes it sound like the author shouldn't have been trying to hand assemble for speed. Or maybe treat it as a learning exercise.

<comment><USER28>
      Or maybe treat it as a learning exercise.

Is there any other reason to complete a Project Euler question?

</comment></comment></comment><comment><USER29> > If you think a 64-bit DIV instruction is a good way to divide by two, then > no wonder the compiler's asm output beat your hand-written code...

Compilers employ multitudes of optimizations that will go overlooked in hand- written ASM unless you, as the author, are very knowledgeable. End of story.

</comment><comment><USER30> When I started programming on a Apple II+ assembly was important. Today there are likely only a few people in the world who truly understand what any particular CPU family is actually doing sufficiently to beat the compiler in some cases, and they probably are the ones writing the optimizer. But 6502 was fun to code for and the tricks were mighty clever but you could understand them.

<comment><USER2> > Today there are likely only a few people in the world who truly understand > what any particular CPU family is actually doing sufficiently to beat the > compiler

I'm not sure that's true. There are hundreds of compilers in the world, being maintained by thousands of developers. Then there are all the JITs. And the people who make the standard library implementations. And performance critical stuff in game engines, OS kernels, hardware drivers, high-frequency trading. Then there's the embedded space. And then there's Fabrice Bellard.

My previous employer, Cambridge Silicon Radio (one of hundreds of similar companies nobody's heard of) had dozens of people on the staff that worked on this kind of thing. I have friends at ARM, Broadcom, Samsung and Raspberry Pi that mess around with processor designs for a living. This is just my little experience of the industry. There are armies of these people.

</comment></comment><comment><USER31> Not too surprising answer: "your assembly sucks"

</comment><comment><USER32> Because the complier has optimized it better than you.

</comment><comment><USER33> > but I don't see many ways to optimize my assembly solution further

I can't do it therefore it must be impossible!

</comment><comment><USER34> This was a borderline help vampire question, but it ended up working out well, probably for nerd-sniping reasons.</comment>


What would happen if Twitter were to shut down over night? - m-localhost Is that possible? What effect would that have on public opinion? Is Twitter/social media the Bayer, Degussa, IG Farben of our time (See also facebook in Myanmar)? <comment><AUTHOR> the world would instantly become a better place, it isn't half as important as it likes to think it is

</comment><comment><USER2> 1\. Loads of people and companies would set up Twitter clones/successors to try and cash in. Some of these would be federated/open source, some wouldn't, but either way, it's likely one or more would take off thanks to the Twitter refugees.

2\. Existing Twitter alternatives would see a huge boost in popularity. Mastodon would get thousands of new signups in a matter of minutes/hours, and niche alternatives like Minds and Gab would probably see a fair bit of growth as well.

3\. The media would panic as they realise the 'easy source of news' they've been relying on is gone and they don't know which replacement will take off yet.

4\. Some 'lucky' alternative would end up attracting Donald Trump, and the popularity (from both fans and critics) would likely send the servers into meltdown. Given his political views, I can see Gab being the winner there.

5\. The job market would see an increase in software engineers, designers, dev ops guys, etc if Twitter's workforce were also laid off/the company didn't exist anymore. It wouldn't be too noticeable (those fields are already super packed with candidates as is), but you'd see a small jump in numbers none the less.

6\. Many, many news sites, blogs, wikis and forums would break horribly, since they used tweets as sources in articles and posts. Think the recent Photobucket catastrophe was bad? Well, the number of Twitter embeds likely dwarfs that by a thousandfold.

I think that sums it up.

<comment> m-localhost Very good points. I haven't thought about the broken website problem due to embeds.

</comment></comment><comment><USER3> There would be replacements but they wouldn't have staying power. Twitter works because there's only one. Powerful people in the world can use it to monitor popular opinion on any topic. So its main role today in the lives of young people is political in nature. It allows them to come together and deliver a message to the establishment in a way that no other institution in society does. Think about the difference between Occupy Wall Street and #MeToo. People complain a lot about Twitter witch hunts, but that just shows you that Twitter movements actually get results. I can't think of a single goal from the Occupy movements that was met. The thing is that Twitter does not encourage dialogue or cooperation across subcultures of people. So likely, if Twitter were gone, each community would come up with its own replacement, and the powers that be would have no use for those.

</comment><comment><USER4> I won't be able to invoke human intervention from otherwise ignorant service providers.

Twitter is my fastline to customer support.

<comment><USER5> I hate this about companies that use social support. Because its still in its infancy a lot of companies have marketing teams on their social media, someone complains to marketing - they skip the queue and call the desk line of one of the customer support managers.

</comment></comment><comment><USER6> Lots of annoying articles would be written about it, its stock price would tank and we'd forget about it in about 3 months.

</comment><comment><USER7> Some opportunist guy whould create a clone very fast, demand creates supply.

<comment><USER8> Mastodon would skyrocket, although it wouldn't take on everybody. Facebook would probably profit too.

</comment></comment><comment><USER9> All the political parties in India would lack an avenue to vent against each other and also lose a wonderful avenue for mass-propaganda.</comment>


Show HN: Receive Alerts when your Server's software has Security Vulnerabilities - <AUTHOR> https://beta.secureit.io/tryit <comment><USER2> My company uses [http://appcanary.com](http://appcanary.com) and recently GitHub has introduced a similar feature [https://github.com/blog/2470-introducing-security-alerts- on-...](https://github.com/blog/2470-introducing-security-alerts-on-github)

<comment><AUTHOR> I searched and I did not know about them. Thanks for letting me know. These are actually the first paying service I have seen on this (at least the server side, I had seen it for webapps).

I'll probably start out with Java/Scala on the webapp side and on the server side I'm thinking of an easy to use support for Kubernetes and Rancher OS. If that's more around your ally subscribe there on the website or here.

I'm curious on what is your company, regardless, any pain points that you might have noticed while using AppCanary, or suggestions on SecureIT?

<comment><USER2> Usually they would like to install a daemon which checks local packages and all Gemfiles for example. The problem would be in ensuring that the daemon does not misbehave. A solution which gets integrated into a CI/CD pipeline would not have this problem but it would not be able to provide assurance on the integrity of the base system, only the artefact (deliverable).

<comment><AUTHOR> CI/CD or even the CVS repository (Git e.g.) - as a hook or with full access is on the lines I'm thinking about. Thanks & Cheers!

</comment></comment></comment></comment><comment><USER3> This is actually an idea I had started working on, but specifically for PCI requirement 6.2 in conjunction with some kind of automated threat analysis.

If I can list every software used in the card processing environment and get automated alerts fired straight into my ticketing system to create an event, this would be good.

<comment><AUTHOR> Hmm, interesting. Automated threat analysis, how exactly would that work? Like the configuration OVALs? If I'm not mistaken Red Hat has quite the support via OVALs to some of the PCI requirements.

Regarding the card processing environment, what does that usually consist of? Linux servers?

You can reply to info@ SecureIT or here. I'm interested in knowing more.

Cheers

</comment></comment><comment><USER4> It might be useful, but I am finding it pretty hard to understand what it is from the landing page. I would suggest putting the message there clearer.

<comment><AUTHOR> yup, yes, definitely going to. Even the secureit.io is not very clear on it. If you have any more insights let me know. Cheers

</comment></comment><comment><USER5> It would be nice if the home page had some kind of an example page or report. I don't want to sign up for something if I don't know how it works first.

<comment><AUTHOR> Hi!

You don't need to sign up to use the app. The 'try it' mode allows you to generate and see the reports without signing up. To setup the alert though, you will need to input an email. But you're right, it should show the process upfront. That explanation is on the works and will be on the next version of the frontpage and/or the TryIt part.

Meanwhile you can set a phony email _although you won 't get the email with the alert of course_ to see how the process works. But I would love to know what you thought of it through the chat or here.

The link to the try it mode is: [https://beta.secureit.io/tryit](https://beta.secureit.io/tryit) (or click above)

Cheers

</comment></comment><comment><AUTHOR> This is till a WIP, but still pretty useful, all comments are welcome</comment>


Show HN: I wrote a Bash library - <AUTHOR> Shelon: https://github.com/housni/sheldon<p>It's not a framework, it's a library. It attempts to mimic function names in Python. Most functions work in Bash 4.3+ but there are those that work on older versions. The 'help' target in Makefile is on crack! Check the issues in that repo for upcoming features. Useful for DevOps Engineers or anyone who has to write Bash scripts. <comment><USER2> Clickable link: [https://github.com/housni/sheldon](https://github.com/housni/sheldon)</comment>


To SQL (relational) or not to SQL (NoSQL) that is the question - <AUTHOR> http://chuckjohnson.wordpress.com/2012/03/19/to-sql-relational-or-not-to-sql-nosql-that-is-the-question/

<comment><USER2> I thought it was generally accepted that NOSQL actually meant "not only SQL" as in use the tool that is best for the task and not the whole problem.

<comment><AUTHOR> Well some people objected to the initial way NOSQL was described/marketed and others decided to ease the objections.

At the end of the day, I think it's far more important that people understand what problems NOSQL was built and is designed to solve and use it accordingly.

I plan to bookmark that URL for future reference, though I already have a pretty good idea where to use which.</comment></comment>


Does Apple's iPhone OS 'Game Center' Threaten Nintendo? - <AUTHOR> http://www.pcworld.com/article/193831/does_apples_iphone_os_game_center_threaten_nintendo.html/

<comment><USER2> Until an iPhone can provide the tactile satisfaction of pressing buttons or the current generation of gamers prefers a touch interface, IMO, no. Pardon the pun, but iPhone vs. Nintendo gaming is like comparing Apples to Oranges.

<comment><USER3> Touch-screens can be a serious threat, even without directly replacing all things a traditional handheld is good at. It just needs to reduce the argument for a dedicated gaming device, by providing enough games that the DS' audience enjoys.

Touch Screens are no good for a MegaMan. But games on the order of Cooking Mama, Nintendogs, Brain Age, Pokemon, Final Fantasy, Harvest Moon, etc -- these make up a huge slice of the DS' most-popular titles. And they don't need buttons.

<comment><USER4> I think that as long as Mario and Zelda will require buttons, Nintendo will be safe.

<comment><USER3> Safe, certainly. But potentially finding themselves moving significantly less product to significantly fewer users.

Consider the home console situation: The PS2 had its run of the console business. But the PS3 is struggling to expand out of the core gamer niche. Sony's 'safe' in that the MGS, God of War and Final Fantasy fans aren't going anywhere. But the more-numerous, more-casual gamers, even the gamers who had PS2s and bought God of War, bought Wiis instead.

And the Wii does enough games well enough that it's harder to convince them to buy the PS3 and God of War 3, even though they know they'll never get a game quite like GoW3 on their Wii.

</comment></comment></comment></comment><comment><USER5> Gaming on the iPhone is nothing like gaming on the DS. The DS provides multiple interfaces (touch input via stylus, tactile game pad) for gaming. The DS is far cheaper. The battery lasts longer on the DS. The DS has better, fuller games, which won't tire you out after 20 minutes of playing.

iPhone is better for super casual gaming. 20 minutes while commuting. Sitting on the couch during a commercial.

Both have their merits, but the iPhone doesn't necessarily threaten Nintendo

</comment><comment><USER6> No, but it sucks to be OpenFeint at this moment, or so I imagine...

</comment><comment><USER7> If the iPhone was going to threaten Nintendo, it would have done it already. Game Center-like backends are hardly uncommon on it. OpenFeint has been around for a long time, and it's pretty prevalent.</comment>


HANA C++ Development Environment and Processes - def- https://hookrace.net/blog/hana-cpp-development/# <comment><AUTHOR> Interesting. Are you hiring remotely as well?

<comment> def- Haven't seen it for HANA developers, but you can filter for "Virtual" location: [https://jobs.sap.com/search/?q=%22software+development%22&lo...](https://jobs.sap.com/search/?q=%22software+development%22&locationsearch=virtual)</comment></comment>


Inside Medium's Meltdown - <AUTHOR> http://www.businessinsider.com/inside-the-meltdown-of-evan-williams-startup-medium-2017-2 <comment><USER2> > In his post announcing the layoffs, Williams said the business model Medium > had been pursuing, advertisement-driven media, was to blame for > "misinformation," and that Medium would no longer sell ads or help the > publishers it hosted on its site with ad revenue, and therefore it no longer > needed the people it had hired to work in those areas.

> "The state of tech blogs is atrocious. It's utter crap," he told Bloomberg's > Brad Stone in 2013. "They create a culture that is superficial and > fetishizing and rewarding the wrong things and reinforcing values that are > self-destructive and unsustainable." And he said he was "pessimistic about > the state of media, and that's why I want to work on this problem."

The irony.

</comment><comment> rm_-rf_slash I was recently talking with my girlfriend about print media, and she brought up a point I have been unable to shake from my head: because we get all of our information digitally, we don't value it as much as a physical medium that we pay for. Instead, there is just so much free information at the click of a button (and even paywall stuff can be bypassed if you put in the extra 5 seconds), that consuming information comes to feel like a chore.

It reminds me of the famous scene in Mark Twain's "Tom Sawyer", when Tom convinces a group of kids to paint the very fence he was contracted to paint. Instead of offering money for their services, he pitched the activity as a fun privilege to enjoy.

There's a lot of good stuff on Medium. There's also a lot of crap. And there is no way to seamlessly progress from article to article without encountering any crap at all.

Are the comments going to be informative, or an argumentative flame war? Roll the dice and see how much time of your life was well-spent or wasted.

I got the daily newsletter from Medium for years. Read it fairly often. Then I just got sick of it and unsubscribed. With the exception of links from HN, I haven't gone back since.

<comment><USER3> > because we get all of our information digitally, we don't value it as much > as a physical medium that we pay for.

This is not a new phenomenon. "today's news is tomorrow's fish and chip paper" is a lyric from 1981, and it's much older a sentiment than that.

</comment></comment><comment><USER4> I've never found Medium to be a compelling idea, even less so since Williams said:

> The idea won't be to start a website. That will be dead. The individual > website won't matter. The Internet is not going to be about billions of > people going to millions of websites. It will be about getting it from > centralized websites.

The course was easy to predict. Publishers move the platform. The platform discovers its interests (i.e. it's investor's interests) don't really align with those of the publishers. The publishers are left in the lurch.

Here's what I don't get: there's absolutely no need to centralise. Hosting a website isn't especially complex. If you control your own site, you control your own destiny. Medium is a pretty CMS, but that's not enough of an incentive to give up control over your publishing platform.

I feel the same about Google AMP: it't not hard to do what AMP does. A lightweight site and decent CDN will get you 90% of the way there. So what's the upside?

<comment><USER5> Exposure, favorable rankings, and content grouping.

There is also something I find nice about the uniformity and minimalism of Medium. It's not that other sites have regained geocities level of divergence, but it's easy to just focus on the content with Medium.</comment></comment>


IE6 users are kind of stupid - <AUTHOR> http://www.pcworld.com/article/236944/internet_explorer_users_are_kinda_stupid_study_suggests.html

<comment><USER2> Other reports of this story:

<http://news.ycombinator.com/item?id=2818847> <\- This has all the comments

<http://news.ycombinator.com/item?id=2822935>

<http://news.ycombinator.com/item?id=2822162>

<http://news.ycombinator.com/item?id=2823776>

<http://news.ycombinator.com/item?id=2823808>

<http://news.ycombinator.com/item?id=2823949></comment>


Old Versions of Android Apps - <AUTHOR> http://www.oldversion.com/android/ <comment><USER2> I really wish there were something like this for iOS. Facebook in particular seems obsessed with bloating their app by trying to become everything from Craigslist to SnapChat.

</comment><comment><USER3> I used to be super irritated with updates for both OSes and apps. I can't tell you how long I force closed my last Android device's updater to prevent getting Android 5.x. Mostly after learning more about security vulnerabilities, I learned this really wasn't a reasonable or viable position to take.

Use the latest version. If you don't like it, switch to something else. Being attached to a specific version of a specific app is likely to doom you to constant frustration, because tech is always changing, compatibility always breaks, and new security vulnerabilities are always found. If you keep your data in standard file formats or protocols which are open, switching clients/apps is relatively painless. Detaching from nonstandard Gmail features opened up the entire width of IMAP clients to me, for instance.

In the above-mentionned case, that's why I just stopped using Android. After a while, it just isn't worth fighting upstream.</comment>


Ask HN: Are there programs whose halting status is undecidable? - <AUTHOR>

Can you write a program for a Turing machine for which no human will ever know whether it will halt or not? A few rules/assumptions:
- I'm not talking about a program too long to read, because that's boring, but something whose halting status is essentially unknowable. After all what if humans solve aging, solve solar catastrophe, etc.?
- I assume Turing machines have no random number generator, so you can't write a program like "if rand() > 0.5 then halt else spin."
- I'm asking about programs that are not just undecided but undecidable. For instance you could write a computer that halts iff it finds a positive even integer that is not a sum of two primes (cf. Goldbach's conjecture), and no one knows yet whether that program will halt. But who's to say someone won't figure it out in a hundred years? Can you write a program whose halting status is demonstrably undecidable? <comment><USER2> I assume you're asking because the "non-constructive" proof of the halting problem's undecidability is unsatisfying and you want a concrete example.

Another way to approach the problem is to talk about the reals and the naturals: the cardinality of the reals is greater than the cardinality of the naturals. Turing machines are encoded in binary, hence the set of Turing machines is no larger than the set of natural numbers. Hence there are some reals that cannot be computed by a Turing machine.

This suggests an obvious example: write a program to compute the square root of a number with infinite precision. Then let it run. For any input, can you tell me whether it's stuck trying to compute an irrational number, or just taking a long time to compute a very large rational number?

<comment><AUTHOR> Actually I'm asking because I'm curious whether the mind has the same limitations as a Turing machine.

I really like the simplicity of your example, but it seems like it only works if you can't see the source code. If you see the source code---which is what you'd allow to any Turing machine---why couldn't you figure this out very easily?

<comment><USER2> No, it doesn't matter how you implement square root. If you were able to tell me whether any execution of the program halts, then you would be able to tell me, for any `n`, whether or not `n` is irrational (since irrational results are exactly the results that it won't halt on).

But this isn't possible: it's an open problem whether or not `pi + e` [is irrational]([http://math.stackexchange.com/questions/28243/is-there-a- pro...](http://math.stackexchange.com/questions/28243/is-there-a-proof-that- pi-times-e-is-irrational)). So if you could always tell me when the square root program halted, you'd be able to tell me whether or not it halted for `(pi + e)^2`.

But if you were able to tell me that, you would have solved an open problem in number theory along the way -- you'd have solved a whole class of open problems about whether or not certain expressions are rational. I can't prove to you that no solution of this kind exists, but, intuitively, do you see how big the implications would be if you could solve the halting problem for your square root machine?

<comment><AUTHOR> Ah, thanks for clarifying! I think I overlooked the "square root" part of your original response. You're right, seeing the source code is no help at all! And it's difficult to say that a human could always say if sqrt(x) is rational, for all x. Still, this seems a bit like the Goldbach conjecture example: we don't have a math proof for this now, but some day we might. I wonder if there is any program that is provably undecidable---like the way Godel's theorem proves that some statements are undecidable from their axioms.

</comment></comment></comment></comment><comment><USER3> A program that tries to find a solution to the Goldbach conjecture will eventually halt. Either it finds a solution or the numbers themselves become so large that they overflow the computers working memory. The halting problem I think is only interesting for Idealized Turing Machines. For real computers, the Second law of thermodynamics should be enough to prove that any program will halt sooner or later.

<comment><AUTHOR> For real computers, yes, but we're talking about Turing machines. :-) By your logic there is no halting problem at all because every machine will eventually halt. A Turing machine has infinite tape and infinite time.

</comment></comment><comment><USER4> Yes, the halting problem in general is undecidable.

</comment><comment><USER5> char input = Console.ReadKey();

if (input == 'y') { Console.WriteLine("Yes"); } else { Console.WriteLine("!Yes"); }

// Might never finish - what if the user never inputs a char?</comment>


Show HN: Ledgersight, a General Ledger API - <AUTHOR> http://ledgersight.com/ <comment><AUTHOR> Creator here. As a developer, I worked on ledgers of many types at different companies. I never understood why were people splitting financial systems, from accounting systems, from billing systems, and so on. Why can't they all be the same? Is not all of them just storing transactions?

I heard many times that maintaining an updated balance is the single biggest issue with these systems, so most people design them use relational databases to make sure "anything touching money is ACID".

SAP built Hana due to scalability issues on their general ledger, main problem being keeping the balance while transacting. I spoke with a lot of friends in the industry having trouble with relational databases going down by queries during the billing process.

I thought a lot about the issue and decided to build a system breaking all of these misconceptions (in my opinion). It uses DynamoDB (NoSQL), it uses the double-entry accounting system (the best way to make sure money is not lost), and it scales to >100K transactions per second (it actually can go further, that's only the free tier of loader.io).

Here are the docs: [http://ledgersight.docs.stoplight.io](http://ledgersight.docs.stoplight.io)

I took a lot of inspiration from the Ledger CLI, I believe companies will benefit a lot from getting access the simplicity and powerfulness of the Ledger CLI on an API.

Hit me up if you want an API Key to play around. Any feedback will be much appreciated.</comment>