We Now Know More About the Apparent Poisoning of the Pussy Riot Member - <AUTHOR> https://www.newyorker.com/news/our-columnists/we-now-know-more-about-the-apparent-poisoning-of-the-pussy-riot-member-pyotr-verzilov/ <comment><USER3> Probably worthwhile raising people's awareness of toxidromes, and how physicians try to recognize and think through these syndromes. There is a fantastic review article out this past year that helps to concisely put things together to improve your ability to distinguish nerve agents, mustard agents, etc. Quick recognition of the likely class of agent based on symptoms is important, because the treatments (and the risks to responders) differ.

Original at [https://www.nejm.org/doi/full/10.1056/NEJMra1705224](https://www.nejm.org/doi/full/10.1056/NEJMra1705224)

Full repost hosted presumably by one of the authors at [http://www.dickyricky.com/Medicine/Papers/2018_04_26%20NEJM%...](http://www.dickyricky.com/Medicine/Papers/2018_04_26%20NEJM%20Toxidrome%20Recognition%20in%20Chemical- Weapons%20Attacks.pdf)

</comment><comment><USER4> Poison in the System[1] is the first part of Buzzfeed's investigative journalism series on many unexpected deaths related to Russia since 2003. The entire series is worth a book.

[1] [https://www.buzzfeed.com/heidiblake/poison-in-the- system](https://www.buzzfeed.com/heidiblake/poison-in-the-system)

<comment><USER5> I've always wondered: why poison? It doesn't always seem to kill the victim and makes it easy to identify the perps as state actors.

<comment><USER6> The US version of it is a Hellfire missile from a drone remote-controlled from 2 continents away.

Way more lethal, way more collateral, quite obvious to identify as the act of a state actor, still common practice barely anybody takes issue with.

<comment><USER7> Your comparison is completely unalike. Yes the US drone war program is bad. Yes the endless war on terror is bad. But these are not the same as a tyrant poisoning anyone who becomes inconvenient to him.

The closest comparison I think you could validly make would be something like the harsh treatment of Chelsea Manning or Reality Winner (or Drake, or Snowden, etc). None of which were taken out with poison or a Hellfire missile.

(Edit: that's not to excuse the treatment of those people either.)

<comment><USER6> No, it's exactly the same. Both are extrajudicial and state-sponsored killings aka assassinations.

Just because many people have blind trust in the US government and the validity of its kill list aka "disposition matrix" [0] doesn't change the basic injustice of the act, which is just as unjust as poisoning some "enemy of the state".

The international laws and human rights broken in both cases are exactly the same, the only difference is the methodology of the final "execution".

> None of which were taken out with poison or a Hellfire missile.

It's extremely naive to assume we know every drone victim ever, it's not like the US drone program is a shining beacon of transparency.

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

<comment><USER7> Putin targets Russian citizens that are his personal enemies because they speak up, protest, or otherwise embarrass him. He does it using poison in a manner to make sure everyone knows who did it and what the consequences are if you cross him.

The US drone program does not target US citizens who speak up, protest, or embarrass the president of the USA, at the behest of just the president.

(Stating the obvious, but that's not a defense of the drone program. You've outlined its problems. But it's just clearly not the same thing.)

<comment><USER6> > The US drone program does not target US citizens who speak up, protest, or > embarrass the president of the USA, at the behest of just the president.

How do you know that? Does the US publish its list? No, it doesn't, so you are making that statement on literally nothing but good faith.

While at the same time you use bad faith to frame the Russian version as something where Putin personally orders people killed for slighting him or some other mundane reason.

The reality is both are killing "enemies of the state", justified and regulated by their own, internal, rulesets and governmental institutions. They and others have been doing so openly, and covertly for decades. Heck, this kind of stuff even has been glorified as a pop-culture export from the UK as "the agent with a license to kill".

In that context, there's literally no difference if it's an Obama, Trump, Putin or their UK equivalent giving the final "okay" or if the target is a US/UK/Russian national who's a terrorist/pedophile/traitor/whatever.

It's about the lack of accountability, the lack of due process, the lack of recourse. All these issues exist regardless of the US, Russia or anybody else doing something like this.

In that context, the US drone war is pretty much the overt manifestation of a practice that used to be kept covertly due to its inherent controversy. But in the zeals of a war on terror, where even torture became openly condonable, too many people have lost their moral compass.

<comment><USER8> _> The US drone program does not target US citizens who speak up, protest, or embarrass the president of the USA, at the behest of just the president._

 _How do you know that?_

Well, there's simple occam's razor - if drone strikes were doing this, we'd probably have heard about it. On the other hand we have a rising body count of journalists, artists, and ex-spies with real names and histories.

No matter how you feel about drone strikes, you can't compare these things.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> When I see stories like this, I think of this editorial written by Lasantha Wickrematunge, a leading Sri Lankan journalist, to be printed in the event of his being killed:

 _And Then They Came For Me_

 _No other profession calls on its practitioners to lay down their lives for their art save the armed forces and, in Sri Lanka, journalism. In the course of the past few years, the independent media have increasingly come under attack. Electronic and print-media institutions have been burnt, bombed, sealed and coerced. Countless journalists have been harassed, threatened and killed. It has been my honour to belong to all those categories and now especially the last. ..._

It's a powerful essay that challenges not only authorities but also simplistic hero/villain narratives about them, about journalists, and about their readers. Highly recommended:

[https://web.archive.org/web/20180120100014/http://www.thesun...](https://web.archive.org/web/20180120100014/http://www.thesundayleader.lk/20090111/editorial-.htm)

 _If you remember nothing else, remember this: The [Sunday] Leader is there for you, be you Sinhalese, Tamil, Muslim, low-caste, homosexual, dissident or disabled. Its staff will fight on, unbowed and unafraid, with the courage to which you have become accustomed. Do not take that commitment for granted. Let there be no doubt that whatever sacrifices we journalists make, they are not made for our own glory or enrichment: they are made for you. Whether you deserve their sacrifice is another matter. As for me, God knows I tried._

</comment><comment><USER10> Any indication of what type of poison was used? The symptoms sound horrific. Blindness, and continued hallucinations after days. Must be very traumatic.

<comment><USER11> Media reported that he "may have been poisoned with strychnine", but there's no official diagnose yet.

EDIT: I'm badly mistaken. It was reported about Russian-British couple in Salisbury. I've got confused, since there are three different poisonings being discussed in the media daily. Normal day in Russia(

</comment></comment><comment><USER12> Things that are interesting about this to me:

1\. In Russia, nobody really knows or cares about pussy riot. The western fascination with them is a kind of exoticism. Nadya Tolokonnikova can fill a 1000-5000 seat lecture hall in a major american city, but in Moscow it'd be a surprise if 100 people showed up. This isn't out of fear or anything like that; think what kind of attendance a young, white, American punk woman doing art pranks in America would draw on the American speaking circuit. It's the same in Russia, to most people they're just not that interesting.

2\. In Russia, nobody knows or cares about zona.media. This article says "...Media Zone quickly established itself as one of the country's most reliable sources of information," but it's basically the modern Russian equivalent of IndyMedia: a protest calendar that only a very small contingent of activists pay attention to with the normal levels of radical infighting and articles written for the echo chamber. Nobody "on the street" has even heard of it.

3\. Putin has a slight growing problem with young people who didn't experience the "before" and "after" of his taking power in the 90s, but for the most part nobody cares about these stories. If you ask people "on the street" whether they think Putin was responsible for the apartment building bombings referenced here, most will straight up say "even if he was, I don't care, he's still amazing." There was even a podcast (radiolab?) that actually did these interviews.

However, I am very prepared to believe that the Russian state poisoned Pyotr. What I never understand about these recent actions, though, is why? Why go out of your way to poison a no-name activist that operates in fringe circles for researching a story that nobody would care about, even if Putin were to confess live on TV channel 1?

<comment><USER13> > Why go out of your way to poison a no-name activist that operates in fringe > circles for researching a story that nobody would care about, even if Putin > were to confess live on TV channel 1?

A message to the West perhaps?

> The western fascination with them is a kind of exoticism.

But the West is important to them. They know the fascination and they know the West is watching so they just showed everyone they can be ruthless.

It could play on the angle that Westerners should be careful about supporting too much someone like that as their popularity could end up killing them. For example, say Harvard wanted to invite Verzilov to give a talk. Now they might think twice - it would be nice to have him, but would they be painting a target on his back because of it? So it has kind of a secondary chilling effect.

Another reason:

> Verzilov had been working on an investigative story about the deaths of the > three Russian journalists, Alexander Rastorguev, Orkhan Dzhemal, and Kirill > Radchenko.

It wasn't that he was particularly dangerous because of his political stance but because he started to dig into other journalists' suspicious deaths. So he might have been a no-name but got close enough to uncover things.

One more reason:

Eliminate the troublemakers early. Don't wait till they become popular. Have someone monitor the media and detect who is becoming "dangerous" and eliminate them before they have a huge following.

<comment><USER4> > Another reason:

> Verzilov had been working on an investigative story about the deaths of the > three Russian journalists, Alexander Rastorguev, Orkhan Dzhemal, and Kirill > Radchenko.

This is the most likely reason, because:

> Russian journalists killed in Central African Republic were researching > military firm with Kremlin links, their editors say

[https://www.theguardian.com/world/2018/aug/01/russian- journa...](https://www.theguardian.com/world/2018/aug/01/russian-journalists- killed-central-african-republic-investigating-military-firm-kremlin-links)

<comment><USER14> The Military firm is Wagner group -

>Wagner's forces remain outside the Russian armed forces, following the whims of their master, the oligarch Yevgeny Prigozhin. [https://www.theatlantic.com/international/archive/2018/08/ru...](https://www.theatlantic.com/international/archive/2018/08/russian- mercenaries-wagner-africa/568435/)

And re Prigozhin:

>In 1981 he was sentenced to twelve years imprisonment under articles of robbery, fraud, and involving teenagers in prostitution.

>His ties to Putin go back to at least 2001: He's worked on everything from election interference to setting up pro-Putin newspapers to sending Russian mercenaries to Syria to fight on behalf of Bashar al-Assad's regime.

>... personally approved a Russian mercenary attack on US forces stationed in eastern Syria in early February [https://www.vox.com/world/2018/2/26/17044930/yevgheny- prigoz...](https://www.vox.com/world/2018/2/26/17044930/yevgheny-prigozhin- putin-mueller-troll-farm)

Probably not the kind of guy who'd worry too much about having an investigative journalist hit.

</comment></comment></comment></comment><comment><USER15> I always like to ask, "who wins?". News gets out that Russia is poisoning people critical of it. Who wins? Do they achieve their goals of silencing criticism? Obviously people think negatively of them and think twice before visiting the country. So, who wins?

<comment><USER16> Good question. In my eyes Russia indeed has really no motive to do this. On the other hand, given the constant demonization of Russia over the last years, this perfectly fits that narrative.

But if the goal was this demonization of Russia, then yeah, that's a lot of motive right there.

</comment></comment><comment><USER17> At this point, are we really surprised at the way some people who perceive themselves as above the law (apply this to any political or commercial leaders you see fit) will behave?

We have passed a turning point at which previously reprehensible behaviors have become tolerated. And as an English speaker living in the Netherlands has come to learn, some of us have an ingrained inclination to avoid directly calling out what to most people would be an obvious problem (to avoid potentially offending).

Putin's Russia kills people. It imprisons people. It poisons people. It cheats, it steals (from masses of poor people). It lies in the face of the world (bare chested). For some reason we now tolerate this without calling it for what it is.

And now we have an American government that has for so long not only avoided calling it out but instead has celebrated non-virtues while avoiding contagious fatal flaws that we forget how wrong for civilization the behavior is. Not only that, but we've begun to celebrate the virtues of dictators - <USER2> benevolent ones (if they exist), but previously-OBVIOUS horrible self-serving ones.

So, trying to shut the rant down, it's all quite f-d up. We should not only not be surprised, we should be up in arms. Ironically, the people who should be up in arms are the ones who wisely have realized that arming the civilians is a net-negative. But at least in the US, the right to bear arms is exactly to undo situations like the one we are clearly headed toward.

<comment><USER18> For a while I shared the mentality that Russia was unequivocally bad and the anti-thesis of all Western values of freedom. It was like common knowledge to me.

But with every breathless proclamation like yours of Russia as a cartoon villain I started to have doubts. It seemed like everything was suddenly Russia's fault--they were the absolute root of all evil in the world. Anyone who disagreed was obviously a Russian bot.

The last straw for me was when Theresa May declared, without any doubt, that the Russian state had attempted to assassinate two British citizens using nerve agents (10 days after the fact, before the conclusion of any investigation and without any concrete evidence to implicate Russia).

This Russia-phobia is dangerous. We have made a bogeyman and a scapegoat out of a desperate, nuclear-equipped nation that less than 30 years ago had its federation, economy and national identity shattered. I'm afraid that this delusion won't stop until a full on conflict breaks out which should be a much scarier prospect than yet-another-evil-dictatorship.

<comment><USER19> I think you both have valid points. Russia is not always a good global citizen. It's had a history of ignoring protocol if it got in their way. They have had cheerleaders when they were Soviet, they have a few chearleaders now (ME, for example).

But we, in the West, and countries aligned with the West, fail to understand their motives. Like China, they have internal motives that while they look like they are strategizing against the West in particular, at times it's just due to internal issues.

Russia didn't anex Crimea to poke the West. They took it because not having it exposed them militarily (as well as domestically made them looked weak).

For all his faults, Kissinger understands those things better than most public figures in their public speaking (are willing to admit, at least).

<comment><USER20> > They took it because not having it exposed them militarily

Ok, I'll bait - it exposed them to what?

<comment><USER19> It's advantageous to have a warm deep water port [Sevastopol] so you can mobilize your navy easily in the middle of winter --as well as allows for the trade of good during winter months-- both things which allow offensive and defensive options.

<comment><USER20> They already had a warm deep water port there before Sevastopol.

Any other "exposures"?

</comment></comment></comment></comment></comment></comment><comment><USER21> Following their World Cup protest, I discovered that some of Pussy Riot's music is on Spotify, in case anybody is interested.

Edit: I guess people aren't interested. My bad.

<comment><USER22> Upvoted. Some of their music is good.

</comment></comment><comment><USER23> Any news about the Russian government should be read with the understanding that the Western political establishment is _desperate_ to find a pretext for entering the war in Syria and deposing the Assad regime, which has the military backing of Russia.

<comment><USER24> Your theory here being that Masha Gessen is collaborating with the Trump administration.

<comment><USER23> No.

<comment><USER24> Then help me understand what your point could be about this New Yorker piece?

<comment><USER25> Not the OP, but the obvious interpretation is that the Trump administration is not only not equivalent to, but in opposition to, the "Western political establishment".

c.f. the "Deep State".

True or not, it's a charitable read of OP.

<comment><USER24> I'm fine with s/Trump administration/deep state; the question stands.</comment></comment></comment></comment></comment></comment>


Let's fix NPM with IPM – Immutable Package Manager - <AUTHOR> https://github.com/ipmjs/ipmjs#readme <comment><USER2> How does this fix the issue? Even if you think the Kik trademark claim was invalid... what happens when a valid trademark claim arrives?

<comment><USER3> Ideally, names could still change hands, but it would require a major version bump. So I publish 'google-lib' 1.0.0, Google files a trademark claim and is given publishing rights on the 'google-lib' package, but _only_ for versions >=2.0.0. If a company still goes after you for hosting the archived code, _that 's_ when you make a legal stand and try to get EFF involved or something - because there's zero case for "reasonable likelihood of [trademark] confusion" over a deprecated version of a package which is only available via 'npm install'. I would expect this to never/rarely happen.

The harder question is what to do when you get a valid _copyright_ claim, ie. when someone publishes code that wasn't theirs to publish. I think in this case, immutability doesn't really work, and you'd have to retroactively remove all versions. This should also be fairly rare, especially since so many packages are <500 lines of code.

<comment><USER4> That's actually sort of how NPM works currently, they mentioned that that's exactly how they would solve kik situation, by giving them new version of the package: [http://blog.npmjs.org/post/141577284765/kik-left-pad-and- npm](http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm)

"Had Azer taken no action, Kik would have published a new version of kik and everyone depending upon Azer's package could have continued to find it."

<comment><USER5> > In a global namespace for unscoped modules, collisions are inevitable.

why does npm works with a global namespace to begin with ? don't they understand that's the root of the issue ?

</comment></comment></comment></comment><comment><USER6> More Go centric, but they are similar. So there may be some ideas that could cross-pollinate.

[https://github.com/artktec/gopkgr](https://github.com/artktec/gopkgr)

</comment><comment><USER7> I wonder if it makes sense to combine some kind of blockchain technology.

<comment><AUTHOR> I like the idea and I couldn't agree more. Would be awesome if each individual package could be verified, maybe even stored, using the block chain.

If you have some time, please add an issue on the repo and start the discussion over there.</comment></comment>


Next Ubuntu will be the "utopic unicorn" - <AUTHOR> http://www.markshuttleworth.com/archives/1363

<comment><USER2> Well, that sounds attainable.</comment>


The Two-Party System Is the Worst Case Scenario - <AUTHOR> https://theintercept.com/2016/07/29/the-two-party-system-is-the-worst-case-scenario-an-interview-with-the-green-partys-jill-stein/ <comment> lloyd-christmas While I very much dislike how our country's voting process works, I do not like presidential candidates addressing how presidents get elected. If a president had an impact on how the president gets elected, you end up with Putins and Erdogans.

<comment><AUTHOR> What is the problem with ranked voting? If I were to really want Jill Stein to win, but if she can't win, I'd put my full vote for Hillary Clinton, because I don't think Trump should win- I as a voter should have a way to indicate that in a democracy. Simple 1-candidate voting enforces the two party system and makes people pick the lesser of two evils.

Without proper democratic voting we might as well choose candidates at random, as at least that would provide a chance of the majority electing a candidate they preferred.

<comment> lloyd-christmas > What is the problem with ranked voting?

I didn't say there was a problem with it, nor did I imply it. My criticism isn't about the content of her argument, it's that she, as a presidential candidate, is making it in the first place.

</comment></comment></comment><comment><USER2> I can't take anything she says seriously any longer after this [0]. It just boggles my mind.

[0]: [https://www.washingtonpost.com/news/post- politics/wp/2016/07...](https://www.washingtonpost.com/news/post- politics/wp/2016/07/29/jill-stein-on-vaccines-people-have-real- questions/?tid=sm_tw)

<comment><USER3> I watched the piece and I'm honestly wondering what your objection is.

I assume that you, like me, are very much in favor of vaccination. She clearly is as well, but 1) has concerns that large portions of the American public don't trust the agency that regulates vaccines and 2. thinks that all medicines (and vaccines) should be carefully studied for safety. She also rightly points out that mercury was removed from most vaccines a number of years ago because there were other safer and more effective adjuvants. She makes no reference to the autism myth and says that she thinks vaccines are a critical part of public health (or something to that effect).

I apologize if I have misinterpreted your distaste for her, I just wanted to say that as a strongly pro-vaccination person, I don't really disagree with anything from that clip.

(I also have never read / seen any interview material from her prior to this article and discussion, so I'm not defending her as a supporter.)</comment></comment>


John Carmack on Inlined Code - <AUTHOR> http://number-none.com/blow/john_carmack_on_inlined_code.html <comment><USER2> The older I get, the more my code (mostly C++ and Python) has been moving towards mostly-functional, mostly-single static assignment (let assignments).

Lately, I've noticed a pattern emerging that I think John is referring to in the second part. The situation is that often a large function will be composed of many smaller, clearly separable steps that involve temporary, intermediate results. These are clear candidates to be broken out into smaller functions. But, a conflict arises from the fact that they would each only be invoked at exactly one location. So, moving the tiny bits of code away from their only invocation point has mixed results on the readability of the larger function. It becomes more readable because it is composed of only short, descriptive function names, but less readable because deeper understanding of the intermediate steps requires disjointly bouncing around the code looking for the internals of the smaller functions.

The compromise I have often found is to reformat the intermediate steps in the form of control blocks that resemble a function definitions. The pseudocode below is not a great example because, to keep it brief, the control flow is so simple that it could have been just a chain of method calls on anonymous return values.

        AwesomenessT largerFunction(Foo1 foo1, Foo2 foo2)
        {
            // state the purpose of step1
            ResultT1 result1; // inline ResultT1 step1(Foo1 foo)
            {
                Bar bar = barFromFoo1(foo);
                Baz baz = bar.makeBaz();
                result1 = baz.awesome(); // return baz.awesome();
            }  // bar and baz no longer require consideration

            // state the purpose of step2
            ResultT2 result2; // inline ResultT2 step2(Foo2 foo)
            {
                Bar bar = barFromFoo2(foo); // second bar's lifetime does not overlap with the 1st
                result2 = bar.awesome(); // return bar.awesome();
            }

            return result1.howAwesome(result2);
        }

I make a point to call out out that the temp objects are scope-blocked to the minimum necessary lifetimes primarily because doing so reduces the amount of mental register space required for my brain to understand the larger function. When I see that the first bar and baz go out of existence just a few lines after they come into existence, I know I can discard them from short term memory when parsing the rest of the function. I don't get confused by the second bar. And, I don't have to check the correctness of the whole function with regards to each intermediate value.

<comment><USER3> What if I want to test some part of the function in isolation? At my current job I have to maintain a huge and old ASP.NET project that is full of these "god-functions". They're written in the style that Carmack describes, and I have methods that span more than 1k lines of code. Instead of breaking the function down to many smaller functions, they instead chose this inline approach and actually now we are at the point where we have battle-tested logic scattered across all of these huge functions but we need to use bits and pieces of them in the development of the new product.

Now I have to spend days and possibly weeks refactoring dozens of functions and breaking them apart in to managable services so we can not only use them, but also extend and test them.

I'm afraid what Carmack was talking about was meant to be taken with a grain of salt and not applied as a "General Rule" but people will anyway after reading it.

<comment><USER4> Perhaps it suggests our way of testing needs to change? A while back I wrote a post describing some experiences using white-box rather than black-box testing: [http://web.archive.org/web/20140404001537/http://akkartik.na...](http://web.archive.org/web/20140404001537/http://akkartik.name/post/tracing- tests) [1]. Rather than call a function with some inputs and check the output, I'd call a function and check the log it emitted. The advantage I discovered was that it let me write fine-grained unit tests without having to make lots of different fine-grained function calls in my tests (they could all call the same top-level function), making the code easier to radically refactor. No need to change a bunch of tests every time I modify a function's signature.

This approach of raising the bar for introducing functions might do well with my "trace tests". I'm going to try it.

[1] Sorry, I've temporarily turned off my site while we wait for clarity on shellsock.

<comment><USER5> How brittle are those tests though?

I've had to change an implementation that was tested with the moral equivalent to log statements, and it was pretty miserable. The tests were strongly tied to implementation details. When I preserved the real semantics of the function as far as the outside system cared, the tests broke and it was hard to understand why. Obviously when you break a test you really need to be sure that the test was kind of wrong and this was pretty burdensome.

<comment><USER4> I tried to address that in the post, but it's easy to miss and not very clear:

 _"..trace tests should verify domain-specific knowledge rather than implementation details.."_

\--

More generally, I would argue that there's always a tension in designing tests, you have to make them brittle to _something_. When we write lots of unit tests they're brittle to the precise function boundaries we happen to decompose the program into. As a result we tend to not move the boundaries around too much once our programs are written, rationalizing that they're not implementation details. My goal was explicitly to make it easy to reorganize the code, because in my experience no large codebase has ever gotten the boundaries right on the first try.

</comment></comment></comment></comment></comment><comment><USER6> I might be alone on this, but whenever I read things by John Carmack I get a vague sense that he doesn't really get object oriented programming. He always has a lot of interesting things to say, but it also kinda reads like a C guy trying to code in C++. I'm glad his thinking keeps evolving and he's not dogmatic about anything. I'd honestly love to hear his thoughts on C++11

"The function that is least likely to cause a problem is one that doesn't exist, which is the benefit of inlining it."

That's the equivalent of saying "the faster you drive the safer you are b/c you're spending less time in danger"

You'll just end up with larger monster functions that are harder to manage. "Method C" will always be a disaster for code organization b/c your commented off "MinorFunctions" will start to bleed into each other when the interface isn't well defined.

" For instance, having one check in the player think code for health <= 0 && !killed is almost certain to spawn less bugs than having KillPlayer() called in 20 different places"

I don't completely get his example, but I see what he's saying about state and bugs that arise from that. You call a method 20 times and it has an non obvious assumption about state that can crop up at a later point - and it can be hard to track down. However the flip side is that when you do track it down, you will fix several bugs you didn't even know about.

The alternative of rewriting or reengineering the same solution each time is simply awful and you'll screw up way more often

<comment><USER7> >> I might be alone on this, but whenever I read things by John Carmack I get a vague sense that he doesn't really get object oriented programming.

I'm starting to think object oriented programming is a bit over rated. It's hard to express why exactly, but I'm finding plain functions that operate on data can be clearer, less complicated, and more efficient than methods. Blasphemous as it may seem, a switch statement does the equivalent of simple polymorphism and can be kept inline.

<comment><USER6> You clearly don't work on a large code base =)

Most programming concepts are really about code organization and not expressiveness or the ability to express an algorithm clearly.

Object oriented programming only really starts to make sense when you are working on something that will take thousands of man-hours. If you are working alone, or on a small project is can be completely irrelevant.

The work flow you are describing is what MATLAB guys do. It's an absolute nightmare once the project gets too large. It is however very fast an flexible for prototyping.

<comment><USER8> Big things like say, the linux kernel? Which is not OO and is better off for it?

<comment> FLUX-YOU Ultimately our biases towards where the paradigms belong are a result of how the history has developed so far.

But hopefully we've learned that the guy selling OOP as the answer to everything is full of shit

<comment><USER9> _" But hopefully we've learned that the guy selling OOP as the answer to everything is full of shit"_

Replace OOP in your statement with "anything" and I'd say you're spot-on.

</comment></comment></comment></comment></comment></comment><comment><USER10> Haha, I like this quote: "That was a cold-sweat moment for me. After all of my harping about latency and responsiveness, I almost shipped a title with a completely unnecessary frame of latency."

<comment><USER11> A good insight into his mindset and way of seeing things.

</comment></comment><comment><USER12> I'm not a professional programmer and I rarely work with large code bases. So the fact that my code has drifted steadily over the years towards the large- main-function I thought was a factor of several things, first being my general amateurism. I still think that, but there are definitely other reasons too: I now use more expressive languages (Python instead of C) and more expressive idioms within those languages (list comprehensions instead of while loops) and more expressive structures/libraries (NumPy instead of lists of structures), so I can afford to put more in one spot. I also write smaller but more numerous programs.

But there are very real advantages. I learned through game programming and still do some for fun and I absolutely prefer having a main loop that puts its fingers into all the components of the game than to have a main loop which delegates everything to mysterious entity.update()-style functions. The lack of architecture allows me to structure the logic of the game more clearly for exactly the reasons Carmack outlines. Everything is sequenced - what has already happened in the frame can be seen by scrolling up a bit instead of digging through a half-dozen files.

But the real win here is for the beginner programmer. I strongly dislike the trend these days towards programming education being done in a "fill in the blanks" manner where the student takes an existing framework and writes a number of functions. The problem is that the student rarely has any idea what the framework is doing. I would rather not have beginners write games by make on_draw(), on_tick(), etc. functions but much rather have them write a for loop and have to call gfx_library_init() at program start and gfx_library_swap_buffers() at the end of a frame. That way they can say "The program starts here and steps through these lines and then exits here" versus having magic frameworks do the work for them. There is plenty of magic done these days behind the scenes for any beginner, but it is too much to have a completely opaque flow-control.

<comment><USER4> I particularly liked your last paragraph about beginner programmers, and I want to strengthen it. Abstraction is not just a drag on learning programming, it's also a drag on learning new codebases, even if you're already fairly experienced.

Abstraction is good for people experienced with a codebase, but as codebases grow larger and more complex that usually means the first few people, because newcomers are rarely able to attain the same grasp of the big picture.

This suggests that authors of say open source projects who want to gain more collaborators might want to go against their instincts for abstraction.

(This thought crystallized for me after conversations on HN in the past couple of weeks: [https://news.ycombinator.com/item?id=8308881](https://news.ycombinator.com/item?id=8308881) and [https://news.ycombinator.com/item?id=8327008](https://news.ycombinator.com/item?id=8327008))

<comment><USER13> The key difference is that those who built the abstraction understand exactly what it abstracts, and thus what its capabilities and limitations are. Those who didn't, don't get quite the same picture.

I'm not a fan of excessive abstraction either - the main thing I use it for is to reduce code duplication, which IMHO is one of the real benefits. Code that contains lots of functions-called-once or classes-used-once feels like a terribly inefficient and obfuscated way to do something, and far less straightforward than it could be.

The whole "abstraction is good because it allows us to build large complex systems" notion is all too common in beginning courses in programming/software engineering architecture, and it tends to make people think that large complex systems are also good. Thus the feeling that somehow all software should be large and complex, and the resulting architecture-astronautism and disturbingly inefficient software. I completely disagree - abstraction should be taught as being a necessary evil for managing complexity, for use only when that complexity is actually justified and cannot be simplified further. Abstraction hides complexity but does not eliminate it; in fact it could be said that it probably adds to it. Code hidden by abstraction is still code that gets executed, consumes resources, and could contain bugs.

</comment></comment></comment><comment><USER14> If anyone other than Carmack wrote this, I doubt it would be so well received so I'm glad he did.

We all have our own programming dogma that we love and defend religiously, but we should never stop asking if our code is truthfully, objectively, clear and easy to read, prone to bugs and/or runs efficiently. "Best practices" can get you 80% of the way there, but a developer should never stop questioning the quality of their code, even if it contradicts the sacred rules.

<comment><USER15> Would that apply to any craft?

</comment></comment><comment><USER16> Back when I was writing real-time signal processing code, I spent quite a bit of time refactoring code from variations of styles A and B to style C. The problem Carmack talks about is even worse when some of those subroutines were in separate source files. Over the course of my refactorings, I was able to re-arrange and combine functionality in ways that were not possible with the discrete functions. I was able to pull operations out of inner loops that repeatedly and expensively calculated the same values. I found and fixed all sorts of actual or potential bugs in doing this. The original code was extra hairy, though, because it was written for DSPs, not general-purpose microprocessors.

As a side note, the original code contained large numbers of manual loop unrolling optimizations like noted in the email. I actually saw a performance increase from removing them. Same in some cases for manually inlining the function calls. From what I could tell, writing simpler, inline code made the optimizer much more efficient.

<comment><USER17> Wouldn't in-lining make unit testing more difficult?

Admittedly I am not a very experienced programmer, but I thought the general line of thought with regards to making your program easier to test would be that each function should do as little as possible.

<comment><USER18> Yes it would, but Carmack is advocating the inlining of functions that deal with game state. These tend to be kinda hard to test in isolation anyway. But he does also advocate keeping small helper functions pure.

</comment></comment></comment><comment><USER19> There's an interesting game programmer problem here, that is somewhat alien to a coder like me who grew up on the web. Where for a web coder, statelessness is the default, and we have to work to recover and recreate state between 'frames', game coders live in the run loop - and so the assumption is that you have a repository of persistent global state to act on each frame.

Having noticed that he has a problem when multiple functions are all interacting with that same shared global state, it's kind of amusing that Carmack's reaction is to reduce the number of functions, rather than remove the global state.

<comment><USER20> At its core the problem game programmers run into is that game state is very globalized with a lot of dependency overlap. You can push around the data into different containers and declare dogmatic methods of access, but you always wind up with the same problems: The animation state depends on the physics. The rendering depends on the animation state. The physics of a local entity depend on its collision with the rest of the world. The results of physics depend on which things collided first. And so on and so forth.

And so games live within this environment of confusion over which things happen when. At every point there are a few defensive tools - queue up actions in a buffer, poll values instead of copying them, etc. - but the overall management of these concurrent, overlapping systems remains a challenging task lacking in silver bullets.

</comment></comment><comment><USER21> The following alternative style (vs. the 3 presented by Carmack) is one that I find very easy to read.

      algorithm() {
        do_small_thing_one();
        do_small_thing_two();
        do_small_thing_three();
        ...
        do_small_thing_X();
      }

Advantages over Carmack's Style C:

1\. Substitutes comments for accurate and specific function names. Why better? Because comments can get out of sync with the code.

2\. You can quickly see the sub-steps of the algorithm, rather than reading a multi-page-long giant function with a ton of comments.

When using this style, the inner functions are not visible outside of that source file (you can arrange this depending on your programming language). Then it's easy to make sure they are only called once within the source file, or only called appropriately.

That's because I agree with Carmack that functions called from lots of unrelated places are a terrible thing.

(Edited for clarity after people pointed out that it seemed like I was just advocating for Carmack's style A or B.)

<comment><USER22> That is option A and B. I think the entire article is describing the down sides of that.

You can't see if you a repeating the same stuff in multiple small things.

<comment><USER21> I guess this kind of got lost in my comment, but the point is that these functions are never called from anywhere else.

You achieve that by not exposing them in header files.

<comment><USER23> If they aren't called from anywhere else and they're only called once (in the parent), it might be better to inline them.

Doing so goes against the urge to decompose as much as possible but it'd make the code easier to follow for the next guy. "What does do_small_thing_X do?"

Even when the next guy is you, a year from now. Do you _really_ remember what do_small_thing_X does?

<comment><USER21> Yes, I do remember. If the function name isn't sufficient, you need a different decomposition of the problem.

Another advantage of doing it my way is that you can put multiple comments inside those "small" functions if you need to. So you get two levels of decomposition. That really helps if your overall algorithm is broken into smaller parts that still need some explanation.

</comment></comment></comment></comment></comment><comment><USER24> A few questions: Are there any good examples of code written in this style (e.g. by Carmack or Blow)? When I tried this style, I would frequently end up with 800+ line functions: is this what the code is supposed to look like in the end, or should I be refactoring earlier? When I do end up refactoring, it's often hard to switch to a functional style. There are complex dependencies between the different "minor" functions, and the easiest route forward seems to be to replace the function with a class: minor functions become methods, and the function-level local variables become instance variables, etc. Also, this is a small issue, but how do you deal with minor functions that "return" variables? I typically wrap the minor functions in brackets, and I declare the "returned" values as local variables right before opening bracket, but it looks strange.

</comment><comment><USER25> > "The function that is least likely to cause a problem is one that doesn't > exist, which is the benefit of inlining it."

That statement (at least taken in isolation) is false. Inlining it means that _you 're still executing the exact same code_. If it had problems as a function, it still has problems when inlined.

But that isn't the problem that Carmack is trying to address. He's concerned about bugs caused by lack of programmer comprehension of the code's role in the larger function. It's a valid concern. But inlining it makes it harder to find problems in the details of what the inlined function does (or even to realize that that's where the problem is, or maybe even to realize that there's a problem at all).

All styles help with some problems and make others worse. The answer isn't a style, it's good taste and experience to know when to use which style.

<comment><USER26> _Inlining it means that you 're still executing the exact same code. If it had problems as a function, it still has problems when inlined._

But if it's inlined, it's no longer a function. ;)

What he's saying here is that the function itself was fine and free of bugs but that there is a problem for the programmer. The programmer's understanding and expectation of what the function does isn't in that it affects state in a way the programmer didn't know or expect. What the function does becomes much more obvious and controllable when you inline the function's body.

</comment></comment><comment><USER27> I'm assuming this was posted because it was brought up during Jonathan Blow's talk last night: [http://www.twitch.tv/naysayer88/b/572153991](http://www.twitch.tv/naysayer88/b/572153991) (which have been interesting, (and Twitch is a great format for these))

</comment><comment><USER4> An aside on tool interactions: For the past year or so I've been using a new way to do syntax highlighting[1][2] that works _really well_ for highlighting the dataflow in large functions (whether well or poorly written): [http://i.imgur.com/EmFMTtv.png](http://i.imgur.com/EmFMTtv.png)

[1] [https://medium.com/@evnbr/coding-in- color-3a6db2743a1e](https://medium.com/@evnbr/coding-in-color-3a6db2743a1e)

[2] [http://www.reddit.com/r/programming/comments/1w76um/coding_i...](http://www.reddit.com/r/programming/comments/1w76um/coding_in_color/cezpios)

<comment><USER28> Great idea, so simple yet no IDE provide this feature out of the box.

<comment><USER29> KDevelop (specifically Kate) does this.

</comment></comment></comment><comment><USER30> The Saab Gripen aircraft that is mentioned did crash anyway (in its first flight show over Stockholm 1993 [http://en.wikipedia.org/wiki/Accidents_and_incidents_involvi...](http://en.wikipedia.org/wiki/Accidents_and_incidents_involving_the_JAS_39_Gripen)) in spite of that specially crafted fly-by-wire flight software...

<comment><USER30> You're right, it wasn't the software as such (more like the design of the system).

I just read more about PIO and it's funny, it reminds me of a short story I read a long long time ago, written by Arthur C Clarke, I remember the scene in it where a pilot is remote controlling his big space ship or plane of some kind, while standing on the ground. But because the remote is going through a satellite, there is a feed back delay, say 1 second or so. So when he tries to compensate for a wrong turn, a flavor of PIO is induced and the ship crashes. Think that particular story was written in the 40's, good foresight of Mr. Clarke.

<comment><USER31> I like Clarke also, but this is less an instance of good foresight on his part than it is an understanding of feedback control theory. Control systems analysis advanced quite a bit in WW2 and by the time that story was written, the issues caused by low control bandwidth were probably well known.

</comment></comment></comment><comment><USER32> I found the functional programming (in C++) advice post linked from the referenced post a much more interesting read. [http://gamasutra.com/view/news/169296/Indepth_Functional_pro...](http://gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php)

"Avoid globals" is a fairly common (and good) truism for programmers of all stripes. But casting it in light of the central (and easily digestible) tenet of functional programming makes it much more approachable. Smart (but sometimes insufferably pompous ) proponents of functional programming should take notes.

</comment><comment><USER33> Steve McConnell's classic "Code Complete: A Practical Handbook of Software Construction" cites a number of studies of real systems from the 1970s and 1980s with some surprising results. Some studies showed that function size inversely correlated with bug counts; as functions increased towards 200 LOC, the bug count decreased. Similar, another showed that shorter functions had more bugs per LOC and _reduced_ comprehension for programmers new to the system. Another study showed that function complexity was correlated with bug count, but size alone wasn't.

</comment><comment><USER34> There is an interesting parallel between Mr Carmack's "inlining" observations and one of the sessions I went to at Strange Loop this year. Jonathan Edwards was trying to beat back "callback hell" (i.e. unpredictable execution order leading to unpredictable side effects) by radically simplifying the control flow of his programs and keeping the execution model dirt-simple. Both would appear to argue that it's best to arrange heavily stateful code in a simple linear sequence, and use a top-down execution model, so that stateful effects are clear and easy to predict.

That being said, I've seen procedures that followed this sort of approach that were thousands of lines long. Even if we could have cut down on the ridiculous number of conditionals in that code, most of the state at that scale asymptotically approaches an undifferentiated mass of global variables. The result is testable and maintainable only via heroic effort. There have got to be limits to this kind of approach. (For Mr Edwards the solution was to break the whole thing up into a sequence of composable views, or lenses, with the interface between each stage being well-defined.)

I wonder to what extent Mr Carmack's pivot to pure functions is simply an acknowledgement that there were much better ways to refactor the code than the mess of one-timer procedures that probably seemed like a good idea the first time through...

</comment><comment><USER35> Seems like everyone misreading the intent of the post. He is NOT advocating inlining code in this post. He is suggesting that FP is better at solving the same problems in a more sensible way.

The email was written in 2007. In there, he advocates the inlining of single- use functions into god functions as it reduces the risk of these functions being opted into other routines, especially when they all deal with shared mutable data.

Single-use functions are explicitly singled out in his email; he mentions that he does not encourage duplicating code to avoid functions.

| "In almost all cases, code duplication is a greater evil than whatever second order problems arise from functions being called in different circumstances, so I would rarely advocate duplicating code to avoid a function"

The blurb at the front indicates the intent of his post. Since then he has favoured a functional-programming approach - don't inline your functions, but avoid making your functions rely on mutable/larger scope states. Pass in everything that is needed by the function through parameters. Avoid functions with side-effects, encourage idempotence. That way, reusing the function does not lead to unintentional side-effects.

He also mentions that should you still decide to inline, " you should be made constantly aware of the full horror of what you are doing.".

A lot of things change within a decade. =)

</comment><comment><USER36> _it is often better to go ahead and do an operation, then choose to inhibit or ignore some or all of the results, than try to conditionally perform the operation._

 _The way we have traditionally measured performance and optimized our games encouraged a lot of conditional operations [...] This gives better demo timing numbers, but a huge amount of bugs are generated because skipping the expensive operation also usually skips some other state updating that turns out to be needed elsewhere._

 _Now that we are firmly decided on a 60hz game, worst case performance is more important than average case performance, so highly variable performance should be looked down on even more._

Two words: Battery life. In case of mobile devices, this is not sound advice.

<comment><USER37> Is this covered by the update in John's introduction?

      To make things more complicated, the .do always, then
      inhibit or ignore. strategy, while a very good idea for
      high reliability systems, is less appropriate in power and
      thermal constrained environments like mobile.

Or do I misunderstand your objection?

<comment><USER36> No, you're completely right - I only skimmed the addendum. In fact, I actually only skipped that particular paragraph - Murphy's law strikes again :(

It's just that two days ago, I had to deal with exactly that issue, so it was fresh on my mind while reading the article...

<comment><USER38> Looks like Carmack was right then. Conditional paragraph execution does lead to extra bugs :)

</comment></comment></comment></comment><comment><USER39> After reading this, I feel a lot better about the huge main() function I wrote for htop. I've always thought about splitting it into many functions, but somehow keeping it all flowing in sequence just made more sense.

</comment><comment><USER40> I never wrote too many C or C++ on the desktop, but often ended up refactoring my embedded code from one style to an other. After a while I realized this is simply my way of understanding the code better, and making sure I haven't missed anything. The direction (inlining or breaking things to functions) almost doesn't matter. What matters is working with the code. It's not so strange If you think about it, designers understand things by sketching and taking notes, that's why you see designers run around with their moleskins.

</comment><comment><USER41> Is anyone else reminded of Facebook's Flux?

[http://www.infoq.com/news/2014/05/facebook-mvc- flux](http://www.infoq.com/news/2014/05/facebook-mvc-flux)

</comment><comment><USER42> > If a function is only called from a single place, consider inlining it.

Funny because it's backward. If a code is duplicated, consider to make a function if the pieces of code are the same _semantically_. (Two pieces of code which are the same at a given time can diverge over time and you don't want to miss that. Only analyzing the sense of what you're doing (=semantic) gives you the answer.)

Never add fancy things (like adding a function which is not a function) in your code because code is not fancy, it causes bugs.

> If a function is called from multiple places, see if it is possible to > arrange for the work to be done in a single place, perhaps with flags, and > inline that.

Well yeah, fix the semantic if it needs to else do nothing.

> If there are multiple versions of a function, consider making a single > function with more, possibly defaulted, parameters.

Well yeah, fix the semantic if it needs to else do nothing.

>Minimize control flow complexity and "area under ifs", favoring consistent execution paths and times over "optimally" avoiding unnecessary work.

The right thing to do is to _never_ optimize unless it's to slow and you've identified the first bottleneck. "Never optimize" means: write the naive code correctly (without performance aberation like adding element in an array).

> To sum up:

Stop fancy. Stop optimization. Stop thinking about code syntactically (=the succession of operation gives the good result). Think constantly about your code semantically.

</comment><comment><USER43> I don't have a great deal of experience tuning code, so would someone be able to explain how inlining is related to mutation of state? I'm not John Carmack or Brian O'Sullivan, and I'm not sure if I understand how purity would make things better.

We do inline our code in Haskell sometimes, but usually the real gains (in my limited experience, with numerics code) are to be had by unboxing, FWIW.

<comment><USER44> Inlining doesn't always work in side-effecting languages. E.g. only if `f` is pure are the following two fragments identical.

        let a = f () in a + a

        f () + f ()

<comment><USER45> If the compiler has the full source of f() available at compilation time, it knows whether it can convert between those two. (Though not all compilers are good at knowing the memory-usage implications of doing that kind of commoning operation.)

(And, for that matter, whether it can convert that to "f()<<1".)

<comment><USER46> Does `shl eax 1` really outperform `add eax eax`? Although i guess that's a question for `-mtune` to decide.

<comment><USER47> SHL EAX,1 and ADD EAX,EAX are the same, time wise. The only difference is that the A flag (auxiliary carry [1]) is undefined for SHL and defined for ADD. SHL EAX,n may be faster than n repeats of ADD EAX,EAX, but there are other ways to do quick multiplication by powers of 2 though.

[1] The auxiliary carry reflects a borrow from bit 4 to bit 3, or a carry from bit 3 to bit 4. It's used for BCD [2] arithmetic, and there is is no direct way to test for it.

[2] Binary Coded Decimal

</comment></comment></comment></comment></comment><comment><USER48> > If something is going to be done once per frame, there is some value to > having it happen in the outermost part of the frame loop, rather than buried > deep inside some chain of functions that may wind up getting skipped for > some reason

> I do believe that there is real value in pursuing functional programming, > but it would be irresponsible to exhort everyone to abandon their C++ > compilers and start coding in Lisp, Haskell, or, to be blunt, any other > fringe language.

"Here, let me dismiss functional programming, and by the way OCaml and other 'non-pure' functional languages don't exist, and functional programming languages aren't useful for anything 'real' so you should do your functional programming in C, and also you may want to dump everything in one long-ass function because I don't like deep stacks".

He's just rationalizing C traditions.

</comment><comment><USER49> I believe in both functional and encapsulated patterns. It all boils down to scope of the task at hand. There is a certain kind of beauty in programming in a pattern than can compliant to a particular interface and a pattern that's efficient and scoped to the result required. Inline is a great way to encapsulate in a functional way.

</comment><comment><USER50> Seems like a big argument against type C is that it would be more difficult to unit test the code. The nice thing about A/B (which are essentially the same to me) is that each subroutine becomes an easier target for unit testing.

</comment><comment><USER51> Does anyone write in style C and then refactor to style A/B? That gives you all the benefits of both styles..

<comment><USER52> No, the problem with style A and B is that smallFunction() might have only been correct under the context of it executing inside largeFunctionA(). IMO this risk is actually increasing even more if it originates from a refactoring from style C, since you didn't design smallFunction() from bottom up considering all possible use cases, you most likely just highlighted a random block in largeFunctionA() because it was getting too big and clicked "extract method" in your IDE.

Imagine two months later someone writing largeFunctionB() is browsing around the code and finds smallFunction(), thinking it will do the job he requires but actually it has a hidden bug that was never triggered under the context of it executing in largeFunctionA or under the limited input range that largeFunctionA was using.

See in particular this paragraph from the article:

        Besides awareness of the actual code being executed, inlining functions also
        has the benefit of not making it possible to call the function from other
        places. That sounds ridiculous, but there is a point to it. As a codebase grows
        over years of use, there will be lots of opportunities to take a shortcut and
        just call a function that does only the work you think needs to be done. There
         might be a FullUpdate() function that calls PartialUpdateA(), and
         PartialUpdateB(), but in some particular case you may realize (or think) that
         you only need to do PartialUpdateB(), and you are being efficient by avoiding
         the other work. Lots and lots of bugs stem from this. Most bugs are a result
         of the execution state not being exactly what you think it is.

<comment><USER51> Oh yeah I see what you mean. Do you think all smallFunction()s should be generic/reusable?

Seems like it's the fault of the second developer for using the smallFunction() without understanding what it does.

</comment></comment></comment><comment><USER53> > do always, then inhibit or ignore

Explain?

<comment><USER54> Rather than conditionally execute code (to avoid performing an unnecessary expensive operation) always execute the code, then discard the result if it is unneeded. The idea being that the performance gained by avoiding the unnecessary operation is not worth the complexity added.

<comment><USER55> As a minor note, conditional checks can have significant performance impacts if you don't consistently handle the conditional.

As an example performing an operation every other frame can cause your CPU to thrash due to always taking the wrong path. (I of course am oversimplifying and OOO CPUs are quite complex)

</comment></comment></comment><comment><USER56> We'll all be programming in Haskell soon enough

</comment><comment><USER57> Is this arguing that developers shy away from the forced OOP, and Patterns, instead relying on simple to read, step by step, functions?

One of my biggest gripe about OO programming was that you had no idea what the other components were doing unless you investigated each component directly. Sometimes the dependencies and the chain would get so large and complicated, you'd spend more time figuring out how to wrap your head around the whole thing than doing things that result in direct business benefit.

But every interview you go to will tell you otherwise, inflating technical debt is a great thing to keep managers keep their job and for sales team to boast about six digit LOC = Obviously state of the art.

</comment><comment><USER57> How would you explain the benefits of functional programming with an employer who absolutely refuses to believe that OOP is overvalued? Lot of job requirements will say experience with OOP and then be asked to recite from memory what Singleton patterns look like or draw a Factory pattern as a yardstick of developer efficiency.

<comment><USER58> You can do a prototype, and try to convince like that. Or just do your own thing and don't mention any paradigm labels.

Or you can look for a more enlightened employer. Mine is hiring, for example.

<comment><USER59> What sort of functional programming jobs do they have available and in what languages?

<comment><USER58> Google is pretty limited in the functional languages as a main tool for your job category. It's easy enough to sneak in functional things here and there, though.

Standard Chartered, where I worked before doing FP, is looking for Haskellers every now and then. Contact me (see profile) for some more info. Citrix is still using OCaml in Cambridge, UK, as far as I know. Not as much Haskell any more as they used to.</comment></comment></comment></comment>


Oracle and the End of Programming as We Know It - <AUTHOR> http://www.drdobbs.com/jvm/232901227 <comment><USER2> "You might recall that the Lotus v. Borland suit (1990) originally resulted in a ruling affirming the copyrightability of a menu hierarchy."

Well those resources were certainly well spent, as the current dominance of these two companies indicates.

<comment><USER3> Here's to the pattern continuing in the case of Oracle. They are a blight.

<comment><USER4> I'd be a tad bit concerned about a patent troll obtaining Oracle's IP if they ever go down, though.

Oh, the joy of having to choose the lesser of two evils.

<comment><USER5> Let's worry about the first, "real" evil right now, rather than a hypothetical one in the future.

<comment><USER6> Or, take a cue from Stallman and worry about both.

</comment></comment></comment></comment></comment><comment><USER7> API copyrights is a terrible idea that would promote vendor lock in and block interoperability. It would be a disaster for companies writing to a small niche API or who lost access to a flaky vendor's approach to their problem.

This wouldn't really be so bad as far as programming languages go. AT&T already cross-licensed the C and UNIX ecosystem to the University Of California's open source BSD project and you could inherit their license. Java VMs and compilers could be distributed under GPL (and Android would be a better platform under GPL with less fragmentation). Python, Ruby, Perl, and the like license themselves to the world freely and easily.

I can't think of any really major programming languages that would be harshly damaged. C# is largely effectively proprietary because Microsoft rattles the patent sabre at non-Windows implementations. I don't know what the status of Javascript might be, but the standard API is fairly tiny.

Of course, no unfree language or API in the future would ever gain traction without a monopoly platform provider of some kind to require it and still it would never spread beyond that platform. Users would be too terrified of vendor lock-in.

Things like Wine would need to take development overseas, but the need for them is shrinking along with the use of proprietary platform binaries.

<comment><USER8> _> C# is largely effectively proprietary because Microsoft rattles the patent sabre at non-Windows implementations._

C# is an open standard, submitted to ISO and ECMA (at least for versions < latest). MS also signed a legally binding patent pledge to not sue anyone for the language and runtime IIRC.

There exist at least two C# open source implementations that I know of, Mono and some GNU project.

<comment><USER9> The runtime is a hodgepodge of standardised bits and Microsoft extensions though.

<comment><USER5> That's my worry. They could always find some technicality to sue over.

</comment></comment></comment></comment><comment><USER10> IT lawyer and digital liberties' advocate Carlo Piana mentions at [https://plus.google.com/u/0/115445134403759043734/posts/coVx...](https://plus.google.com/u/0/115445134403759043734/posts/coVxN3TDcmj) that such API copyrightability has been largely denied by the SAS v. WPL case that came out today (nice coincidence !) : "[...] neither the functionality of a computer program nor the programming language and the format of data files used in a computer program in order to exploit certain of its functions constitute a form of expression of that program and, as such, [they] are not protected by copyright in computer programs" - [http://curia.europa.eu/juris/document/document.jsf?text=&...](http://curia.europa.eu/juris/document/document.jsf?text=&docid=122362&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=115060)

<comment><USER11> Fortunately that happens in Europe, but that also means the ruling doesn't apply abroad. With US being very keen on trying to apply local laws to companies/people in other countries... We'll see what happens.

</comment></comment><comment><USER12> A ruling could also go along the line that Sun / Oracle might have a copyright to the API but Google was free to use them.

In any case I guess we will see appeals from either side.

The author mixed in C# and VB in Mono - while MS has in the past applied and received patents on their APIs they have explicitly provided this use. This might be the way forward - company who created those APIs keeps control but let everyone use them.

Nevertheless, IMHO if I provide a solution like the Java language into the public domain / license it under GNU, parts like APIs become elements of speech - otherwise the whole thing becomes rather philosophical (and solved far more than 100 years ago by Hegel - 100% information is not possible).

</comment><comment><USER13> Actually, if APIs/languages turned out to be copyrightable, IBM might just sue Oracle for using SQL and other related APIs. Oracle are even trying to invalidate the defence of implicit acceptance (same situation with both Sun and IBM).

Really stupid move on Oracle's part.

<comment><USER14> That would be actually very good for Oracle. Oracle would pay a certain amount of money to IBM in exchange for licensing these APIs. As they say, business is IBM's middle name so it's not like they're going to make this a political question, they will happily take the money. Suddenly, the barrier to enter to relational database market is a lot higher, and PostgreSQL (and MySQL copies without a license from Oracle) are illegal. How is this a stupid move on Oracle's part?

<comment><USER15> I guess it would speed up nosql adoption quite a bit if things would actually get that far.

<comment><USER16> NoSQL isn't a replacement for SQL. It's a separate technology.

<comment><USER15> Yes I understand that, but if SQL would become oracle expensive I think you will see a lot of companies/projects switching to one of the many nosql options that don't infringe IBM's patented API.

<comment><USER17> I don't think you understand. How can you switch from the one to the other if they're separate technologies? Going on foot is not a substitute for driving a car when we're talking about transporting 100 refrigerators from a port to a warehouse 300 km inland, it's only a substitute when we're talking about transporting a person less than a few kilometers and when time is of little importance.

That's not to say that there are no alternatives to relational databases or SQL, but the leap to 'oh then NoSQL will take over' doesn't make much sense.

<comment><USER15> Both are in the business of storing data that can later be retrieved again, so I don't think your analogy really holds in this case. Maybe you are thinking of one particular nosql solution but I think almost all projects could find an alternative to a database that uses SQL. That is not to say that it shouldn't be a relational database or that there's a one shoe fits all solution out there.

<comment><USER18> I think you would really struggle to find adequate replacements for relational databases in at least two areas: reporting and ad-hoc queries.

<comment><USER11> Mongodb has ad-hoc queries (not as simple as SQL, but still). Many engines can run huge aggregated queries (hadoop?)

But I think the problem is placed in the wrong place. If SQL the language/API is copyrighted, then isn't it easier produce a new API with the same functionality?)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> According to Groklaw, the jury will not decide whether copyright applies to APIs. The judge instructed them to assume it does, find whether there is a violation, and if so, the judge will decide whether APIs can be copyrighted at all. If they find no violation, he doesn't have to rule on the matter.

</comment><comment><USER20> I know it would be extremely traumatic to the entire Android ecosystem but I'd personally be happy if Google just shat out Java entirely and put their efforts into making Go the native tongue of Android.

<comment><USER21> Why?

<comment><USER20> Go is a cleaner, more elegant language that makes better use of memory.

</comment></comment></comment><comment><USER22> Good observation. I wonder what would happen if programming and selling software in the US suddenly becomes too dangerous to do. Would it impact the rest of the world?

<comment><USER23> I'd hope it'd help to further flame innovation in Europe and Asia. Crippling US innovation with onerous IP laws (like this might lead to) would probably lead short-term to a dip in global tech innovation (and a correlated rise in IP law expenditures :)) until money and talent moves elsewhere on the globe. One can hope.

On the other hand, the US has always been good at exporting copyright provisions and IP laws so worst case, we'll all be at the behest of rent- seekers like Oracle, etc.

</comment></comment><comment><USER24> >However, a silver lining could present itself: The jury could affirm that the APIs are copyrighted but that the syntax of the function signatures are a fair use exception.

Perhaps I'm missing something, but aren't APIs a documented bunch of function signatures and class hierarchies? According to the silver lining above, what's _not_ covered by the fair-use?

<comment><USER25> Hmm, maybe publishing the API in book form?

</comment></comment><comment><USER26> This is a sad situation. I don't want to name names, but the startup I am working at is being sued by a much bigger company for exactly the same thing. Copyright infringement over their APIs.

</comment><comment><USER27> One question is what will happen with Apache Harmony? From what I've read of the case, Apache have basically done the exact same thing that Google did, but Sun/Oracle never bothered to go after them. How will that project survive with the proverbial sword of Damocles hanging over it?

<comment><USER28> The Apache Harmony project has been discontinued.

<comment><USER27> Oh, you're right! I only wondered because of what I've been reading about the case, since it was mentioned a few times.

Though I guess the same question could be asked of GNU Classpath, which as far as I can see is still actively maintained.

</comment></comment></comment><comment><USER29> Any idea how much would this license that Google possibly needed may have cost? Or would it have been one of a kind?

<comment><USER30> The Sun CEO at the time claimed that they would have paid Google to use Java, the disagreement was who got to make decisions and neither side trusted the other to get it right (personally I think history has vindicated Google on this point).

<comment><USER25> Well, considering the success of Amazon's Android fork, I think that vindication is still pending.

And no matter who's been right - legally or business-wize - I find it seriously annoying to have two Javas.

<comment><USER30> Amazon use Dalvik don't they? Why not the JVM?

<comment><USER25> Because OpenJDK is GPL licensed, and I guess Amazon didn't want to open-source their code. BTW, Google doesn't want to open-source (or even let Apple look at) the Nexus Android code.

</comment></comment></comment></comment></comment><comment><USER25> I don't care who wins this case, but as a Java developer I hope that eventually Android will come into the Java fold, adhere to standards and run on an awsome, standard JVM. Imagine using all JVM languages, unmodified, on Android. Both Oracle and Google will gain from this, as well as the entire Java developer community.

(Side note: a ruling on API copyrights could have far reaching ramifications, some might be quite unfortunate, but it's important to make clear that Oracle did not start out trying to establish API copyrightability. They simply set out to nail Google for Android, and API copyright was simply a tool in their legal toolbox.)

<comment><USER27> You can run other JVM languages on Android today. The Android compiler take Java byte code and translates it to Dalvik byte code.

See here for Clojure: <http://dev.clojure.org/display/design/Android+Support>

"Works out of the box with 1.2.0+" -- other JVM languages should have a similar story.

<comment><USER31> That's not really fair, tbh, (and I'm a huge fan of Clojure). It's dog-slow on Android. I don't know the details, but I think it's has a lot to do with differences between Dalvik and Hotspot.

<comment><USER32> Clojure is currently significantly slower than Java in general, likely due to dynamic typing. See: [http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...](http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=clojure&lang2=java)

<comment><USER31> Right, but that's not terribly relevant to this thread. As I understand it the difference between Clojure on Dalvik and Java on Dalvik is much greater than Clojure on Hotspot and Java on Hotspot.</comment></comment></comment></comment></comment>


SpaceX reveals fully reusable, vertically landing rocket design [video] - <AUTHOR> http://www.spacex.com/assets/video/spacex-rtls-green.mp4

<comment><USER2> The "Uprising" lyrics are an inspired poke at the traditional space industry: "endless red tape to keep the truth confined... it's time the fat cats had a heart attack, you know that their time's coming to an end..."

<comment><USER3> This also happens to be a much cooler music video than the original.

</comment></comment><comment><USER4> How is carrying all that fuel used in landing up to space more efficient than, say, a parachute?

I'm assuming someone at Space X did at least some back of the napkin math, but color me skeptical.

<comment><USER5> They want their craft to be able to land on any surface. Two of their chief product values are modularity and versatility.

I toured SpaceX HQ just yesterday and saw this video (or some of it). The employee presenting said that landing on Mars w/ a parachute is not a good option. Powered landing makes their craft able to land on any surface.

This is a paraphrase; and I am not a rocket scientist, so don't quote me on this.

<comment><USER2> This is certainly part of it. The powered landing will give them precision control to touch down right on the launchpad instead of having to pick up the assets at sea, saving lots of time and money. But it also allows for a module to land on the Moon or Mars. Mars has an atmosphere, but only with about 1% the density of Earth's, so for vessels with this scale of mass, parachutes aren't much use, besides the issue once again of being able to position your landing spot precisely. Supposedly at every design step where it's applicable Elon has opted to make everything as ready for Mars as possible.

<comment><USER5> _Supposedly at every design step where it's applicable Elon has opted to make everything as ready for Mars as possible._

Absolutely correct. I got that vibe from all employees I listened to yesterday. The underlying motivation of the company is: to go to and colonize Mars. Everything they do before then is to gain credibility, survive, and fund R&D toward reaching their ultimate goal.

<comment><USER6> There's something more than slightly Heinlein about that company. I love it.

<comment><USER7> Elon wants to be the Man who sold the Moon. Or Mars, as the case may be. Don't blame him. I want to be that man too.

<comment><USER8> I was thinking Long Range Foundation, but that works too.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> I thought the whole reason NASA's shuttles jettisoned their rockets and large fuel tank was because getting that added weight in to space was prohibitive. How is it that they propose to get not only the entire rocket in to space but also enough fuel to provide a soft landing on re-entry of all 3 pieces? I realize rocket tech has come a long way since the Shuttle's design, but is it really that much further along?

I really do hope they can pull it off though!

<comment><USER10> Not an expert on this subject, but the landing phase requires much less fuel than take-off. You only need to slow the craft and during the final approach use fine grain thrusters to maintain control.

I do hope this is feasible.

<comment><USER11> It requires less fuel because air friction works with you during deceleration, not against you, and because, by the time you do the landing, the craft weighs a lot less, not because you only need to slow down.

I think the video left out a lot of the dull part of aero breaking, making it look as if all breaking was done on rocket power.

I do not see how this would be cheaper and safer than just using a disposable run-of-the-mill steel pipe as main engine (yes, that is exaggerating), but they must have done the math.

</comment></comment></comment><comment><USER12> In a recent interview, Elon Musk was saying how we wouldn't have airplane travel the way we have today if the airplanes wouldn't be reusable.

He was saying that to point out that this is how reusable rockets should revolutionize space travel, in a way just as big.

<comment><USER13> Hmm, well, but it's interesting that the US went down that road and built an unreliable "reusable" spacecraft that had a high failure rate and had be largely reconditioned at high expense after every flight. Meanwhile, the Russians are using an incrementally improved capsule design from the '60s that's simpler, cheaper, and safer.

I'm not saying that a true reusable speacecraft wouldn't be revolutionary. And maybe it's possible with '10s tech in a way that it wasn't in the '70s. But picking "reusable" as a goal in and of itself, rather than using metrics like reliability or cost per pound to orbit, seems like a dodgy business.

<comment><USER14> When it comes to spacecraft Fuel is cheap manpower is expensive.

The Americans built the first ever reusable spacecraft but they never really stuck with one design. Just about every shuttle was slightly different which resulted in slightly improved performance, reduced safety, and dramatically increased costs. They then kept using them well past the designed lifetime which once again radically increased the costs. All while flying them a minimum number of times each year.

<comment><USER15> How cheap is the fuel? Say, a space shuttle? I've heard a launch costs $450 million, but it doesn't say if it was fuel alone.

<comment><USER16> In U.S. dollars in the year 2000, it came to about $16 of fuel per pound of payload launched. We had a homework assignment to figure out that number in our propulsion class at the University of Washington.

Shocking. The rest of that $10k per pound is amortized launcher costs and operations. (If you include the initial R&D, it goes up to something like $50k per pound.)

The shuttle was a truly immoral launch vehicle.

<comment><USER17> That's incredible. You should do a blog post about that. It's really fascinating and I don't think is been published anywhere.

</comment></comment></comment></comment></comment></comment><comment><AUTHOR> The video gives the idea, but full details here:

[http://www.sfgate.com/cgi- bin/article.cgi?f=/n/a/2011/09/29/...](http://www.sfgate.com/cgi- bin/article.cgi?f=/n/a/2011/09/29/national/a161633D91.DTL&type=science)

<comment><USER18> I love this quote "Now we need to make sure that those simulations and reality agree, because generally when they don't reality wins."

<comment><USER19> Reminds me of one of my favorite Feynman quotes:

"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." — Richard P. Feynman, minority report on the Space Shuttle Challenger Accident ( <http://quotes.cat-v.org/science> )

</comment></comment></comment><comment><USER20> How did they manage to flip the second craft from it's reentry position (nosecone down) back around for landing?

Wouldn't carrying the extra fuel to slow the craft on reentry make this cost prohibitive, thus why most craft use parachutes or similar passive slowing devices?

<comment><USER21>
      > How did they manage to flip the second craft from it's reentry position [...]?

Apologies, I think I don't understand...

The video is a concept video, not a real-life recording.. it's CG. But you're asking about real-world physics. And everyone else is talking about it too, as if the video actually happened, even though it's just a CG animation.

I'm just really confused; sorry. Heh. I know I'm missing something obvious here -- figured I'd ask what it was, even though I look silly. :)

<comment><USER22> The video wouldn't have much point unless it was showing the design of how the rockets will actually work. Sure, the actual design and details of the rocket may be different in real life, but the basic idea of having the components soft-land back at HQ would be real.

</comment></comment></comment><comment><USER23> Wow, this seems almost as important to space travel practicality as the assembly line was for cars. To think where we (as people) were 100 years ago and to contemplate where we might be in the next 100 years... exciting times we live in.

</comment><comment><USER24> Youtube link...

<http://www.youtube.com/watch?v=p176UpWQOs4>

</comment><comment><USER25> Very awesome. Quite an amazing feat if they can vertically land a rocket on such a small target like that. Dig the Muse soundtrack too.

</comment><comment><USER26> To quote Steve Ballmer: "I've got four words for you: I LOVE THIS COMPANY!"

</comment><comment><USER27> Unfortunate music choices aside, the video was well done and clearly demonstrated the concept without narration or text.

</comment><comment><USER28> I'm hoping that the _materials_ are finally here to usher in the next generation of space vehicles, because this idea wasn't nearly as plausible back in the 60's.

</comment><comment><USER29> From SpaceX page:

"SpaceX CEO & CTO Elon Musk will discuss the future of human spaceflight in advance of his company's planned flight later this year to the International Space Station, the first private mission to ISS for NASA, at a National Press Club luncheon today at 1pm EST."

</comment><comment><USER30> I thought it was impossible (or highly impractical, mass-wise) to build a single-stage orbital rocket. Are there additional boosters this rocket is using?

<comment><USER6> It's not single stage. It's 2 stage and a capsule, just like regular Falcon 9.

</comment></comment><comment><USER31> I suspect this announcement has a lot to do with positioning SpaceX to compete with Bezos' Blue Origin on upcoming contracts. Blue Origin has been working in stealth mode exclusively on a reusable design, while SpaceX has focused on a conventional launch vehicle that they can market right now. Musk & Co. have had admirable success, but reusable systems are a whole different ballgame, and very little of their current hardware is likely to be applicable in that context.

</comment><comment><USER32> How would we react if one of the commercial missions goes wrong?

There must be a certain difference of standards, when a public organization kills people for science, and when a private company kills people for profit.

<comment><USER33> Actually, private companies were killing people for profits since always. The whole concept of corporations was iirc created because private people didn't want to be accountable for ships that sank and killed the sailors.

Even now, private companies killing people is nothing unusual. Think oil rigs, or airplanes. Sure - a spaceship exploding and killing the crew is quite spectacular, but when you build a company like SpaceX, you build it with the knowledge that something like this _will_ happen.

With every manned flight, you have the procedures in place for the catastrophic failure, and when it happens, you execute "Plan Red". Nobody is running around screaming. At least I'd like to think so :)

</comment></comment><comment><USER34> Are they going to land on a single torch? How?

</comment><comment><USER35> What did I just watch?

<comment><USER36> A reusable rocket concept with some magically fuel supply that seems to defy physics ;)

<comment><USER37> There's nothing magical about the fuel supply. In the past, people didn't try to bring rockets back down and land them on their tails because of the technical challenges, not because of fuel concerns.

It takes a lot less fuel to land than to take off for two reasons: wind resistance helps instead of hinders and so much fuel has already been burnt that there is a lot less weight to slow down than there was to accelerate on the way up.

<comment><USER6> Coming down, the empty fuel tank is basically an aluminium balloon.

</comment></comment></comment></comment><comment><USER38> Where are they hiding all the fuel?

Also, this isn't a design. It's a video. I have some video about a UN mission to colonize Alpha Centauri that went slightly awry (the mission that is, not the video).

<comment><USER39> Can you put that on youtube or something? Sounds interesting.

<comment><USER40> I'm pretty sure he's referring to _Sid Meier's Alpha Centauri_ , a classic awesome 90's video game <http://en.wikipedia.org/wiki/Sid_Meier%27s_Alpha_Centauri>

</comment></comment></comment><comment><USER41> I'm not sure I follow how this is supposed to be progress. This looks like NASA did _before_ the had real shuttles, and (though I'm not an aeronautical engineer) it seems really strange to me that they think launching and bringing down, not one, but _3_ different parts of a space vehicle safely and exactly where they want it... Sounds far fetched to me.

Virgin Galactic seems to have a much better design and plan - plus, they actually have a working spacecraft, spaceport, and they're selling tickets for the first flights in 2013 right now. SpaceX is a CG animation of a rehashed 30-year old design. Wanna know who my money's on?

<comment><USER42> I'll bite.

VG is putting tourists into sub-LEO. SpaceX is building rockets that can reach any orbit, carry many tons of payload and even send manned missions to the Moon or Mars.

When Musk started SpaceX he decided to use tried and true designs and instead focus on refining those designs for performance, safety and cost. He did so by moving the entire manufacturing chain in-house. Many would argue that he has achieved his goal.

Rockets (which usually have to be multi-stage) are more cost effective and more capable than the Shuttles. The Shuttles are too fuel hungry and too inflexible (in the configuration they settled on) to fly to the Moon or Mars (or even move beyond LEO). They are not "space planes", capable of zooming around space at will, they are Earth gliders with rockets attached.

I haven't read his rationale for the self-landing rocket stages, but I would guess it's about recovery costs. It's not cheap to track down and fish rockets stages out of the ocean. They also have to be completely rebuilt after their plunge into salt water. Heat damage is likely an issue as well. If keeping that amount of reserve fuel would not limit the rocket's main mission, it would undoubtedly save a lot of money in recovery and restoration costs.

It's progress because the Shuttle missions were a step in the wrong direction if the ultimate goal is to make space accessible. Well designed rockets can be more capable, just as safe (if not more so) and can operate at a fraction of the Shuttle program's cost.

<comment><USER43> "I haven't read his rationale for the self-landing rocket stages, but I would guess it's about recovery costs."

At the press club he mentioned that a $50m rocket might have 200k of fuel costs in it, so if you can reuse most of it, you are way ahead on cost.

</comment></comment></comment><comment><USER44> Well, the space shuttle's booster rockets were similarly reusable, don't see why this couldn't work in theory, except for the no parachutes trick. It's probably to make the video more dramatic.

I wonder what kind of maintenance cost those boosters had. They didn't have the same needs as the shuttle, it wasn't catastrophic if they broke on re- entry, but one did blow up during launch. It's probably important that the crew re-entry vehicle is small and so is easier to maintain than the shuttle was.

<comment><USER45> It's no parachute so that it can land on the moon or mars where there is no atmosphere, or very little atmosphere compared to earth.

I'm sure that the first few tries will use parachutes too because I'm not sure rocket science is far enough along at this point to do it without.</comment></comment>