Sass Guidelines - <AUTHOR> http://sass-guidelin.es <comment><USER4> No leading zeros?! [1] I'm pretty sure most math/engineering fields recommend leading zeros for readability, e.g, NIST: "For numbers less than one, a zero is written before the decimal marker. For example, 0.25 s is the correct form, not .25 s." [2]

If it's to make the resulting css file a byte smaller, shouldn't be the preprocessor be able to strip it out?

[1]: [http://sass-guidelin.es/#zeros](http://sass-guidelin.es/#zeros) [2]: [http://physics.nist.gov/cuu/pdf/sp811.pdf](http://physics.nist.gov/cuu/pdf/sp811.pdf)

<comment><USER5> Actually I am thinking of changing this. Someone brought the issue on GitHub: [https://github.com/HugoGiraudel/sass- guidelines/issues/32](https://github.com/HugoGiraudel/sass- guidelines/issues/32). It is currently being discussed.

<comment><USER6> In a similar vein why do you prefer hex colors in shortened lowercase format? I've been partial to uppercase long form.

<comment><USER7> This is not in a similar vein. Leading zero's for values less than 1 is the correct way to write values less than 1.

3-character or 6-character hex values is only a matter of optimization (fewer characters, which the compiler should be able to handle), and consistency (having both the 3- and 6-character versions in the same file or definition). Case is personal preference and nothing more.

</comment></comment></comment></comment><comment><USER8> This article is a goldmine—well done. I especially appreciate the care that's been taken to explain the rationale behind each suggestion.

I've worked with Sass fairly extensively, and have picked up some of these practices on my own, but not all of them. I'll definitely be consulting this page in the future.

<comment><USER9> The author, Hugo Giraudel, also writes one of the absolutest best blogs on Sass ([http://hugogiraudel.com/](http://hugogiraudel.com/)). I've been using Sass heavily since 2009 and consider myself a fairly advanced user, but still learn new and useful things from Hugo's blog on a regular basis. This styleguide looks like an awesome compilation and extension of years of blog articles.

</comment></comment><comment><USER10> I have to really disagree about extend. Yes, it's easy and potentially disastrous to misuse extend erratically, but used sanely there should never be side effects and your compiled css should be smaller than otherwise.

Regarding side effects, they're easy to avoid if you structure your main file in a logical way. For generic extension, your library of base classes (both actual classes and silent classes) should be included before your components which extend and build on them, therefore any inherited styles come before (and can therefore be overwritten by) the extending component but never the other way around. When extending a component, the extending objects should always be in the same file and come after (e.g. .gallery followed by .gallery- foo and .gallery-bar which both extend .gallery). If full blown objects/components are related enough to extend, they're related enough to be in the same file.

Avoiding extend compiled file size bloat mostly comes from sane nesting behavior that you should be following regardless. Adding single selectors to an extended rule is almost always going to be smaller than inlining/mixing that rule, even for simple rules.

Discoverability is always going to take a hit with extend, yes, but in my opinion dryness, single-point-of-change, and compile size are far more important than in-file discoverability, assuming your project layout is sane. Extend in sass isn't really any different than using traits in oop languages, it's an incredibly useful pattern when employed correctly.

<comment><USER11> If you haven't seen it, there is this discussion in the issue tracker:

[https://github.com/HugoGiraudel/sass- guidelines/issues/28](https://github.com/HugoGiraudel/sass- guidelines/issues/28)

</comment></comment><comment><USER12> This is great, also check out [http://cssguidelin.es/](http://cssguidelin.es/) on a related note. +1

</comment><comment><USER13> Looks really nice but it kind of lacks tackling the difficult issues - <USER3> guidelines what to put into classes and how to name them to avoid css class soup. By the way the "7-1" foleer organization is not something you would do in a big programming project (organize things by their type but of use instead). There was a nice blog on it that used analogy of "Socks Drawer".

</comment><comment><USER10> I have to really disagree about extend. Yes, it's easy and potentially disastrous to misuse extend erratically, but used sanely there should never be side effects and your compiled css should be smaller than otherwise.

Regarding side effects, they're easy to avoid if you structure your main file in a logical way. For generic extension, your library of base classes (both actual classes and silent classes) should be included before your components which extend and build on them, therefore any inherited styles come before (and can therefore be overwritten by) the extending component but never the other way around. When extending a component, the extending objects should always be in the same file and come after (e.g. .gallery followed by .gallery- foo and .gallery-bar which both extend .gallery). If full blown objects/components are related enough to extend, they're related enough to be in the same file.

Avoiding extend compiled file size bloat mostly comes from sane nesting behavior that you should be following regardless. Adding single selectors to an extended rule is almost always going to be smaller than inlining/mixing that rule, even for simple rules.

Discoverability is always going to take a hit with extend, yes, but in my opinion dryness, single-point-of-change, and compile size are far more important than in-file discoverability, assuming your project layout is sane.

</comment><comment><USER10> I have to really disagree about extend. Yes, it's easy and potentially disastrous to misuse extend erratically, but used sanely there should never be side effects and your compiled css should be smaller than otherwise.

Regarding side effects, they're easy to avoid if you structure your main file in a logical way. For generic extension, your library of base classes (both actual classes and silent classes) should be included before your components which extend and build on them, therefore any inherited styles come before (and can therefore be overwritten by) the extending component but never the other way around. When extending a component, the extending objects should always be in the same file and come after (e.g. .gallery followed by .gallery- foo and .gallery-bar which both extend .gallery). If full blown objects/components are related enough to extend, they're related enough to be in the same file.

Avoiding extend compiled file size bloat mostly comes from sane nesting behavior that you should be following regardless. Adding single selectors to an extended rule is almost always going to be smaller than inlining/mixing that rule, even for simple rules.

Discoverability is always going to take a hit with extend, yes, but in my opinion dryness, single-point-of-change, and compile size are far more important than in-file discoverability, assuming your project layout is sane. Extend in sass isn't really any different than using traits in oop languages, it's an incredibly useful pattern when employed correctly.

</comment><comment><USER10> I have to really disagree about extend. Yes, it's easy and potentially disastrous to misuse extend erratically, but used sanely there should never be side effects and your compiled css should be smaller than otherwise.

Regarding side effects, they're easy to avoid if you structure your main file in a logical way. For generic extension, your library of base classes (both actual classes and silent classes) should be included before your components which extend and build on them, therefore any inherited styles come before (and can therefore be overwritten by) the extending component but never the other way around. When extending a component, the extending objects should always be in the same file and come after (e.g. .gallery followed by .gallery- foo and .gallery-bar which both extend .gallery). If full blown objects/components are related enough to extend, they're related enough to be in the same file.

Avoiding extend compiled file size bloat mostly comes from sane nesting behavior that you should be following regardless. Adding single selectors to an extended rule is almost always going to be smaller than inlining/mixing that rule, even for simple rules.

Discoverability is always going to take a hit with extend, yes, but in my opinion dryness, single-point-of-change, and compile size are far more important than in-file discoverability, assuming your project layout is sane. Extend in sass isn't really any different than using traits in oop languages, it's an incredibly useful pattern when employed correctly.

</comment><comment><USER10> I have to really disagree about extend. Yes, it's easy and potentially disastrous to misuse extend erratically, but used sanely there should never be side effects and your compiled css should be smaller than otherwise.

Regarding side effects, they're easy to avoid if you structure your main file in a logical way. For generic extension, your library of base classes (both actual classes and silent classes) should be included before your components which extend and build on them, therefore any inherited styles come before (and can therefore be overwritten by) the extending component but never the other way around. When extending a component, the extending objects should always be in the same file and come after (e.g. .gallery followed by .gallery- foo and .gallery-bar which both extend .gallery). If full blown objects/components are related enough to extend, they're related enough to be in the same file.

Avoiding extend compiled file size bloat mostly comes from sane nesting behavior that you should be following regardless. Adding single selectors to an extended rule is almost always going to be smaller than inlining/mixing that rule, even for simple rules.

Discoverability is always going to take a hit with extend, yes, but in my opinion dryness, single-point-of-change, and compile size are far more important than in-file discoverability, assuming your project layout is sane. Extend in sass isn't really any different than using traits in oop languages, it's an incredibly useful pattern when employed correctly.

</comment><comment><USER10> I have to really disagree about extend. Yes, it's easy and potentially disastrous to misuse extend erratically, but used sanely there should never be side effects and your compiled css should be smaller than otherwise.

Regarding side effects, they're easy to avoid if you structure your main file in a logical way. For generic extension, your library of base classes (both actual classes and silent classes) should be included before your components which extend and build on them, therefore any inherited styles come before (and can therefore be overwritten by) the extending component but never the other way around. When extending a component, the extending objects should always be in the same file and come after (e.g. .gallery followed by .gallery- foo and .gallery-bar which both extend .gallery). If full blown objects/components are related enough to extend, they're related enough to be in the same file.

Avoiding extend compiled file size bloat mostly comes from sane nesting behavior that you should be following regardless. Adding single selectors to an extended rule is almost always going to be smaller than inlining/mixing that rule, even for simple rules.

Discoverability is always going to take a hit with extend, yes, but in my opinion dryness, single-point-of-change, and compile size are far more important than in-file discoverability, assuming your project layout is sane. Extend in sass isn't really any different than using traits in oop languages, it's an incredibly useful pattern when employed correctly.

</comment><comment><USER10> I have to really disagree about extend. Yes, it's easy and potentially disastrous to misuse extend erratically, but used sanely there should never be side effects and your compiled css should be smaller than otherwise.

Regarding side effects, they're easy to avoid if you structure your main file in a logical way. For generic extension, your library of base classes (both actual classes and silent classes) should be included before your components which extend and build on them, therefore any inherited styles come before (and can therefore be overwritten by) the extending component but never the other way around. When extending a component, the extending objects should always be in the same file and come after (e.g. .gallery followed by .gallery- foo and .gallery-bar which both extend .gallery). If full blown objects/components are related enough to extend, they're related enough to be in the same file.

Avoiding extend file size bloat mostly comes from sane nesting behavior that you should be following regardless. Adding single selectors to an extended rule is almost always going to be smaller than inlining/mixing that rule, even for simple rules.

Discoverability is always going to take a hit with extend, yes, but in my opinion dryness, single-point-of-change, and compile size are far more important than in-file discoverability, assuming your project layout is sane.

</comment><comment><USER10> I have to really disagree about extend. Yes, it's easy and potentially disastrous to misuse extend erratically, but used sanely there should never be side effects and your compiled css should be smaller than otherwise.

Regarding side effects, they're easy to avoid if you structure your main file in a logical way. For generic extension, your library of base classes (both actual classes and silent classes) should be included before your components which extend and build on them, therefore any inherited styles come before (and can therefore be overwritten by) the extending component but never the other way around. When extending a component, the extending objects should always be in the same file and come after (e.g. .gallery followed by .gallery- foo and .gallery-bar which both extend .gallery). If full blown objects/components are related enough to extend, they're related enough to be in the same file.

Avoiding extend file size bloat mostly comes from sane nesting behavior that you should be following regardless. Adding single selectors to an extended rule is almost always going to be smaller than inlining/mixing that rule, even for simple rules.

Discoverability is always going to take a hit with extend, yes, but in my opinion dryness, single-point-of-change, and compile size are far more important than in-file discoverability, assuming your project layout is sane.

</comment><comment><USER10> I have to really disagree about @extend. Yes, it's easy and potentially disastrous to misuse extend erratically, but used sanely there should never be side effects and your compiled css should be smaller than otherwise.

Regarding side effects, they're easy to avoid if you structure your main file in a logical way. For generic extension, your library of base classes (both actual classes and silent classes) should be @included before your components which extend and build on them, therefore any inherited styles come before (and can therefore be overwritten by) the extending component but never the other way around. When extending a component, the extending objects should always be in the same file and come after (e.g. .gallery followed by .gallery- foo and .gallery-bar which both extend .gallery). If full blown objects/components are related enough to extend, they're related enough to be in the same file.

Avoiding @extend file size bloat mostly comes from sane nesting behavior that you should be following regardless. Adding single selectors to an extended rule is almost always going to be smaller than inlining/mixing that rule, even for simple rules.

Discoverability is always going to take a hit with @extend, yes, but in my opinion dryness and single-point-of-change are far more important than in-file discoverability, assuming your project layout is sane.

</comment><comment><USER10> I have to really disagree about @extend. Yes, it's easy and potentially disastrous to misuse extend erratically, but used sanely there should never be side effects and your compiled css should be smaller than otherwise.

Regarding side effects, they're easy to avoid if you structure your main file in a logical way. For generic extension, your library of base classes (both actual classes and silent classes) should be @included before your components which extend and build on them, therefore any inherited styles come before (and can therefore be overwritten by) the extending component but never the other way around. When extending a component, the extending objects should always be in the same file and come after (e.g. .gallery followed by .gallery- foo and .gallery-bar which both extend .gallery). If full blown objects/components are related enough to extend, they're related enough to be in the same file.

Avoiding @extend file size bloat mostly comes from sane nesting behavior that you should be following regardless. Adding single selectors to an extended rule is almost always going to be smaller than inlining/mixing that rule, even for simple rules.

Discoverability is always going to take a hit with @extend, yes, but in my opinion dryness and single-point-of-change are far more important than in-file discoverability, assuming your project layout is sane.

</comment><comment><USER10> I have to really disagree about @extend. Yes, it's easy and potentially disastrous to misuse extend erratically, but used sanely there should never be side effects and your compiled css should be smaller than otherwise.

Regarding side effects, they're easy to avoid if you structure your main file in a logical way. For generic extension, your library of base classes (both actual classes and silent classes) should be @included before your components which extend and build on them, therefore any inherited styles come before (and can therefore be overwritten by) the extending component but never the other way around. When extending a component, the extending objects should always be in the same file and come after (e.g. .gallery followed by .gallery- foo and .gallery-bar which both extend .gallery). If full blown objects/components are related enough to extend, they're related enough to be in the same file.

Avoiding @extend file size bloat mostly comes from sane nesting behavior that you should be following regardless. Adding single selectors to an extended rule is almost always going to be smaller than inlining/mixing that rule, even for simple rules.

Discoverability is always going to take a hit with @extend, yes, but in my opinion dryness and single-point-of-change are far more important than in-file discoverability, assuming your project layout is sane.

</comment><comment><USER10> I have to really disagree about @extend. Yes, it's easy and potentially disastrous to misuse extend erratically, but used sanely there should never be side effects and your compiled css should be smaller than otherwise.

Regarding side effects, they're easy to avoid if you structure your main file in a logical way. For generic extension, your library of base classes (both actual classes and silent classes) should be @included before your components which extend and build on them, therefore any inherited styles come before (and can therefore be overwritten by) the extending component but never the other way around. When extending a component, the extending objects should always be in the same file and come after (e.g. .gallery followed by .gallery- foo and .gallery-bar which both extend .gallery). If full blown objects/components are related enough to extend, they're related enough to be in the same file.

Avoiding @extend file size bloat mostly comes from sane nesting behavior that you should be following regardless. Adding single selectors to an extended rule is almost always going to be smaller than inlining/mixing that rule, even for simple rules.

Discoverability is always going to take a hit with @extend, yes, but in my opinion dryness and single-point-of-change are far more important than in-file discoverability, assuming your project layout is sane.

</comment><comment><USER14> Very good guidelines, agreeing with 99% of the things and learnt of mix at the same time !

</comment><comment><USER15> Disclaimer: This is intended as a helpful correction, not nitpicking.

"... France about to move IN Germany" should be "... from France about to move TO Germany"

Cheers -- and thanks for a useful resource! :)

<comment><USER16> There are a few similar slip-ups in the article; the author is presumably not a native English speaker. However, despite that - and what really motivated me to comment - I find this really well written, and the odd mistake just adds a bit of character. Very impressed.

<comment><USER5> True, I am not a native English speaker (French here). Doing my best to fix all those tiny typos. Any report appreciated. :)

</comment></comment></comment><comment><USER17> Great resource. I'm about to use Sass again after a hiatus of ~3yrs. Reading through this has been a great refresher on core principles and best practices.

</comment><comment><USER18> Amazing. This is something that I would happily recommend. I've never seen so mature and deep guidelines and best practices. Kudos to the author.

</comment><comment><USER13> Looks really nice but it kind of lacks tackling the difficult issues - <USER3> guidelines what to put into classes and how to name them to avoid css class soup. By the way the "7-1" foleer organization is not something you would do in a big programming project (organize things by their type but of use instead). There was a nice blog on it that used analogy of "Socks Drawer".

</comment><comment><USER19> You changed leading zeros in the body, but in the to; dr at the end you didn't.

Great document!

<comment><USER5> Fixed, thanks!

</comment></comment><comment><USER20> OMG .... those tabs and leading 0's were holding me back ... now ... i can write great code.

And @while is a complete waste ... i mean ... it is the only thing that seperates it from less but what evez ... i glad i dont use it in my "read Sass" projects ... wtf you mean when designing a web site right?

</comment><comment><USER21> Why strictly two spaces and no tabs? Ive found this to be a trend I just don't understand.

At my work we have ~30 front end developers and we have a strict tabs only policy, so everyone can use their IDE to choose their tab width depending on how they like it.

Am I missing some benefit?

<comment><USER22> How does your team successfully enforce a maximum line length while having a tabs-only policy? I know it's possible to do this, but in my experience, most teams I've encountered that have a tabs-only policy end up with lines of code that go on for miles because enforcing a maximum line length while having a tabs-only policy is more difficult than doing so while having a spaces-only policy. Long lines of code are especially annoying to people such as myself who have their editor split into multiple 100-character wide panes.

<comment><USER21> Interesting I guess the answer to that is we don't have a strict limit? Looking at a library now its all pretty much ~100ish but nothing set in concrete as a rule. That seems a bit restrictive IMO.

Our other coding style rules kind of keep it down generally I suppose, like for SCSS declaring selectors on new lines (like in this styleguide) and in JS keeping callbacks to one level etc..

</comment></comment></comment><comment><USER23> Is the primary benefit of SASS to reduce development time? I find it slows me down having to wait for it to re-parsed on every pageview during active development. Does it offer any other tangible benefits?

<comment><USER24> Try using gulp, gulp-sass (libsass) and gulp-livereload (LiveReload.) It's almost instantaneous and you do not need to reload the page to see your changes. There's also a Grunt equivalent tool chain, but I find gulp faster and prefer to use code for configuration rather than using Grunt's giant config objects.

</comment></comment><comment><USER23> Is the primary benefit of SASS to reduce development time? I find it slows me down having to wait for it to re-parsed on every pageview during active development. Does it offer any other tangible benefits?

</comment><comment><USER23> Is the primary benefit of SASS to reduce development time? I find it slows me down having to wait for it to re-parsed on every pageview during active development. Does it offer any other tangible benefits?

</comment><comment><USER23> Is the primary benefit of SASS to reduce development time? I find it slows me down having to wait for it to re-parsed on every pageview during active development. Does it offer any other tangible benefits?

</comment><comment><USER23> Is the primary benefit of SASS to reduce development time? I find it slows me down having to wait for it to re-parsed on every pageview during active development. Does it offer any other tangible benefits?

</comment><comment><USER25> What is sass?

<comment><USER26> Its a CSS preprocessor. [http://sass-lang.com/](http://sass-lang.com/)

In a nutshell, you write SASS with all sorts of bonus features that CSS doesn't do, and then you compile to CSS.

</comment></comment><comment><USER20> OMG .... those tabs and leading 0's were holding me back ... now ... i can write great code.

And @while is a complete waste ... i mean ... it is the only thing that seperates it from less but what evez ... i glad i dont use it in my "read Sass" projects ... wtf you mean when designing a web site right? The fanboyism is intense in the sass community, ggs.</comment>


How can a computer deal a poker hand? - <AUTHOR> http://fermatslibrary.com/s/a-sample-of-brilliance <comment><USER2> > _After solving a challenging problem, I solve it again from scratch, > retracing only the insight of the earlier solution. I repeat this until the > solution is as clear and direct as I can hope for. Then I look for a general > rule for attacking similar problems, that would have led me to approach the > given problem in the most efficient way the first time. Often, such a rule > is of permanent value._

This has been one of my principles all my life, and I was just thinking recently about the fact that I've never seen it written down anywhere. (Also, about the fact that it really is a question of personal style, because I've read through rough work/notebooks from very successful people who don't seem to think that way at all.)

<comment><USER3> Isn't that a bit like "Plan to throw the first one away"?

[https://en.wikiquote.org/wiki/Fred_Brooks](https://en.wikiquote.org/wiki/Fred_Brooks)

<comment><USER4> It's crazy that a sofware engineering book from the 70's is still pretty relevant

<comment><USER5> True wisdom is timeless. Assuming we're still around for another two and a half millenia, I imagine the _Art of War_ will still be read and studied.

</comment></comment></comment></comment><comment><USER6> > It is easy to generate a random sequence of inte- gers in the range l..N, so > long as we don't mind dupli-cates

Is it? I was surprised to learn of modulo bias [1]. Does the "Randint(1, J)" implementation take it into account? It's a very easy mistake to make and can have an impact on the uniformity of the shuffle.

If you haven't heard of it it has to do with the relationship between the range spanned by your system's RAND_MAX and J. If RAND_MAX is not a multiple of J, the highest range (RAND_MAX-J..RAND_MAX) will not deliver the entire span of J.

[1] [https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle#M...](https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle#Modulo_bias)

<comment><USER7> Any random number generator library worth its salt should have a properly implemented RandInt(1, J) function available, instead of just a RandInt(1, RAND_MAX) primitive.

Behind the scenes, mind you, it's easy to implement such things from random number generators of a fixed range. For example, it could be done as follows (for convenience, I'll speak as though our fundamental randomness primitive just produces random bits, though all sorts of things would work just as well):

We ought keep track, internally to our random number generator library, persistently of some interval [Low, High) in [0, 1) (which can be initialized to all of [0, 1) itself); any time a RandInt(1, J) is required, we partition [0, 1) into J many equal intervals, find which one [Low, High) lies entirely within, use the corresponding number as the value to return, and also modify [Low, High) by applying to it the affine transformation which would take that particular subinterval to all of [0, 1). If ever, while doing this, we find [Low, High) spans multiple subintervals, we first do the following until it does not: generate a random bit and then replace [Low, High) with either its lower or higher half accordingly.

Essentially, we are using [Low, High) to keep track of an underspecified value uniformly distributed throughout [0, 1), and then pulling out leading "digits" in arbitrary bases of this value as required by the user, zooming our window in accordingly after doing so. Random bits are used to further and further specify this value, and thus no randomness ever goes to waste. At all times, we will have made the minimum number of invocations of random bits necessary to power the amount of random integers of whatever varying sizes asked for so far.

<comment><USER8> > pulling out leading "digits" in arbitrary bases of this value

Generally this bookkeeping isn't worth the complexity. Modern PRNGs are super efficient: PCG is about 3x faster than Mersenne Twister.

<comment><USER7> Well, supposing one wanted "true" randomness and had access to a source of such, but still cared to be efficient about using it.

<comment><USER8> Sure, but in practice I think we'd be hard pressed to find someone with such stringent requirements.

For all practical purposes, using your entropy stream to seed ChaCha is more than good enough. Want something with a proof? Seed a Blum Blum Shub generator.

</comment></comment></comment></comment></comment><comment><USER9> This looks very familiar. I think I read part of it back in the 80's when I was first learning programming. I think it was in reference to "How to truly 'shuffle' a deck of cards using a computer algorithm. Lots of discussion on techniques to do close to true random shuffling of ordered decks.

<comment><USER10> It's Bentley's _Programming pearls_ column from the _Communications of the ACM_, which was collected into a series of books, such as _Programming Pearls_ and _More Programming Pearls_, where you probably saw it.

</comment></comment><comment><USER11> Is this a mathematically sound shuffle? It removes a random element from a sorted deck and then adds the element to a new deck. Python code below:

import random

def shuffle():

        random.seed()
        sorted_deck = range(52)  # [0..51]
        shuffled_deck = []
        slots_avail = 52
        while slots_avail:

            idx = random.randint(0, slots_avail - 1)
            shuffled_deck.append(sorted_deck[idx])
            del sorted_deck[idx]
            slots_avail -= 1

        return shuffled_deck

<comment><USER12> Try your algorithm with a smaller n first, instead of n=52, such as n=2 or n=3, and slots_avail=n.

For n=3 it generates the permutation {1,2,3} with probability that is 11% higher than the correct probability.

<comment><USER13> Would you mind sharing your proof of this? I don't think you are correct. It seems to me that OP's algorithm is correct and will yield all permutations with equal probability.

All he's doing is picking a random card from the sorted deck and moving it to the top of the un-sorted deck. The sorted deck then becomes one card smaller.

For N = 2, In position 1 you choose card 1 with 50% and card 2 with 50% probability, and card 2 is just the remaining card. Thus

        p(12) = 50%
        p(21) = 50%

For N = 3, In position 1 you choose card 1 with p=1/3, card 2 with p=1/3, and card 3 with p=1/3:

        p(1xx) = 33% = 1/3
        p(2xx) = 33%
        p(3xx) = 33%

Then using the remaining 2 cards you just do the N=2 case from before, and so you have:

        p(123) = 50% x 33% = 1/6
        p(132) = 50% x 33%
        etc

<comment><USER12> You're right, I think I misread the algorithm.

</comment></comment></comment></comment><comment><USER14> Great article from a classic series that every programmer should read.

Here's an odd thing -- when I copy'n'pasted the awk implementation the pasted copy had errors reminiscent of OCR. For example the (j became Cj, the ARGV[2] become ARGV121.

What's going on here? Is the website detecting the copy and make the browser get something else? Is it Chrome - or something else doing some guessing?

<comment><USER15> I think the document is scanned from a paper copy. The pixels shown on the screen is from the scanned image, but the text for copy-and-paste was created by OCR when the document was scanned and prepared. You often see this with pdf files, I guess the software used to create them has OCR functionality built in.

If you use "inspect element" in your web browser you can see how it is displayed. Each page is a <div> which contains first a big image (with the scanned document page), and then a <span> for each word, which are positioned using absolute positioning to be placed over the corresponding word in the image. The <span>s each have "color: transparent", so you can't see them but you can still select them.

</comment></comment><comment><USER16> Been reading on Fermat's Library for a while now. Love the product!

</comment><comment><USER17> Does anyone know if this paper is part of the book Programming Pearls also by John Bentley?

<comment><USER18> It's in _" More Programming Pearls"_ from the same author (who, by the way, is called Jon Bentley, not John Bentley)

<comment><USER17> Thanks!</comment></comment></comment>


There's Less to Private Equity Than Meets the Eye - <AUTHOR> https://www.bloomberg.com/opinion/articles/2018-11-12/there-s-less-to-private-equity-than-meets-the-eye <comment><USER2> Gist of articles: Private equity returns are more explained by overall bull market that individual talent.

My 2 cents:

Private equity is a key winner of the ever increased "cost" of going public. Enron, Worldcom and other scandals made the legal pendulum swing hard in investor protection. Quarterly calls, getting hounded by analysts, making the number, lawsuits, short sellers... live is tough for a public company CEO.

As a result, private equity has grown so much, displacing the public markets. With this outsized footprints, it is only natural that returns zone in on the market returns.

<comment><USER3> The carried interest loophole has certainly helped as it keeps costs artificially low.

It also short changes social security and Medicare.

<comment><USER4> Maximum taxable earnings for SS is $128,400. Everybody who takes advantage of the carried interest loophole draws a regular salary too, and it's much higher than 128K, so no effect.

<comment><USER3> Not quite, although I guess it is technically a different loophole.

> Another sharp difference involves a tax category called self-employment tax, > a substitute for Social Security and Medicare taxes paid by filers who don't > have regular paychecks.

Rauner's returns show he paid no self-employment tax in 2015 and 2016, years in which he collectively reported nearly $279 million in adjusted gross income. In 2014, Rauner paid just $152 and last year just under $20,000.

The IRS has recently begun cracking down on investors in limited liability corporations such as those in private equity for underreporting income subject to Social Security and Medicare tax.

A 2016 study by the federal agency estimated such underreporting had cost the two financially struggling entitlement programs for retirees $65 billion between 2008 and 2010 alone.

[https://www.politifact.com/illinois/article/2018/oct/21/raun...](https://www.politifact.com/illinois/article/2018/oct/21/rauner- pritzker-tax-disclosures-rich-avoidance/)

</comment></comment></comment></comment><comment><USER5> It would be more interesting to see if the top Private Equity firms are consistently the top firms. note: if private equity matches the market, the top firms beat it.

I am not surprised that mediocre performers will enter any market and drag down the average. In order to tell if it is "skill", you have to see consistency.

To put it another way: Is it more likely than average that Sequoia's next fund will beat the S&P?

<comment><USER6> This is all fine and good ... but PE as a class should still be able to beat the S&P and if not, then we need to possibly change our view of these things.

I don't doubt any of this a bit.

<comment><USER5> Well, if you accept the premise that this is "fine and good", then why should[edit:n't, as in why shouldn't] the PE class beat the S&P.

Let me tell you a story that may or may not be true. We would need a study to tell us.

There are some very smart people who have noticed that debt is much cheaper than equity. They go into a company and borrow against the cash flows of the company. They borrow enough to buy the company and have cash leftover. Essentially they find money for free. In order to do this, they have to know the bankers who trust them, know how to value the firm and so forth. They go out and make a killing year after year.

You and I look at this and think, how hard can it be? We put up a shingle, and we try to do the same thing. Now we don't have the same relationships so we put everything on our credit card. We can't value the company properly and make a few mistakes. We lose a lot of money for a few years and shut down.

Let's say that when you average your and my performance with the other company, we get the S&P 500 average. And we conclude there is nothing in private equity and that there is no skill involved.

Is that the right way to look at it? Or should say that there is PE as "properly" practiced?

I suggest a simple test: if that other firm makes money year after year then there is skill. If their company is up one year and down the other, and you and I have a good year and then a bad year, it may be luck.

<comment><USER6> " then why should the PE class beat the S&P"

It's a matter of perception. PE is generally viewed as advantageous because they have less strings attached, and do more, have the best teams in the business, huge political access (massive political figures on funds boards).

They do post higher returns. Most people think they do, and they charge higher fees.

But if you risk adjust those returns, they're not doing anything. Literally nothing if they can't beat the S&P consistently.

Here's the problem: the 2+20. If PE managers are getting 2% for managing and 20% of the upside, then, well, you might as well just stick your money in the S&P and save all that.

Given those higher management fees, PE is actually a money loser. Just hustlers.

It might very well be something else altogether once you look at the industry, it could be some funds are just crap, some are consistently great - and it boils down to the ability of fund sales people to make deals. So if there are a lot of crap funds with good sales staff ... this will drag the average down. Maybe the good PE firms are actually good :)

<comment><USER3> > Given those higher management fees, PE is actually a money loser. Just > hustlers.

They get a special tax break on top of it!

</comment></comment></comment></comment></comment><comment><USER7> I think many people are missing the point by measuring everything against a single benchmark. The fact that many different investment vehicles (alternatives, indexes, mutual funds, PE, etc) produce very similiar returns is a sign that the markets are working properly. If every investment dollar was just mindlessly plowed into SPY or vanilla public markets then other kinds of investments would generate huge returns (like hedge funds in the 90's). The spread between different investments should be low, because that's how we know the market is efficient.

As an aside, I also think it's silly to just take into account returns. For example, many managers add positions that are predicted to have a net negative on the returns of the portfolio compared to some other position, because it adds diversification or is thought to decrease the variance of the portfolio as a whole.

</comment><comment><USER8> If a tree falls in a forest and nobody is around to hear it, PE funds would love for you to believe it doesn't make a sound! That said, besides the lack of real time mark to market reporting and thus lack of measurable volatility, perhaps there is some value in long term investing that's forced by the lock up period?

</comment><comment><USER9> > the big returns investors think they are getting from private equity funds > are really just the result of leverage and the bull market

This suggests one way PE firms can beat passive indexing.

In bull markets, capital, and therefore leverage, is easier to obtain for niche or exotic investment firms (citation needed) and therefore for PE firms overall. And if they manage to get 10x leverage in bull years and 3x leverage in bear years, they end up comfortably beating the S&P even if they have zero or negative alpha.

I'm skipping over a bunch of details here, but doesn't this seem plausible?

<comment><USER10> This would require that changes in lending constraints precede the transition in the equity markets between bull and bear markets. The reverse seems much more likely: equity markets drop a lot, and banks/debt investors respond to that by tightening up their lending requirements.

</comment></comment><comment><USER11> Link to paper: [https://fisher.osu.edu/sites/default/files/pe_index_- _sep_24...](https://fisher.osu.edu/sites/default/files/pe_index_-_sep_24.pdf)

</comment><comment><USER12> Skip to third from last paragraph for any reference to the actual study.

Otherwise, enjoy commentary like "Those magic words apparently always get you far on Wall Street.".

Sometimes I wish the researchers __were actually quoted in these.

</comment><comment><USER13> consider a private equity company that can borrow money in the us at extremely low rates, take this money and invest it in an emerging market country like India or china or wherever. even if they don't add any value to the company they acquire 'on average' it is growing at 6-7 percent, now if your levered by 70-80 percent youre going to get about 30 percent returns for doing nothing. on top of that the stock market is doing well and providing returns on top of that.

</comment><comment><USER14> My two cents:

PE has been a huge home run because stocks have rallied, but also because their funding costs have been minimal, and returns have been supercharged due to leverage (no such thing as Reg T in PE land).

And yes, the carried interest loophole is a disgusting abomination that cannot be undone in an orderly and democratic fashion because the chief beneficiaries of this loophole are now all billionaires and can/have bribed all the politicians of both parties.

People like Sanders and Ocasio Cortez can undo this, but they are socialists who are probably also keen on undoing a bunch of other stuff the the center/left, center and center/right support. e.g. free enterprise, low taxes, and minimal government interference in our business and personal lives.</comment>


BlinkLink Post-Mortem: 50k pageviews, 700 blinks - <AUTHOR> http://clayallsopp.com/posts/blinklink

<comment><USER2> "I stopped these at first with IP banning, and switched to Rack::Attack for throttling per-Twitter-ID."

I wonder what Twitter-ID he means. Is there an API to get a numeric ID for a given handle that stays the same even when you change your username? If he means the username, wouldn't it be possible to programatically change the username after each request and thus avoid the throttling?

<comment><USER3> Each twitter account comes with a unique numeric identifier in addition to your handle. If it didn't you wouldn't be able to login with twitter on some websites when you change your handle.

[https://dev.twitter.com/docs/platform- objects/users](https://dev.twitter.com/docs/platform-objects/users)

EDIT: After rereading your comment you might have been asking if it was possible to retrieve this id with a simple API call and not with OAUTH. It is possible with "users/show" as explained here: [https://dev.twitter.com/docs/api/1/get/users/show](https://dev.twitter.com/docs/api/1/get/users/show)

<comment><USER2> Thanks, good to know. Though in the current version of the API (1.1), there is a rate limitation of 180 requests/15m ([https://dev.twitter.com/docs/api/1.1/get/users/show](https://dev.twitter.com/docs/api/1.1/get/users/show)), which could become a problem quite quickly on a website of that scale.

<comment><USER4> The rate limit is done against the user's access token, not the server itself. A billion users gets you 180 billion requests in 15 min.

</comment></comment></comment></comment><comment><USER5> An interesting titbit of information from this post is the approx. # of visitors reaching the front page of HN can get you:

"BlinkLink managed to get about _50k pageviews_ against _17k visitors_ "

I'm not sure on how much other sources (Reddit, Twitter) contributed to that number though.

<comment><USER6> From my articles that have hit the top 10, 50k pageviews with a little bit of virality seems reasonable.

You can roughly estimate the amount of visitors on a front-page HN post by 1 point :: 100 unique visitors. In this case, (17k visitors on 138 points), visitors viewed the page 3-4 times, which is unusual.

<comment><USER7> >visitors viewed the page 3-4 times, which is unusual. well, this had the bizarre counting effect that had some people refreshing a lot to see how fast it was going down or if anyone was tweeting it to make it go back up etc.</comment></comment></comment>


Ask HN: Questions to ask during a phone interview - <AUTHOR> This morning I had a call with a recruiter for a senior position at apple, after we talk he said to send him the CV and he then talked with the manager that is hiring at apple. He said that this manager wants to have an introductory interview at the phone tomorrow and he recommended to prepare some questions so I could look more interesting.<p>The problem is that Apple is a big company and is full of information about the working environment on glassdoor,  so I'm not sure what I could ask that I will not find online <comment><USER2> Well, what sorts of things would affect whether you'd be interested in the position? Some examples might be a description of the team (size, composition); examples of projects you'd be working on; the manager's personal philosophy; growth opportunities.

</comment><comment><USER3> Different teams can be different in large companies.

[https://www.keyvalues.com/culture-queries](https://www.keyvalues.com/culture- queries) has a bunch of good questions.

</comment><comment><USER4> What are your 30, 60, 90 day priorities for me in this role?

<comment><USER5> That's a good start. I'd expand it to be: 1 month, 6 month, 12 month, 24 month.</comment></comment>


Spotify Moving from Kafka to Google Cloud Pub/Sub, Part II: Messaging at ~1Gbps - <AUTHOR> http://labs.spotify.com/2016/03/03/spotifys-event-delivery-the-road-to-the-cloud-part-ii/?resubmit=hn <comment><USER2> The Kafka tests included things like reboots, but it sounds as though they didn't test anything like that with Google's could products, presumably because they couldn't.

<comment><USER3> It's not so much they "couldn't", it's that things like global presence, reliability, and scalability are just part of the service. With Kafka, you can potentially design a system that has these properties, whereas PubSub gives you this as a service.

</comment></comment><comment><USER4> Some people would say that this is the first step in an acquisition. I don't know if Google wants to take on the music industry this squarely though.

<comment><USER5> Not the first step, this was the first step [https://news.spotify.com/us/2016/02/23/announcing-spotify- in...](https://news.spotify.com/us/2016/02/23/announcing-spotify- infrastructures-googley-future/)</comment></comment>


Chemists Confirm the Existence of New Type of Bond - <AUTHOR> http://www.scientificamerican.com/article/chemists-confirm-the-existence-of-new-type-of-bond/ <comment><USER2> Why is the muonic hydrogen required?

From the Bohr formula the Rydberg energy of the muonic hydrogen would be some 200 times larger than regular hydrogen. Anyone know how that plays a role?

It can't be sqrt(spring/mass) for vibration since the proton is anyway already some 2000x heavier than the electron. Unless spring somehow depended on the Rydberg energy, which is possible since the P.E-K.E would depend on mass via the K.E.

<comment><USER3> The decrease in potential energy upon vdW bond formation in reactions with typical hydrogen isotopes dominates the negligible gains in vibrational zero- point energy from reactants to products. With the muonic hydrogen substitution, the authors claim instead that the driving force for "bond formation" results from a decrease in zero-point energy which compensates for the expected losses in potential energy.

<comment><USER4> I have a few published articles in quantum chemistry, and I barely can understand your explanation. It feels right, but I think I need to take 30 minutes to try to understand the details. Can you explain this like I'm a graduate student with only 3 years in the university, please?

<comment><USER3> The authors of the article in topic provide a more coherent explanation than I could ever articulate:

>> Conventionally, the formation of chemical bonds is due to a decrease in potential energy (PE), often accompanied by small increases in vibrational zero point energy (ZPE). In principle, this basic mechanism can be completely reversed, wherein chemical bonds may even be formed by an increase in PE if there is a sufficiently compensating decrease in vibrational ZPE, giving rise to what has been coined "vibrational bonding" of molecules stabilized at saddle-point barriers on a potential energy surface (PES), far away from potential minima.

<comment><USER4> Thanks. But I think your previous comment has an interesting point about why muons are different than electrons. I'm not sure because I hadn't made the calculations, so any confirmation or refutation is welcome. Let's try:

When two normal molecules, with electrons, are close, they can form different kind of bonds. The weakest bond is the "van der Waals" bond. It's caused because the electrons of the molecules change their position slightly due to the presence of the other molecule.

In this experiment they only replace the electron of a hydrogen atom by a muon. The muons have much more mass than the electrons, so the radius of the orbit is much smaller. (They are quantum particles, so they don't have orbits, but please forgive this technical detail.) As the orbits are smaller, the displacement caused by the other molecule is smaller, so the van der Walls force is smaller.

In the normal (electron) case the van der Walls force cause the formation of the intermediate molecule. In this case (muon) the van der Waals forcé is so weak that other effects are more important.

[I left out the part about zero point energy. It's also interesting but this explanation is becoming larger than the article :) .]

<comment><USER5> It's the proton that is replaced, not the electron.

<comment><USER4> Ups! :( You are right and now I'm confused.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> > chemists experimenting at a nuclear accelerator in Vancouver observed that a > reaction between bromine and muonium—a hydrogen isotope—slowed down when > they increased the temperature

Isn't saying muonium is "a hydrogen isotope" sort of like saying a car is "a horse isotope"?

<comment><USER7> Sounds like more of a pseudo-isotope?

I thought proton equivalency was the fundamental definition of an isotope, though perhaps that's just a lie you feed chemistry undergrads.

<comment><USER8> The antimuon is "proton-like" for a lot of purposes: it has a +1 charge and it's much heavier than an electron. So you've got a heavy bit with +1 charge and an electron orbiting it, you call it hydrogen.

<comment><USER9> It would have been very nice had the article said that, and described what "muonium" is. I took it to be a proton plus a muon, not an anti-muon plus an electron.

To describe it as "a hydrogen isotope" is just about the optimal mix of uninformative and misleading!

<comment><USER10> It's probably as close as you can get to accuracy while still keeping those who passed their high school chemistry classes in your audience.

For the purposes of explanation, the antimuon-electron pair is chemically similar enough to a proton-electron pair to call it an isotope. It has a +1 massive center, with a probability distribution for a less-massive -1 charge cloud.

Deuterium and tritium, two true isotopes of hydrogen, increase the mass of the center by adding neutrons. An antimuon is, I think, about 10% the mass of a proton. So muonium would act a lot like extra-light hydrogen for the instant before it decays.

It would have been clearer to call it an "exotic atom, chemically similar to hydrogen", though. That wouldn't conflict with the common definition of isotope as an atom with the same number of protons as the reference atom, but with a different number of neutrons.

I'm actually not aware of any exotic atoms that are _not_ chemically similar to hydrogen or antihydrogen, as getting an exotic helium-like atom would require forming a +2 exotic center and making two -1 charges interact with it before it decays. That is likely beyond our current capabilities.

</comment></comment></comment></comment></comment><comment><USER11> "With a Fleming working on a bond, you could say the atomic interaction is shaken, not stirred." What a great lol to start the day with.

</comment><comment><USER12> (With a Fleming working on a bond, you could say the atomic interaction is shaken, not stirred.)

Ha!

So, does that mean the idiotic idea behind that magic material from The Core called Unobtanium might actually be real?

</comment><comment><USER13> This is charge shift bonding. I did several computational research projects on this in undergrad. It's nice to finally see this reaching the media.

</comment><comment><USER14> Link to paper: [http://dx.doi.org/10.1002/anie.201408211](http://dx.doi.org/10.1002/anie.201408211)

</comment><comment><USER15> Given that I have absolutely no real understanding of chemistry, what implications does this have?</comment>


An explanation to the global talent shortage - <AUTHOR> https://medium.com/@calderwhite/education-in-tech-ea22d896e6fc <comment><USER2> Maybe its not an education problem. Maybe the idea that everyone can be an engineer/coder is just as ridiculous as everyone can be a musician.

<comment><USER3> And not everyone is _interested_ in becoming a programmer. Not everyone wants to sit at a desk staring at a computer screen all day at their job.

<comment><USER4> And many of the ones that _do_ want to sit around and code (older workers) find it impossible to finds job — throwing a monkey wrench into the narrative of some massive shortage.

</comment></comment></comment><comment><USER5> I don't think that tech is any more complicated than other fields/subjects. Every subject has levels of abstraction, and as you advance the layers are gently stripped away.

When I started in this field, I began by learning to use some apps, then progressed to learning a single programming language, then another, then about assembly and binary, then about logic gates and then about transistors.

The reason for a talent shortage in tech has more to do with children's education than anything else. I remember giving a talk in front of about 600 developers and asking them, "How many of you chose this field because you were inspired by a teacher at your school?". I'd say about three hands went up. I think if I had been talking at a literature conference, a medical conference or an archaeological conference, there would have been far more hands raised in the air.

The majority of successful developers that I know are self-taught. Even those with CS or SE degrees acknowledge that the skills that got them hired were self-taught. There could be thousands of potentially amazing developers out there that will never know their potential because they either never experienced being taught CS at school, or it was taught badly.

Early years education is important. We should be introducing the subject as early as we introduce English, Math, Science, History, etc. We've all done history projects on the Romans, or Geography projects on volcanoes, when we were six or seven, why not do projects on Turing machines at the same age? Kids should be programming (Scratch) as soon as they can use a mouse and a keyboard.

Unfortunately we have a vicious circle. While there is a tech shortage, we'll have a shortage of tech competent teachers. You're simply not going to get the best of the best, entering the world of education, when there are more lucrative jobs in industry. If we really want to solve the shortage of talent, CS teachers need to be paid an industry competitive salary, and then we need to wait twenty years for the products of their teaching to enter the market place

<comment><USER6> > There could be thousands of potentially amazing developers out there that > will never know their potential because they either never experienced being > taught CS at school, or it was taught badly.

In my eyes, the same way it found all of the self-taught developers is the same way it "could have found" the group of potentially unbeknownst developers you are talking about.

I'd guess the natural desire to understand how things work (taking apart electronic toys as a child) lead a lot of developers to developing. I find it hard to believe deep down there are generally curious tinkerers who haven't found their way to a programming language of some sort?

<comment><USER7> > I find it hard to believe deep down there are generally curious tinkerers > who haven't found their way to a programming language of some sort?

I know one. He's rigourously logical. As a hobbyist, he's worked with electronics and complex mechanical systems: analogue cameras and vintage hifi were two of his passions. He's used computers for decades, but for some reason, they never clicked with him in any deep way. I've explained Turing machines to him, and he understands the concept, but it didn't trigger an interest in going deeper. Fundamentally it's about fear, I think. Fear of facing one's own intellectual shortcomings. Computers expose that in a more raw way than tinkering with physical objects, I think.

</comment></comment></comment><comment><USER8> Or, you know, there's no shortage and it's just a narrative ploy from corporations in order to decrease wages.

<comment><USER9> A shortage of something increases the price... a corporation ploy to create a fake shortage to increase price, decreases price?

<comment><USER10> The fake shortage is an illusion, but it results in a real increase in supply, which decreases price.

<comment><USER11> and how that did work so far? All I can see wages are going upward for a years

<comment><USER12> _Research into real wages in Silicon Valley has found that 90 percent of jobs in the region are paying less than 20 years ago._

[https://www.zdnet.com/article/tech-companies-blamed- for-20-y...](https://www.zdnet.com/article/tech-companies-blamed-for-20-years- of-falling-wages-in-silicon-valley/)

<comment><USER13> Your own article says " _The one group of employees whose wages rose across the board are those working in the high-tech sector in Silicon Valley, with median pay up 32 percent compared with 1997._ " and tech sector employees are who we are talking about.

<comment><USER4> Meanwhile housing prices and rents in the same region went up 300%. Seems like a major net decrease in income.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> I cannot agree, that the troubles with a talent caused by some inherent complexity of tech. I got a bachelor degree in psychology, and generally I think that psychology is a much more complex topic than tech. In tech if you do not understand something, you could read a book explaining things. In a psychology mostly you even do not know what you are not understand, because there is a layman's understanding of human mind that you have been learning for decades, and it needs a lot of effort to separate scientific knowledge from intiutive.

The most problem with tech is fast change rate. It leads to a troubles with devising good ways to teach. You know, if we look at any teaching process, we'll see that people teach other people by the way they'd learnt themselves. It comes naturally to any people, and therefore we could read that BASIC is the best language for novices: because those who recommend BASIC learn how to code with BASIC.

Normally this process of creating curriculum works, generation of professors after generation distill teaching methods. But it does not works with modern tech. If we tried to keep in the curriculum all the stuff we learnt in a college and than add some more, than in a mere 20 years we might come to a situation when students needs 10 more years to get a degree. So we need to throw things out, and no one really know how important rejected bits of knowledge. Because knowledge is not a state of mind, it is not a bunch of bits, it is a process evolving through education and experience. So to replicate knowledge of a person we need to replicate process from the birth.

First years of human life backed up by thousands years of parental experience, and they generally work. But the book about Rust was written a several years ago. Than it was rewritten. Maybe a decade more and it come to a state when ownership and borrowing is not difficult at all. There is nothing inherently complex in ownership and borrowing, it just our past experience gets in a way of understanding them. All we need is to create RASIC -- a rust version of BASIC, -- and teach kids to program in RASIC with an intent to introduce them Rust later. Then the next generation would be unable to understand our troubles with ownership and borrowing, they would think that C rules are dumb and they need a specially wicked creative mind to invent them. They would see C rules as we see Brainfuck: someone did his best to invent a language to make things difficult.

<comment><AUTHOR> I agree with you in that the challenge is partially caused by the rapidly changing environment. However, I also believe the combination of the changing environment and the style which technology is taught creates the problem. It is taught in a more specific manner that promotes getting things to "just work". Or at least, that is what a young student might strive for. I am also not trying to compare the "complexity" of the subject to others. I am simply saying that technology is extremely interconnected. All the topics relate to one another. So, when getting something to "just work" without understanding multiple times, this compounds on itself to create a real challenge in the long run.

<comment><USER14> I agree, that there is a feedback loop between education and practice. But I meant that any attempt to change something needs to start from the root cause: the rapid pace of tech progress. This pace is a good thing, but it comes with a cost.

 _> I am simply saying that technology is extremely interconnected. All the topics relate to one another._

I believe that it is an artifact of our cognition: our understanding of tech is not crystallized enough. To draw borders between topics one needs a lot of time to think and to experiment. It is like developing software by splitting it into separate libraries: you need a lot of time to think to do it perfectly. But in a 10-20 years your separation of a problem domain will stop being perfect because the problem changed.

</comment></comment></comment><comment><USER15> I have interviewed many people just out of school. They never gained anything from school. They aren't any better equipped for the job than anyone else.

Frankly, I know what the textbooks have in them; it's not like the content was missing. Do we blame the teachers or do we blame the students? It really doesn't matter.

How about another reason why people quit IT?

[https://www.ontario.ca/document/industries-and-jobs- exemptio...](https://www.ontario.ca/document/industries-and-jobs-exemptions- or-special-rules/government-employees-and-professionals#section-3)

In Ontario, Canada if you work in IT, you dont get breaks, lunches, overtime, weekends, you can work until 2am in the morning and then be expected to be at work at 7am.

The MSPs in Ontario pretty much all do this. Don't like it? Quit or be fired.

</comment><comment><USER16> To the extent what you describe about depth and breadth is true, it's true of all knowledge and all subjects.

I highly recommend Nathan Ensmenger's The Computer Boys Take Over for a look at the history of the so-called "skill gap" (which is mostly bullshit) since the 1960s. It has a little to do with the nature of the subject matter, but it has a lot more to do with historical contingencies and internal dynamics at schools and companies.

[https://www.amazon.com/dp/0262517965/ref=cm_sw_r_cp_awdb_t1_...](https://www.amazon.com/dp/0262517965/ref=cm_sw_r_cp_awdb_t1_u1YmDbZVX26FD)</comment>


How I Hustled to Get the Perfect Startup Job: From Tradecraft to Zumper - <AUTHOR> https://medium.com/@inaherlihy/how-i-hussled-to-get-the-perfect-job-bd24e74188ae

<comment><USER2> Trying to circumvent a company's hiring process by cold e-mailing ALL 730 employees at a single organisation; as well as calling out busy people who couldn't respond to your cold e-mails or couldn't take time out to meet with you personally by full name, position, and company in a self-promoted Medium post seems a highly negative signal and poor form, especially in Silicon Valley. This is likely the reason most of these companies passed.</comment>


Create Dockerfiles for easily buildable Docker containers - <AUTHOR> http://crosbymichael.com/dockerfile-deep-dive.html

<comment><USER2> The idea behind Dockerfiles is to allow a source repository to be built and packaged automatically, to the exact specification of the upstream developer, regardless of his/her choice of development tools, distro or language.

Source repo comes in, container comes out. No other exchange of information necessary. The only dependencies left are 1) the hardware architecture, 2) the kernel and 3) the docker runtime (which is itself a 5MB static binary).

This makes things like this potentially possible:

        $ docker run git://github.com/antirez/redis

Voila, you are running Redis - built and configured to the specifications of Salvatore himself.

</comment><comment><USER3> With containers, Docker gave us universal compatibility for running software. A Dockerfile gives us universal compatibility for building and customizing our software. Docker needs some time for the community to grow and the documentation to mature, but once it does I think it will be difficult to imagine ever not having Docker. Docker is largely "batteries not included," and slowly getting more useful with improvements like this, bind mounts [1], and lots of users writing their own tutorials.

1: [https://github.com/dotcloud/docker/pull/602](https://github.com/dotcloud/docker/pull/602)

</comment><comment><USER4> I like Go and all but it seems like it is a poor choice for this project. Is there a good rationale for why you would use go to build this?

<comment><USER2> We chose Go, even though we're traditionally a Python shop, for a few reasons:

1) It compiles to a static binary, which makes it very easy to drop docker into an existing ops stack with very little hassle and without having to drag a whole language-specific toolbox along. This has made it easier to adopt docker for devops teams of ruby, python and java persuasion (among others).

2) the language itself is straight-forward, easy to learn and familiar to a lot of people. It's basically a more accessible C. As a result it's been easier to get people from different programming backgrounds to contribute.

This is in addition to, you know, the language being good :)

<comment><USER4> I do like 1) and I agree with your final point. However, all the error handling code, etc is pretty brutal. I imagine someone will put a few scripting languages on top of it at some point.</comment></comment></comment>


This Year We Can End the Death Penalty in California - <AUTHOR> http://www.paulgraham.com/prop62.html <comment><USER2> We've moved most comments to [https://news.ycombinator.com/item?id=12847611](https://news.ycombinator.com/item?id=12847611).

</comment><comment><USER3> Repost from the dead thread.

There is one good reason to keep the status quo (death penalty without any actual deaths) which is that anyone given a death sentence gets their case reviewed and appealed by excellent lawyers working pro bono. The people who get life get no help at all and are just left to rot in jail.

I have read of prisioners being upset when given a life sentence as they know that no one will help them appeal their conviction. If you are innocent you want to be given a death sentence and sit on death row since you will have people helping you get your conviction overturned.

<comment><USER4> "If you're a single-digit millionaire like Hulk Hogan, you have no effective access to our legal system." \- Peter Thiel

[http://www.marketwatch.com/story/single-digit- millionaires-l...](http://www.marketwatch.com/story/single-digit-millionaires- like-hulk-hogan-cant-afford-justice-says-peter-thiel-2016-10-31)

<comment><USER3> Yep. Imagine you are a poor, young black man and have been given an overworked public defender who has no time to put together even the most basic defence. You are innocent, but have been found guilty. Do you want to be left to rot in jail for the rest of your life with zero outside support or given a death sentence and have a huge amount of legal effort put into overturning your conviction?

There are tens of thousands of people serving life sentences getting zero legal support and quite a few of them are innocent.

</comment></comment></comment><comment><USER5> Duplicate of: [https://news.ycombinator.com/item?id=12847611](https://news.ycombinator.com/item?id=12847611) (taking advantage, it looks like, of the WWW here and no WWW on the original).

<comment><USER4> Yeah, that's on page 4 now, because people tend to flag political articles they disagree with now. I can't wait for the election to be over; hopefully sanity will return to HN.

<comment><USER5> I agree with this article about as forcefully as I agree with anything, and I flagged it, because political appeals don't belong on HN.

Either way: this is a duplicate, and should be killed or merged with the first post.

<comment><USER4> It isn't really a political appeal, you know. It's an argument about effective processes. Which is what hackers do all day, look for the best process to solve a problem. I urge you, in the strongest terms, to click the [unflag] button now.

<comment><USER5> This is the problem with political discussions on HN: we've all read the guideline that says "don't post political appeals to HN", and so we waste time rationalizing that our preferred political appeals are something other than politics --- often with some superficial veneer of engineering-speak. I've been here for a pretty long time, long enough to have seen the same tropes used to get Ron Paul's RE[LOVE]OLUTION on the front page. I'm not impressed.

What makes this one worse is that it has Paul Graham's name on it. Naturally, half the site thinks that means it's pre-approved for HN. But no: just because he wrote it doesn't mean he thinks it merits a shitshow political thread on HN about it.</comment></comment></comment></comment></comment>


The Terrible Misogyny in the Games Industry - <AUTHOR> http://nastythingssaidabout.wordpress.com/2014/08/26/the-terrible-misogyny-in-the-games-industry/

<comment><USER2> If you tweet to your enemy "I'm gonna use my orbital laser to incinerate you from space, so that you're wiped clean off the map!" Your enemy will not be actually, literally scared. Because your threat is obviously imaginary. You do not have a space laser, and anyway few people have ever been incinerated by space lasers at all.

If you tweet to your enemy "I'm gonna toss a molotov through your window while you sleep, so that you and your family are cooked alive", they might be legitimately scared. Because that threat is not obviously imaginary. It could feasibly happen, and it is exactly the kind of thing that has been done by hate groups before.

So a threat only becomes a Threat when, in context, it's sufficiently plausible.

That context is key. The plausibility of a threat changes based on who makes the threat, and whom they threaten. If a misogynistic troll on the internet says that he's going to rape me (a man), I can pretty easily laugh it off. I feel safe in assuming the troll is a hetero-male, and therefore probably has little interest in actually raping me, and besides there's relatively little precedent for guys like me being stalked and raped by weirdos.

If the troll says the same thing to a woman, it's interpreted differently. Very many women are raped in our society, it is a constant real fear. And it's not at all unbelievable that a weirdo might seek to stalk and rape a woman he's become obsessed with. Rare, sure. But real enough to be scary.

Point being, yes both men and women are threatened with rape. But while to men it's obviously just an especially colorful way of expressing hatred, to women it can constitute a real and serious threat.

</comment><comment><USER3> This post sets up and knocks down a strawman quite expertly. You're right, it's not just Anita Sarkeesian who gets death threats, threats of rape, etc. leveled at her by idiot troll gamers. That's gaming's culture of harassment and embarrassing childishness due to anonymity.

What the author conveniently ignores is that while Jack Thompson woke the gamer troll machine by being a living caricature of game-hatred, Anita Sarkeesian invites the same wrath by creating level-headed, well-researched videos whose only "incendiary" call to action is for the creators of games to be more thoughtful and inclusive in their use of female characters in video games.

The misogyny isn't in the harassment itself, it's in why the harassment is occurring.

</comment><comment><USER4> > All these horrible comments, just because she's a woman

Huh ? Are you kidding me ? She's not just nobody. She's a feminist, who is very vocal about her opinions, has tons of viewers, and obviously have very polarizing opinions about video games and the place of women/girls in it.

Claiming she's "just a woman" is ridiculous. When you expose yourself, become popular and have lame opinions about some stuff (yeah, obviously I think most of what she talks about is BS), of course you will get a certain number of people who are violently opposed to you, and not just because of your gender.

It's like saying "people don't like Phil Fish and want to murder him just because they are jealous" or something.

<comment><USER5> I don't believe that that ("because she's a woman") was the author's thesis. He is representing what they believe is someone else's thesis: that this is what you get for just being a woman in games.

(Did you read the rest of the article? I don't think you could reasonably believe this was the author's thesis, reading the rest of the article.)

</comment></comment><comment><USER6> All this link proves is that 'gamers' treat everyone who threatens their childish world-view with childish responses.

Nothing has changed. Gamer still equals douchebag, crybaby man-child.

<comment><USER7> or, you don't know what you're talking about and don't care. Which is fine, but wasting everyones time stereotyping (according to this article) 378 million people is not. Condescesion can easily be construed as childish, so grow up.

<comment><USER6> I've been playing games since 1885 when I got my first home computer, and Apple IIe. Don't mistake my words as condescension; it's disgust and anger at the revolting behavior of these 'gamers' and embarrassment that I (and other decent human beings) am in some way involved with them.

</comment></comment></comment><comment><USER8> The misandry is a much bigger problem:

[http://www.singularity2050.com/2010/01/the-misandry- bubble.h...](http://www.singularity2050.com/2010/01/the-misandry-bubble.html)

<comment><USER5> Did you read the article, or respond to the title?</comment></comment>


NASA funds grants to companies working on healthcare products - <AUTHOR> http://medcitynews.com/2013/06/a-new-bridge-across-the-valley-of-death-non-dilutive-money-from-nasas-grant-fund/

<comment><USER2> I like the idea of funding startups but it is a risky business.

It would be interesting if they had programs like DARPA, X-Prize challenges.

I think this method is more efficient and should be leveraged by the rest of the government. It is basically a fixed-bid R&D contract.

</comment><comment><USER3> I'll give this one to NASA for free: start using artificial gravity instead of watching how horrible micro-gravity is to each new group of astronauts.

<comment><USER4> I'll contribute to your research for a gravity generator. Or to your research into what different amounts of gravity in each body part does. Or in stabilizing a huge and cost-effective rotating structure. (But I really want the gravitiy generator..)

<comment><USER5> > Or in stabilizing a huge and cost-effective rotating structure.

So a ring-shaped vehicle that spun at just the right velocity so that the outward centrifugal force would be more-or-less equal to earths' gravity. Is that what you are implying here?

<comment><USER6> Although this approach is obvious, there are complicating factors. The Coriolis force makes high-RPM centrifugal gravity unpleasant and perhaps dangerous to humans. So, to achieve 1g, structures would need to be very large (224 meters). Nonetheless, this is probably the best approach.

[http://en.wikipedia.org/wiki/Artificial_gravity#Rotation](http://en.wikipedia.org/wiki/Artificial_gravity#Rotation)

<comment><USER3> Two modules separated by a tether requires much less mass. It makes Coriolis effects hard to notice.

I readily admit they haven't done any of this. The lack of engineering work into making spinning structures is criminal.

<comment><USER7> In structures with a small radius, the "gravity" differential between your feet and your head is a bigger issue than the Coriolis effect. Large structures using the tether approach produce sufficiently large forces on the tether that it becomes a significant engineering problem. Tether structures also suffer the issue that they are much harder to stop and start than a ring structure. This is important because you do not want the structure spinning whilst you make course adjustments. There are modifications to the design that compensate for this, but they add significant complexity to the design of the ballast.

The ESA have put a lot of thought into this, as have Rosmoscos. I assume NASA have put a fair amount of thought into it as well, but I've nothing to back that up.

</comment></comment></comment></comment></comment></comment><comment><USER8> Wasn't there a program in the previous admin where NASA solved YOUR problems?</comment>


Ask HN: What's fastest for go to market? - <AUTHOR> Multiple apps (2 per platform), multiple platforms (iOS, Android) - 4 total. <comment><USER2> What do you want? Stack suggestion? React Native</comment>


Ask HN: Linux on a notebook - <AUTHOR>

Hi all,
So, I'm looking at getting a new notebook and wanted some input. Right now I imagine three options:
1) Native Linux. This is what I've done for the past two laptops I've gotten, currently running Ubuntu on an x220. It scores high marks on the user experience side of things, but I'm unhappy with it otherwise. I still consistently get 20-30% lower battery life than when running under Windows, and various other annoyances (sometimes not going to sleep when closed, for instance). Even getting there, though involved a lot of really stupid bullshit. Making it into a usable experience was a total PITA, and I'd seriously pay someone a lot of money not to have to deal with it again, except I don't trust anyone else not to screw things up. For that reason I'm disinclined to take this option again, unless there's a simple way to get things working. In an easy, user-friendly way, not a "it's theoretically possible if you spend a couple days of your life messing with config files" type of way.
2) Linux on a VM. I have little experience with VMs, but this option appeals to me: I imagine it minimizes the amount of "stupid bullshit" I'd have to deal with, and even though it would involve some time investment on my part, I see it as time well spent. Do people who have tried this option like it? What virtualization software do you use? And most importantly how taxing is running the VM constantly on battery life?
3) Learn to live with OSX. If I understand correctly, it's possible to run X11 on OSX. Is this easy or obnoxious to do? Can you get XMonad up and running without the OSX dock/menubar/etc? I have no real ideological preference for Linux and really just need a good Unix to work with. Do people have any experiences with this?
I'm also open to other suggestions, if you have them. <comment><USER2> Well you could look here: <http://www.ubuntu.com/certification/desktop/>

But your laptop is already certified there, the sleep thing has been around in linux for a long time and the only thing is to make sure it goes to sleep before you put it away or shut it down when you are done.

Battery life again isn't going to improve with another laptop windows should be better for pretty much every supported laptop, you could look into buying a bigger battery maybe?

You could try System76 but I don't know that they will be better than an x220

<comment><USER3> I used a System 76 machine (pangolin) for two years. It was great, except battery life was never more than 1.5hrs. That's pretty bad for a 15" laptop.

If the machine will always be plugged in, I recommend System 76. But if battery life is an issue, there are better laptops out there.

</comment></comment><comment><USER4> My next linux laptop will probably be a Dell XPS from the Sputnik project: [http://bartongeorge.net/2012/05/07/introducing-project- sputn...](http://bartongeorge.net/2012/05/07/introducing-project-sputnik- developer-laptop/)

I think it's interesting because of the notion of having some sort of Chef or other configuration management on Github, and then being able to fork that for particular development purposes or preferences and switch between them. I gather from some of the other interviews that the sputnik project is aiming for something like that.

As far as hardware goes, I like Lenovo ThninkPads best, and the Dell E65xx series that kind of copy them are also pretty good. I expect to screw around googling driver settings and etc on any new hardware I buy, so I'm not to worried about "just working". Someone else's definition of everything "just working" probably isn't good enough for me anyway.

Running clones of specific production environments in a VM is a good idea, using it as your main everyday interface is not, IMHO.

<comment><USER5> Second the Lenovo Thinkpads. Right now I am running a T510 with out of the box CentOS 6.2 (All default options chosen during installation, no tweaking afterwards) and I get battery life in excess of 3.5 hours.

</comment></comment><comment><USER6> Native is easy enough if you're willing to either shop around (our Samsung Q330 i3 took minimal messing around with for 11.10 and "just worked"™ for 12.04) or pay somebody.

You say you're willing to pay so take a look at people like Zareason and System76 -- people who design the hardware around what will work in Linux. You pay them over the odds, they support you.

But don't get hung up on some features. Battery life is one of those where everybody seems to get the same drop vs Windows. Yeah, I'd really like those bugs found and fixed but it's not going to affect my purchasing decisions. If I need long battery life, I just look at bigger batteries (or slower CPUs). Graphics is another interesting topic.

I'd also go out of my way to avoid dual-GPUs (Optimus et al) for the moment. They do work (bumblebee, ironhide, tbp, etc) but having to prepend things with optirun can get annoying - plus they're another power drain.

</comment><comment><USER7> If you have no ideological preference then use OS X. It uses a real unix and XQuartz is very up to date. You can use Homebrew, but I had some major issues with in the past so YMMV. I personally use MacPorts as Fink is too out of date as I have a 500gb hd and I prefer the 3rd party software to have separate dependencies from the core Mac system software.

</comment><comment><USER8> Try using powertop to help tweak power settings Linux may have overlooked by default. It's in the repos, last time I checked.

</comment><comment><USER9> 3) Don't try to bend OS X to be what it isn't: you will be frustrated, disappointed and will not succeed.

If you decide to learn to live with it, actually learn to live with it: you _will_ have to adopt new usage patterns and tools. Don't try to turn it into Ubuntu, it's not.</comment>


Congress passes bill allowing FDA to regulate smartphone apps - <AUTHOR> http://news.yahoo.com/congress-passes-bill-allowing-fda-regulate-smartphone-apps-002106746.html

<comment><USER2> _promotes innovation, protects patient safety, and avoids regulatory duplication_

Yes, the government has an excellent track record at achieving those objectives.

<comment><USER3> This isn't fair. The FDA does a pretty decent job at it's regulation. I'd say we have the best (or near the best) regulated food supply and drug supply of any nation. It's impressive when you consider that the country is also the third largest by population and fourth by land mass.

I develop for one of the countries largest medical software companies ("EHR companies" now, I guess), so I have a little bit of an idea of what medical software does and what the industry wants to do with apps. (And dealing with regulation). Some Telehealth solutions go far beyond just displaying EHR data and help actively manage a patient's health by taking/accepting certain vitals, drug reminders, etc. And apps are going to be doing this / already doing this.

The FDA absolutely is the regulator for medical devices. Here is the relevant federal code ([http://www.fda.gov/RegulatoryInformation/Legislation/Federal...](http://www.fda.gov/RegulatoryInformation/Legislation/FederalFoodDrugandCosmeticActFDCAct/FDCActChapterVDrugsandDevices/default.htm#Part_A)) that covers medical devices. And I do absolutely agree that a smartphone app, when used to manage patient healthcare, patient ehrs, drug schedules, etc is a 'medical device' that should be regulated by the FDA.

The FDA isn't some archaic, out-of-date and ineffective regulatory agency. They do a good job and aren't shy about recalls, huge fines and enforcing compliance.

</comment></comment><comment><USER4> Can anybody claim with a straight face that there's even a problem here? Where's the evidence of harm?

It seems so transparent that this is just a bureaucracy trying to enhance it's own power / relevance / budgetary future.

</comment><comment><USER5> Now they have to regulate them, will they then become liable for any that slip thru that should in all fairness of been regulated.

Who will regulate the refulator and who regulates them and were does joe public come into the equation. Who gains, who loses, stay tuend to next weeks episode of Soap.</comment>


Soviet research of the 1920s on whether dogs can be psychic - <AUTHOR> http://www.atlasobscura.com/articles/dog-telepathy <comment><USER2> our cat back then and now our dog would wake up, start to pace around (and the dog's face expression when he looks at me would be the pretty clear readable excited expression that "She is coming home!!!"), etc. several minutes before me or my wife would come home. The irregularity of the specific time when for example i'd get back from work have always been significantly higher that those several minutes, while those several minutes mean that i'm like 1 or 2 kilometers still away in the car (or in public transportation bus back then in Russia).

<comment><USER3> > our cat back then and now our dog would wake up, start to pace around (and > the dog's face expression when he looks at me would be the pretty clear > readable excited expression that "She is coming home!!!"), etc. several > minutes before me or my wife would come home.

Rupert Sheldrake wrote a book about this phenomenon [1]. There are many things in the universe that Science has yet to adequately explain.

[1] [http://www.sheldrake.org/books-by-rupert-sheldrake/dogs- that...](http://www.sheldrake.org/books-by-rupert-sheldrake/dogs-that-know- when-their-owners-are-coming-home)

</comment></comment><comment><USER4> Is "atlasobscura" anything more than nonsensical clickbait? The formula is always:

"[How/Why] a (Insert Random Thing) (VERB) to (TRANSITIVE VERB) that (Absurdity or Ridiculous Claim)"

<comment><USER5> How is this article clickbait? It seemed to deliver what the headline promised. These days, "clickbait" around here is turning into what "fake news" is to the current U. S. administration: another name for articles I don't like.

<comment><USER4> I deconstructed the headline specifically to outline how it is clickbait. The results are shocking, wait until you see what happened next!</comment></comment></comment>


Adult Literacy In America [pdf] - <AUTHOR> http://nces.ed.gov/pubs93/93275.pdf

<comment><AUTHOR> It's hard to believe only ~5% of adults can do level 5 tasks. Example: "Interpret a brief phrase from a lengthy news article"</comment>


Getting started with Solaris SMF - <AUTHOR> https://blog.grandcentrix.net/getting-started-with-smf/

<comment><USER2> Great article, keep it up, Tim!</comment>