Drop the distinction between mutable and immutable local variables in Rust - <AUTHOR> http://smallcultfollowing.com/babysteps/blog/2014/05/13/focusing-on-ownership/ <comment><USER2> Here is a koan.

Shared mutable state is evil. So functional programming languages thought: let's have no mutable state. So Rust thought: let's have no sharing of state.

Rust is not a functional programming language. It is a different approach to the same problem.

</comment><comment><USER3> I appreciate the distinction, but I believe I disagree with allowing mutability on variables without explicit statements.

In particular, I want to be able to ensure that the only variation is the variation I explicitly state - for single threaded or for multithreaded code, I don't care.

Having blobs of mutable state being passed around in a single threaded program is also a huge source of bugs. It is NOT a good idea. I don't have time today to tease out the implications of this proposal, but if it allows structs to be passed around and modified en-route in the same thread _by default_ , just like C, then Rust loses a great deal of appeal. Sorry.

<comment><USER4> Global mutable state in Emacs Lisp has been a nightmare whenever you're trying to make multiple libraries that are still being updated play nice together. Still single-threaded, still ick.

I'd go a step further and say I don't want side effects that aren't explicit either, but oh well. That's why I use Haskell :)

</comment></comment><comment><USER5>
      "that the problems with data races and memory safety arise
       when you have both aliasing and mutability. The functional
       approach to solving this problem is to remove mutability.
       Rust's approach would be to remove aliasing."

This is the crux of the argument and it makes sense to me.

<comment><USER6> I can't help but wonder if mutability and aliasing are secretly the same thing. For example, we can't optimize memcpy by reordering reads if the source and destination arrays are aliased. But if we had a hypothetical language where arrays can be mutable or immutable, we could require the source array to be immutable and the destination array to be mutable. Then we'd be able to reorder reads just fine, because writing to the mutable destination array can't affect the immutable source array!

</comment></comment><comment><USER7> I think this is a good change.

Consider a program like this [one][1]:

        fn mutter( x : ~int ) -> ~int {
            let mut y = x;
            *y = 24;
            return y;
        }

        fn main() {
            let y = box 42;
            let x = mutter( y );
            println!("x:{}", x);
        }

That's currently legal, but we mutate the box with 42 in it in a function that doesn't declare itself mut, because it has the only reference to the box, it can freely start mutating it, and then give it back at the end.

[1]: [https://gist.github.com/tbelaire/d5d6950cb0798cf6e194](https://gist.github.com/tbelaire/d5d6950cb0798cf6e194)

<comment><USER8> Interesting. However, in main(), the variable `y` can no longer be referenced, since it would fail the borrow checker. Doesn't that effectively mean that it is immutable, as it won't be referenced any longer?

<comment><USER9> I would say it's a proof that mutability is overcomplicated if you have to define it in such ways...

</comment></comment></comment><comment><USER10> Perhaps things are different in rust, but in C assignment to something which ought to not change (either by the = vs == typo or some higher level cognitive error) is not too uncommon source of bug.

Being explicit about what data should be immutable or not as a way of expressing intent helps eliminate these bugs. In rust, the mutability is analyzed strongly by the compiler and is important for the ownership rules, so I'd expected the use of the mut flag to be more successful than const is in C / C++.

<comment><USER11> Specifically, note that mistaken use of `=` vs. `==` is impossible in Rust regardless of this proposal, since:

1\. assignment is an expression that returns nil

2\. `if` expressions require their conditions to evaluate to boolean

3\. no types can be implicitly coerced to boolean

An example:

      fn main() {
          let mut x = 2;
          if x = 4 {}  // error: mismatched types: expected `bool` but found `()`
      }

</comment></comment><comment><USER12> For a language that's supposed to have its 1.0 release later this year, these sure sound like pretty significant breaking changes.

<comment><USER13> > For a language that's supposed to have its 1.0 release later this year, > these sure sound like pretty significant breaking changes.

And that is why I think Rust is one of the most exciting new languages out there. They have not been stubbornly sticking to their original plan when they found out that it wasn't really a good idea after all.

For example the change from N:M thread scheduling to native threading.

The language and the compiler have been serving as pretty nice research vehicles for advancing practical and useful programming language and compiler design.

<comment><USER12> Don't get me wrong, change to make things truly better is probably worth it. But I'm not convinced that's what we're really seeing with Rust any longer.

Many of the recent changes seem to be what I'd call "oscillation".

So a problem is noted with some specific functionality or feature of an existing programming language. A different approach is initially taken when implementing something similar for Rust. Yet problems are found with this new approach, so a different approach is tried. And problems are found with this, so something else is tried.

The matter discussed in the article appears very much to be yet another example of this.

Continually searching for some vague "optimal" solution seriously impacts the usability of the language, especially when there might not even be a solution with satisfactory trade-offs. It's disappointing when code written a week ago suddenly needs significant updates due to language and library changes, especially when the language is supposedly "stabilizing".

Rust doesn't exist in a bubble. It's facing some stiff competition from languages like C++11, C++14, Go, Scala, and even Java. Maybe they aren't as "perfect" as Rust aims to be, but they offer many of its core benefits, and they let people get work done today, while still undergoing improvement. Rust, on the other hand, appears to be stumbling around, searching in vain for some vague notion of "perfection", while being unusable to real-world developers who need at least some stability.

<comment><USER2> You are not convinced, but most Rust users are convinced. I guess time will tell.

I started using Rust from Rust 0.5 (December 2012). I saw zero oscillation so far. From what I can see, Rust is converging, rapidly.

Consider this: you can observe these at all because Rust is developed in the open. I think you would have similar reaction if you could observe Go development done behind the closed door before the release.

<comment><USER14> Actually, there are a few things in which Rust has recently gone back to old behaviour (though "oscillation" would be a bit strong as a description of it). Nested block comments is one that was removed a year or two back as unnecessary and reinstated a few months ago. I can't think of any of the bigger ones off the top of my head; calling them oscillations could also be a bit strong too, as they tend to end up subtly different when they come back—different and superior.

</comment></comment></comment></comment></comment><comment><USER15> With this (though I know it's still just proposed) and the unique pointer change[1], it appears Rust's periodic table of types[2] (often cited as a sign of over-complexity in the language) is being heavily simplified!

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

[2] [http://cosmic.mearie.org/2014/01/periodic-table-of-rust- type...](http://cosmic.mearie.org/2014/01/periodic-table-of-rust-types/)

</comment><comment><USER16> I think this is a good idea and something that has been badly misunderstood by probably the majority of the community for a long time. Consider the following code in an unspecified language:

        var int x
        x = 1
        x = 2
        print(x)
        x = 3

Clearly, "x" is a mutable variable. However, _in isolation_ , this is not really true. We've _long_ known about "Single static assignment" (SSA, [1]) and the fact that modulo memory issues, this ss equivalent to the above:

        var int x1 = 1
        var int x2 = 2
        print(x2)
        var int x3 = 3

(Obviously the next thing the compiler will observe is unused variables. Bear with me on that so I can keep the code samples simple. :) )

So in the context of a single simple executable context like this, the distinction between mutable and immutable is actually _meaningless_. Again modulo possible memory consumption issues, there's nothing you can write that will actually distinguish between "being in an immutable environment simulating mutability" (post-SSA transform) or "being in a mutable environment" in this single, small execution environment. If you can not distinguish between the two, then there _is_ no difference.

Let me highlight this again. The existence of this transform is not merely an interesting trivia bit that happens to make optimizing compilers easier to write. It is a _fundamental mathematical statement_ about the relationship between mutability and immutability at this particular scale. This is an important truth.

When does mutability matter? Well, maximally pathologically, with something like this:

        var int x
        x = 1
        spawn_a_new_thread(fun() {
           x = 2
        })
        print(x)

Now what happens? Obviously now we have a way of "witnessing" mutability vs. immutability (at least on a probabilistic basis).

Less obviously, in a mutable language with references mutability still allows "action at a distance", where a function holds a reference to some value X, calls another function with Y, and doesn't "realize" that function will also as a side effect update X. In theory, you could transform this to a purely immutable representation, but in practice, this is the same problem as in the threading case... lighter weight since now it's deterministic and that makes it much easier to deal with than the threading case, but it still explodes the complexity of the program.

The crime of "mutability" is not actually the mutability per se. (After all, under the hood it's all just RAM anyhow... if mutability was _fundamentally_ bad, we'd have already lost!) The crime is performing mutations on the context of a function without the function being aware of it. Threading makes it much worse, but even in a single-threaded context this can produce disaster. So the goal should be to ensure that functions can be assured that all the context they know about won't change without their knowledge and/or consent (to continue my anthropomorphization). More mathematically, it's _really hard_ to prove (formally or just to yourself) any particular invariant in an environment where really any time you release control (single threaded) or even just whenever (multithreaded) things you "own" may be changed out from underneath you... in the worst case, composite data structures can change _while_ you use them! The function becomes practically nondeterministic, and that's hard to work with.

A way to do this is by ensuring that everything is immutable, but for this particular purpose that's overkill. Ensuring that only things you uniquely own can be mutated works just fine... you own it, you "know" you changed it, and you've proved that nobody else can be surprised by any changes, even within the same thread, then you're back where we started at the beginning... you're a simple transform away from "immutable", and despite multithreading, the function is again deterministic.

Erlang has always struck me as suffering from this particular badly... the coding style often ends up with Value1, Value2, Value3 as we perform transforms on some value, but Value1 is immutable so we can't "update" it, but even if we could, it wouldn't matter because there's already no _references_ in the language, so there's already no way to send these things across processes. The immutability is really just an annoying side show [2], what matters is that the language has strictly value-only semantics for inter- process communication. It makes the language significantly more annoying to program in for what is basically no gain, because back in the 90s this confusion about what immutability is really _for_ was quite prevalent.

This is the key to writing simple, yet robust code; for a function to know that once it starts, there are no surprises. Whatever state it witnesses at the beginning will not change out from underneath it, so we need not continuously be screwing around with locks or fearing what other code may have references to our values.

Incidentally, true pervasive immutability becomes important if one is also _lazy_. You can't have a thunk in such a language that may end up either one thing or another, "depending". The nature of a "execution context" in such a language is very different and the line between functions becomes much fuzzier, especially with multithreading permitting true nondeterminism of thunk evaluation order. In a strict language, though, I think immutability is a side-show, what matters is ownership and change visibility.

[1]: [http://en.wikipedia.org/wiki/Static_single_assignment_form](http://en.wikipedia.org/wiki/Static_single_assignment_form)

[2]: And yes, I also know that "=" is not "assign" but "pattern match with binding", but we could trivially add a := "pattern match and re-bind" operator to the compiler and the VM would never even have to know.

<comment><USER17> _' You can't have a thunk in such a language that may end up either one thing or another, "depending".'_

Well, you _can_ , and on a very rare occasion that's what you want (see "amb"), but you should be explicit that that's what you're asking for (and probably why) because those occasions really are pretty rare and usually pretty complicated/subtle.

<comment><USER16> Simplifications, of course. :) See also "lazy IO" and the joys of "seq" and all the manifold subtleties it has.

But I'll stick to my original claim, modified by "in general"... in general, nondeterministic thunks (where "nondeterminism" means "influenced by things that are not immutably set at the function's start of execution" or something like that) is dangerous and almost (but not quite) always wrong.

<comment><USER17> For sure. I didn't mean it as a gotcha, just raising an interesting (I hope) aside.

</comment></comment></comment></comment><comment><USER18> Interesting. Clojure removes mutability in the general case and removes aliasing with transients for local mutability in the particular case.

</comment><comment><USER19> I was part of the Reddit discussion linked in the article, and although I haven't had the time to think through the issues (nor do I have the same experience as the Rust dev team), I'd like to offer some thoughts.

First, I am a big fan of functional programming, coming from OCaml and Haskell mostly and not so much experience writing software that needs to be as fast as possible. This definitely colours how I judge a language: all other things being equal, I will prefer a language that is closer to ML than to C. In most functional languages, if you want to a name to refer to a mutable cell, you need to declare it as such (let x = ref expr for OCaml, some sort of state monad in Haskell). I have grown to prefer to have as many of my variables be immutable as is practically possible: it feels like there are less moving parts in the program that can go wrong. This is a reason I was happy with Rust's initial design choice. I also quite enjoy the fact that you need to be explicit about your intent to have a variable refer to a mutable cell and that immutable is the default, unlike in languages like C or Java.

pcwalton asked what bugs immutable local variables help prevent, and honestly, I can't think of anything non-trivial. I can imagine some scenarios where a developer would get a compiler error instead of weird runtime behavior, for instance:

        let mut i = 0;
        let j = 0;
        while i < 10 {
          some_processing();
          j += 1;  // oops! meant i += 1;
        }

If `let mut` is removed from the language, this piece of code would compile, but I suspect that it should be relatively fast and easy to spot the bug and fix it. However, as a programmer, I like that a simple keyword can help me reason about code without having to inspect a larger portion of the program (i.e. scan the block containing the definition to see if the variable is modified).

Another thing that immutable-by-default local variables seem to encourage (at least, they encourage me) is to approach problems in a more functional programming oriented way. For instance, let's say you want to find the x value such that f(x) gives the greatest result. You can use regular imperative programming:

        let mut max = 0;
        let mut max_result = 0;

        for x in range(0, N) {
          let y = f(x);
          if y > max_result {
              max = x;
              max_result = y;
          }
        }

        println!("f({}) = {}", max, max_result);

But maybe you'd look at the two mutable variables and think "maybe there's a higher-level way of doing this..." and you end up with:

        let (max_result, max) = range(0, N)
            .map( |x| (f(x), x) )
            .max()
            .unwrap();
        println!("f({}) = {}", max, max_result);

(Hopefully I didn't make too many mistakes in the code.) Perhaps this style of programming doesn't need any encouragement, but for me, when I see mutable variables, I pause and consider for a moment if I couldn't perform the task in a manner that would be more declarative and less error-prone.

When I think about it, I can sort of see that it makes sense that mutability be linked to uniqueness: most problems with mutable variables comes from the fact that they can be modified in surprising ways. Though I must ask: if a reference can be mutated if you have the only reference to it, could there be cases when you want to have the only reference to a cell and still be unable to modify it (i.e. &mut const)?

Finally, I appreciate the practical implications for the compiler writers; I am part of the Sable lab at McGill where we work on a MATLAB compiler, and the crazy edges cases of Matlab are really a headache when doing any work in the system, and I can definitely understand wanting simpler semantics. If we want Rust to be a safe language, having a semantics that is simpler to implement and verify is definitely something important.

With that said, I'll re-read Niko's post (some parts, especially about closures, were not clear on my first read), and I hope that although this issue seems to be raising some passions, in the end the community and the dev team will figure out what works best for everyone and Rust will be stronger for it.

<comment><USER20> I do like the comfort of being able to nail-down local things so that they don't move, as it were. The encouragement it provides is subtle, but i do appreciate it (especially on a large team, where colleagues span the full range of the talent spectrum).

I think it's worth noting that even a very shallow notion of immutability would provide enough comfort for me. Compiler writers could call it a "syntactic blanky".

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

Something along those lines shouldn't be mutually-exclusive with the current proposal, local reasoning being sufficient. Something like 'final' or 'const' (or, better still, replacing the 'let' keyword with 'val' and 'var' as in Scala.)

</comment></comment><comment><USER21> He lost me somewhere at closures.

> This is the same problem as the Env example above: what's really happening > here is that the FnMut trait just wants a unique reference, but since that > is not part of the type system, it requests a mutable reference.

Wait, what? The closure `|| * errors += 1` wants a _unique_ , but _NOT_ a _mutable_ reference to it's environment, so that it can _mutate_ the `errors` variable?

I guess that using `only`/`uniq` instead of `mut` would definitely be clearer and less confusing. Although I don't understand why they want to remove local immutable variables, which IMO have nothing to do with "immutability", but rather with "rebinding".

<comment><USER22> For a reference to be mutable, it has to be the only outstanding reference to an object. You can create as many immutable references as you want, because the object can't change. On the other hand, if you have the unique reference to an object, there's no particular reason you shouldn't change it.

Rust's mutability is more than rebinding, though. If you want to change a value of a field in a structure, which is something that doesn't involve rebinding the variable, you have to have a mutable variable holding the structure. The mutability is "inherited" from the variable.

</comment></comment><comment><USER23> We changed the title to the portion of the first sentence that describes the topic.

</comment><comment><USER24> I like the idea of &only as it greatly simplifies an understanding of the borrow checker. However, I think we still need to be able to mark things as immutable for things like rodata stuff, mapped in rom, persistent data structures, etc. And if we're going to be marking mutability, I would prefer immutable to be the default. It probably matters more for function arguments than locals, though.

</comment><comment><USER25> I thought the following was fairly illuminating:

        if the compiler says something must be mutable, that
        basically always means I forgot a mut keyword somewhere.
        (Think: when was the last time you responded to a
        compiler error about illegal mutation by doing anything
        other than restructuring the code to make the mutation
        legal?)

</comment><comment><USER26> Fine, if you want to remove mut, then add const

</comment><comment> one-more-minute This seems like a mut point.

<comment><USER27> Downvoters seem intent on muting you.</comment></comment>


Sun, Java, IBM and Eclipse - <AUTHOR> So I just happened to read why Sun microsystems failed even though it produced crazy stuff like Java, Solaris, ZFS etc. In that article, amongst other mistakes, I found out that it was getting heavy competition from IBM, HP and others for Java. Sun marketed Java as a language that you write once and run anywhere, and then said that it ran best on Solaris servers. It was reluctant in making Java truly open, and in response to that IBM open sourced a bunch of tools for Java dev. It caused quite a lot of economic and strategic damage to Sun because it was investing heavily in making a proprietary tools business for Java. One of the tools released is called Eclipse. Do you realize the irony.<p>Sun. Eclipse. <comment><USER2> You are fifteen years late with this observation, I'm afraid.</comment>


Is Sugar the Next Tobacco? - <AUTHOR> http://www.psmag.com/health/robert-lustig-sugar-obesity-diet-50948/ <comment><USER3> It's very bad, it's everywhere and addictive in ways you could never realise. Sugar addiction is very related to carbohydrates. When I cut carbs (and increased fat content) I also lost all interest in sweetness and sugar. Not even diet cokes.

When I was my fittest, I had totally cut sugar/carbs out. Even complex carbs (meh, not much benefit of "complex carbs anyway). I was running on ketone or whatever the terminology is. I was swimming everyday for two hours with no problems what so ever. I was basically running on fat. This takes a while, usually 2-3 weeks to get into.

Usually when I switched from carb loaded fuel to fat. It took a day of being tired and sleepy. That's it. But it takes a bit longer to completely exercise on fat than just running normal errands.

Most "low calorie" or "low fat" branded "food" products usually have high sugar content. The low fat version of the cremé fraiche we USED to consume at home had more sugar and/or carbs than the high fat one. We consume the latter these days and gain no additional weight. We're not as easy as thermo dynamics, it's more complicated than kcal in/out. Which is why most people prefer carbs/sugar instead of fat. Since the kcal per fat grams is higher.

EDIT; That being said, I've seen the opposite in my partner who happens to be of Chinese descent and others of similar background. The only explanation I have is that their bodies are more advanced than our primal vessels :-)

<comment><USER4> I thought this was satire until I got to the end. The human body needs carbs to run. I'm really skeptical that someone can exercise for two hours without any carbohydrates in their system.

<comment><USER5> No (or low) carbs is a pretty common dieting technique, originally made famous (at least where I am) by the Atkins Diet. My simplistic understanding of it is that when carbs are not available, your body burns fat instead, starting with the fat you consume and then if necessary the fat that your body has previously stored (hence losing weight). A colleague of mine does this for a month once a year to get a bit fitter ahead of his scuba diving holiday, and it works wonders for him.

Regarding long-term use of this diet, it would seem that opinion is divided and I've no idea which side is likely to be right - <http://en.wikipedia.org/wiki/No-carbohydrate_diet> is probably a decent place to start if you want to find out more. But certainly, while it's suggested that long-term use may not be a great idea, there's nothing to say that it would cause problems such as not being able to exercise for two hours a day.

<comment><USER3> I don't think his concern was wether or not it was doable for general use, just for exercise. It's very doable.

</comment></comment></comment></comment><comment><USER6> We will end forbidding everything. Besides, taking sugar is a personal option wich doesn't kill anyone around you. Tobacco while you smoke you make smoke everyone the room, even on the street. We just need education to measure the excesses.

<comment><USER7> If it really does lead to obesity and the connected illnesses, treatment will indirectly take money away from all of the other people with the same insurance company.

Then again, you might not take back as much of your retirement fund :)

I guess ?once/if? insurance companies start charging premiums for people with a diet high in sugar/carbs, this will become a more interesting conversation.

<comment><USER8> _f it really does lead to obesity and the connected illnesses, treatment will indirectly take money away from all of the other people with the same insurance company._

Socialists like rb2k claim that every individual action has some reprehensible act on "society".

The new (or maybe old) tactic of the fascist left.

</comment></comment></comment><comment><USER9> I don't get these health related HN submissions. Salt bad, sugar bad, wheat bad, fitness is a lie... what's next?

I dont't troll. I just don't understand why all of our basic foods are now bad. Guess we made them bad as we put sugar and salt in everything...

<comment><USER9> Like back in the day my grandmother was cooking with lard. Lard from pigs that she kept in her own farm. Later lard also became bad (except bacon which is good...). Nowadays lard is coming back and do you know who uses it? Haute cuisine restaurants.

<comment><USER10> They also use lots of other fats, and lots of salt, and lots of sugar.

They use it because it's tasty.

"Supersize Me" on Haute Cuisine would have similar catastrophic results, but be considerably more expensive.

<comment><USER11> Nonsense, the problem with McDonalds and other fast food restaurants is that it barely qualifies as food -- it uses as few real ingredients as possible because real ingredients have a short shelf life.

<comment><USER12> What non-real ingredients do you think they use? Hamburgers are pretty simple. It's not like Kraft selling guacamole made with food coloring instead of avocados.

<comment><USER13> I've no idea what mcd.s does, but you can add all sorts of crap to hamburger before it becomes _too_ obvious. Probably a lot of it is not ... so appetizing (the bits you don't want to know you're eating, etc).

My mom used to buy hamburger meat that was bulked up with soy protein, mainly because it was cheaper than pure ground meat. [I absolutely loved the taste of that stuff actually, much more than all-meat burgers! Wish I could find it as an adult...]

</comment></comment></comment></comment></comment></comment><comment><USER14> There's an easy fix for that: a shift from sugar to artificial sweeteners. Same as there's an easy fix for cigarettes: move to electronic cigarettes.

But i guess we're more afraid of the unknown chemicals(although limited tests have shown they are much safer) than the original poisons, And we're stuck on trying to teach ideals than implement practicalities.

Such a shame.

<comment><USER5> There are other reasons for not switching as well. As an overweight smoker... I drink normal soft drinks rather than diet (sweetener) drinks partly because of vague things in the back of my head about them being carcinogens, but largely because I'm not a fan of their taste.

Regarding smoking - well I've cut down lately, I was smoking 20-30 a day and in November/December, with the exception of two trips abroad where I smoked fully, I cut down to about 20 cigarettes over the two months, due to a challenge from a friend's kid - I simply don't want to move to electronic cigarettes. I love smoking, if it wasn't unhealthy I'd do it forever. I don't love smoking an electronic cigarette, I don't even like it. I'd genuinely prefer to spend a day without nicotine than a day with electronic cigarettes, or nicotine gum/patches.

<comment><USER14> I switched to sweeteners due to too many trips to the dentist and loving sweet things. I started by changing my coffee from sugar. There are many types of sweetener to choose from , so i've experimented until i found something i liked.

But you do have to have a strong enough reason to switch, not something abstract that will happen in 20-40 years.

</comment></comment></comment><comment><USER15> "You want to get As and As? Eat breakfast."

"I don't have time to eat breakfast," the [13 year old] girl said.

"She'd rather put on makeup than eat breakfast," the girl's mother interrupted.

I'm a Lustig fan, but the people who deserve an overwhelming about of the blame here are the parents.

</comment><comment><USER16> Sugar is bad. I'm trying hard to quit using it, but it's EVERYWHERE! I bought some smoked salmon the other day and the damn thing had sugar put in it! Why?! The same goes for a lot of supermarket sold crap. Sugar, sugar, sugar.

<comment><USER17> The first thing I noticed about American food is that all their bread has sugar in it. I've absolutely no idea how anyone can stand eating the stuff.

<comment><USER18> It's been a while since I was making bread regularly, but I don't think I've ever seen a bread recipe that didn't include sugar. I was under the impression that yeast must eat _something_ in order to make the dough rise.

edit: It looks like my mother has found some, but neither one of us really understands how rising works in these cases.

<comment><USER17> I make my own pizza dough and other breads that rises quite happily with no sugar in the mix. There's really no need for sugar, though I don't know enough about yeast to tell you how it works.

<comment><USER13> AFAIK, the yeasties will eat lots of stuff, including flour, etc.

[I vaguely recall adding not sugar, but _corn starch_ to warm water to get the yeast going. It's been a long time though ...]

</comment></comment></comment></comment></comment><comment><USER19> Add wheat to that list, perhaps even gluten too. The body just runs better without gluten.

<comment><USER20> This got some downotes. If you're skeptical, have you bet TRIED to quit wheat?

It's incredibly hard. I stopped, but it took months of cravings. Very easy to stop eating almost anything else, usually.

<comment><USER15> Don't know about wheat, but are you implying that something's bad simply because it's hard to quit?

<comment><USER19> If you're interested to learn more relating to wheat, there's a book that recently has gained a lot of popularity called Wheat Belly. It goes into the biology of it all.

</comment></comment></comment></comment><comment><USER21> Robert Lustig, while having great science to back up his claims, is very alarmist and has been derided for some of his outright demonization of fructose. Which, when you think about it, is opposite to many demagogues out there; they'll talk up a big storm with very little to back it up. Here, Lustig has plenty to back up what he's saying, but just does it in the wrong way unfortunately. I also thoroughly disagree with his legislation ideas. Legislating society's habits rarely ever works. This is an incredibly complex societal problem that won't be solved by removing sugar from the Generally Recongnized as Safe list.

<comment><USER19> I think for some things to gain attention being alarmist is needed, and then people will hopefully come to their own conclusions after researching it. Sugar is pretty much in everything we eat. It covers over a lot of other issues, mainly that we don't eat as much fresh food as we should - <USER2> we wouldn't need sugar to make it taste good. This is profitable for business, not profitable for a person's health.

</comment></comment><comment><USER22> And for an alternate viewpoint - [https://secure.huffingtonpost.com/david- katz-md/sugar-health...](https://secure.huffingtonpost.com/david-katz- md/sugar-health-evil-toxic_b_850032.html)

"So while fructose as an ingredient excessively engineered into processed foods is, indeed, a problem- I find it far-fetched at best to suggest the native composition of, say, berries is "evil." Lustig seems to be tossing out the the strawberries with the soda. You find me the person who can blame obesity or diabetes on eating strawberries, and I will give up my day job and become a hula dancer."

<comment><USER23> That article does not really disagree with Lustig's central thesis. That pull quote in particular is actually in accordance with what Lustig is advocating. The lecture focuses on the recent trend in the food industry of separating the fructose from the fiber in ways not found in nature.

</comment></comment><comment><USER24> I started the slow carb diet last year for new years resolution. At the time I was addicted to peanut M&M's. Took probably 3-4 months to completely rid myself of the temptations to eat a large bag of them. Anyways, in addition to that time period I can remember the first week of the diet feeling the need for a piece of bread. I was like feigning for it. But I resisted. Definitely surgars have withdrawal symptoms, but with so many different foods and drinks out there I do think its an easier addiction to cure than any drug like alcohol or tobacco or even heroine for that matter.

</comment><comment><USER25> Why was this article suddenly de-ranked? It was on the front page, and literally 10 seconds later it is on page 3. Is there some kind of rule that this article violated? Who makes this decision? Why is there not any transparency on if an article is de-ranked and why?

<comment><USER5> There's an argument, though I don't want to put words into PG's mouth regarding his reasoning, that lack of transparency is a form of protection against voting manipulation, as it's harder to trick a system if you don't understand the system - security through obscurity really.

As it dropped only to page 3, not further, I would hazard a guess that it's more to do with timing, for example maybe a post that's <60 minutes old requires less votes to get a high position than a post that's 60+ minutes old, and it's a hard line rather than gradual? Pure speculation on my part, but if you're interested the answer may (or may not) lie within <https://github.com/nex3/arc/blob/master/lib/news.arc>

</comment></comment><comment><USER26> While it's a good idea to get people off sweet stuff beyond the level of healthy fruit intake, I think it would also help if people stopped demonizing sweeteners like aspartame.

<comment><USER11> How about we just kick the sweet tooth entirely instead of substituting it?

</comment></comment><comment><USER8> _especially after he proposed in the journal Nature that sugar should be regulated like alcohol and that people who buy soda should be carded._

Another sick leftist that wants to regulate every human activity.

<comment><USER27> Any particular reason you felt it necessary to make _three_ vacuous top-level replies? Bundling everything you had to say into one post would have been _some_ improvement, at least.

<comment><USER10> He got replies to each response which is vaguely disappointing.

I'm not sure how the HN "anti down vote rampage" works - if I downvote all three posts do all my downvotes count? Or is there something that detects I'm downvoting 'too many' posts by a single user and silently drops some of my downvotes?

</comment></comment></comment><comment><USER8> _The suits against Big Food have largely been stalled at the failure stage._

Big Tobacco, Big Oil, and now Big Food. These socialists are sick in the head.

<comment><USER28> Really? You think the tobacco industry was doing nothing wrong and the evil socialist came around and attacked them for some socialist agenda?

<comment><USER8> Woosh right over your head. That certain political agendas prefix industries with "Big" doesn't make you think. Yeah, whatever

</comment></comment></comment><comment><USER8> At what point do we start talking about sanctions against leftist-statists like this guy and others who want to essentially enslave us.

At what point is enough is enough, and these people are held to account for infringing on civil liberties.

<comment><USER29> So, someone uses his civil liberty to state his opinion and you want to "held him to account" for "infringing on civil liberties" - <http://en.wikipedia.org/wiki/Irony></comment></comment>


Where Yahoo Leaves Google in the Dust - <AUTHOR> http://www.nytimes.com/2009/08/23/business/23digi.html?hpw <comment><USER2> People are happy to pay for information that's of value to them. How does Google Finance make money, by showing ads to people who are preoccupied with their own business?

<comment><USER3> Well the people looking at Google Finance are generally well-off.

It's the same reason why advertising on Bloomberg TV or CNBC is expensive.

</comment></comment><comment><USER4> This article reads like a bunch of notes. Not much interesting stuff and zero flow. oof</comment>


Dutch police are confiscating expensive clothes from kids who look too poor - <AUTHOR> https://qz.com/1182962/dutch-police-are-confiscating-expensive-clothes-from-kids-who-look-too-poor-to-wear-them/ <comment><USER2> What the hell? What if the clothes where a gift. Also what if they bought them from thrift store. I have seen many times fancy designers clothes at thrift stores for pennies on the dollars. People keeping up with latest trends usually get rid of the ton clothes they buy some how.

Rolex's I could understand that a little more. However, still owning a Rolex is not a crime... Complete and utter crud.</comment>


Share CSS between devs and designers. - <AUTHOR> http://sw4tch.com/swatchbooks/4

<comment><AUTHOR> You can edit these swatches with CSS, SCSS and Compass, or Stylus and Nib. Check out the editor:

<http://sw4tch.com/swatches/6></comment>


It's Behind You: The making of the game R-Type on the ZX Spectrum - <AUTHOR> http://bizzley.com/

<comment><USER2> This book is awesome for anyone who lived those days.

"the PDS assembler could only handle source files up to a certain size so the more you commented your work the less room you had for the actual game code itself"

<comment><USER3> Reminds me of trick from the Commodore BASIC days, where you could use "?" as a replacement for "PRINT" to save a whopping 4 bytes. Seems silly now, but back then it made all the difference.

<comment><USER4> Don't know about Commodore BASIC, but in Locomotive BASIC on the Amstrad CPC, "?" was just a text-entry convenience rather than a memory-saver. BASIC was stored tokenised, so "?" was one byte same as "PRINT" (in fact, I think it was the same byte).

<comment><USER5> Yes, it's that way on C64 too - it didn't save any space.

People certainly did do a lot to save space through omitting spaces, using ";" to separate statements instead of new lines etc.

<comment><USER6> In Commodore BASIC you use ":" to separate statements. ";" is used at the end of a PRINT statement to keep it from appending a newline.

</comment></comment></comment></comment></comment><comment><USER7> I just read the whole thing and it was definitely worth it! If you like these kind of coder memoirs (especially if you like _Masters of Doom_ ) then this will be right up your alley. Plus I'm an R-Type fan so that's an added bonus.

As I was reading it I couldn't help but feel a bit of regret. It was in 1991 on a visit with my dad to LA that I got my first computer (a TRS-80 Model III) along with a book on programming in BASIC. I didn't know what I was doing, but I wanted the computer to do the stuff I saw on _War Games_ and _Explorers_. I got pretty far but it wasn't until 1996 or so that I really got into the swing of "serious" programming in C and C++. Growing up in Dallas, TX I didn't have the first clue where I might find people interested in this stuff. Until sophomore year in college it was really just me. I find that I regret not having lived in a place where I could have "gotten into the scene" early. This is even more ironic considering that my idol at the time (and arguably today as well), John Carmack, worked less than 5 miles from my house!

</comment><comment><USER8> Downloading the PDF takes quite a while D: Maybe they're being overloaded a bit? Anyway, here's a mirror of the book's PDF (14MB): [http://f.cl.ly/items/1C1J1c3W0V2e1903453r/It%27s%20Behind%20...](http://f.cl.ly/items/1C1J1c3W0V2e1903453r/It%27s%20Behind%20You-%20the%20making%20of%20a%20computer%20game%20by%20Bob%20Pape.pdf)

</comment><comment><USER9> From reading this, it appears the only reason we had any decent 8-bit games at all was due to professional pride and heroic effort on the part of the bedroom programmers employed! He was largely left to his own devices (but given a tight deadline).

Bittersweet moment in the book - the photo of some suit accepting the "best game" award for his game. They never even bothered to tell him he had won...

</comment><comment><USER10> "My original plan was to self-publish this book and put it up for sale - at a purely nominal price of course (ahem) - and maybe make a few pounds from the thing but there's a part of me that finds this idea just wrong"

There is nothing wrong with making a few pounds from such an interesting story. I'm sure there is more people around like me who actually find a pity not being able to easily purchase a physical copy of this book. I actually find quite convenient to pay for not having to print it ( I mean book printing ) myself. And I actually love to have physical books too, specially this sort of books :)

</comment><comment> n-gauge This is a fantastic read, brings back many memorys of my youth. One thing I was thinking about was the undisclosed multiface backup hack that was mentioned. I believe this could have been done using the Z80 shadow registers, which was a copy of all the Z80 registers in a seperate bank and had to be switched to in by code. If these were used instead via in game switching the multiface 1 would not be able to switch to the shadow registers, it would just copy the main registers, so storing a key in the shawdow register would defeat the multiface 1.

...and thanks again to the op for this ebook.

</comment><comment><USER11> Can't wait to read the PDF! Thank you Bob.

One of the best games ever and an unbelievable ZX Spectrum port.

I still remember holding and reading the box cover from the shops to my home.

And, shameless plug, this is what I did for my summer vacation project: "R-Type Real Time Memory Visualisation" ZX Spectrum [http://zaf.io/page-3o.html#p139](http://zaf.io/page-3o.html#p139)

</comment><comment><USER12> Neat, check-out the sprites for Lizzy and George from Rampage, they are often the same when not in profile! They're under the Extras button.

</comment><comment><USER13> One of my favorite games I played on my Spectrum and on a friend's Amiga.

<comment><USER14> I played it on my MSX-2 just checked on youtube to remember how it was: [http://www.youtube.com/watch?v=QkBL8KjAyDs](http://www.youtube.com/watch?v=QkBL8KjAyDs)

the scrolling was choppy but the action was.. action!

</comment></comment><comment><USER15> I learned to program on the ZX Spectrum. Ahhh, memories...

<comment><USER16> Spectrum? You youngsters had it easy. I cut my teeth on a ZX81.

<comment><USER17> I had a ZX81... nearly put me off for life [http://rdn32.com/2013/07/28/how-i- got-into-programming/](http://rdn32.com/2013/07/28/how-i-got-into- programming/)

When I visited the Centre for Computing History ([http://www.computinghistory.org.uk/](http://www.computinghistory.org.uk/)) I noticed that as well as having games for their collection of 1980s home computers, they also had developer tools. Having read about Ian Bogost's "A Slow Year" (for the Atari 2600) it occurred to me that making new games for old machines using "period instruments" might be an interesting exercise. What I had in mind was games that would never have been written at the time, but that would have been technically feasible.

That's as far as the idea got because, er, I'm not a games programmer. As close as I got to an actual idea was that perhaps it would be possible to write a Tetris clone for the ZX Spectrum. Can anybody think of something better?

</comment></comment></comment><comment><USER18> This looks like a great read. It must have been challenging to do a decent arcade conversion for the 8 bit home computers. The spectrum was probably slower than the z80 sound cpu in the arcade board.

</comment><comment><USER19> Note that the book is freely available, but the game unfortunately is not (or at least [1] says "distribution denied").

[http://www.worldofspectrum.org/infoseekid.cgi?id=0004256](http://www.worldofspectrum.org/infoseekid.cgi?id=0004256)

I remember that the Spectrum version of the game was very good, with full colours (perhaps thanks to very fast 8-pixel jumps), as well as the arcade machine it was based on.

<comment><USER20> Some nostalgia, then - [https://www.youtube.com/watch?v=56IFFd43acU](https://www.youtube.com/watch?v=56IFFd43acU)

That includes the full experience of loading the game from tape. I guess on those who had a ZX-Spectrum will bother watching.

For actual game-play footage , jump to 5:38 - [https://www.youtube.com/watch?v=56IFFd43acU#t=5m38](https://www.youtube.com/watch?v=56IFFd43acU#t=5m38)

</comment></comment><comment><USER21> The tune is blasting in my head now. Title tune by Huelsbeck and level 1 by Whittaker... these two wrote so many great game tunes.

<comment><USER22> Great composer, no doubt, but slow (Estimated delivery: Dec 2012) going with the Turrican Soundtrack Kickstarter [0].

0: [http://www.kickstarter.com/projects/chris- huelsbeck/turrican...](http://www.kickstarter.com/projects/chris- huelsbeck/turrican-soundtrack-anthology-by-chris-huelsbeck)

<comment><USER21> Thanks for the heads up!

</comment></comment></comment><comment><USER23> I play that game on my nexus 7 ([https://play.google.com/store/apps/details?id=com.dotemu.rty...](https://play.google.com/store/apps/details?id=com.dotemu.rtype))

love it :)

</comment><comment><USER24> Does anyone else see the logo image moving in a weird way? like when you are not exactly looking at it, it feels like animating, like those fancy optical illusions. (sorry for being off-topic but this is bothering me)

</comment><comment><USER25> This is a great little book.

</comment><comment><USER26> I've got to say that for anyone who owned a micro in this period, you should spend an evening reading this book. I loved it, fascinating stuff!

</comment><comment><USER27> it's so rings a bell: [http://www.dotkam.com/2008/11/19/zx-spectrum- child/](http://www.dotkam.com/2008/11/19/zx-spectrum-child/)

</comment><comment><USER28> This made my day!</comment>


The Theory Behind MP3 (2002) [pdf] - <AUTHOR> http://www.mp3-tech.org/programmer/docs/mp3_theory.pdf <comment><USER2> If this topic interests you, I highly recommend "MP3: The Meaning of a Format" by Jonathan Sterne as well as his previous work, "The Audible Past: Cultural Origins of Sound Reproduction." The former does a pretty good job of explaining the basics of the MP3 format and gives insights into how it has influenced the production of sound recordings.

</comment><comment><USER3> TL;DR Visual.ly needs to turn this into an infographic</comment>


PlantUML Updates to "CoronaVirus License" - <AUTHOR> https://plantuml.com/license <comment><USER2> This is silly.

Reading through the complete licensing terms... even to this non-lawyer, the author(s) don't seem to understand licensing.

So there's the CoronaVirus License, thingy....

A little further down the page... "PlantUML is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. "

OK... so that's contradictory.... there's no "or" in picking a license and terms of one license are, in principal and spirit, antagonistic to the terms of the other.

And then there's a very confusing bit about image ownership...

That wipes this UML tool off my candidate tools list.

</comment><comment><AUTHOR> I do believe that the author's heart is in the right place here, but I wonder what this is going to do to corporate adoption of PlantUML.

As an individual user, I have no issue with the license.

As a consultant, I am making sure my clients are aware of this very strange update.

I would urge the author to please consider offering a plain OSI-approved license, at the risk of losing considerable adoption.

</comment><comment><AUTHOR> UPDATE: The PlantUML team responded to my question, and says this is a very temporary license change.

[https://forum.plantuml.net/11018/will-you-reconsider-the- cor...](https://forum.plantuml.net/11018/will-you-reconsider-the-coronavirus- license)

</comment><comment><USER3> Chalk it up to over reaction without sufficient consideration</comment>


Bountyhunting at Conviro - An early stage product development experiment - <AUTHOR> http://conviro.tumblr.com/post/59405025897/bountyhunting-at-conviro-an-early-stage-product Curious to hear the Hackernews community's thoughts on a bounty system for getting stuff done. It has been a fun experiment so far. Has anyone done something like this? <comment><USER2> Interesting idea. Incorporate BDD tools for definition and validation to minimize ambiguity.</comment>


What has shut down and what will possibly shut down - <AUTHOR>

    MegaUpload - Closed.
    FileServe - Closing, does not sell premium.
    FileJungle - Deleting files. Locked in the U.S..
    UploadStation - Locked in the U.S..
    FileSonic - the news is arbitrary (under FBI investigation).
    VideoBB - Closed! Will disappear soon.
    Uploaded - Banned in the U.S. and the FBI went after the owners who are gone.
    FilePost - Deleting all material (will leave executables, pdfs, txts)
    Videoz - Closed and locked in the countries affiliated with the USA.
    4shared - Deleting files with copyright and waits in line at the FBI.
    MediaFire - Called to testify in the next 90 days and it will open doors. Pro FBI
    Org Torrent - Could vanish with everything within 30 days "he is under criminal investigation"
    Network Share mIRC - Awaiting the decision of the case to continue or terminate Torrente everything.
    Koshiki - Operating 100% Japan will not join the SOPA / PIPA
    Shienko Box - 100% working China / Korea will not join the SOPA / PIPA
    ShareX BR - group UOL / BOL / iG say they will join the SOPA / PIPA
 <comment><USER2> Seems like they went after everyone. 2012 has not been so good for these types of sites.

<comment><AUTHOR> I agree. I wonder if they'll start coming after sites like Youtube and Tumblr as well.

<comment><USER3> How about Hacker News? I see someone just posted a list of file sharing sites on it, that's got to be illegal somehow? <http://news.ycombinator.com/item?id=3503788>

<comment><AUTHOR> I sort of expected this reply, needless to say I'm not surprised. I compiled the list just so people will know, if they go after this thread, then they're sickening.

</comment></comment></comment></comment><comment><USER4> what about rapidshare/ifile?

<comment><AUTHOR> I tried looking that up, as of typing, they have not yet issued any statement. So I think they're still good. However, it must be remembered that Rapidshare has had some issues as well too.

Rapidshare has already been involved in numerous lawsuits in Germany and I believe have come out on top on the important ones.</comment></comment>


D at 20: Hits and Misses [pdf] - <AUTHOR> https://digitalmars.com/articles/hits.pdf <comment><USER2> I think the presentation exposes the big picture: D is a _very_ loaded language. It tries to serve every possible exotic need imaginable. Probably not as much as C++ but that's a committe-designed language, it doesn't count.

The feature bloat makes it very hard to learn D, let alone being an expert on it. I think it's telling why its creator focuses on individual features to assess its success. Now, all those missed features either have to be maintained or carefully removed which is a lot of work and might actually break existing code.

I like D because of its vision: C++ for humans. It fails on that vision simply because it has become a gigantic incoherent product like a research project.

It probably needed a harsher approach to feature requests to make sure the language stayed on the vision. Now it's a programmer's dream and a programmer's nightmare at the same time.

I think Go, for instance, has made a better decision to stay barebones.

I see that the creator intends to include Rust's borrow-checking semantics which reminds me that Rust is probably what D should have been in all aspects.

<comment><USER3> > The feature bloat makes it very hard to learn D, let alone being an expert > on it.

Learning 100% of any programming language should not be a goal. I know less than 10% of the functionalities of my microwave oven or my washing machine. This doesn't prevent me from successfully using them and save a lot of time.

Bjarne Stroustrup himself says learning all the nitty-gritty details of C++ is counterproductive and unnecessary.

<comment><USER4> The problem with feature bloat is related to a very well known fact: Code is read more often than it is written. As a consequence, if you don't know the little details of a language, it might be a harder to read code written by someone else that is more knowledgeable.

Consider for instance Lua, which is often read by people that have superficial knowledge of the language. Lua has a very standard syntax that anyone with basic general programming knowledge will understand:

> player:set_pos({x=0, y=0})

But it also has syntactic sugar:

> player:set_pos{x=0, y=0} -- note the braces instead of parens

This is where you lose half of your readers because they have to look for that weird syntax in the manual.

In defense of language implementers, it is sometimes difficult to "resist" feature requests. It's difficult to say "no" in general, in particular when you are not Niklaus Wirth and have half a dozen languages designs on your resumé; all you have is your gut feelings as justification.

<comment><USER3> I have 15 years experience as a professional C++ programmer in various teams and companies (and although I don't know 100% of C++17, I consider myself productive!).

When diving into new codebases, the couple of esoteric-used-features-you-did- not-know-existed in C++ was never a big deal. Learning the required C++ features was always a matter of days (because the codebase is full of real examples).

Understanding the overall structure of the code, the interactions/dependencies between the components, in what file/directory should go your first feature... this is the hard part. And it's many orders of magnitude harder than learning a couple of new language features.

Don't get me wrong, I'd really like that C++ and D be smaller, and I don't like feature bloat. I once wrote a source code processor based on clang, and then you realize how big the language really is (there are _many_ AST node types), and having all your code written in it starts to feel like technical debt.

However, I pragmatically have to recognize that feature bloat isn't a real problem for professional C++ programmers (It might be, for compiler vendors - at this point, I'm not expecting any new C++ compiler to be created).

PS1: C++ certainly gives you some shiny tools to make interesting messes (I've seen codebases where simply including a header would change the program behavior). This isn't related to the feature count, but rather to the semantic of the individual features themselves, like macros/templates. At least we don't have monkey patching ...

PS2: About your Lua example: even without knowing the syntax, can you sincerely have the slightest doubt about what "player:set_pos{x=0, y=0}" actually does?

</comment></comment></comment></comment><comment><USER5> Looks like this is slides from a talk Walter Bright gave which has been posted to YouTube [1]. It helps with some missing context.

For example, I wondered why in the slides he felt implementing contract programming in D was a miss; it seemed like a strong selling point for the language. According to the talk (around 1:34:30), however, he felt that contract programming was relatively unpopular/unused in D and that "assert" covered most of the use cases for it.

[1] [https://www.youtube.com/watch?v=p22MM1wc7xQ](https://www.youtube.com/watch?v=p22MM1wc7xQ)

<comment><USER6> Contracts are interesting but I think to make it usefull 1) are ON on release! and 2) Become part of the docs.

One example:

         fun date(y:i32, m:i32, d:i32)
         {... code ...}

This scream for more context (and better param names!). With contracts:

         fun date(y:i32, m:i32, d:i32)
         assert
             y in 0..9999
             m in 1..12
             d in 1..31
         {... code ...}

But I need to see it in the docs, in the tooltips, etc. Now are useful!

<comment><USER7> Good old February 31.

<comment><USER6> Nothing like a bug behind a safety feature :)

<comment><USER8> That's … not a bug.

A buggy assertion would be one that fires when the input is correct.

Assertions aren't formal verifiers or replacements for a test suite.

</comment></comment></comment></comment></comment><comment><USER9> I use binary literals all the time, for what it's worth, in code involving hardware interfacing. Only complaint with C++14's implementation is that they didn't allow underscores to be inserted for clarity, a la Verilog.

Those underscores turn out to be a _really_ big deal, and leaving them out of C++ was a massive mistake. Nobody wants to read constants like 00110100101101011011011101011110, but 00110100_10110101_10110111_01011110 is fine. An implementation of binary constants that doesn't allow this is going to be less popular.

<comment><USER10> You can use ' as the digit separator, like:

        0b00110100'10110101'10110111'01011110

It's not ideal, but using underscores was off the table, because things like _100_ are actually valid variable names and it would have caused parsing issues.

<comment><USER11> _100_ is an identifier in D, too. The simple rule is _ can be embedded in a numeric literal, it just cannot start one.

<comment><USER10> Actually I got this wrong - the ambiguity occurs with C++11 user-defined literals, not with variable names. See [http://www.open- std.org/jtc1/sc22/wg21/docs/papers/2008/n274...](http://www.open- std.org/jtc1/sc22/wg21/docs/papers/2008/n2747.html)

</comment></comment></comment></comment><comment><USER12> Interesting that garbage collection is listed as a miss due to latency, and Go has gotten popular with garbage collection with an emphasis on low latency.

<comment><USER13> The big issue is lack of technical resources to improve GC's performance on D's runtime.

Some improvements have been made lately, but not at the level of manpower and CS background from other GC enabled languages.

I am quite confident that if D had something like Microsoft behind it, its GC would long be as good as Sing# or System C# (M#) were.

<comment><USER11> > The big issue is lack of technical resources to improve GC's performance on > D's runtime.

The underlying issue is that to make the GC more performant requires the addition of "write gates", where writing through a pointer notifies the GC that the memory object has changed. This is a reasonable choice when a language is heavily GC dependent (like Java).

However, D is not at all heavily GC dependent. But it is very dependent on memory references. Hence the GC speedup from adding write gates would be more than lost from the cost of executing those write gates.

</comment></comment></comment><comment><USER14> Will the "misses" be removed from D eventually?

<comment><USER15> Many of them have been already.

<comment><USER11> A tree needs pruning now and then :-)

<comment><USER16> I hope that doesn't mean removing the GC in favour of borrow checking or manual memory management.

<comment><USER11> The GC, although often maligned, is highly useful and will stay.

</comment></comment></comment></comment></comment><comment><USER17> What I find D interesting is that it is a really good fit for scientific programming. Maybe Julia is an answer, but in terms of producing interoperable code, it is the holly Grail. And people can port their Java code mostly painlessly. Science is the killer app of D where GC is a blessing in disguise.

</comment><comment><USER18> Some of the slides are contradictory: miss lack of safety by default and miss focus on GC. Well if you want safety by default, then either you use a GC or you're a Rust/cyclone clone, I don't see a third way..

<comment><USER13> The third way is not throwing out the baby with baby water.

The path pursed in the past by Mesa/Cedar, Modula-3, Sing# or more recently System C#.

Provide automatic memory management by default, while offering all the tooling stack and global allocation, with low level stuff and untracked references requiring explicitly unsafe code.

For more modern approaches that combine those ideas with Cyclone ones, Chapel, Swift, Ada/SPARK, ongoing Haskell and OCaml support for linear types.

So you get the productivity of automatically memory management, graphs, self referencial structures and what not, while being able to go low level for more fine-grained resource management.

</comment></comment><comment><USER19> D is 20? That's.......telling.

<comment><USER20> That is if we count the development of D1 which appeared in 1999. Later in 2007 D2 emerged with breaking changes. D1 was discontinued in 2011 and D2 became simply D. So, yes formally D is 20 years old but one could say that it's newer reworked version is just 12.

<comment><USER11> I _started_ on D 20 years ago. It was a couple years before I even managed to make a prototype that people could play with. 20 years ago it was a few notes on a piece of paper :-)

</comment></comment></comment><comment><USER21> I guess they never miss huh</comment>


Battery breakthrough: Double performance lithium battery that doesn't catch fire - <AUTHOR> https://news.umich.edu/battery-breakthrough-doubling-performance-with-lithium-metal-that-doesnt-catch-fire/ <comment><USER2> Having read through a lot of battery breakthrough reports, I tend to zero in on the 'hard bit' which in this particular case is here: _U-M researchers solved this problem with chemical and mechanical treatments that provide a_ pristine _surface for lithium to plate evenly, effectively suppressing the formation of dendrites or filaments._

My reading of that was _if_ you create this _pristine_ surface, you get a wonder battery. On the other hand, if the surface has a defect in it anywhere you get dendrites, and the subsequent shorts they cause.

When I read that part I said "Ok, so this will make great bespoke batteries that the military can use for their human carried gear, but they will be too expensive to compete with the existing lithium ion technology."

I really hope that I'm wrong here, and there is some process that can reliably make massive numbers of pristine plated lithium / ceramic nodes but until we see that I don't see this breakthrough making it out of the lab.

<comment><USER3> Here'a post a made on reddit a few years ago about this very problem. I think its pretty relevant here and just about anywhere else that does cutting edge research:

"I want to expand on this because it is a point so often overlooked with all these "holy shit we just created a new tech that is 10000% better" articles. I'm gonna use a loose analogy to try and explain it.

Say you made a perfect cupcake. It is insanely fucking delicious, and will revolutionize the idea of cupcakes. You spent years researching the art of cupcakes, and now have written down the perfect combination of all cupcake factors to make this divine cupcake. Your milk must come from a special dairy who set aside the .02% of the milk that meets your needs, your flour must come from one certain granary using a special indoor grown grain, the eggs from your own 3 specially bred super pampered chickens. The mixing takes place over eight unique specialized mixing procedures, with varying steps in between. The cupcake paper is made from the wood of an endangered Guatemalan tree (requiring federal clearance to obtain 10 sheets of it) and the baking tray from a steel alloy made by one company in Japan, and it's not reusable. The baking process has been tailored to the unique characteristics of your $20,000 1'x1'x1' oven. It takes 3 hours to bake with precise temperature control and positioning adjustment needed throughout the process. The icing also requires it's own set of unique ingredients and precise procedures. To make one of these cupcakes takes 14 hours and costs $2600. If any corners are cut in the process the whole thing falls apart. But done right it is indeed perfect.

A business man finds out about the cupcake that makes people cry tears of joy. He comes to you and needs you to make 35,000 of them a day to sell for $10 each in order to be profitable. Logistically this is simply impossible. No equipment on earth exists that can follow such precise steps for such large quantities, much less a company capable of making it. Your oven costs 20 grand and can bake one cupcake in 3 hours, you need 5000 in 3 hours. Your ingredients come from sources that produce only a minute fraction of what you would need. Never mind that they are scattered around the country making same day delivery impossible short of having your own air fleet. Or that there are only 3 chickens on earth that produce the right eggs. Or that the rare beetle poop in the icing comes from an entomology professor in Peru. Even if you could do all this you still need to adjust the recipe to account for being handled by machines and conveyors. And packaging. And shipping. Oh and slash the cost by a factor of 260.

Since this is all obviously impossible at the time (and for the foreseeable future), you instead just submit the recipe to a food journal and let cooking magazines and TV shows have a field day with sensational articles about the coming cupcake jesus. You become well known and grant money for your legendary lasagna project pours in. There never was any intention to bring this to market, it was just a proof of concept with the added benefit of getting your name out there. It's up to someone else down the road to pick it up and figure out mass production.

If anything people should get more hyped about advancements in production techniques. That's when you will actually get new shit in your hands."

<comment><USER4> This happened to me in real life. I made a circuit board by hand in the 1980's called the Amiga 14. Basicly if you had the board and a 16 MHz 68000 it double the speed of your Amiga 1000.

I demo it at the World of Commodore in Toronto (I was a member of the Amiga Developer Group that had a booth) the following week I go a call from a gentleman, he wanted to buy 5,000 of them if I made them cheap enough.

But when I designed the circuit I just wanted something to speed up my computer, I never planned a design for mass production. I tried for weeks to change the design for mass production but I could not do it.

Today I know how to get the job done, but back then I did not have the knowledge to mass produce anything I designed.

<comment><USER5> That wasn't an impossible task back then, you could've partnered with a good EE and got it shipped.

</comment></comment></comment></comment><comment><USER6> The web site [1] shows a much lower level of hype. Listed problems:

\- Low-temperature performance

\- Density 1.8x to 5x liquid electrolyte

\- How to manufacture in quantity?

The increased density is a big problem. The ceramic materials are much heavier than liquids. That seems inherent in using ceramics. This might be a good technology for stationary applications, because of the faster charging and lower fire risk. Depends on cost.

[1] [https://sakamoto.engin.umich.edu/](https://sakamoto.engin.umich.edu/)

<comment><USER7> Why is density a problem? The article claims improved energy _per gram_ (mAh/g), so the denser, the smaller, and thus the better...

<comment><USER8> The article seems to skirt around this. It gives the energy per weight for just part of the battery and then gives a theoretical energy per volume for the whole battery. The claimed theoretical improvement for the whole battery per volume is 2x so if the density of the whole battery increases 1.8 to 5x then the solid state battery could be anywhere from slightly better (10%) to significantly worse per weight.

</comment></comment></comment><comment><USER9> I'm kind of surprised how people are complaining how we hear about many battery break throughs yet we do not see any of them come to reality. Bridging science to reality through engineering takes time. Lots of time. Think of LEDs. We had those tiny dome shaped LEDs for the longest time. Yet it took over two decades to get to useful LEDS to consumers we have today (like CREE).

<comment><USER10> This isn't a question of lag time. The overwhelming majority of these "breakthroughs" never come to market at all, and Li-Ion batteries are largely the same as five years ago, save some modest cost reductions from economies of scale. The big factors here are a) PR-driven media overhype, b) people not understanding that the big challenge in batteries is not making a few very high-performance batteries, but in building factories that can churn them out economically at enormous scale.

<comment><USER11> >Li-Ion batteries are largely the same as five years ago

Try 20. Libretto 50 (Pentium 75MHz palmtop) was released in ~1998. It was powered by two 1300 mAh 17670 cells. Today top of the line 17670 come in 1800 mAh. 20 years, less than 50% improvement.

<comment><USER12> Panasonic makes a 3400mAh 18650, NCR-18650B, which is very similar in volume and 2.62x higher capacity, ~2.55x higher density than the 1998 17670 cells. Not to mention we also have power density-optimized cells now. High performance DIY drone batteries are available that are 4 cells in series, 14.8-16.8 V, 1300 mah, about 150 grams, and can deliver 100+ A (1500 W), and be recharged hundreds of times before significant degradation. 5 years ago, a similar sized package could've delivered maybe 50 A peak, and it would degrade much faster, only lasting a few dozen cycles at that load before losing significant (20%) capacity. They would "puff" and overheat much more easily.

</comment></comment></comment></comment><comment><USER13> There's good skepticism in this thread, but at the end of the day, I think there's reason to be optimistic about better batteries.

* So many different technologies are showing some promise, and only one needs to be commercialized for a breakthrough. Put another way, this is an engineering an manufacturing issue, not a physics problem.

* The battery market is getting bigger and bigger, with ever more money at stake.

* Some real big investments into various battery startups and R&D programs have been made, at least several hundred million from various automakers. Either they're taking desperate risks, or else they see real progress on solid-state lithium batteries.

So often with technology, you don't see much progress until it arrives, and then things seem to change overnight.

</comment><comment><USER14> Keep in mind a few things here. This is a press release, and press releases always hype their topic. Researchers discover ways to improve batteries weekly. Until they can prove it's cost effective and mass producible it doesn't matter to most of the world. Don't get excited until they start using it in products.

</comment><comment><USER15> There is also another type of Lithium ion battery, LifePo4 which is lithium Iron posphate batteries. These type of Lithium ion batteries are much safer and are not likely to catch fire but they have slightly lower energy density. Hopefully the Umich breakthrough can be combined with LifePo4 to give it better energy density.

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

The common battery type Lithium ion cobalt is bad for the environment due to Cobalt mining in Congo. Cobalt is a conflict mineral. Lithium Cobolt batteries are the type that catches fire. Lithium Cobolt is an environmental risk if it leaks into the soil. [https://en.wikipedia.org/wiki/Lithium_cobalt_oxide](https://en.wikipedia.org/wiki/Lithium_cobalt_oxide)

Positive electrode [https://en.wikipedia.org/wiki/Lithium- ion_battery](https://en.wikipedia.org/wiki/Lithium-ion_battery)

<comment><USER16> Headway cells!

</comment></comment><comment><USER17> NOVA did a show about batteries, including a researcher at Tufts University who created lithium batteries that you could impale with a sharp object or cut with scissors that would not catch fire even while continuously providing power.

[https://www.pbs.org/video/nova-battery-wont- explode/](https://www.pbs.org/video/nova-battery-wont-explode/)

</comment><comment><USER18> Paper here:

doi: 10.1016/j.jpowsour.2018.06.055

Not a material's scientist, but it seems that they identified the importance of having a "pristine surface" and then developed a process of mechanical and chemical treatments to obtain the "pristine surface" which involves sputter coating with Au?

</comment><comment><USER19> About time for another amazing battery breakthrough! I haven't seen one in a few months. :P

<comment><USER20> s/month/day/

</comment></comment><comment><USER21> > U-M engineers created a ceramic layer that stabilizes the surface—keeping > dendrites from forming and preventing fires

I'm curious how strong this ceramic layer is. When I hear 'ceramic' I think of 'brittle, fragile' materials, and I'm not sure having a battery that would explode if dropped or hit would be much of an improvement.

<comment><USER22> I used to have the same intuition but also just recently started to learn about material sciences. They refer to 'ceramics' as a wide family of material that is comparable to "metal" and "crystals" and the likes. These families are usually categorized by the type of atomic bonds found in them. Example, Wikipedia starts the article on "Ceramic" with:

       A ceramic is a non-metallic solid material comprising an
       inorganic compound of metal, non-metal or metalloid atoms
       primarily held in ionic and covalent bonds.

At least, if your mental model was about ceramic vases and ornamental objects.

<comment><USER21> Interesting, thank you for the explanation. I generally think of things like tiles (e.g. like the ones on the space shuttle that were fragile) when I hear ceramics.

</comment></comment></comment><comment><USER23> Sounds promising but I'm not going to count my chickens until they're in high volume production. Lots of cool technologies never make it to the real world at scale because they can't be manufactured cost effectively at scale because of some little thing that doesn't seem like a big issue at first.

<comment><USER24> Agreed. Rooting for them but the number of battery and solar breakthroughs that don't get to market make it hard to get too excited on research + a pr push.

</comment></comment><comment><USER25> So many battery breakthroughs have been announced. Not one of the "breakthroughs" for cars have been released to the public. Most are "5 years away" or more.

Ionic with the polymer batteries looks promising, but again, as others have stated, it's the manufacturing process that is rough.

Works great in the lab, but scaling what was done in the lab to the public is really, really hard.

<comment><USER26> I agree that scaling is hard and progress is slow. I think that a major breakthrough _has_ made it into cars, though: lithium ion batteries.

The 1990s-vintage GM EV1 used lead-acid or NiMH batteries. The earlier generations of Prius used NiMH batteries too. The Tesla Roadster was the first highway-legal serial production EV to use lithium ion batteries. It took 17 years after lithium ion batteries saw first commercial use in small electronic devices (commercial batteries out in 1991, Roadster in 2008). Because, as you say, scaling is hard.

Of course the first Roadsters now seem like old hat and every auto maker is using lithium ion batteries. We're eager for the next, better _kind_ of lithium battery. But just getting autos to use _any_ kind of lithium battery was a big enough change that it deserved the "breakthrough" moniker, IMO.

<comment><USER27> A major driving factor in the advancement of lithium-ion batteries for automotive use was the patent issues surrounding large-format NiMH batteries.* Once Chevron got its grubby hands on the NiMH patents, the technology was effectively dead in the water.

* [https://en.wikipedia.org/wiki/Patent_encumbrance_of_large_au...](https://en.wikipedia.org/wiki/Patent_encumbrance_of_large_automotive_NiMH_batteries)

Interesting that Patent #6969567 expires a week from today. I doubt that will lead to a revival of NiMH technology, though.

</comment></comment></comment><comment><USER28> Having previously worked in materials science (though not specialised in battery tech), this does sound promising, but without the academic paper (is there a prepub available?) it's impossible to know with any confidence.

</comment><comment><USER29> It's a breakhrough when it's shipped in devices. Only then, not before.

</comment><comment><USER30> When you get the news articles with "breakthrough", just do Ctrl+F and type "could". If you get hit in title or first paragraph, close your tab and move on. You just came across another PR article on immature tech.

</comment><comment><USER31> I wonder if a solid electrolyte would allow for sub-freezing charging of the batteries.

</comment><comment><USER32> I wonder how much battery research as increased since ~Tesla

<comment><USER33> "research secured"

</comment></comment><comment><USER34> Congrats, hard not to be jaded at this point though. Does this address the Nickel/Cobalt cathode issue at all?

</comment><comment><USER35> Bah! in about 25 years BIC will be selling lighter-size fusion reactors. I'll just wait.

</comment><comment><USER36> I have nieces and nephews that can prove the fireproof claim invalid.

</comment><comment><USER37> Funding secured.

</comment><comment><USER38>
        revolutionary_battery_tech_news++

</comment><comment><USER39> Battery breakthrough articles are as reliable as apocalypse predictions.

<comment><USER40> not quite that bad.</comment></comment>


Christmas Carol and other eigenvectors - <AUTHOR> http://evelinag.com/blog/2014/12-15-christmas-carol-and-other-eigenvectors/index.html#.VI9OjOpGjUY

<comment><USER2> I wish everyone would stop saying that PCA is about eigenvectors and eigenvalues... it's about _singular_ vectors and _singular_ values. The best way to compute PCA is _NOT_ to compute the eigenvalues of A'*A. There are specialised SVD algorithms that should be used instead:

[https://en.wikipedia.org/wiki/Singular_value_decomposition#C...](https://en.wikipedia.org/wiki/Singular_value_decomposition#Calculating_the_SVD)

Randomised methods have also gotten popular in recent years:

[https://code.google.com/p/redsvd/](https://code.google.com/p/redsvd/)

[http://arxiv.org/abs/0909.4061](http://arxiv.org/abs/0909.4061)

This is one case where the machine learning community takes a numerical analysis idea and by giving it a different name also loses some of the insights associated with the other name. Normally I don't care if they call it "training" instead of "line search" or "features" instead of "dimensions", but PCA should be using better algorithms. Instead of telling everyone to just use the inferior method of using generic eigenvalue solvers, use better specialised methods.

I know that finding eigenvalues of A'A is "good enough", and I guess "eigenvalue" is already a big enough word for most programmers, but there's no reason to not relegate better methods to specialised libraries and make those specialised libraries available. If nothing else, LAPACK and ARPACK have bindings for almost every language.

</comment><comment><USER3> N-grams are also regularly used in bioinformatics. For example you can split a genome sequence into words of length k, where we use the term 'k-mers'. You can use a k-mer frequency table as a heuristic where ever performing a full sequence analysis is too computationally expensive. For example if two genomes A <-> B have a smaller euclidean distance in their respective kmer tables than A <-> C you might assume that A and B are more closely related in evolutionary distance. This is just one example and kmers are widely used through out the bioinformatics field. For instance, the wikipedia entry for velvet has a description on how they can be used for genome assembly:

[http://en.wikipedia.org/wiki/Velvet_assembler](http://en.wikipedia.org/wiki/Velvet_assembler)

<comment><USER4> Have you by any chance taken a look at applying NLP techniques like generating sentence vectors with recurrent neural networks to this type of data? 2+ pair mappings (ngrams) have been in use successfully for a while in NLP, but they don't know about any context outside the current ngram.

Recent work has involved creating word and sentence vectors that capture much richer dynamics and this is where a lot of the excitement is coming from in the deep learning world wrt text (of any language, maybe even computer code, as it turns out)

I've been wanting to try applying these machine learning techniques to this type of problem (could be for clustering--which was your example-- classification, regression, or sample generation--of eg novel and probable sequences?)

If you or anyone here as an interest in this sort of thing on the bio side, please contact me (email in profile)

</comment></comment><comment><USER5> Coming from OCaml, I'm jealous of what I see of the F# standard library. Looks like there is a lot of nice built-in stuff. The different case conventions make a bit jarring, though.

</comment><comment><USER6> This is pretty neat. I never would have thought that just _letter pairs_ would correlate with authorship.</comment>


Chromium sends data to Google upon startup - <AUTHOR> http://groups.google.com/a/chromium.org/group/chromium-discuss/browse_thread/thread/574c792f23ab2ffd/8bbf44e8b1d877a0?pli=1#

<comment><USER2> [http://www.google.com/support/chrome/bin/answer.py?answer=11...](http://www.google.com/support/chrome/bin/answer.py?answer=114836&hl=en)

<http://inari.aerdan.org/gallery/chromeopts.png>

The initial request is the GoogleURLTracker class, which manages what Google TLD you're on. On the trunk, this won't happen if your default search engine is not Google, and even if it does happen, we won't save/update any cookies as a result of the update request.

Also, the reporter is using a binary downloaded from the continuous builder, that's why RLZ is included.

<comment><USER3> None of those settings seem to apply to the case in question:

 _It seems that on first request it query google for unique client ID (getting NID Cookie)

Requests to safebrowsing are not anonymous. All of them signed with cookie, getted on the first 2-3 requests_

EDIT: You added those two sentences. The guy claims changing the default search engine didn't change this behavior.

<comment><USER4> Did he clear the browsing data, too? I don't use Chromium, but I've seen similar requests with other browsers. The only way I have found to get the browser to stop sending the requests is to zorch all the browsing history, saved cookies, cached garbage, burn the village to the ground and sacrifice small birds. Of course, as soon as you search for soemthing against google.com, the requests will happily start up again.

</comment></comment></comment><comment><USER5> It's a bug and they're working on it:

[http://groups.google.com/a/chromium.org/group/chromium- discu...](http://groups.google.com/a/chromium.org/group/chromium- discuss/msg/a6b8bb51c6ed2aac)

</comment><comment><USER6> <http://www.chromeplus.org/> strips all that crap out. Cant stay as current but it's worth it.

<comment><USER7> The current version of Chrome is 5.0.375.99... Chrome Plus is at 5.0.375.38.

I'd be more worried about the vulnerabilities fixed in Chrome that aren't fixed in Chrome Plus:

[http://googlechromereleases.blogspot.com/2010/06/stable- chan...](http://googlechromereleases.blogspot.com/2010/06/stable-channel- update_24.html) [http://googlechromereleases.blogspot.com/2010/06/stable- chan...](http://googlechromereleases.blogspot.com/2010/06/stable-channel- update.html) [http://googlechromereleases.blogspot.com/2010/05/stable- chan...](http://googlechromereleases.blogspot.com/2010/05/stable-channel- update.html) [http://googlechromereleases.blogspot.com/2010/07/stable- chan...](http://googlechromereleases.blogspot.com/2010/07/stable-channel- update.html)

</comment></comment><comment><USER8> I'm more concerned about the opt-out "safe browsing" feature CCing Google on all your requests, complete with ID cookie. When did that cease to be a cardinal sin? Didn't Palm get reamed for that recently?

<comment><USER9> It doesn't do that on all your requests, does it? I thought everyone did that via local bloom table (or similar structure), and checking with a central backend only when it gets a potential hit.

<comment><USER8> My bad, it does not appear to be hitting the safe browsing service on every request but just a few times soon after the first request of a session. I guess it's probably just updating the bloom filter.

They're still not off the hook for doing autocomplete on the server by default. That effectively gives them every typed in URL.</comment></comment></comment>


My first hackathon; or, gender, status, code, and sitting at the table - <AUTHOR> http://andromedayelton.com/blog/2012/04/06/my-first-hackathon-or-gender-status-code-and-sitting-at-the-table/ <comment><USER2> Overcoming impostor syndrome! Woo!

Code culture measures how much you self-perceive to know about code. It's only after a bit of getting to know a person that you can get at their actual levels of competence. If you are in a situation that claims to be a meritocracy, but all claims of merit have to be evaluated in seconds, then it's not a meritocracy, it's a self-confidence-ocracy. Unfortunately, self- confidence can be negatively correlated with talent... ( <http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect> )

<comment><AUTHOR> I've not encountered a "code culture" that "measures how much you self- perceive to know about code." I've encountered management cultures like that, but if you have a bunch of developers working together, people deeply know the wizards from the blowhards.

<comment><USER3> _If_ you have a bunch of developers, yes. But the entry level filter is people who aren't yet developers, and people talking about code. I've found actual developers pretty welcoming, but I also had to skip the entire beginning of the pipeline to get to them.</comment></comment></comment>


User Story - <AUTHOR> https://en.wikipedia.org/wiki/User_story <comment><USER2> I've been writing a ton of user stories lately... does anyone have any pointers on what qualities made user stories outstanding/super helpful to them?

For instance, was there something a particular BA/PM did when they wrote up specs that made your life easier?

There's a spectrum of a Jira issue with a title "User Avatar Upload" and a blank description or even receiving the equivalent length of War & Peace that's confusing and contradicts itself. Thoughts on the middle ground below?

\----

Title: User Avatar Upload

Story:

 _As an_ Accountant

 _I want_ to upload a photo as an avatar

 _So That_ other users can quickly recognize my content and contributions.

\--

Acceptance Criteria:

1\. Should accept .png, .jpeg, .jpg, .tiff file formats.

2\. Should reject with friendly notification files that do not match whitelist.

3\. Should make copies of image in resized formats.

4\. Should store them in storage bucket or CDN for performant retrieval by the users and application.

5\. Should not allow execute code to be injected. (Example: malicious JS, PDF, misnamed file types, etc)</comment>


Examples of objects/machines suriving accelarations of 15,000g+ [Slingatron KS] - <AUTHOR> http://www.kickstarter.com/projects/391496725/the-slingatron-building-a-railroad-to-space/posts/562115

<comment><AUTHOR> The Slingatron guys list examples of objects and machinery that could withstand the acceleration their proposed Slingatron launch system would produce. Very interesting, I didn't know half of those…

</comment><comment><USER2> In short:

* 50k g acceleration is nothing much for the current crop of gun-fired munitions carrying electronics, batteries, cameras, thrusters and even foldable actuators.

* 100k+ g that munitions have been developed in 1990s also include electronics and thrusters.

* Electronic components are known to withstand 200k+ g, and plain polycarbonate solid projectiles used in railgun research don't break under 500k g.

* So a spacecraft that withstands 40-60k g of Slingatron is definitely doable, even though axial accelerations need to be addressed, too.</comment>


Ask HN: Share your .emacs (or .vimrc?) - <AUTHOR>

Inspired by this post: http://news.ycombinator.org/item?id=2007829
I find it useful/informative to get to see what other people have in their text editor configuration file.  In the spirit of that, anyone care to share theirs? Mine isn't anything special, but here goes:
http://pastebin.com/gUXsprcL <comment><USER2> I use Janus (<https://github.com/carlhuda/janus>) for my vim setup and then customize it via .vimrc.local ([https://github.com/misham/.dotfiles/blob/master/vim/vimrc.lo...](https://github.com/misham/.dotfiles/blob/master/vim/vimrc.local))

</comment><comment><USER3> Here's my .vimrc: <https://github.com/quesada/dotfiles/blob/master/.vimrc>

The nice thing is that all the plugins are from the package manager; it takes me 2 min to get a working install. Sabayon is great.

</comment><comment><USER4> (Vimrc) This is pretty broken without the .vim/ folder as well, but here goes: <https://github.com/sethwoodworth/dotfiles/raw/master/.vimrc>

</comment><comment><USER5> Some things I've pieced together:

<https://github.com/sid137/.vim>

<https://github.com/sid137/emacs>

</comment><comment><USER6> Here's mine - <http://bitbucket.org/dekomote/vim/src/cc45f0d7a542/.vimrc>

</comment><comment><USER7> Pretty much just a series of hacks.

<http://pastebin.com/PCh0LwxR></comment>


Show HN: IKEA Stock Checker - <AUTHOR> https://github.com/yeutterg/ikea-stock-check <comment><AUTHOR> Here's a little weekend project I put together after finding it frustrating to plan IKEA trips. It basically generates a shopping list with item locations and notifies you if there are quantity issues.

The code is pretty hacky and there are most definitely bugs. But maybe you'll find it useful.

</comment><comment><USER2> Let me just check if they have l;askfjvaosligjhwa;oifdhjaol in stock...</comment>


YouTube star John 'TotalBiscuit' Bain dies aged 33 - <AUTHOR> https://arador.com/totalbiscuit/ <comment><USER2> More comments can be found here:

* Totalbiscuit, one of gaming's most popular YouTubers, has passed away | Hacker News || [https://news.ycombinator.com/item?id=17150221](https://news.ycombinator.com/item?id=17150221)</comment>