The Hidden Cost of C++ - <AUTHOR> http://www.rachelslabnotes.com/2009/10/the-hidden-cost-of-c/

<comment><USER3> The argument boils down to the fact that C++ can express more in a single line of code than C can.

 _a = func(b,c);_

....

 _Is it a function call, a member function call, or is it an anonymous constructor? Are b and c implicitly invoking copy constructors for other classes as part of type coercion? Is that a normal assignment, or an assignment operator? Is there a cast operator involved?_

If it's such a complicated expression, then the equivalent C code would be correspondingly large and hard to understand, and it would be just as complicated to figure out its cost. The not-so-hidden cost of C is that even simple things end up being many, many lines of code. C++ was invented because certain kinds of C programs -- programs that were _already being written in C_ \-- were painfully verbose to express and complicated to change.

If writing your code in C would be simple and clear, then you would have to be stupid to write it as complex, obscure C++. When your C++ code gets complex and you start banging your head against a wall, imagine re-expressing it in C. If the result would be an improvement, then you screwed up. If you blame C++ for screwing up, then you're a language feature junkie. Admit it and check yourself into rehab.

 _That is the hidden cost. The mental model for a simple function call became incredibly large and complex, and every function call is potentially as complex. Which makes reasoning about performance a rather hard thing to do.... All that translates ultimately into either worse performance or longer development time. Neither one is something you like to hear about._

I don't know how it is a "hidden cost," because it's quite well understood that any reasonably expressive language can say more in a single line of code than C. Anyway, the size of the mental model of your _program_ is what you should be worried about. C++ doesn't give you worse performance or longer development time. It gives you more choices for how you express your program. It means more _different_ problems, because you can write C-style code and have C-style problems, or you can use the possibilities C++ offers and have different problems. If you already know that the choices forced on you by C are usually the right ones for your domain, then by all means apply that knowledge to how you write C++. For instance:

 _Worse, it makes profiling harder than necessary. All the type coercions that happen at the API level will show up as separate functions, not attributed to the callee, but the caller._

If you want them attributed to the callee, it's pretty simple. Do the coercions in the callee, just like you would have in C.

<comment><AUTHOR> Your counterargument boils down to "use C instead". That is exactly what I am currently advocating.

I don't blame C++ for screwing up - I blame it for being an ill-designed language that makes it _easy_ to screw up.

Any of the high-level features of C++ are well-implemented in any number of decent languages that don't obfuscate your code and incur horrible link times. And my argument (for game development) is that C++ is indeed the wrong language for the domain. In fact, I'd argue it's wrong for most, if not all domains. And I'm not exactly alone - I can't recall any prominent figure that actually thinks C++ is a decent language, except Bjarne Stroustrup. (Correct me if I'm wrong - I'd love to hear about it!)

<blockquote> If you want them attributed to the callee, it's pretty simple. Do the coercions in the callee, just like you would have in C. </blockquote>

The issue is that in many instances, I own the caller, but not the callee. And the person owning the callee can _unintentionally_ make my code perform worse by simply changing the API. Or adding a destructor.

<comment><USER3> No, my counterargument is to use the features of C++ when they help and not when they hurt. I claim that C++ doesn't hurt C programmers. It just brings out their deficiencies in different ways. For instance, embracing features you don't understand and then complaining about the consequences is stupid, and stupid people don't write good code in any language. You understand C++ well enough to know the pros and cons (or at least the cons) of various C++ language features, but you complain that your fellow programmers might not:

 _The issue is that in many instances, I own the caller, but not the callee. And the person owning the callee can unintentionally make my code perform worse by simply changing the API. Or adding a destructor._

This is just bad programming practice on their part. The performance cost of a destructor shouldn't be a surprise to the person who writes it. If someone is messing with the performance of types you use or removing functions(+) you call without consulting you and without themselves taking responsibility for calls to that functionality, then obscure features of C++ is just one of the many ways they're going to screw you on a regular basis. How would those programmers screw you in C? I don't know, but I know they would.

Nobody who knows C++ well enough to use it effectively would call it a "decent" language in the sense of "not obscene," but it is definitely "decent" in the sense of "adequate." It's easiest to define C++'s deficiencies with respect to other languages (for instance, memory management in C++ is much more intrusive in source code than in Java) but comparing it to C is way too simple. After all, the primary problem with C++ is that it doesn't remove any of C's dangers; it just gives you better ways of abstracting them away in some cases. The second problem with C++ is that it's extremely complicated and takes a long time to learn. And that's it. Every other supposed misfeature of C++ (relative to C) seems to stem from people hitting the second problem without realizing it. In your case, your coworkers should be more conservative about messing with things (such as defining expensive automatic type conversion functions) when they don't understand the consequences (such as those type conversions actually being invoked.)

(+) This is the most plausible explanation for different type conversions suddenly being invoked. It could also happen by adding a function that invokes a more expensive type conversion to a type that is more closely related to the type declared by the caller, thus making the new function a better match than the old one, but it's unlikely that a conversion between two types that are more closely related would actually be more expensive.

<comment><AUTHOR> _No, my counterargument is to use the features of C++ when they help and not when they hurt._

That was Stroustrups reasoning: "Only pay the cost when you use it". In retrospect, believe that that's a bad choice for language design, because there's a good chance somebody will use a feature without fully understanding the ramifications it has over the entire code base.

C opts for the opposite and uses annotation to treat certain code segments as "special" and make them faster - "inline", and (in the distant past) "register" come to mind.

 _(or at least the cons)_

I believe I do get the pros as well, at least to some extent. I've been using it since CFront came out ;) And I'd still advocate it for use in a small team (<5 people?) of experienced programmers - you _can_ make it sing.

But gamedev engineering teams are at least 15+ people, with the occasionally less-experienced ones thrown into the mix. C++ is, in a sense, like a professional power tool. It sure can get stuff done, but the wrong person uses it and its a blood bath, and it's not appropriate for single small home repairs. (Gah. Bad analogy, but I can't come up with a better one right now)

 _This is just bad programming practice on their part. The performance cost of a destructor shouldn't be a surprise to the person who writes it_

Possibly. I'd argue that it's hard to always keep all performance ramifications in mind. But let's for a moment say it's indeed simply bad programming practice - the issue that makes this a problem is that _my_ code pays the cost, not the offending code. Which is a rather indirect.

C++ changes often have tendrils all through the system. It is easy to make inadvertent mistakes.

* but it is definitely "decent" in the sense of "adequate.*

It clearly gets the job done, yes. We are shipping games occasionally, after all. I'm looking for better ways to ship games, and I think that abandoning C++ might bring gains.

 _The second problem with C++ is that it's extremely complicated and takes a long time to learn._

That's what my hidden cost is referring to - C++'s complexity makes it hard to understand. You certainly _can_ write code that performs well in C++, but it is arguably harder to get it right than C.

I like to think there's a better solution than either one hiding somewhere, but I haven't found it yet.

</comment></comment></comment></comment><comment><USER4> I fixed a single line of code that drove our embedded processor to 50% cpu - it called 5 ctor/dtors. Changing it to a ref arg with a ref return, and dropped to under 10%. And yes, class defs had to be redeclared, the line of code was unchanged. Very indirect, utterly beyond the original authors comprehension.

<comment><USER5> Do you know how to fix almost every one of these cases for good? Just don't allow implicit copying of your classes. Problem solved. If someone tries to write that horrible code, they can't.

This is more a question of knowing what you are doing and less of C++ sucking. C doesn't solve this - you still have to know what you are doing there or you end up shooting yourself in the foot. I much prefer having an interface with virtual methods to a struct with function pointers.

<comment><USER4> Of course! However the original author of the offending code didn't know to define private X(X&), so had the problem. C++ is a power saw; you can cut off your hand.

</comment></comment></comment><comment><USER6> And the hidden cost of using Java is that there is a JVM! These are only hidden to developers who don't really know C++. If you have virtual functions everywhere and have api that encourages copy or anonymous constructors you get what you asked for. And any profiler worth its salt should be able to show you what is really happening so you can quickly fix it.

For a game shop who is worried about performance there are many little things you can have your developers do to prevent the compiler from doing many of these things and you should have it be part of your normal API reviews to make sure that developers follow them. A simple example

class Box { public: Box(int x); };

class Foo { public: Foo(Box a) };

... Foo(1); ...

Pop Quiz: How would you change Foo (or the whole api) to cause Foo(1) to cause an error?

<comment><USER7> Pop Quiz: Why should I clutter my brain with these little guessing games about what the compiler is doing? And why should these pop quizzes slow down my group's code reviews? There are, after all, languages out there that do not force this insanity on us.

The alternative for performance-critical applications is not Java, but C. C remains surprisingly tough competition after all these years for those rare pieces of software where programmer time is cheap compared to hardware resources. Having had non-trivial experience of both languages, _reasoning_ about the performance of a C program is much, much easier than reasoning about non-trivial C++ programs' performance. Guesses based on local code inspection have an order of magnitude less uncertainty attached to them, which is basically what Rachel is saying here.

<comment><USER8> I am surprised to see that so many programmers still like to reason and guess what the performance of their program is instead of profiling it...

And hearing C proposed as an alternative to C++ is mind boggling. I don't want to match malloc/free calls, strcat strings together or realloc pointers. I don't want to declare a bunch o function pointers in a struct and call it OOP. I don't want to use macros because C99 has poor adoption rate and C89 doesn't have inline. I don't want to watch the compiler blissfully convert unrelated types to one another just because it can. I don't want to pass types around as void* and lose any useful type information I might have had. I don't want to fumble with return codes.

And in C++ I don't have to. I can use Qt, the STL and Boost and be very productive. Telling me to program in C is not even funny.

<comment><AUTHOR> I propose a _lower_ level than C++ for the kernel, and a _higher_ level for the rest.

C++ is simply at the wrong abstraction level.

Oh, and I don't _want_ to manually track resources myself, either. But guess what, somebody has to do. And on a game console, that's you. There's not much of an OS to speak of.

You did notice I was talking about game development, right? ;)

<comment><USER8> My reply was not targeted at you and I don't do game programming.

Anyway:

* smart pointers don't need an OS.

* for me, C++ is at the exactly right abstraction level to allow me to use only C++ instead of "C++ + other language" or "other language and C for speed". Most C + HLL proponents underestimate the logistics overhead of using multiple programming languages.

<comment><AUTHOR> _Most C + HLL proponents underestimate the logistics overhead of using multiple programming languages._

I'll concede that as a valid concern, especially for smaller projects where everybody touches many areas of the code. As projects grow, a separation becomes easier.

Add to that the fact that most games need scripting support anyways, and you'll see that the logistics overhead is at least not much different.

</comment></comment></comment></comment></comment></comment><comment><USER9> Wow it is C++ bashing season again it seems.

Yes you have to know what you are doing in C++. But this is not different in other languages. Understanding and optimizing code is a touch discipline. No matter what language.

There is also another side to this story. C++ can absolutely generate highly efficient code. Code that performs much better than C equivalents.

For example, I've looked a lot at generated (iPhone/ARM) code for cases where (function) templates are used and C++ wins most of the time. Doing compile- time configuration of code is usually much more efficient than having runtime- configured code. By using templates and inline functions the compiler can do some seriously cool performance tricks.

Sire, there may be more code (bigger text segment) but that is a small sacrifice for what you gain in speed. Specially these days where a 8MB fart app is easily downloaded over a 3G connection without hesitation.

<comment><AUTHOR> Yes, you _can_ use C++ to do amazing things. In large-scale projects, that usually backfires, though, unless you contain the "magic", because _interactions_ in C++ are harder to predict.

The problem with C++ is not that you have to know what you are doing - <USER2> also have to know what everybody else is doing.

And the "small sacrifice" of a bigger text segment is a big one in this particular domain. We only have 512M available, and a tremendous chunk of that is eaten up by graphics. An executable seriously exceeding ~20MB would spell trouble.

And I'd argue that AAA games are slightly more complex than a fart app ;)

<comment><USER10> When I code in a team, we don't just write one big mass of C++ and _hope_ that all the interactions work out okay!

Instead, we follow modular programming practices. If some interactions are too slow, we know who didn't optimize his section and we kick the problem back to him.

<comment><AUTHOR> That would be nice. Except that - again, for performance reasons - we often have to break the boundaries between modules. Most game engines are a tangled web, since many parts are talking to many other parts. (I think there are ways around that, and there will certainly be a post on it. But that's the way things work right now)

So it's not always that easy to just find a guilty party and blame them.

</comment></comment></comment></comment><comment><USER10> The author is worried about _optimizing_. He should know that in high- performance applications, you should just write the code _then_ profile it. We all know that C++ is fast; the real question the author should be asking is whether C or C++ can more quickly express ideas/is more maintainable/etc.

This post about not knowing how a function is called is really splitting hairs, bordering on irrelevant imo -- sure, it can affect the time taken _to call a function_ by ten times, but this is not a large performance hit at all for 95% of your code, and even less since most high performance items are on the GPU. If it ends up that it does affect performance in a critical area (found via profiling), the author even suggested how it can easily be fixed.

I don't see what the big deal is. If you're a game programmer, change your coding conventions so that you don't get into problems like this.

<comment><AUTHOR> She does know that you need to profile, TYVM. But ideally, you pay at least cursory attention to performance even when you write the code. Writing code with complete disregard to performance, saying "oh, the profiler will find it" is not an acceptable choice.

You don't write sloppy code and argue that you can find bugs in the debugger, either, do you?

And no, most high-performance items are not on the GPU. Most games are already GPU-bound, so you want to take load off of it. (Also, with the arrival or LRB et al., the GPU/CPU distinction becomes moot)

If those issues were irrelevant, I wouldn't care about them. There's one thing I _do_ care about: Shipping high quality games, developed as fast as possible. C++ hurts that goal.

And no, the 95%/5% rule does not hold true in game development. But don't trust me - read, for example, Tim Sweeny, the guy behind the Unreal engine. According to him, there are not hotspots. Another Unreal programmer: <http://lambda-the-ultimate.org/node/1277#comment-14238>

"Dan Vogel, was fond of pointing out that UE2 had a basically flat profile"

 _That_ is the big deal. In a flat profile, things like calling overhead matter everywhere.

<comment><USER10> Worrying about not knowing how functions are called on your first iteration is such a moot point. Simple programming conventions (e.g. no multiple inheritance) can eliminate this problem. Even if each function call does take 10x longer, I would argue that in 99% of the cases you wouldn't even notice the difference, practically speaking.

 _Shipping high quality games, developed as fast as possible._

If this is what you care about, then you should care about optimizing AFTER you write the initial version and identify hot spots.

 _You don't write sloppy code and argue that you can find bugs in the debugger, either, do you?_

Sloppy code vs. "slow" code are vastly different. I would much much rather have slow code, since 99% of the time it isn't even noticed by the user. Hence, it was worth not thinking about how to improve it.

 _most high-performance items are not on the GPU._

I agree that you want to take load off the GPU. However, CPU speed has not been the limiting factor in games for a LONG time. In fact, in conferences such as the GDC it is rarely discussed any longer, only in the context of using more CPU if available for non-engine tasks such as AI.

 _And no, the 95%/5% rule does not hold true in game development._

There is a big difference between what is essentially a graphics engine (you reference the Unreal engine) and a video game. If you look at modern games, do you think it is a waste that they are based on interpreted scripting languages? They can do this because as I said above, CPU isn't as limiting a factor as before.

<comment><AUTHOR> _Sloppy code vs. "slow" code are vastly different._

Not really. Some amount of up-front investment can avoid a lot of pain at the end. Do I obsess about every single call? No, of course not - but I try to avoid obvious performance issues.

While you _can_ optimize them after the fact, it's more time you're spending.

_CPU speed has not been the limiting factor in games for a LONG time_

Yes, actually, it is. It might not be _raw_ speed - we're talking cache misses instead - but you still have to be careful with your resource usage.

_There is a big difference between what is essentially a graphics engine (you reference the Unreal engine) and a video game_

Yes, and no. Unreal is more than a "graphics" engine - it's an entire game engine. (There's way more than graphics there.) And CPU performance still is discussed at GDC. See here, for example: [http://www.scribd.com/doc/15118967/Hitting-60Hz-in-Unreal- En...](http://www.scribd.com/doc/15118967/Hitting-60Hz-in-Unreal-Engine)

And the games built on top of it use some scripting. And often dive into C++ and even the engine itself to make the game actually perform well.

But that's exactly the model I'm advocating. Write the kernel in a low-level language (preferrably not C++, for many reasons, some of them mentioned in my post), and do the game logic in a scripting layer on top.

The faster you can get the kernel, the more resources you can devote to a language that makes life much easier for the rest of the world.

So yes, I wasn't exact. When saying "game development", I was referring to "engine development". The point still stands - I think C++ is inappropriate for low-level tasks (too much "magic") as well as high-level tasks. (Incredibly convoluted language. No, I'm not saying Stroustrup is a bad designer. I'm saying the constraints he imposed on himself forced C++ to head that direction. And design by committee helped.)

 _If you look at modern games,_

I do. Every day. Intimately. I work on them. That's why this topic matters to me. It'd be kind of stupid to complain about C++ usage in game development without knowing about it ;)

</comment></comment></comment></comment><comment><USER11> It always surprises me that some will seek to defend C++ when even its author seems to admit that it is flawed. Many famous programmers have pointed to the language's limitations. People use it because of pragmatism: it has what they need for the APIs they want to use.

 _If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one?_ Tom Cargill

</comment><comment><USER12> There are constructors in C++. The water is wet, how sneaky of it.

You either know the code you are working with or you don't. C++ or not.

<comment><USER13> What he is pointing out is that C++ makes it harder to 'know the code you are working with'.

<comment><USER12> I understand the point, and I am saying it is a trivial one.

Calling func(x) in C may as well be causing x to be cloned or have some other nasty side effects that are not immediately obvious from looking at the code. Similarly how one should always keep in mind the existence of macros when reading C code, one should also keep in mind the existence of constructors and casting operators with C++. That's hardly the hidden cost.

It is easier to write messy or obscure code in C++, especially for a novice programmer. But this has less to do with the language per se and more with established coding practices within specific team. If there _is_ a hidden cost to C++, it is the fact that it requires higher level of competence. Not that it has constructors.

<comment><AUTHOR> The point is that, with a rational team, I can tell (roughly) what a function is doing, based on the name. It's not going to be called 'dot_product' and clone data passed in ;)

What I can't tell is how much extra code the compiler will generate at this point, and that is the problem.

> If there is a hidden cost to C++, it is the fact that it requires higher > level of competence. Not that it has constructors.

I didn't say the cost is in the constructors. They're a _symptom_ of the cost. The cost is creating the mental model of your app.

Sure, if the entire team consisted of C++ superstars, we _might_ be able to get away with this. Given the team size on current games, (and the fact that superstars are rare) that's unlikely to be the case.

<comment><USER14> If there's no enough "superstars", then perhaps your coding guidelines should accommodate that so that the "mental model" of the app would be more managaeble for the code monkeys.

<comment><AUTHOR> This is not a question of "code monkeys". It's simply a question of having some programmers that are less experienced than others. And that's kind of unavoidable if you ever want to hire new people...</comment></comment></comment></comment></comment></comment>


Academic Research Is in Danger of Becoming a Joke - <AUTHOR> http://www.intellectualtakeout.org/blog/academic-research-danger-becoming-joke <comment><USER2> I swear, it's like people pass around the same handful of examples when they want to complain about irrelevant academic research.

What they never do is justify the "becoming" part. For over a century, people have complained about university research as 'useless ivory tower activities' (quoting [https://books.google.com/books?id=p6T3eo5ltFAC&pg=RA15-PA53&...](https://books.google.com/books?id=p6T3eo5ltFAC&pg=RA15-PA53&dq=ivory+tower+useless&hl=en&sa=X&redir_esc=y#v=onepage&q=ivory%20tower%20useless&f=false) as a 1983 reference I picked arbitrarily from a Google Books search).

Go back to the 1950s and I'm sure you'll see similar complaints about the uselessness of academic humanities research.</comment>


Special Paint on the Hood of the World War II Jeep Could Detect Mustard Gas - <AUTHOR> https://jalopnik.com/how-special-paint-on-the-hood-of-the-world-war-ii-jeep-1826657149 <comment><USER2> > "after looking at blue British detector paint in the early 1940s"

It is odd that the article doesn't delve into that point more. In the early stages of the war, actually from mid-1938 onwards, British aircraft and vehicles had 'gas detector' panels which were squares paper soaked in the detection paint and taped-on. It was usually yellowish with one on the wing or the fuselage-spine of aircraft:

[https://ww2aircraft.net/forum/attachments/a380efa1d53530a5-j...](https://ww2aircraft.net/forum/attachments/a380efa1d53530a5-jpg.428273/)

Those fell out of use from late 1940 due to the low risk of gas attack and production ended in 1943. Just as the USA was starting production of its M5 paint!

</comment><comment><AUTHOR> The United States had mustard gas munitions in the European theater in case they needed to retaliate against a first use of chemical weapons by the Germans. In 1943 the Germans launched a successful air raid on the port of Bari, Italy [1]. One of the ships destroyed in this attack was a U.S. freighter carrying mustard gas munitions. Many allied servicemen and Italian civilians were exposed to mustard gas in this attack, and their treatment was impaired because the military command absolutely did not want to reveal the presence of chemical agents to the Germans in fear that the Germans might use that as a justification for using their own chemical weapons.

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

</comment><comment><USER3> Reading "The Hollow Years" about France in the 1930's.

As war seemed more and more likely from the mid-1930's onward, a lot was talked about the possible merger of chemical warfare and new airplane technology.

A particularly haunting line the author cites from a contemporary historian talked about how "a few dozen bombers can spread enough gas to push over all of Paris a tsunami of mustard gas 100 feet high and 50 miles wide".

Probably not true, but interesting how they merged threats old and new.

<comment><USER4> H G Wells wrote in 1933 that submarines armed with intercontinental ballistic missiles loaded with some kind of chemical weapons would be a dominant factor in shaping future conflicts.

He also predicted the international post service would take over the world and enforce universal basic English as the global standard language, so... some good ones, some bad.

Still, the sub warfare bit was very prescient.

<comment><USER5> About the international post service... isn't Amazon somehow going that way?

<comment> the-dude The internet.

</comment></comment></comment></comment><comment><USER6> The article make it sounds like the Germans were the ones known to use chemical weapons during the WW1. Both sides used it quite extensively, this wasn't just the German. [https://en.wikipedia.org/wiki/Chemical_weapons_in_World_War_...](https://en.wikipedia.org/wiki/Chemical_weapons_in_World_War_I)

<comment><USER7> I agree the article is misleadingly written, but presumably the Allies in WWII knew they had no plans to use mustard gas in the immediate future, whereas the enemy could not be relied upon to abstain.

</comment></comment><comment><USER8> Coming to Battlefield V one presumes.

</comment><comment><USER9> Doesn't human eyes and skin serve as a more immediate detector than a color changing star? Surely you would start feeling the effects of a liquid chemical weapon attack before your magic mustard star would have time to change color.

<comment><USER10> From the article:

> ...agents like mustard gas, which have a characteristic odor, tend to dull a > victim's sense of smell "after only a few breaths so that the smell can no > longer be distinguished." In addition, the implementing body of the Chemical > Weapons Convention states, respiratory damage can occur in the presence of > even tiny, unsmellable concentrations of the agent.</comment></comment>


W3C's Web App Source Code Protection Community Group - <AUTHOR> http://www.w3.org/community/webappscp/

<comment><USER2> This reads like a blithe, poorly-written high-school essay on the problem with "view source":

 _With the advent of HTML5, the web apps become popular, especially the mobile web apps. Web apps can be classified as either Hosted App or Packaged App. The source code of Packaged Apps (such as the apps in Firefox OS or Tizen OS) are installed and running locally. Users can easily view the source code. Similarly front end source code of Hosted App can also be easily seen by anyone. In this case, the publicity of source codes becomes a problem. Because web developers never hope their web apps are easily copied by others._

</comment><comment><USER3> Some journalist needs to drag Berners-Lee out of his hole to answer for the mess he's making.

<comment><USER4> Have at it: @timberners_lee

<comment><USER3> It looks like he hasn't responded to anyone else re: DRM, why would he talk to me? The point is he's only communicating about this through proxies and needs to explain himself.

</comment></comment></comment><comment><USER4> Wow, they're actually going through with it.</comment>


Skylon's SABRE Engine Passes a Big Test - <AUTHOR> https://www.universetoday.com/143810/skylons-sabre-engine-passes-a-big-test/ <comment><USER3> In case anyone was confused by the article's description, here's the Wikipedia:

"SABRE (Synergetic Air Breathing Rocket Engine) is a concept under development by Reaction Engines Limited for a hypersonic precooled hybrid air-breathing rocket engine. The engine is being designed to achieve single-stage-to-orbit capability, propelling the proposed Skylon spaceplane to low Earth orbit. SABRE is an evolution of Alan Bond's series of liquid air cycle engine (LACE) and LACE-like designs that started in the early/mid-1980s for the HOTOL project.

The design comprises a single combined cycle rocket engine with two modes of operation. The air-breathing mode combines a turbo-compressor with a lightweight air precooler positioned just behind the inlet cone. At high speeds this precooler cools the hot, ram-compressed air, which would otherwise reach a temperature that the engine could not withstand, leading to a very high pressure ratio within the engine. The compressed air is subsequently fed into the rocket combustion chamber where it is ignited along with stored liquid hydrogen. The high pressure ratio allows the engine to provide high thrust at very high speeds and altitudes. The low temperature of the air permits light alloy construction to be employed and allow a very lightweight engine—essential for reaching orbit. In addition, unlike the LACE concept, SABRE's precooler does not liquefy the air, letting it run more efficiently.

After shutting the inlet cone off at Mach 5.14, and at an altitude of 28.5 km, the system continues as a closed-cycle high-performance rocket engine burning liquid oxygen and liquid hydrogen from on-board fuel tanks, potentially allowing a hybrid spaceplane concept like Skylon to reach orbital velocity after leaving the atmosphere on a steep climb."

[https://en.wikipedia.org/wiki/SABRE_(rocket_engine)](https://en.wikipedia.org/wiki/SABRE_\(rocket_engine\))

<comment><USER4> >After shutting the inlet cone off at Mach 5.14, and at an altitude of 28.5 km, the system continues as a closed-cycle high-performance rocket engine burning liquid oxygen and liquid hydrogen from on-board fuel tanks

the benchmark of today - SpaceX - separates the first stage at Mach6-8 at 65-80km height. Thus, the SpaceX second stage has less delta-v to add and don't have to carry all that weight - the SABRE would naturally be bigger than the 2nd stage for the same payload. The economical space related case of HOTOL/SABRE single-stage-to-orbit pretty much disappeared for a foreseeable future when SpaceX started to recover the 1st stage. That not to say about suborbital flights SF-Shanghai though. Or even "just" hypersonic as SABRE tech seems to successfully deal with one of the major/key obstacles for it (and that is huge, i'm in no way trying to dismiss their work). And one can see how SABRE can be used in some cases as a convenient 1st stage, i.e. by being able to launch from any big airport instead of only specially designed spaceports (such a 1st stage would probably be better than that [https://en.wikipedia.org/wiki/Pegasus_(rocket)#Carrier_aircr...](https://en.wikipedia.org/wiki/Pegasus_\(rocket\)#Carrier_aircraft)).

<comment><USER5> Imagine putting SABRE on the first stage though - the engines would be heavier, but using air instead of carrying oxygen, for the full burn of the first stage. The payload mass fraction would be dramatically higher without carrying the oxidizer mass on board.

<comment><USER4> It is possible though cost&complexity seems high - we theoretically can even today bundle a bunch of SR-71 engines and probably stretch them beyond designed Mach 3.3 for the short time. Having low thrust-to-weight (SABRE promises up to 14, SR-71 had 6) we'd need either a lot of them for VTOL which leads to high cost, or we're limited by the size of maximum realistically possible hypersonic capable plane, plus the plane body being the additional weight. For example VTOL calculation - say engine weights 1 ton, we can lift off 13 ton of fuel and payload. It will use 40 ton of O2 from the air. For rocket engine - 1 ton engine can lift off 100+ ton, and if we just take the 13 ton fuel plus 40 ton O2 we'd have 45 ton budget for the rest (body plus payload). In reality you'd need higher fuel ratio, and this is why VTOL for atmospheric breathing engine pretty much isn't an option .

Going beyond pure rocket engine for the 1st stage i think air-augmented rocket ([http://astronautix.com/g/gnom.html](http://astronautix.com/g/gnom.html)) being simpler (thus cheaper) would be the next step that would get us closer (specific impulse wise) to what SABRE is targeting.

</comment></comment></comment></comment><comment><USER6> These guys don't disappear - they have been around forever with their Skylon plane.

Just a heads up, it's a long way from testing one component of an engine on the ground to getting a full engine demo going to then testing it in the air to then build the plane then integrating engine - then getting orbital trips working with reentry!

I am curious how much private capital they have been able to attract (outside of govt contract players). Obviously if this is really revolutionary then they will but this always felt like a long term / govt kinda of cool - tech forward but pork barrel project for the UK.

More of their background from a somewhat more balanced source - at least the headline put revolutionary in quotes.

[https://www.bbc.com/news/science- environment-36773074](https://www.bbc.com/news/science-environment-36773074)

They do claim to have the "best engineers" in the industry - so beating out big players like rolls royce, PW, CFM, spacex, blue origin, ariane aerospace - so that is a positive they have.

<comment><USER7> These things take time, but it's not the complete story, Virgin Galactic has been around since 2004, so the same year GMail launched, without producing a single passenger flight.

Blue Origin has been around for almost 20 years, and they have a few suborbital flights to their credit, and an engine that has yet to fly.

SpaceX, on the other hand, has been around since 2002 and achieved orbit in 2008, and have completed a lot of milestones since then.

I suspect the biggest difference between these companies is not talent or vision, but sens of urgency

<comment><USER8> Sense of urgency lets one leverage the best current technologies and take the best compromises within the time and monetary budget. But this is incremental innovation. It fails at tackling novel concepts where the paths forward are not so clear. You can't incrementally tunnel through a wall.

At one point maybe SABRE is ready and the next SpaceX comes along and will build a spaceship with it. The spoils of innovation seldom accrue with the inventors.

<comment><USER9> > The spoils of innovation seldom accrue with the inventors.

We are British, why change the habit of a lifetime ;)

That said, critical aspects of the design are protected and the private investors (big scary defense contractors etc) would no doubt sic the lawyers on anyone that attempted to rip it off.

</comment></comment></comment></comment><comment><USER10> Skyon's SABRE Engine _Component_ Passes a Big Test.

Still very cool progress and quite the test setup.

</comment><comment><USER11> How do you pronounce it? Sah-brey or say-ber?

<comment><USER12> Haha if this was office reference

<comment><USER11> It is.

</comment></comment></comment><comment><USER13> Everyone over here on HN seems to be quite negative about the SABRE engine. While there's very little evidence for this engine being useful for orbital applications, it is instead a very compelling idea for a Concorde and/or SR-71 replacement. Scramjet engines don't seem to be happening anytime soon (I just listened to a Queensland University researcher saying that their research may yield an actual engine in 4-5 decades). This idea of pre-cooling the incoming air seems closer to reality.

</comment><comment><USER14> Here's to a single stage to orbit craft a la Kerbal space program's RAPIER engine (although it's probably still not realistic to expect better than two stage due to the rocket equation)

<comment><USER15> Pretty sure KSP RAPIER is a fictional copy of the described SABRE engine.

<comment><USER16> The names seem to indicate that, both being similar kind of weapons.

<comment><USER14> Absolutely. [https://wiki.kerbalspaceprogram.com/wiki/CR-7_R.A.P.I.E.R._E...](https://wiki.kerbalspaceprogram.com/wiki/CR-7_R.A.P.I.E.R._Engine)

</comment></comment></comment></comment><comment><USER17> Looking forward to the integration test, if they get this to work it will be quite the engine.

</comment><comment><USER18> Isn't it inevitable the SpaceX will (and already does) dominate the entire space industry?

Won't it be cheaper to launch on starship than anythign else even for very small payloads? Yes, I know about RocketLab but I wonder if they will be able to survive once starship is up and running.

<comment><USER19> European governments will continue to back Ariane because strategically it makes sense. Russia will bankroll energyia likewise. Dominance is not static and private capital will not entirely replace state actions.

<comment><USER20> A nitpick, Energiya doesn't make rockets this days, rather Soyuzes, Progresses, satellites, upper stages (Block D)... Launchers are made mostly by Khrunichev (Proton) and Progress (Soyuz-2).

Russia tries to develop new rockets, but so far it's really slow and quite expensive. It's possible that when NASA will stop paying for Soyuz transport to ISS, it will become even slower. It's not a particularly good time in Russia for new rockets paid by the state.

<comment><USER19> All true, but do you seriously think Putin will renounce a domestic space industry? They might pick jv partnerships like ariane to stay afloat. Or sell engines or something but i dont see them giving up. To your side of this, the cash flow to a russian space sector will end when a man rated launcher from the U.S. starts making regular trips to the ISS, I guess.

<comment><USER20> > do you seriously think Putin will renounce a domestic space industry?

Probably not. It's possible to bring the space industry to the state of aviation industry, but 1) some resources are still available to maintain some level (as you mentioned) 2) to keep the same level, one needn't spend too much effort and 3) there are some interested parties in Russia which wouldn't want too deep degradation of space industry (e.g. periodically some hints to that come from Samara).

So a likely outcome could be maintenance of some expertise, at least for military purposes, and possibly attempts to cooperation with foreign partners - China, Europe etc. No total destruction; "just" \- potentially - <USER2> deep crisis.</comment></comment></comment></comment></comment>


HN first days - <AUTHOR> http://web.archive.org/web/20070226001637/http://news.ycombinator.com/

<comment><USER2> With only a few exceptions. It's the same site.

The one site that stood out the most is excite.com</comment>


Bugs Everywhere - <AUTHOR> http://bugseverywhere.org/ <comment><USER2> Nice to see this on the front page. I wrote a Masters thesis about distributed issue tracking using darcs' patch theory[0]. You can read it here[1].

Although the initial goal of the project was to build a working issue tracker that can integrate with darcsden[2], it later evolved mostly into a playground for playing with dependent types in Agda. So, sadly I don't have anything I can show HN yet. I do have a tiny little private prototype which I haven't gotten around to finishing yet because of other commitments. Maybe this is just the push I need to get it working.

[0] [http://hub.darcs.net/vikraman/thesis](http://hub.darcs.net/vikraman/thesis)

[1] [http://vikraman.org/thesis.pdf](http://vikraman.org/thesis.pdf)

[2] [http://hub.darcs.net/simon/darcsden](http://hub.darcs.net/simon/darcsden)

</comment><comment><USER3> I love the idea of BugsEverywhere but the project has languished since I started using it (August of 2013). I've got a faithful reproduction in Java (with the goal of creating an Eclipse plugin) but I've given up on BE ever really taking off.

In any case, I love the idea that I'm committing my issues changes with my code changes!

<comment><USER4> So how does it work? Does it put files in the repo? a parallel branch structure? something else?

<comment><USER5> There is a directory that gets stored in the repository which has all the bug information. There are also email and HTTP server integrations you can set up to have issues be automatically created in a central repository.

</comment></comment></comment><comment><USER6> I wrote a mini-survey of distributed bug tracking in 2008 here:

[http://evan-tech.livejournal.com/248736.html](http://evan- tech.livejournal.com/248736.html)

<comment><USER7> In 2013 I did something similar. Unfortunately the state of the art didn't seem to advance any between 2008 and 2013. Perhaps the third time distributed bug tracking flares up in the global discussion it'll stick around and make progress.

[http://travisbrown.ca/blog.html#TooMuchAboutDistributedBugTr...](http://travisbrown.ca/blog.html#TooMuchAboutDistributedBugTracking2013-04-20)

<comment><USER8> It's unpopular currently, mostly because most of the distributed bug trackers mentioned use vcs-based storage without a public-facing frontent. Even as a developer, it's nice to being able to see/report bugs without having to fiddle with VCS commands.

But don't dismiss them.

Fossil, which is not strictly a distributed tracker but rather an entire source-control system, is still maintained and very active. Several popular projects use it. And you do get distributed issue tracking for free.

BE is actually pretty mature. Development has stalled, but you have an email and web interface along with a pretty extensive bug manager which is certainly more advanced than Github issues. When configured with git, it's easy to chose where bug storage should be in-branch or use a dedicated branch.

Using the VCS itself to store data has its advantages. As the early proliferation of projects showed, implementing a distributed bug tracker on top of a distributed VCS is almost trivial. The truth is that if github added support to embed issues in BE format under a dedicated branch, BE would become massively popular.

Then you also have SimpleDefects (SD), which actually implements his own distributed database, web interface (which I'm using) and a bi-directional syncronization plugin system. Way harder to implement, and it's not surprising that SD is less mantained than BE, even though it would hold much more promise (a github issues sync plugin exists, but has bitrotted).

SD, in its current state, is also more featured than github issues.

Give these projects a spin. Contributing to BugsEverywhere in particular is _not_ hard.

<comment><USER7> The article I wrote was really just documenting all I had learned while researching distributed bug trackers and, when I didn't find any existing distributed bug trackers I liked, writing one myself[0]. I certainly don't dismiss distributed bug trackers and am quite happily using one on a regular basis.

My big question is why distributed bug trackers aren't more popular considering the popularity of distributed version control and the general weakness of the bug trackers on sites like github or bitbucket.

[0] [https://github.com/travisb-ca/nitpick](https://github.com/travisb- ca/nitpick)

</comment></comment></comment></comment><comment><USER9> I think bugs have to be on a central place. That's the only way you can track them reliably. What if someone record a bug, commit his/her own repo, but can't/don't push? Bugs might "lost" this way.

<comment><USER8> This is a non-issue. Issue tracking would work the same way git forks do: there's at any one time, always a "reference" repostory, implicit or explicit.

This same repository will also hold the reference state of bugs. It's really that simple.

The thing is, with a distributed bug tracker you can now also record local bugs which are pertitent with your fork only, while _also_ keeping track of the reference with minimal effort.

</comment></comment><comment><USER10> So how does a user submit a bug? Through a merge request or something? Maybe I'm just overlooking something, but I couldn't find this on the page.

<comment><USER3> Yes ... the BE system creates a .be folder in your Git (or other DVCS) project and you commit changes to your local copy to the server. Issues are text files and binary attachments, so merges behave the same way they would for your code.

</comment></comment><comment><USER11> What is the advantage over something like fossile[0] ?

[0] [https://www.fossil-scm.org/](https://www.fossil-scm.org/)

<comment><USER8> Fossil integrates all the aspect of source control into one: source versioning, issue tracking, wikis/documentation, and a self-contained web inferface which is actually pretty nice.

The timeline of fossil's web view has IMHO one of the best visualizations currently[1] when working with multiple branches. It's roughly what gitk/github network graph/git log --graph does, except it's _so much better_ and understandable I wished git developers would catch on.

[https://www.fossil- scm.org/index.html/timeline?r=trunk&nd&c=...](https://www.fossil- scm.org/index.html/timeline?r=trunk&nd&c=2015-05-30+21%3A51%3A19&n=200)

My current problem with fossil is that it's not so efficient when it comes with large repositories, and I actually like git's staging area. Otherwise, the entire scm is _solid_ , and the UI (web and cli) is definitely superior to git and mercurial.

BugsEverywhere, in constrast, just uses the current repository as a storage for bugs. You can use BugsEverywhere with git, mercurial, bzr, darcs... even with "cvs" if you wanted to.

</comment></comment><comment><USER12> I find it odd you have to mail bugs to the developers

<comment><USER3> "You may also send merge requests via the mailing list or using Gitorious."

Since issues are tracked in your local copy, adding an issue to the list and then sending a merge request will add your new bug to the list maintained on the server. If you check out the project, you'll find a .be folder next to the .git folder - this is where the magic happens.

</comment></comment><comment><USER13> it would be nice to see how the public facing frontend is organized. sadly it looks like [http://bugs.bugseverywhere.org/](http://bugs.bugseverywhere.org/) is down.

is there another place to check it out to get an installation with some actual data?</comment>


Facebook intimidates developer, bans him and his code for life - <AUTHOR> http://www.reddit.com/r/facebook/comments/o76m7/facebook_intimidates_developer_bans_him_and_his/ <comment><USER2> Facebook terms of usage <https://www.facebook.com/legal/terms>

Section 3.2:

"You will not collect users' content or information, or otherwise access Facebook, using automated means (such as harvesting bots, robots, spiders, or scrapers) without our permission."

Seems writing a bot that automatically takes actions on a user's behalf would clearly violate the Facebook terms.

Banning bots is perfectly reasonable behaviour for any site, a badly written bot, especially one that's distributed to large numbers of users could very easily cause a denial-of-service attack because of sloppy programming.

Facebook probably should have just dropped the developer a friendly email rather than a letter from their lawyers and banning the developer might be going over-far, but there's nothing wrong with them wanting to ban the plugin.

<comment><USER3> Have you ever read the Facebook TOS fully?

I challenge you to find a single game on the site that does not violate one of their extremely vaguely worded clauses.

This is basically just a "We can, for any reason, at any time, ban you. Suck it up."

That's why I've lost all interest in the Facebook platform.

Too much of this nonsense going on.

<comment><USER4> _> This is basically just a "We can, for any reason, at any time, ban you. Suck it up."_

It probably had to do with his plugin enabling users to play Facebook games without actually playing them. I'm sure game creators want a human looking at the ads in (and next to) their games, so it's no wonder he was banned.

</comment></comment></comment><comment><USER5> _> but it also seriously limits his chances of finding employment as a programmer._

That doesn't sound quite right. _TOO HOT FOR FACEBOOK!!!_ could look great on the right résumé.

The whole thing is just what we've come to expect from facebook by now tbh.

<comment><USER6> True, but it does suck to be banned from the ubiquitous platform in which you've spent time becoming highly specialized.

edit: Apparently he developed a _browser_ plugin that doesn't use Facebook's API, so it looks like this may actually be a decent endorsement.

<comment><USER7> Highly specialized in facebook API? If you are a half decent developer you can easily pick up any API in few days if not in few hours.

<comment><USER8> Not on facebook. It feels like IE6 in development. About one billion pittfalls and the documentation is not helpful most of the time.

</comment></comment></comment></comment><comment><USER9> Here is a snippet from Friendly Gaming Simplifier Message Board:

       On the day of 6th January 2012 02:05 GMT+1, I have
       received a legal note from Perkins Coie attorney company,
       which is representing Facebook Inc., based in Menlo Park,
       California.

       According to this note I must follow all of the below
       demands "In order to avoid further escalation of this
       matter":
       - Stop offering the FGS Browser Software, or any other
       software that interferes with Facebook's intended
       limitations or impairs the proper working of Facebook,
       - I must cease and not access the Facebook site(s) and/or
       services for any reason whatsoever.

I cannot find explanation why he got this message.

<comment><AUTHOR> It doesn't look like they provided any explanation, just gave a "fair" warning, "In order to avoid further escalation of this matter."

</comment></comment><comment><USER10> What's really funny about telling him he's not allowed to use any Facebook services is that, short of blocking all connections between his computer and Facebook's servers, he _can't_. Even if he never goes to facebook.com again, he'll still encounter Like buttons and other FB social plugins on many, many sites.

</comment><comment><USER11> I don't know if HN is that stupid...

Here's my story. I made a facebook website using their API in a bad way. EXACTLY like this story, that guy knew he was using facebook's API in bad way. I got 100.000 fans on my facebook app and then they closed it, banned me domain and banned me from using the API again. It doesn't mean I'm banned from using their API again... they're saying a lot of things they don't do... and it doesn't mean also that I can't work for a company that need a facebook developer (and that would be a shitty job).

sorry for my english I'm french.

but this article is sensationalism !

</comment><comment><USER12> 1\. FB's lawyers sent him a letter asking him to stop. No more, no less.

2\. Being 'banned from FB' is not really a legally defined classification for human beings, and HR organizations are paid to care about actual legal reality.

3\. If he's not using FB APIs or other licensed information, how are FB's options for "further escalation" anything more than a louder brand of saber rattling? All it takes is one good lawyer looking to stand up to Goliath pro- bono, in a case that we know would be very highly publicized, and suddenly all the downside to a court battle is on FB's end. On what legal theory could FB hope to receive damages?

4\. Despite all of the above, sometimes knuckling under and running for cover is the right move. A good programmer knows his limitations, and he's under no obligation to stick his neck out.

<comment><USER13> > _On what legal theory could FB hope to receive damages?_

Possibly: Increased costs of support to 130,000 people using unapproved software in combination to Facebook, who get weird results from the software when Facebook updates something and blame Facebook not the software, and who bitch and moan to Facebook for support? (Obviously most people don't bother with support, and they just complain to friends.)

</comment></comment><comment><USER14> Its important to note he was developing a browser extension and was not interacting with Facebook's exposed APIs.

</comment><comment><USER15> He wasn't "banned for life". He received a "cease and desist" letter from Facebook's lawyer that threatened (bluffed) to escalate their challenge against the game. It's classic scare tactic employed by lawyers for unethical clients.

<comment><AUTHOR> He quotes "I must cease and not access the Facebook site(s) and/or services for any reason whatsoever." There is not EOL date in his statement.

<comment><USER16> It's not the "for life" anothermachine is disputing, it's the "banned." What he received sounds like a simple nastygram. I could send you a letter demanding that you give me your house, but that wouldn't mean that you are obliged to do so.

<comment><AUTHOR> He's not a US citizen, he doesn't have funds to fight Facebook and he cannot count on the lawyers to help him for free. They used disproportionate force against him. I'm sure he will remember that lesson.

<comment><USER17> If he's not a US citizen and he isn't in the US, what's he got to lose by continuing to distribute the plugin? Any judgement against him would be pretty much pointless.

</comment></comment></comment></comment></comment><comment> k-mcgrady Why was he banned? I can't seem to find the reason on the reddit page or the developers blog post.

<comment><USER18> I've never heard of the plugin before, but it looks like it did some of the tedium of clicking on the game status updates for you. (If someone can give a good description, I would love to see it).

My guess is that FB doesn't like the software doing this because it means the users aren't doing it themselves, and thus aren't able to see the ads they would have otherwise, cutting down on revenue.

The only other reason I can think of that would make any sense is that the games servers might have had load issues (since the plugin could act faster and on more things than a human). However, I would put my ad theory above as far more likely.

<comment><USER19> >The only other reason I can think of that would make any sense is that the games servers might have had load issues (since the plugin could act faster and on more things than a human). However, I would put my ad theory above as far more likely.

Also consider that many facebook games operate with a micro-transactional model where you CAN buy stuff with in game currency earned by the 'tedious clicking' but if you want to speed things up, you can buy currency with real cash. If the 'tedious clicking' is mitigated by a plugin, then the pressure to pay real cash is decreased, costing the app developers revenue

So, this plugin reduces facebook's ad revenue, reduces app developer's revenue and if the application uses facebook credits as currency, facebook loses its cut of lost developer revenue as well. Its' not at all surprising that facebook went after it.

<comment><USER3> The key issue here is that is was a plugin that acted like a robot on the site.

Effectively they only thing that Facebook can do about that sort of application is ban people using it.

However, just like the Wow Glider saga they chose to pressure the developer instead. However, unlike that, it was just a browser plugin. No magical API calls, or anything like that.

I couldn't care less about micro-transactions, ad views and the spamware Facebook applications: Facebook is doing this because they can't take the bitter pill of banning _users_ who violate their TOS; instead they will attack the developer of said tool.

There is no justifying their actions.

fail.

<comment><USER19> Sorry but this post reeks of of personal hatred toward facebook and contains little value.

Regardless of the method chosen to attack this issue at the end of the day this hurts both their bottom line and their app developer's bottom line, which hurts the user base as a whole. Clearly your not a facebook user, so frankly, your opinion doesn't matter to them as long as your the minority.

Of course they would go after the source of the issue instead of their profit center (users). Are you really arguing that Facebook is evil for not attacking their users? I mean really its terrible of them to focus on their users and their profit centers over a singular third party developer, absolutely terrible.

I have a feeling if this article was titled "Facebook bans 50,000 users" you would have come here and made the same "I hate Facebook" argument.

<comment><USER3> Don't be silly. Of course I use Facebook. Most people do.

I have no time of day for the developers of the spamware that fill it, but that's not the issue here.

A plugin that does not in any way use the Facebook api is just a stand alone application.

This is exactly what Cory Doctorow is talking about with the war on general purpose computing. A company flailing wilding and applying bad (legal) pressure to bare against the issue of people using their computers to do something the company doesn't like (in this case automating game actions) is the wrong solution.

<comment><USER19> I don't understand your position at all. In essence it appears to be "if they don't use our API we have no recourse at all, its all fair use". Along the same lines any bot that automates any computer game is "ok", even if it destroys an entire industry of professional gaming, any application that scraps web data is "ok", etc. HN even blocks that kind of use.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> This sounds very similar to the Missing e situation that Tumblr users are facing:

[http://shortformblog.tumblr.com/post/15046201810/missing- e-t...](http://shortformblog.tumblr.com/post/15046201810/missing-e-tumblr- message)

Essentially a plugin got really popular to the point where it was starting to cause problems. Tumblr hasn't gone so far as to get lawyers involved, however, but they have put a message up for regular users of the plugin, suggesting they turn it off.

</comment><comment><USER21> Hmm,

There is a little more on this here:

[http://blog.games.com/2012/01/06/facebook-friendly-gaming- si...](http://blog.games.com/2012/01/06/facebook-friendly-gaming-simplifier- cease-desist/)

" _...the plug-in had racked up an impressive following of players "in-the- know," who kept the project a secret for fear of such an outcome..._ "

Maybe such a plugin shouldn't be disallowed by Facebook but it seems like it wasn't surprising to many people that it was...

</comment><comment><USER22> Apparently, FGS was banned because one lone game developer made it a point to complain. This particular browser extension was both the least intrusive, and smoothest working, of its' kind. The developer also worked WITH the game developers. so that this extension worked in a way that the game developers agreed to.

The myriad explanations as to "why" this happened can be found in these two articles, at the least, and in the comments to them.

<http://ireport.cnn.com/docs/DOC-727662>

<http://ireport.cnn.com/docs/DOC-728485>

For those who seem to believe that this was anything other than an UNREASONABLE action on the part of Facebook, I suggest that the only way to make REASONABLE would be to enjoin other, BIGGER programs that do what this one did and more. Programs that allow you to do things that one CANNOT do in- game, which is not something this browser extension did.

</comment><comment><USER23> Is not cheating definitively, this program is doing nothing else that collect from our walls, the items from the walls is free, so we don't have the possibility to collect stuff for which we suppose to pay... just collect the postings, if nobody took it before you...and with FGS, in 2 clicks you can collect hundreds...that's why all the ill people on Facebook was so in need of this program. For the people like me it was good, because when I come home after a whole day of work, I can collect item posted 12 hours before. And another wonderful thing which this FGS is doing, is that is receiving and sending back hundreds of gifts with 1 click. Having this wonderful FGS, we start to play 6-7 games, now without it, many of us are forced to quit playing and because many are on Facebook just for play, we'll close the Facebook accounts also. :(

</comment><comment><USER24> I would hire him

<comment><USER24> The fact that

1\. a developer could create a working product that is live and used by a lot of users. 2\. a developer could create something that draws a significant attention from a huge company like facebook since it turns out that the product has significant impact that it's actually all over the news when facebook tries to limit it.

These to me would not be a strong reason for hurting a chance of employment. On the other hand, this is the kind of developer you want to work with.

<comment><AUTHOR> These things can bite you when you least expect them. Say you hired him to write a web app and later on the users (or investors, or clients) want to have FB login. Now you need to fire the guy or separate him from the FB login implementation, testing, and use. The guy's got a huge target mark on his ass.

<comment><USER25> No it's just a cease and desist letter, even if he did comply its not a binding agreement. And even if he did agree facebooks systems are so automated that he would likely recieve an invite to use their systems which would nullify the ban. People banned from casinos often receive invitations to visit the casino which nullify the ban via the casinos marketing efforts.

<comment><USER26> > even if he did comply its not a binding agreement.

They're claiming he violated the ToS, which probably is binding. Moreover, they can take direct action to boot him from Facebook.

I think Facebook is being silly here, but I don't see why people appear to think that they wouldn't follow through on their threats.

</comment></comment></comment></comment></comment><comment><USER27> I have a question which is more legal related. It is "public" secret that US government (and other governments) have and use persona management softwares which clearly violate Facebook terms of usage. The question is: does Facebook has any legal standing against that? Can Facebook or other social networks sue government for offering private intelligence companies contracts to create software to manage "fake people"?

<comment><USER28> [http://en.wikipedia.org/wiki/Sovereign_immunity_in_the_Unite...](http://en.wikipedia.org/wiki/Sovereign_immunity_in_the_United_States)

</comment></comment><comment><USER29> OK, so where's the source ;)

<comment><USER30> Here: <http://code.google.com/p/fgs/source/checkout>

</comment></comment><comment><USER31> I NEED HELP FINDING OUT ABOUT SOMEONE WHO HAS BEEN PLAYING A PRETTY NASTY GAME WITH ME, IS ANYONE WILLING TO HELP?

</comment><comment><USER32> limits his chances of finding employment as a programmer??

Why exactly? Facebook API is s __t and no good programmer wants to develop on top of it.

<comment><USER33> No good programmer wants to, but does so anyways because of Facebook's marketing potential.

</comment></comment><comment><USER34> What about all the Like buttons everywhere?

<comment><USER35> It's the Facebook subreddit, that's a custom style set on that subreddit. The like buttons are actually reedit upvote buttons.

<comment><USER36> All the info regards the FB v FGS fiasco can be found here;

[https://www.facebook.com/help/community/question/?id=1911115...](https://www.facebook.com/help/community/question/?id=1911115&ref=notif&notif_t=answers_answered)

<https://www.petitionbuzz.com/petitions/savefgs>

<http://www.zdnet.com/tb/1-112687#1_112687_2285681>

<http://ireport.cnn.com/docs/DOC-728485>

[http://thedailyattack.com/2012/01/07/facebook-intimidates- de...](http://thedailyattack.com/2012/01/07/facebook-intimidates-developer- bans-him-and-his-code-for-life/)

[https://www.facebook.com/pages/Support-Arkadiusz-flies- Rzadk...](https://www.facebook.com/pages/Support-Arkadiusz-flies- RzadkowolskiCreator-of-FGS/273823565972663?sk=wall)

[http://www.zdnet.com/blog/facebook/facebook-bans-browser- plu...](http://www.zdnet.com/blog/facebook/facebook-bans-browser-plugin-fgs- and-its-developer/6955)

[http://journalxtra.com/games/facebook-bully-fgs-cease- desist...](http://journalxtra.com/games/facebook-bully-fgs-cease-desist- notice-fb-lawyers-4580)

[http://facebookkit.com/facebook-bans-browser-plugin-fgs- and-...](http://facebookkit.com/facebook-bans-browser-plugin-fgs-and-its- developer/)

<http://rddweb.com/fgs-facebook-zynga/>

[http://blog.games.com/2012/01/06/facebook-friendly-gaming- si...](http://blog.games.com/2012/01/06/facebook-friendly-gaming-simplifier- cease-desist/)

<http://www.sims-social.com/2012/01/help-save-fgs.html>

[http://www.ixwebhosting.mobi/facebook-disable-plug-ins- more-...](http://www.ixwebhosting.mobi/facebook-disable-plug-ins-more- than-27000-users-fgs-petition-to-retain/)

<http://www.cityvillechat.com/news/facebook-attacks-citizen/>

<comment><USER23> hi, I'm new in here and made an account just because I saw you talking about Arkadiusz Flies and his FGS. FGS is not a bot as others, as I am just a simple user of the computer, I'm not able to explain you what it is, but before judge Flies, please inform yourself, and after, when you'll understand that he is completely innocent, you'll give me and 30.000 others some help. FGS is the best ever, is completely different of other bonus collectors, has his own browser which has nothing to do with cheating and collecting unpaid stuff. Wwe can collect with one click hundreds of bonuses from our friends walls, nothing stgealing...just the stuff we loose because we have to go to work sometimes :) We've started to believe that facebook want to legally steal the program from Flies... Please help...this kind of bullshit can happen to anyone if we don't stand up. Facebook is taking advantage because Flies is a student, he can't pay for a legally action against this Facebook. Yes, we thought about Google +, but I don't know if Google is a good platform for FGS and...what's the sense to go in Google, when our games 20-30 there are not yet on Google... If Google will accept all these games, millions of people will leave for good this shit Facebook. We're waiting just a little sign from Google, in the meantime we made all accounts and took Flies in our circle. Till then, we need all the help we can find.</comment></comment></comment></comment>


How to destroy an American family - <AUTHOR> http://specialreports.dailydot.com/how-to-destroy-an-american-family <comment><USER2> The real issue here--as the family recognise--is the utter lack of reasonable security measures on the part of the vendors (food, deliver, police) who are fooled into harassing them.

Why is it possible to fake a phone call from any number?

Why is it possible to cancel service without a reasonable verification step?

<comment><USER3> Because phone numbers aren't public keys.

What's a reasonable verification step?</comment></comment>


Zoom for Music Education - <AUTHOR> https://music.yale.edu/news/yale-led-effort-yields-zoom-upgrades <comment><USER2> Has anyone tested this over a city-wide area?

Better than JamKazam?</comment>


Genetics extends the long arm of the law - <AUTHOR> https://www.knowablemagazine.org/article/technology/2019/genetics-extends-long-arm-law <comment><USER2> Pro: Law enforcement has access to a great tool for identifying people.

Con: Government has access to a great tool for identifying people.

<comment><USER3> Another Con: In the not-too-distant future, a sequence can be recreated from the digital record[s].

Another Con: Assuming that you can copy the database out, all you need is one instance of the Y-Chromosome's owner name and you can find their children and children's children and...</comment></comment>


Scientists see mechanism for spontaneous HIV 'cure' - <AUTHOR> http://news.yahoo.com/scientists-mechanism-spontaneous-hiv-cure-111655252.html

<comment><USER2> Great to see APOBECs in the news! My colleagues and I have been working on solving the structures of these proteins for the last 5 years and more. If HNers have any questions, I'll try answering to the best of my knowledge.

<comment><USER3> How close are we to seeing a commercial application for this?

<comment><USER2> The fundamentals of activating APOBECs are being worked out by multiple groups across the world. That said, one phrase you'll always read around the APOBEC3 sub-family of proteins (responsible for the anti-HIV effect), is "double-edged sword". The biggest risk, with (cytidine deaminase) enzymes that act on DNA, thereby changing the fundamental genetic code, is causing cancer. More recently, APOBEC3B (no anti-HIV effect, but same sub-family), was shown to have _extremely strong_ correlation with breast cancer[0]! The emerging therapeutic field involving APOBECs will require highly specific targeting of activators(anti-HIV) as well as inhibitors(anti-cancer)[1].

[0]: [http://www.cell.com/abstract/S0092-8674%2812%2900528-4](http://www.cell.com/abstract/S0092-8674%2812%2900528-4)

[1]: [http://www.apogenbiotech.com/](http://www.apogenbiotech.com/)</comment></comment></comment>


Show HN: Poutly| Friendly email reminders to past due clients - <AUTHOR>

I've heard many freelancers complaining about clients taking ages and ages to pay after a project has been completed.
In my experience, I have seen that the invoice that gets "chased" is normally the one that gets paid first.
Poutly send friendly email reminders (SMS coming soon) to past due clients.
Would love your thoughts.
http://paymentrem.herokuapp.com <comment><USER2> The fonts are broken on Google Chrome on Windows 8.1 at 1920x1200. They don't render in a readable manner. They make iOS 7 look readable. t's look like lowercase Ls. Capital Es look like squared-off capital Cs. 4s look like a bent over 7, etc.

<comment><AUTHOR> Thanks. Will look into.

</comment></comment><comment><USER3> Is there a sample reminder you can show on the site? I agree that the font needs to be changed. It's practically unreadable on my BlackBerry Q10.

One more thing: throw in a guarantee somewhere and I think your conversions will rocket. Great idea btw. Good luck!

</comment><comment><USER4> clickable: [http://paymentrem.herokuapp.com](http://paymentrem.herokuapp.com)</comment>


Ask HN: What is your repeatable marketing process? - <AUTHOR> I'm curious about what repeatable marketing process startups are using to reach out to and acquire customers. Is it AdWords, affiliate marketing, social media marketing, blogging, PR, etc.? <comment><USER2> Build a free application that draws people in to the site. Not necessarily like the freemium model, just offer something cool for free. Either give away great software, or become an authoritative source of data, or both.

This worked amazingly well for me with my fantasy football website. I made software to let people do free mock drafts. Over the last five years it's grown substantially with virtually zero advertising. I then sell premium fantasy football software to those visitors. Also, I aggregate data and have become a reliable source that people link to. Building the free app and becoming a source of data has led to my site becoming the #1 result in Google for just about any search term that I care about.

It's sort of a twist on the freemium model. The conversion rate is very low, but the customer acquisition cost is virtually zero, so it is still profitable.

</comment><comment><USER3> Scalable content creation for organic SEO. I'm a two trick pony for customer acquisition, and this is my better trick. (#2 is AdWords.)

<http://www.kalzumeus.com/2010/01/24/startup-seo/>

[http://www.kalzumeus.com/2010/07/17/seo-for-software- compani...](http://www.kalzumeus.com/2010/07/17/seo-for-software-companies/)

Repeatability is a core, baked-in element of the strategy.

<comment><AUTHOR> If you blog it, they will come?

</comment></comment><comment><USER4> The only repeatable processes you should implement are:

1\. Identifying your customer 2\. Creating a fulfilling customer experience

Now there's a ton of ways to support #2, but if you've truly understood #1 you know which ways to follow with. The hard part is making the experience consistent yet unique for each customer/customer type you have. Measure everything, or create proxy measures and plan before acting.

</comment><comment><USER5> This went through HN recently and it's a great article actually. <http://news.ycombinator.com/item?id=1610540>

<comment><AUTHOR> Hi, I agree that it's a great article, but PR seems to be a one-time (or few- time) thing that cannot really be translated into a repeatable process that I can do day in and day out.</comment></comment>


Nanocubes: Fast Visualization of Large Spatiotemporal Datasets - <AUTHOR> http://nanocubes.net/ <comment><USER2> Kind of related, I recently made a similar style of visualisation for 99designs.com - [http://a.tiles.mapbox.com/v3/dhotson.d2013/page.html](http://a.tiles.mapbox.com/v3/dhotson.d2013/page.html)

Once I got the data into PostGIS and aggregated into hexes (slightly harder than it sounds) it wasn't that big a deal to visualise using Tilemill and MapBox.

I haven't read the nanocubes paper yet, but it sounds much much faster than my approach using PostGIS. It took me many hours to import and process tens of millions of points in my visualisation. It'd be great to be able to turn something like this around in <10 mins.

Would this nanocubes approach work with hexes? (they look cooler IMO)

Offtopic: After all this, all I can think about—is making a Settlers of Catan MMO. ;-)

<comment><USER3> Heh, I had a conversation a few weeks ago with Jeff Heer, coauthor of a very similar paper where we talked about how to make this stuff work with hexes. I think it can be done, but the hierarchical part is a pain, and I'll need more than a HN comment to explain :) Look me up offline if you're interested and we can chat.

</comment></comment><comment><USER4> Or as we in the graphics fields call it: mipmapping, geoclipmapping, megatexturing, virtual texturing or slippy maps.

There's a related capability called "interpolation" which could be linear, bicubic etc. Looks nice too, try it.

<comment><USER3> (Hey, I'm a big fan of your WebGL work!)

This is really not about interpolation or mipmapping; it's about creating a data structure that allows you to quickly answer queries with which to build visualizations. For example, you might want to see a heatmap of all tweets that happened in 2013, but you might want to see only the count of a particular week, or a month of tweets from Instagram. You might also want to see all of these things above over the entire world, or over a single metro region. What nanocubes enables is answering these queries in time essentially proportional to the size of the _output_ (we take a polylog hit, but that's kind of to be expected). We don't even touch all of the input data, which, if you ask me, is kind of nice.

I wish I had bigger public datasets to show you, but we keep this fast experience with datasets in the billions of points.

About your interpolation point: yes, we could (and do sometimes) use interpolation and smoothing. We choose here not do it here so that it looks the same when you go to the webgl-less mode and run it on an iPhone or iPad, there isn't a big visual difference.

<comment><USER4> > it's about creating a data structure that allows you to quickly answer > queries with which to build visualizations

Hm, I see, so this can output the virtual miplevels quickly? Also, would it work with a "full" dataset (i.e. no empty cells)?

> About your interpolation point: yes, we could (and do sometimes) use > interpolation and smoothing.

Also consider miplevel interpolation, makes the transitions between levels much easier on the eye (doesn't work well with nearest sampling).

<comment><USER3> > Hm, I see, so this can output the virtual miplevels quickly?

Yes: when you see the tiles on (say) [http://www.nanocubes.net/view.html#twitter](http://www.nanocubes.net/view.html#twitter), what you're getting is not a precomputed tile: the server is actually visiting the datastructure every time (and I hope I can convince you that at that speed, it is _not_ touching 210 million points :). The reason you can't precompute all choices is simply that there's too many of them and you'd run out of bits in the universe (the paper, [http://www.nanocubes.net/assets/pdf/nanocubes_paper.pdf](http://www.nanocubes.net/assets/pdf/nanocubes_paper.pdf), has details).

> Also, would it work with a "full" dataset (i.e. no empty cells)?

Not exactly. We get away with an in-memory data cube exactly because in many practical cases the data is sparse over the address space. With dense data you'll take a much more significant memory hit (but it's one you'll have to take with _any_ aggregation scheme. The paper, again, has details)

> Also consider miplevel interpolation, makes the transitions between levels > much easier on the eye (doesn't work well with nearest sampling).

That's fair, although again we're hoping to keep the WebGL version feature- compatible with the leaflet.js version (that does canvas-only, and has no zoom transition at all); the smooth version looks nicer, as you can see in the (bit on the PR-heavy side, sorry) following video [https://www.youtube.com/watch?v=8P9QA6TJwys#t=69](https://www.youtube.com/watch?v=8P9QA6TJwys#t=69)

</comment></comment></comment></comment><comment><USER3> Author here, happy to answer questions.

<comment><USER5> > and in _some_ cases it uses sufficiently little memory that you can run a > nanocube in a modern-day laptop.

What's the limitation? (I admit that I did not attempt reading the paper yet)

EDIT: To reword it, this sentence gives the impression that there could more factors than just plain quantity, and I was wondering if that is the case and what that could be.

<comment><USER3> Memory usage gets worse as the number of dimensions increases (because there's more ways in which to build summaries), and also as the number of unique keys increases (because there's more of different things to store). The main advantage nanocubes has is that it's a _sparse_ scheme: previous work on fast data cubes for visualization (immens, for example) use a _dense_ storage scheme, and so memory usage goes up proportionally to the size of the address space instead.

</comment></comment></comment><comment><USER6> A high speed multidimensional query seems like it would be useful for visualizing and analyzing server logs to look for attacks and other trends.

<comment><USER3> You're right, it is :)

The version with online demos uses latitude/longitude for the spatial dimension, but a new version we're working on (under the master branch on github) allows arbitrary x,y addresses. With that, we've encoded IP addresses as locations in space-filling curves to play around with source IP/destination IP datasets. It's particularly nice because the hierarchical nature of the spatial addresses end up mapping to larger and larger subnets of the IPv4 space.

</comment></comment><comment><USER7> Would this make sense as a type of index in PostGIS?

<comment><USER3> It's open source ([http://github.com/laurolins/nanocube](http://github.com/laurolins/nanocube)), so one could certainly try that. With that said, it is currently an in-memory store with no disk backing, so it would be a significant amount of work to get it going.

At the same time, I certainly believe that _some_ sort of hierarchical, low- footprint data cube would be a great addition to postgis.</comment></comment>


Show HN: The Harlem Shake Bookmarklet (Happy Valentine's Day Internet) - <AUTHOR> http://blog.moovweb.com/2013/02/happy-valentines-day-internet-behold-the-harlem-shake-bookmarklet/ <comment><USER2> At Moovweb, all we do is target elements on pages... and deliver miracles with it.

</comment><comment><USER3> nice :) I made something similar <https://gist.github.com/chinchang/4666645>

</comment><comment><USER4> I haven't smiled this big in a while. Good work.

</comment><comment><USER5> sorry if this a n00b question ... how are they able to target just the right elements on a page across pretty much any website?

<comment><USER6> Check out the source code on Github. <https://github.com/moovweb/harlem_shaker>

</comment></comment><comment><USER7> I can't stand the Harlem Shake but I love this.

</comment><comment><USER8> Hah awesome - check it out on FB or pinterest

</comment><comment><USER9> Just when I thought it had jumped the shark.

</comment><comment><USER10> just made my day. I so want a flying nyan cat now</comment>


Machine Learning on Rails with Ruby - <AUTHOR> http://blog.bigml.com/2012/07/06/machine-learning-on-rails-with-ruby/

<comment><USER2> Awesome announcement...and though I get what you're doing here, using "Rails" un your headline was a real diversion</comment>


Training an AI to write BuzzFeed clickbait headlines - <AUTHOR> http://dataskunkworks.com/2018/11/05/i-trained-an-ai-to-write-buzzfeed-clickbait-headlines-you-wont-believe-what-happened-next/ <comment><USER2> Am I missing something here, or would a mark of chain be much easier to write and solve the problem just as well?

Seems like much less effort. Of course, maybe the author wanted to work on an RNN instead?</comment>


Challenging problems, non-obvious statistics. - <AUTHOR> http://news.bbc.co.uk/1/hi/magazine/8153539.stm

<comment><USER2> _Imagine you've invented a machine to detect terrorists. It's good, about 90% accurate. You sit back with pride and think of the terrorists trembling._

I've done better than this -- I have a terrorist-detecting machine which is 99.9999% accurate.

It's a sheet of paper with the words "not a terrorist" written on it.</comment>


Ask HN: Hiring someone on vacation - <AUTHOR>

Let's imagine you are an US company, you meet someone on vacation (who planned to stay less than 3 month) and you really want to hire this person because of his unique skills, and offer him a long-term contract. What kind of legal procedure can you engage? <comment><USER2> You should probably talk to an immigration attorney, it depends on a loooot of factors. And let me tell you first that there is no easy road.

The "obvious" answer would be to file for a H1B in April 2014, in order to hope to be allowed to get that contract signed in October 2014... but I guess you won't take that for an answer! :)

You can base a more ambitious visa strategy on stuff like: * the outstanding stability and growth of your business (E visas, I believe) * the outstanding career and unique skills of your guy (O visas) * the existence of a stable branch of your company in your guy's country, if there's one. (L visas, I believe) * ...

Whatever the road you guys take, it will cost you a lot of money, will take a loooot of lawyer time to build a convincing case, and then quite some time to get it reviewed, with no guarantee about the outcome. Who said the US immigration system was broken?

Good luck!</comment>


PRISM: All your data, in one place - <AUTHOR> http://prism.andrevv.com/

<comment><USER2> This is cute. Now be prepared for a thorough audit :-)</comment>