Ask HN: Do you mostly program in a non-FP or non-OO style? Why? - open-source-ux Functional and object-oriented styles of programming dominate programming languages today. Are you using a language that has neither of these features? If so, what is the language and why do you use it?<p>Or are you using an FP or OOP language but rarely use the FP or OOP features? If so, why? <comment><AUTHOR> Primarily a Python and Go programmer.

OO: Only rarely, and only where it really makes sense. Most programs I work on are not complex enough to justify the overhead (boilerplate, cognitive).

FP: I use this more, but again, only when I can really justify the added cognitive overhead.

You'll notice the two references to cognitive overhead: I have adapted the "write for a 6th grade level" idiom into programming. I want as many people to be able to pick up the code and modify it as possibly can. I work with everything from interns to decades plus veterans, and my code must be grok- able by both. Pure FP tends to confuse interns, and veterans have a tendency to hate the layers and layers of indirection and abstraction OO brings into a program.

Normal and boring old "an imperative main method with functions" tends to be the least offensive and most understandable to all parties. Compromise r fun.

<comment><USER2> Programming for the lowest common denominator? Something about that sounds wrong.

I generally agree with "use only as much cognitive overhead as needed to get the job done" ( I'm enjoying that term ) - but it seems like a slippery slope that could slowly bring everyones abilities down to the least capable developer.

<comment><USER3> It's also an excuse to avoid any sort of abstraction whatsoever, which makes solutions to genuinely difficult problems impossible to read, since one has to wade through the low-level details at every step.

To me, it's a bit like telling a person how to get from point A to point B by telling them when, how hard, and for how long to step on the gas and what angles to put the steering wheel at. Sure, that might work to get someone out the driveway, but good luck getting to the grocery store that way.

I will genuinely never understand the go philosophy that "excessive" abstraction is bad, with no attempt to justify why _current_ levels of abstraction — which are charitably hundreds of times more complicated than the difference between, say, go and ruby — are good, right, and just. Everything we do on a computer from processing to memory access to networked communications to rendering to handling input to relational data modeling to… _anything_ is dozens of layers away from what's actually happening. But somehow right now we're at the optimal level of abstraction and any more would just be _too much_. Okay.

<comment><USER4> > no attempt to justify why _current_ levels of abstraction — which are > charitably hundreds of times more complicated than the difference between, > say, go and ruby — are good, right, and just

It seems to me that Go is part of a reaction from people who are _not_ happy with current levels of abstraction.

<comment><USER5> I think the grandparent means that Go is already very abstracted from what's actually happening (e.g. programmers don't have to think about quantum mechanics, voltages, machine code (i.e. the actual numbers), microcode, CPU caches, virtual memory, finite memory/memory management (GC), implementing runtime type-checks or virtual dispatch) like many other languages. On one of those "spectrum" diagrams everything is bunched really far to the right:

                                                 asm    Go Ruby SQL
      reality <</comment></comment></comment></comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>---> abstract

Their point is something along the lines of: there's not as much justification for why all that stuff to the left is "good" abstraction, versus the justification for why the tiny extra bit to the right is "bad". The line between good/bad abstraction seems to be fairly arbitrary.

<comment><USER4> This feels like a false comparison to me. When you write ASM you pretty much know what it's going to do.

When you ADD two registers, you really are making two reads in the register file, which _really is_ a piece of physical hardware, and those reads _really do_ go to a physical adder and get written back to the real, physical register file. And languages like Go translate reasonably (but not exceptionally) straightforwardly to assembly. Even if you don't know all of the details that go into making it fast, your first guess of _what_ it's doing is pretty much right.

In contrast, adding some lazy FP callback into your latest node.js framework on DOM objects might be doing something, somewhere, but who on earth really knows?

<comment><USER3> > This feels like a false comparison to me. When you write ASM you pretty much > know what it's going to do.

This is because it's an excellent layer of abstraction on top of the machine code which is interpreted by the abstraction of microcode which sends it to the abstraction of a physical processor that's itself just an abstraction on top of transistors that themselves are an abstraction around manipulating voltages on a complex network of circuits.

Nobody bats an eye at these levels of abstraction. And they're not perfect! Modern CPUs have _hundreds_ of errata. Skylake's alone is almost 40 pages long, at 3-4 per page.

But you take them for granted because they're several layers lower than what you have to deal with on a regular basis.

Even your example of adding two registers required compiling through an assembler, scheduling execution by a time-sharing operating system that fakes the concept of running hundreds of parallel processes by rapidly looping through running processes, and on and on and on.

We are awash in a sea of abstractions more deep and complex than even a dozen of the world's best engineers put together could hope to fully understand. And yet people earnestly defend language design decisions that prevent a single function from comparing two values of any arbitrary numeric type as being too complex, when issues like that are less than a hundredth of a hundredth of a hundredth of a percent of the complexity that are modern computers.

<comment><USER4> Electronics Weekly says[1]

> "The M0 is a third of the size of the M3 in its minimal configuration," ARM > CPU product manager Dr Dominic Pajak told EW – 12,000 against 43,000 gates.

That same page is 2.8MB _compressed_ , the half of which is Javascript decompresses to 2.6MB.

Yes, a big OoO core has a lot more to throw around, but the vast majority is spent on tricks to make things go faster. The layers are thinner than you expect, and they're built that way on purpose. The hardware below assembly is a _far_ smaller jump than the browser in the sky.

[1]: [https://www.electronicsweekly.com/news/products/micros/arms-...](https://www.electronicsweekly.com/news/products/micros/arms- cortex-m0-processor-how-it-works-2009-03/)

<comment><USER3> Over two-thirds of that is ad-related code. The HTML, CSS, and basic Javascript needed to run the site appears to be on the order of < 250KiB. Images obviously bump that number higher.

You are not arguing against abstraction. You're arguing against the user- hostile influence of advertising on delivery of content on the web.

<comment><USER4> And you think adblockers have a legitimate reason for their codebase to be 3x the size of DOOM? If all this abstraction from the low level C code of DOOM to the high level Javascript-on-the-browser bought us anything, you'd think the abstract one that is solving an easier problem would take _less_ code, not more.

<comment><USER4> s/adblockers/adverts and trackers

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> Data scientist/engineer here. I write Java by day, Rust by night and in both I embrace a data-driven design, where I first carefully lay out the data so that it's easy to use within the code. In hot loops, I avoid dynamic dispatch for its runtime cost.

I don't embrace the FP style either because while I generally limit mutation (`final` almost everywhere), I use mutation where it leads to code that is easy to understand, which would be exceedingly "clever" in FP style.

</comment><comment><USER7> I mostly use a procedural style (i.e. C like) in java, for working out new ideas in solo projects.

It's simpler, more flexible, less verbose and easier to follow than a full-on OO style. A great example is the early calculatoe e.g. in ed 2 vs 3 of the compiler "Dragon" book: older uses C, later uses OO java... and it's so much worse.

However, OO is great for wrapping up modules of functionality for which you've understood and settled on an informed architecture (or you just need to sweep repetitive boilerplate away).

I think inheritance is just about completely useless (but not quite completely), and (java) interfaces are great - if you have more than one implementation.

Big, multi-person projects are a different story.

I don't use much fp-style, except where recursion is natural (e.g. parser combinators); or for plug-in functions (hardly fp though).

<comment><USER8> I was writing a small but semi algorithm-heavy library in C# that didn't rely much on other libraries. I later decided to port it to Java and realized that the more C#-like I had written the original code the harder it was to port. Later when trying to port it to JavaScript I ended up re-writing the C#/Java code to rely less on the standard libraries since each standard library differed so much. At that point my code started to look very procedural in the OO languages possibly similar to what you've been doing in Java.

I came to the realization I didn't even need a lot of the language features for what I was doing and decided to switch it to C to not have to maintain various versions of the library and it was a steep learning curve but I've come to really enjoy the simplicity but powerful capabilities of C.

<comment> le-mark Thanks for sharing this, it's a great, succinct example of the journey many experience. You could flesh this out and post it on medium or something to get the ideas out there for discussion.

</comment></comment></comment><comment><USER9> Procedural programming is what I learned first (Pascal), and I trust myself to write good code in a procedural style.

I do some microcontroller programming, and it's usually straight C. The hardware registers are all global, and their contents change based on external stimuli, so that kind of rules out the idea of stateless programming.

The earlier versions of Visual Basic had kind of a compromise, where it came with a lot of pre-made objects, and you could create objects if you got the special kit, but the casual programmer was only expected to _use_ objects. I kind of adhere to that idea when I write in OO languages such as Python.

I use OO sparingly when programming Python, often to encapsulate hardware functionality, but then use those objects within programs that still look procedural.

I avoid using inheritance, mainly because I don't trust myself to do it in a maintainable way.

</comment><comment><USER10> I've written almost entirely object-oriented code for two decades. My programs have almost no global variables.

I've tried functional programming in Rust, but it's not going well.[1] I don't like the "x.and_then(|foo|).if_even(|bar|).except_on_alternate_tuesdays(|baz|)" style. Rolling your own control structures is not good for readability.

[1] [https://github.com/John-Nagle/rust- rssclient/blob/master/src...](https://github.com/John-Nagle/rust- rssclient/blob/master/src/wordwrap.rs)

</comment><comment><USER11> 1\. "Shallow" OOP - minimal use of inheritance, composition ok but without making a Russian doll with 7+ layers with it.

2\. "Grand scale Functional characteristics" \- exposed API should try and have "referential transparency" and "composability" (you can write systems with "functional properties" in languages like PHP just fine btw.)... find not much benefit from "small scale / low level" FP.

3\. Wrap stateful algorithms & other code rich in mutable variables in either (a) referentiaally transparent functions or (b) shallow objects that make it obvious how and when state changes.

4\. Avoid the "islands of functional purity in a sea of objects" pattern like the plague - it results in large scale intellectual masturbation at the small scale, and incomprehensible systems at a large scale, your monadic fantasy is useless when stuck inside the method of a 8-levels-inherited monster object... _functional is important on a whole-system level, a 10 line method is easy to understand even if it mutates local variables all over the place_

 _In theory_ FP would be great at all scales when coupled with a good type system... but I've never got to work on projects in languages like Haskell or Scala and I'm not sure _I could handle_ the cognitive overhead of it.

Oh, and _don 't use Exceptions, ever!_

<comment><USER11> _On programming languages:_ It also doesn't matter whether _the language_ has such a good support for functional programming when you don't care about doing in _on the small, inside inner-inner-function level_ , so `map`, `foldr`, functor or whatever... make no much difference. As long as you have _the basics_ , like "first class functions" and "lexical closures", you can do "large-scale functional" programming in languages like Go just fine. It actually feels more refreshing in a minimalist language like this and with a minimalist and explicit type system :)

</comment></comment><comment><USER12> I use Scala - it can be used or abused to do advanced OOP and advanced FP.

I tend to see programming as writing. The style of writing depends very much on the context and the audience.

I lean towards "basic" FP (immutability/pure functions/composition) but none of the heavy category theory concepts (anything with types that are too complex). Its mostly procedural with a hint of FP.

Most things should be functions, most higher level things (classes/packages) should be primarily ways to bundle related functions.

Prefer to maintain a clear separation between data & operations on data or structures imposed on top of it. I dislike the OOP approach of bundling data + transformations together. Also dislike inheritance because that is baking one particular structure into the definition of data.

</comment><comment><USER8> My preference recently for side projects has been imperative/procedural style of programming. I prefer it to OO and FP hands down. To me code is so much easier to read when you don't have clever abstractions everywhere, most code reads line by line and isn't trying to hide anything. I think there is a tradeoff between concise terse code you find in OO/FP that reuses other code vs the long step-by-step procedural code. For me personally I'd prefer longer code that is not reusing a bunch of other functions.

It's almost a weird paradox: OO/FP focuses on reusing code yet imperative/procedural code (ie: C) does not reuse code but is itself the most reusable code. You can't have your cake and eat it too I guess.

<comment><USER13> Reusable code may be not the best code. There is probably a lot of redundancy (cross-cutting concerns). Or alternatively, increased interface complexity, to the point where it's easier to just write a custom-tailored version of the code.

I still like to program in C and make my own thin abstractions / "runtime", tailored to the task at hand, and using only minimal dependencies. That way it's much easier to have only _essential_ dependencies, not _accidental_ ones. It's such a relief seeing a couple thousand lines of cleanly modularized C code compile almost instantly.

For example, by putting a char * into a struct definition a dependency on a more clever string type can be avoided. All that it takes is delegating memory management decisions to another place. Which is actually very beneficial, since most code shouldn't be concerned with mutation or especially allocation.

<comment><USER14> redundancy/duplication is not a boon to maintainability admitting a revolving door of co-authors.

</comment></comment></comment><comment><USER15> PHP. Good old procedural PHP. Cleaner than most OOP and FP projects in the wild and I can code large things quickly and easily. The code is very maintainable as well. I even avoid PHP's OOP solutions with the exception of PDO which I wrap in procedural functions.

</comment><comment><USER16> Physics student here. I write a lot of python scripts/notebooks, which tend to be very imperative in style. They're usually just one-off programs, and there's little in them to be abstracted out. I rarely drop into C, as numba+scipy is usually fast enough.

Other than that, I use Mathematica quite a bit for playing around with ideas. I've tried sympy, and I hoped to switch to it but it's just not as fluid and integrated.

If I'm coding for fun I tend to come back to FP and OO, I'll use either Haskell, Python or CL. I've been meaning to make something using Rust for a while. I'm planning on building a fermentation chamber (and perhaps a kegerator depending on my budget) for homebrewing at some point over the next year; I'm thinking that I might use Rust for the temperature controller.

<comment><USER17> Similar case here as a cognitive science PhD student... analyses (Jupyter notebooks) are basically imperative but if I need to write a library to support the analysis (which I almost always need to do) then OO.

</comment></comment><comment><USER18> When I have an option, I program in a procedural style. The code is easier to maintain and follow this way.

For side projects and for small Python code at work recently I have been applying data-oriented programming patterns. So far they worked surprisingly well.

Perhaps this is because one have an overview of the whole program state that is not hidden behind multiple layers of OOP abstractions and there is no mix between data and code, as happens with functional style.

</comment><comment><USER19> OOP wasn't really yet a thing and GUIs (which I think of as the killer app for OO) were still experimental when I was first learning programming. I started out with Fortran and Pascal on a timeshared mainframe. Probably because of this background, I still find OO languages ungainly, especially the huge libraries that are usually associated. I'm also a bit of a skeptic about the purported value of the OO abstraction, which always seems to cherry-pick from a few problem classes that lend themselves to representation as interacting objects.

While I sometimes teach programming in C# and C++, my main responsibility is our Algorithms and Data Structures courses, for which we've kept using plain old C. From a teaching perspective, it's a great language for teaching fundamental algorithms and data structures. The students are also able to leverage that work into later courses on microcontrollers and embedded systems.

For my own work, I tend to mostly be writing code for somewhat idiosyncratic one-off data processing (I'm currently working on a genetic algorithm for class, student and professor scheduling) or embedded systems. The former I generally work in Common Lisp (SBCL)(although I do keep promising myself to learn enough Clojure to see if I prefer it). This is probably because of the way I think, as I tend to be comfortable building a system from bottom up, moving the data representation from the general facts I start with toward a representation that meets my needs. I actually came to CL pretty late, about a dozen years ago, but it really seems to suit me, possibly because I'm still primarily a command-line person. Being an emacs user certainly was a strong influence, too, although I don't hack elisp very much. I should add that I do often use CLOS, especially when working with more structured data, so I do use _some_ OO, although it's mostly just to provide a more convenient interface to some complicated data type.

For embedded development, I still work almost exclusively in assembler or C, with less assembler every year. I tend to be working on pretty low-powered special-purpose devices, so code reuse and robust interfaces don't add much value, but close control of exactly what the hardware is doing does. This was normal in that domain until comparitively recently, but the power of even cheap devices and the availability of libraries mean that there are a lot more options. I expect that I'll continue to work mostly in C out of familiarity and inertia, but I will admit to having recently bought some Lua books with the intent of trying it with ESP8266.

<comment><USER20> > which I think of as the killer app for OO

Was this written in a book somewhere? I keep hearing it from people, but nobody's able to really explain why. OO is terrible for GUIs IMHO.

<comment><USER19> GUIs lend themselves very well to an object abstraction. The discrete elements (dialogues, menus, controls, etc) are objects that often inherit behaviour from classes of objects (i.e. A modal dialog is a generic dialog is a form is a ...). Events are messages between objects. We even see things like polymorphism eg. anything can get a "click on" message, but different objects behave differently when clicked.

</comment></comment></comment><comment><USER21> I try to only use capabilities that are common to all languages. Some basic math, basic conditionals, and maybe poking a file or memory address somewhere. I don't give a enough of a crap to get excited for new but short-lived features anymore.

<comment><USER22> Same for me. Lately I was wishing there would be a translation matrix for all these basics in every language.

<comment><USER23> A start: [http://hyperpolyglot.org/](http://hyperpolyglot.org/)

</comment></comment></comment><comment><USER24> Personally, I learned to code in an oop style. I cut my teeth on CPP and then a few years of c#, but these days I work in python.

My problem with non OOP in a language like python is that I have trouble scaling large apps and interacting with large libraries, because without type information enforced by the compiler, there is too much left to my own working memory, compared to a strongly types language built around OOP.

What's more, without rigid encapsulation I feel im exposed to an excess of internal code any time I need to look up a parameter or kwarg. Never mind the trouble of navigating five files feel through aliased method names...

As examples, consider matplotlib or tensorflow. Extremely easy to use once you know where everything is and what params to pass where, but I can't help but feel that it would be easier with stronger OOP.

I feel like I have not yet learned to think in a pythonic manner, but after a few years I'm not sure if I every well. As an aside, I just dont understand how python doesn't cause problems for devs when it scales...

</comment><comment><USER25> I primarily use a declarative language called LogiQL, which is a superset of Datalog. It's basically logic programming. Using predicates and rules.

We have a proprietary database called LogicBlox, that allows us to push all business logic down to the database layer, and almost entirely avoid having a service layer, or at least a very lean one. This allows us to address efficiency problems purely by optimizing database joins between predicates (tables).

Our data is highly normalized (6NF).

[http://www.logicblox.com/learn/](http://www.logicblox.com/learn/)

</comment><comment><USER26> FP. Because it makes most things easier while resulting in software that works more consistently.

</comment><comment><USER27> Last project I did was mainly procedural and that's my default go-to type of structure but OO has its place too. For example in that last one, i had few objects that implemented same functionality but with different data structure. So if I wanted to later on add new data structure, just adding a new class with predefined and partly dynamic features, I'd only need to implement a new class.

For data iteration, i prefer functional style (even in python, even after years list comprehension just feels so wrong).

</comment><comment><USER28> SQL is neither FP nor OO! It's not a general purpose language though, so it may not be a great answer. It's still amazingly useful and incredibly prevalent.

</comment><comment><USER29> My current gig has me writing Go, which doesn't do much more than wave a hand at OO to start with, and the codebase I'm working with is particularly un-OO.

</comment><comment><USER30> I mainly write in Go. My adopted approach is to be pragmatic about how I approach my problems.

I kinda tend to start with a OOP style for the data models and a small shake of FP for the functions but change this according to my needs.

There is no one true style for programming, there is only tools for a task and using the best or good enough tool is the only important thing. (Though sometimes it's fun to use the wrong tool and see how it goes)

</comment><comment><USER31> I strive for FP, but since most external libraries are OOP, I've made my peace with it.

That's probably not the right question though. If we're just focusing on implementation, using the right data structures for the problem would have to be job #1.

Screw that up, and everything else (APIs, UIs, enhancements, training, you name it) is going to be an uphill climb.

</comment><comment><USER32> I primarily use nouns for the macro architecture but use lots of verbs in the details.

Neither style especially dominates, and most languages have enough support for both even if the tilt one way or the other. Most people pigeon whole other styles into one or the other, sometimes ambiguously (e.g. actors get counted as both OOP and FP, relational also has that problem).

</comment><comment><USER33> I mostly code in JavaScript.

Try to use FP most of the time, but sometimes a little mutation seems easier to grasp.

</comment><comment><USER34> I primarily use Python scripts in my day job to parse data, automate job runs, analyze data...etc.

Rarely is anything complicated enough to abstract without making the code longer and more complex. Anybody can follow imperative code. OO is more difficult.

</comment><comment><USER35> C

<comment><USER23> Starting with C has made me consider it a travesty whenever seeing a language where "main" is forced into being a method on a class.

OOP as a technique is fine, but any language disallowing freestanding functions is perverted, I tells ya.

<comment><USER35> I agree. I prefer pragmatic languages as opposed to dogmatic ones which is probably why I'm friends with Kotlin

</comment></comment></comment><comment><USER36> Python with tricks from Erlang, PHP frameworks, Lisp. Do FP for most of things, using OOP to structure the code when reuse is necessary: e.g. connectors to external APIs

</comment><comment><USER37> Scala[!] NLP/symbolic math.

</comment><comment><USER38> Even in OO languages, I'm almost exclusively in an FP style because that style focuses on minimizing redundant code (e.g., don't write loops write loop transformer functions), minimizing redundant top level functions (segmentations, hand-tuned stateful getter/setters, etc), and maximizing the opportunity for correctness.

The last part is pretty important because properly testing software that talks to an external service is essentially impossible. Either you test in an integration setting where repeatable results are difficult to maintain, or you mock out your services and then you're testing your opinions against other opinions.

Here's an example of how I push this style to typescript, heavily redacted to remove company-specific marks, names and strutures: (this code is simple by intention; we may have a jr dev on the team soon and an excessive number of generator abstractions could help with this process but would cause readability issues).

        function splitOrders(orders: e.OrderResult[]): {[key:string]: e.OrderResult[]} {
            return orders.reduce(
                (accum, borders) => {
                    // I sure would love a better idiom for non-destructive map updates but
                    // this isn't my primary language. Suggestions welcome!
                    let next = {...accum};
                    next[borders.datatype] = (next[borders.datatype] || []).concat([borders])
                    return next
                }, {})
        }

        export async function undoifyUserProcess(env: any,
                                                tolkien: client.tolkien,
                                                token: client.APIToken,
                                                spotData: IThingData): Promise<any> {

            const legendaryCustomer = await e.getCustomerById(env, spotData.customer_id);
            const orderResults = await e.findThingContractDetails(env, +spotData.spot_id);
            const workSchedule = splitOrders(orderResults);

            let btasks = scheduler.undoifyCustomerFromOrders(
                env,
                token,
                { key: legendaryCustomer.userKey },
                workSchedule['newstyle'].map((wi => wi.bigId)));

            let ltasks = (workSchedule['legacy'] || []).map(async (workItem) => {
                // .. process elided but...
                const nodeKey, groupKey = ["things", "were", "removed"];
                const customerEmail = legendaryCustomer.some_field + "removed work"
                // Factoring this out would have introduced a function with a bunch of parameters
                // or state that is only synthesized here, so we left it embedded & closed over.
                try {
                    return await omg.undoifyUserWithTagGroup(env, tolkien, customerEmail, nodeKey, groupKey);
                } catch(e) {
                    console.log(`... malformed database call your mom for help ...`);
                    throw e;
                }
            })

            try {
                const work: Promise<any>[] = [btasks, ...ltasks];
                const result = await Promise.all(work);
                return await e.recordUndoifyingThing(env, +spotData.spot_id);
            } catch(e) {
                console.log(`...`);
            }
        }

If a language can't express a decently abstract functional style, I do my best to avoid it. Still, I've had to write a bit of Golang at my current job despite its utter lack of descriptive capabilities. It's poignantly frustrating to deal with, but a good reminder of how bad life used to be for programmers.

<comment><USER39> _or you mock out your services and then you 're testing your opinions against other opinions._

I'm curious what you mean. Mocking out the dependencies of a piece of code allows you to test that code exhaustively (for every range of possible inputs) if you choose. Even when that's not practical (probably most of the time), it allows you to do your best. It gives you the hooks to simulate any range of behavior.

 _and maximizing the opportunity for correctness.

The last part is pretty important because properly testing software that talks to an external service is essentially impossible_

It sounds like you're just trying your best to write _correct_ code and then hoping for the best? This absolutely will not scale, and it sounds downright frivolous.

Still, I would love to know more about where you're coming from. Do you do anything to ensure correctness aside from maximizing your hope of writing it in the first place?

<comment><USER38> First of all, Tome4/DND reference?

> Mocking out the dependencies of a piece of code allows you to test that code > exhaustively (for every range of possible inputs) if you choose. Even when > that's not practical (probably most of the time), it allows you to do your > best. It gives you the hooks to simulate any range of behavior.

It lets you mock anything at all, which is not what you want to mock. You want to mock the service (and in a microservices architecture, its interplay with dependencies).

If you can encode those into a series of constant replies? Good, but you'd better be doing something like FSharp's type providers or Facebook/Marlow's Haxl where you capture real traffic off the wire, otherwise all you've done is inject more opinion and conjecture into your tests and confuse that with correctness.

Outside of a very small number of specific methodologies, I think our industry is at mostly a loss for how to test microservices.

> This absolutely will not scale, and it sounds downright frivolous.

It doesn't scale with junior engineers. But neither does unit testing, which is more of the same "I think these tests and we try them and pretend that's test coverage because this line of code was touched" which is demonstrably false.

In typescript, I try to do queue-based architectures with full docker stack simulation. People like to call these "integration" tests, but I consider them unit tests for impure code.

In a language that lets me do pure/impure effect separation even in a communal setting, I tend to use quickcheck for the pure parts and hand-test the impure parts if an environment exists. When I get to use Haxl, I used their caching features to preload responses and my code didn't even know it was being tested, which was great.

Also, in Haskell, I'll sometimes use MonadMock but only if I can grab raw source response from APIs (or of course I need to do something like fix time or random numbers).

But I really try not to waste my time in the futile tarpit that is unit testing anymore. It's sort of the pop quiz mentality applied to software engineering and all it does is provide false confidence that code is "tested" when the quality of the output still varies radically on the discipline of the developer.

When I _do_ go back to Ruby or untyped javascript, I do end up writing unit tests. But they're mostly to capture scope around components to ease refactoring and make requirements explicit; something every language should have.

Sorry for being so frank, but you seemed like you wanted a bigger discussion. I think the industry has collectively decided to freeze all interest in any technology conceived after 2007 and it bugs me.</comment></comment></comment>


Java's Not Dying, it's Mutating - <AUTHOR> http://m.readwriteweb.com/enterprise/2011/02/javas-not-dying-its-mutating.php?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+readwriteweb+%28ReadWriteWeb%29

<comment><USER2> While Java is not in jeopardy of dieing any time soon, It has most certainly been mugged in the back ally by Oracle and is banged up pretty bad. While Java the languadge is a bit verbose at times I never felt that it was in real danger. The library wealth if nothing else kept people fixed to it. But with Oracle's stewardship, it has given people the reason to ignore all the practical reason to stick with Java and move on to other pastures. The problem is none of the cool kids are using Java anymore and that is a real problem, that means new problems sets and new solutions will be accomplished in other languadges it also means all those libraries and the developers who graciously write them and distribute them for free are going to start looking to work in other languages, these political problems do present a serious threat to Java's crown and it seems that Oracle is oblivious to the fact or sees value in monetizing it to the pulp while it can squeeze Java technology adopters.

</comment><comment><USER3> Plus many of the new Graph Databases are written in Java. Neo4j and OrientDB

</comment><comment><USER4> Arguably, most corpses do mutate into other things. This is just an argument of semantics. Java as we knew it is going away. This is as close to "dead" as philosophical ideals get.</comment>


Published a Hacker News app for Android (ICS and above only). Feedbacks? - <AUTHOR> https://play.google.com/store/apps/details?id=com.rickylaishram.hackernews

<comment><USER2> Feedback:

      * I love how smooth the scroll is.
      * The loading more UI is lacking and isn't polished like the rest of the UI
      * Crashed the first time I signed in.
      * I miss seeing the domain (and subdomain) of the linked article
      * I don't like having articles open in a web view. Would much rather have them open in the default browser instead.
      * The comment UI has an odd white stripe on the left of the screen.
      * The extra prompt asking to open comments or article is annoying. Maybe have The middle half of the screen open the article and the right quarter open comments.
      * Maybe support flagging or downvoting by swiping a post or comment off the screen. Similar to clearing a notification.
      * Notification of replies to my own comments would be a nice addition.

Great start and I hope you continue to develop it.

<comment><USER3> Thanks for the feedback. We have just updated the app that should fix the crash on login. We will try to incorporate as much of the features as possible.

</comment></comment><comment><USER4> Please remove the intermediate popup menu when clicking to read an article.

Clicking the title should just go to the article.

The "10 comments" TextView should be clickable to take me to the comments activity.

You could add more clickable margin and bump the font size on that comments text if you feel it's to small to click.

The fact that I have to click twice to read anything will prevent me from using the app. I love the speed and the rendering, so I'd love to use this app, but right now I can't get past the fact I have to click twice every time.

</comment><comment><USER5> I really like this app. My only suggestion would be to add a "Refresh" button or option in the menu. I minimized the app and went back to it about 20 minutes later and it was bringing me to the wrong article comments and then it gave me a 'network error' (guessing the page expired) when scrolling. Closed the app via recent apps vs minimizing it and restarted it, worked fine.

Aside from that, I truly like it.

</comment><comment><USER6> Please make the apk available for those of us who don't gave the proprietary market app or choose not to link a Google id to the phone.

<comment><USER3> Hi, I have put the apk at the end of the page <http://rickylaishram.com/projects/hacker_news>

<comment><USER6> Thanks!

</comment></comment></comment><comment><USER7> Commenting with it too as was unhappy with the HN app I was using - took a minute to work out how to reply though :-)

</comment><comment><USER8> Please charge for this. It's obviously very well done and you deserve to be compensated for your hard work.

</comment><comment><USER9> I'm actually commenting with it. It feels great.

However, it crashed when I tried to sign in. when I opened the app again, I was signed in.

I am using the Asus Transformer with ICS

<comment><USER3> Thanks for trying it out. We are working on a fix for the issue.</comment></comment>


Backblaze for Business - <AUTHOR> https://www.backblaze.com/blog/business-cloud-backup-solutions/ <comment><USER2> Does anyone know if this provides point in time restores?

For example, if one of our PCs was hit with crypto ransomware yesterday at 5pm, backup ran at 10pm and the newly encrypted files were backed up. Is it possible to recover the previous copies? If so, how far back does it go?

<comment><USER3> Yev from Backblaze here -> Yea, with our Computer Backup service we have a 30-day history, so you'd just rollback time and restore from before infection. We've had a lot of customers have to do this -> [https://www.backblaze.com/blog/cryptowall-ransomware- recover...](https://www.backblaze.com/blog/cryptowall-ransomware-recovery/) (including one of our own...#sigh)</comment></comment>


Why Carol Bartz was fired - <AUTHOR> http://www.asymco.com/2011/09/07/why-carol-bartz-was-fired/

<comment><USER2> Interestingly, this matches up with pg's analysis from 2010, based on his experiences in 1998. <http://www.paulgraham.com/yahoo.html>

"I didn't realize the answer till later, after I went to work at Yahoo. It was neither of my guesses. The reason Yahoo didn't care about a technique that extracted the full value of traffic was that advertisers were already overpaying for it. If they merely extracted the actual value, they'd have made less."

The problem with customers that are overpaying is that they eventually come to realize it and stop (over) paying.

<comment><USER3> That only matters if you plan to still be CEO at that point.

<comment><USER4> Or still own equity in the company.

</comment></comment></comment><comment><USER5> Yahoo Japan has always provided a nice comparison to Yahoo itself.

While Yang and co. stood by while Google became everyone's homepage in the US, Yahoo Japan remained the #1 portal in Japan by moving aggressively and continually making the site more useful to their members -- auctions, banking, broadband, personals, etc. All that while at the same time strengthening the brand with the naming rights, universal billboards and of course the sign up girls.

</comment><comment><USER6> It's so interesting to me how you can get these large companies that stay around even though they don't innovate. I mean, I don't explicitly use yahoo services for nearly anything. I occasionally look at flickr photos these days (other people's not mine). I occasionally go to a yahoo group I joined 4-5 years ago. Once a year I do a march madness bracket there. But that's it. There's nothing compelling there for me. (I use yahoo messenger along with 3 or 4 other backends via adium, but it's not my preferred backend... I use it because I know people who prefer it.)

What's amazing is that while clearly Yahoo isn't innovating, and clearly they're having trouble, there's still (apparently) enough people that go there on a regular basis that they are generating _some_ kind of revenue. That to me is amazing: when a company gets big enough it can become a sort of "perpetual motion" machine that keeps chugging in revenue even when it's not "successful" by any normal sense of the word.

<comment><USER7> You do not have to innovate to be successful. The overwhelming majority of profitable businesses out there have never innovated and never will. All you have to do is provide value.

In fact, the majority of innovative businesses fail and fail miserably. You still have to translate innovation to value. That's really hard.

<comment><USER8> Exactly. You know what business will (almost) never go broke?

A mortician.

How much innovation's necessary there?

<comment><USER9> Innovation is actually banned by law for mortuaries in many jurisdictions.

So you have to use chemical X from select manufacturers Y, and place dead body in box T with procedure Q.

<comment><USER10> Not true.

You'd be surprised at how much innovation is in the industry, particularly with respect to social media. I know: my company provides web based software to funeral homes and mortuaries. We let them design headstones online. We even put QR codes on the headstones to make it easy to find the deceased individual's online obituary within the cemetery.

</comment></comment></comment></comment></comment><comment><USER11> As the article points out, Yahoo's problems began long before her tenure and Bartz's primary experience was running a company which was a market leader and was committed to making hard choices in a timely manner [Autodesk]. Nothing could be further from Yahoo's status at the time she took over - Yahoo has not been the leader in their segment for at least the better part of a decade. They are essentially the AOL of the internet - a service targeted at the less sophisticated intern users or those willing to go with their ISP's default in the case of ATT.

There's no fixing it because there is no love for the brand. People have Yahoo email addresses for the same reason they have Hotmail - they got their free email account before Gmail was available and it is too much trouble to change it.

Bartz's hiring was a classic case of drafting a CEO based on who is available rather than fit - there was virtually no overlap between Autodesk's business model and operations and Yahoo's. Hopefully, she will find a much better circumstance in her next role.

<comment><USER12> easy to say that in hindsight - IBM hired Lou Gerstner when it was at the brink of sinking and his previous experience did not have much overlap on what IBM did - he still managed to turn things around

</comment></comment><comment><USER13> Carol Bartz was fired because the MSFT deal for ads has not performed well at all and anyone who had used both platforms before the unification of Yahoo Ads and MS AdCenter would know that AdCenter has always been considerably worse in almost every respect.

AdCenter has always had the problem of MSFT makes it hard to spend your budget to buy any real quantity of traffic. Yahoo was much better at making it easy for you to setup ads, run them, and get traffic. AdCenter sucks at all of that. It is literally years behind of what Yahoo had which was still years behind AdWords.

Even worse, AdWords, even with it's quality score policies designed to drive up the price of ads, makes it so much easier to setup ads and get traffic that there is no way AdCenter can compete.

The secret sauce in online ads is simple - "make it easy for me to spend money to buy traffic". Google nails that every time. Yahoo was pretty good. Microsoft sucks at it.

So, long story short, AdWords is so far ahead of AdCenter that there is no way for Microsoft to catch up. Carol Bartz and Yahoo hitched their horse to the Microsoft AdCenter wagon and that cost Carol Bartz her job.

If it don't make dollars, it don't make sense. Microsoft AdCenter doesn't make much of either for Yahoo.

</comment><comment><USER14> Contrary to what the article states Carol Bartz engaged in plenty of surgery, unfortunately most of it was of the amputation variety.

<comment><USER15> you mean, plastic surgery right ?

[http://images.businessweek.com/ss/08/07/0731_women_in_tech/i...](http://images.businessweek.com/ss/08/07/0731_women_in_tech/image/carolbartz.jpg)

</comment></comment><comment><USER15> I do not worry for yahoo because: <http://www.youtube.com/watch?v=mh4jvDsNtEE>

</comment><comment><USER16> Yahoo was always a technology company trying to be a media company, when being a media company is no longer respectable. At a time when there is so much opportunity, why isn't Yahoo even wading into mobile or social?

A CEO's job isn't only to focus on core competencies if the core business is losing lustre. A CEO's job is to look for new markets, and build up the competencies.

</comment><comment><USER17> The article's premise of Yahoo's value being "behavioral data of its users" seems pretty silly. It's all about the ads (search and display).

Maybe it was a roundabout reference to ad targeting?

</comment><comment><USER18> Yahoo needs a young visionary product guy who understands the web, mobile, etc.

The last thing Yahoo needs right now is an "experienced" executive from another company.

</comment><comment><USER19> Do we seriously need a blog post on "why" she was fired? I think this is blindingly obvious... Yahoo is now a shell of the company it used to be.

</comment><comment><USER20> Yahoo does own Flickr and Delicious, two very active modern "user behaviour" sites. So it's not that they didn't have any such data, they apparently just chose to ignore it.

<comment><USER14> You must have missed this announcement:

[http://latimesblogs.latimes.com/technology/2011/04/bookmark-...](http://latimesblogs.latimes.com/technology/2011/04/bookmark- this-youtubes-chad-hurley-and-steve-chen-buy-delicious-from-yahoo.html)

Yahoo no longer owns delicious.

<comment><USER20> I did miss it, thanks! But that wasn't so long ago, so my point still stands.

</comment></comment></comment><comment><USER15> Carol Bartz was not fired because she is fat, rude and vulgar (although she is) - no, she just pissed off the wrong dude: Jack Ma.</comment>


Americans are changing their relationship with Facebook - <AUTHOR> http://www.pewresearch.org/fact-tank/2018/09/05/americans-are-changing-their-relationship-with-facebook/ <comment><USER2> [https://news.ycombinator.com/item?id=17919811](https://news.ycombinator.com/item?id=17919811)

</comment><comment><USER3> No surprise. A 250MB app that needs updates every week, can't show your friends most recent updates on a chronological timeline, doesn't let you chat with tour friends, analyzes everything within the app including maybe facial emotions, and keeps sending useless notifications to make you open the app; no wonder people are fed up and delete it.

<comment><USER4> Also eating battery, always wanting to do stuff in the background, showing ads that make it seems like it's listening to your conversations.

</comment></comment><comment><USER5> "The new survey finds that around one-in-ten Facebook users (9%) have downloaded the personal data about them available on Facebook. But despite their relatively small size as a share of the Facebook population, these users are highly privacy-conscious."

9% of a huge number is... a huge number.

<comment><USER6> And yet, my wife and I downloaded our personal data from Facebook for reasons very different than privacy (legal evidence stuff), so that's a broad brush.

<comment><USER7> I and several others I know just downloaded it for fun.

</comment></comment></comment><comment><USER8> There could be a lot of story lines here. I go for web over apps as much as possible. Less resource hogging. More control over things like notifications.

I just don't have a burning need to check my FB notifications. But I'll still check FB a couple times a day. No need for the app, but I haven't deleted my FB account either.

I also prefer the stripped down web version which is "free" on mobile connections in places like the Philippines. No images, no video, just plain text in an ugly interface. Perfect.

<comment><USER9> For most people image sharing is the primary Facebook use case. Other social networks and messaging apps dominate plain text sharing.

<comment><USER8> For me, it depends not on what the masses are doing, but what group I want to keep in contact with. Family, friends, locals, hobbyists, etc might all be at different locations on different platforms. For example, one of the communities I'm most active with uses an old PHP script.

</comment></comment></comment><comment><USER10> I wonder how many people who have "deleted the app" do what my SO does and keep using it daily via their phone's web browser whilst still telling people "Yeah I've totally deleted Facebook from my phone".

<comment><USER11> When I deleted FB from my phone, it was a solid statement of "I will not use FB on my phone". I do still use Messenger, because it's primary contact mechanism anymore for so many people, but I don't read the feed on my phone, period.

<comment><USER12> You're still giving them location data and customer profile information. Probably something like: "white male, from $STATE, income bracket derived from home and work location, and probably flagged as "privacy conscious" because you never use the app. That profile is valuable to at least some advertisers.

<comment><USER11> Yes, but my reasons for getting off FB aren't privacy paranoia. I don't particularly care that they're tracking me.

I dialed back Facebook because it ate time better spent doing other things, and I like myself better when I'm not yelling at people who are wrong on the Internet so much.

<comment><USER13> Paranoia? Yeah, that's a completely unacceptable phrase considering what they're actually doing. Shame.

</comment></comment></comment></comment></comment><comment> EZ-E Imagine if Facebook didn't buy Instagram. They must have seen this coming.

<comment><USER14> Yeah, you have to give it to Mark Z for his prescience on that one.

<comment><USER15> And a flag to regulators for not blocking or at least more heavily investigating that acquisition

<comment><USER14> I dont know if they would have had anything to be wary of. Instagram was much smaller then and even tech savvy folk like us HN folk didn't think much of it at the time: [https://news.ycombinator.com/item?id=3817840](https://news.ycombinator.com/item?id=3817840)

</comment></comment></comment></comment><comment><USER16> I was noticing this morning that their "I don't want to see this" feature seems to be stored client side. For a second while the page is loading I'll see an article that immediately poofs away because the client side js reads the setting and hides the article.

Every single time this morning that I refreshed the page, I saw a few articles poof away. They _really_ want me to see the tabloid crap I marked as don't want to see.

<comment><USER17> I think it's doubtful that Facebook wouldn't store that information server- side (you know, to achieve even better ad targeting). Maybe it's both, though.

<comment><USER18> I think the Facebook "I don't want to see this" data is stored server-side, but the code that actually hides posts runs as client-side javascript. That would explain why the client spins so much loading/hiding posts you've hidden, and why the hidden-ness is persistent across browsers.

I've gotten the impression from several accounts that, despite their prestige, Facebook's application code is often unbelievably janky, and this just confirms that.

</comment></comment></comment><comment><USER5> "Deleting the app" from your mobile is like an overweight person hiding the cookies or a cigarette smoker hiding their cigarettes - it's at least a conscious decision to make better choices, however everyone knows it won't work until you actually stop the behavior.

<comment><USER18> > "Deleting the app" from your mobile is like an overweight person hiding the > cookies or a cigarette smoker hiding their cigarettes - it's at least a > conscious decision to make better choices, however everyone knows it won't > work until you actually stop the behavior.

I disagree. A cookie jar doesn't encourage you to make bad choices by nagging you to eat another cookie if you haven't had one in while. Facebook will try to grab your attention _any way it can_ to get you to make the bad choice to open up their app another time. A practical and effective way to escape those attempts is to delete their software from your devices.

<comment><USER5> A practical and effective way to escape those attempts is to delete their software from your devices your account.

There's also an argument to be made, that cookie makers want you to keep eating cookies, just like Facebook wants you to keep "sharing". Facebook has an advantage (living on a device you obsess over), however those cookies you hid on top of your refrigerator ... are they whispering to me?

<comment><USER18> > A practical and effective way to escape those attempts is to delete > their software from your devices your account.

That is another way to do it, but it might not fit many people's lifestyles as well intermediate measures like deleting the app. Facebook is a communication channel, just like email and the telephone, and totally deleting your account has definite costs that vary from person to person. I think it's totally fine for people to manage how they make their own tradeoffs, and I know for a fact that the most extreme action is often more than is really required to get resuts.

Take myself, for example. I'm quite anti-facebook and hardly ever use their software. But I haven't deleted my account because I have friends and acquaintances who still use it for event planning, and I don't want to be either left out or be a prima donna demands special treatment. I get an email notification when I get an invite, and I only log in to RSVP and check the event info.

<comment><USER11> That's a problem for me, too. I'm in a few bands and otherwise host events, and I'm involved in other performance scenes, so FB events are really important to me. They're the #1 reason I can't give it up completely.

<comment><USER19> Meetup, Evite, probably many more in this space. All you need to invite someone is an E-mail address.

<comment><USER18> > Meetup, Evite, probably many more in this space. All you need to invite > someone is an E-mail address.

I could use one of those to plan an event, but there's no way that I can force people to use them to _invite me_ to and event _they 're planning_ instead of Facebook. If they choose to use Facebook, I'm not getting an invite unless I have a Facebook account.

My solution to that problem is to leave up a vestigial Facebook account that I never use and very obviously communicates that I no longer use the site. It contributes to the impression that Facebook use declining and ensures I won't miss anything.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> I exited facebook too. Unfortunately, I started using Instagram instead.

<comment><USER21> Same thing. At least I know that Instagram is mostly all fake and ego- inflating, and I am totally fine with that.

Plus I have much stricter controls on Instagram and only allow a few people to see my photos and videos.

</comment></comment><comment><USER22> Strangely, the front page is linking a better summary than the single item view: [https://www.cnbc.com/2018/09/05/facebook- exodus-44-percent-o...](https://www.cnbc.com/2018/09/05/facebook- exodus-44-percent-of-americans-age-18-29-have-deleted-app.html)

Especially insofar as it includes this topline note:

> The survey does not measure usage of Facebook's Instagram, WhatsApp and > Messenger, all of which remain popular overseas, and does not measure > Facebook's continuing growth overseas.

</comment><comment><USER23> As a shareholder: not too worried about this. Instagram and WhatsApp have plenty of room for growth that can compensate for FB users leaving. A few weeks ago, WhatsApp released its official API[0] and at least here in Europe i have seen many companies starting to utilize it. For example airlines, sending WhatsApp messages keeping you updated on the status of your flight, much more convenient than installing a extra app for every airline. Lot of potential there.

[0] usable via third party providers, for example Twilio

<comment><USER24> I find this kind of amusing. I suspect the adoption of this varies by area/country based on how, ahem, well, _poorly_ basic SMS is implemented and priced in that area.

For example I notice that when in Germany, Whatsapp adoption is quite high, because SMS rates are absolutely ridiculous. Other countries... less so.

I still get SMS (and email, but SMS frankly still _pushes_ more reliably than data based systems) notifications for my airlines, and that also certainly qualifies as Not An Extra App :)

<comment><USER9> SMS will always be more reliable than data service because SMS runs over the GSM signalling side channel.

<comment><USER25> Which is irrelevant when GSM is going away and additionally Wi-Fi being more and more common.

<comment><USER24> Sure.

Aaaand last airport I flew through had a wifi signup which required your phone number.

To send you an SMS.

With a code for the wifi.

So uh...

I'll continue to take my SMS notifications (and emails, which also have nice well-known offline sync properties...) over any more modern appy things, please and thank you.

</comment></comment></comment></comment></comment><comment><USER26> I don't think it's about leaving Facebook - it's just that their app is ridiculously bad. Some people I know eagerly switched to FaceSlim after I showed it to them, which is just a Facebook's web interface wrapped in a lightweight app with added notification features.

<comment><USER27> I use Facebook pretty regularly, but have never installed the app on my phone or tablet because of all the horrible things I've heard about it.

</comment></comment><comment><USER28> What is the reinstall rate? Are historicals higher or lower? What are typical app delete rates for other apps?

So many bits of missing information that prevent these stats from actually providing meaningful insight.

</comment><comment><USER29> Yeah, and how many of those are on Instagram and WhatsApp?

</comment><comment><USER30> I cannot remove it on my Samsung S9+ phone, just "disable"

</comment><comment><USER10> As this paragraph reveals, the title is predictably overblown:

> "Overall, 26 percent of survey respondents say they deleted the app, while > 42 percent have "taken a break" for several weeks or more, and 54 percent > have adjusted their privacy settings."

<comment><USER31> The article could be clearer, but 26% might be out of all age groups. 44% is only the people in the 18-29 age range.

I would be curious to see additional breakdowns. Sure 26% deleted the app, but are they still using messenger? How many are using a web version of Facebook or have stopped using the platform entirely?</comment></comment>


Ask HN: Is it possible for fusion reaction to store energy? - <AUTHOR> <comment><USER2> Possible? Yes, but I'm not sure if my answer is what you are asking about.

When people normally speak about fusion energy, they are referring to fusing small nuclei, such as hydrogen, deuterium or tritium. Any nuclei which fuse to create something smaller than iron will release energy when fused. If you create something the size of iron or larger, it requires energy to do this. So, in a sense, stars that create elements heavier than iron (like supernovae) are storing energy using fusion.

You could fuse two small nuclei to make a larger nucleus that decays later. Fusing deuterium to make tritium (a beta emitter) would be an example. To make it useful, you would probably want to generate an isotope which had a natural decay rate which was appropriate for your storage system. It is generally going to cost more energy to make these than you will get out, and if you can already fuse small nuclei, then fusing those directly is a better energy source.

I suppose in theory one could use energy to break apart small nuclei, then fuse them later. This would qualify. I'm not sure what motivates your question. The practical answer is that light nuclei are already widely available, so if you can fuse them, then using them as a fuel is the most efficient way to have an energy storage system.

There was a bit of research into ways to release energy from nuclear isomers (Hf 178m2) a few years ago, but it appears to have not panned out. If this had worked out, one could make a nuclear isomer with fusion and do this.

</comment><comment><USER3> No, because:

In fusing plasma, the main carrier of energy out, is the neutron, and methods to efficiently use this energy are still to be developed, wait for the fusion plant prototype DEMO. It is not possible to store energetic neutrons.

Fusion ignition is the point at which a fusion reaction becomes self- sustaining, i.e. the energy being given off by the fusion reactions heats the fuel mass more rapidly than various loss mechanisms cool it. At this point, the additional energy needed to heat the fuel to fusion temperatures is no longer needed and can be turned off. Throttling off the deuterium or tritium fuels will stop the reaction.

The produced helium nucleus carries an electric charge which will respond to the magnetic fields of the tokamak and remain confined within the plasma. However, some 80 % of the energy produced is carried away from the plasma by the neutron which has no electrical charge and is therefore unaffected by magnetic fields. The neutrons will be absorbed by the surrounding walls of the tokamak, transferring their energy to the walls as heat.

In ITER, this heat will be absorbed into cooling water, through heat exchangers being dispersed through cooling towers.

In the subsequent fusion plant prototype DEMO and in future industrial fusion installations, the heat will be used to produce steam, driving turbines turning alternators producing electrical output.</comment>


Microsoft updates C++ compiler - <AUTHOR> http://www.computerworld.com/s/article/9233266/Microsoft_updates_C_compiler?taxonomyId=11

<comment><USER2> tl;dr these features were FINALLY added to the Visual C++ Compiler, currently available as a Customer Technology Preview release:

Variadic templates

Raw string literals

Explicit conversion operators

Default template arguments for function templates

Delegating constructors

Uniform initialization

<comment><USER3> thanks for the explanation!

</comment></comment><comment><USER4> Does this update include the promised patch to fully support Windows XP?

<comment><USER5> That is a different CTP: [http://blogs.msdn.com/b/vcblog/archive/2012/10/08/10357555.a...](http://blogs.msdn.com/b/vcblog/archive/2012/10/08/10357555.aspx)</comment></comment>