chrismonsanto

If you're interested in alternative sort algorithms, you might enjoy the self-improving sort [1]. A simplified tl;dr: given inputs drawn from a particular distribution + a training phase, the result is a sort that is optimal for that particular distribution. The complexity is in terms of the entropy of the distribution, and can beat the typical worst case O(n log n) for comparison sorts.

[1]: http://www.cs.princeton.edu/~chazelle/pubs/selfimprove.pdf

> Racial slurs aren't acceptable anymore. That isn't what brought about the civil rights movement, but it's an important consequence of it.

I don't really want to pick sides on 'ban bossy', but I do think this particular analogy is flawed. Unlike a racial slur (or any other identity-based slur), 'bossy' describes intrinsically negative behavior. People who are 'overly authoritative' or 'domineering' will always be looked down on in society whether or not this word is 'banned' or not.

Because when writing a recursive function, the zero element is generally the base case.

    if x:
        <destructure x, recurse on subparts>
    else:
        return <something>

This applies to (natural) numbers as well--'destructuring' usually means decrementing the number.

I agree. To me Barbie looks obviously unrealistic which reinforces to me that it's a toy. However, I don't feel I have a good perspective on this because I never played with Barbies as a child. OTOH the toys I did play with were also not "realistic" in any sense.

Perhaps if kids grow up playing with realistic toys they won't think they are uncanny.

I'm not defending the original quote--I was just saying that the contrapositive "that which doesn't make you stronger, kills you" seems overly absurd unless you consider the universe of discourse.

Sorry to be pedantic, but I think it's implied that the universe of discourse is "all things that are attempting to kill you." The contrapositive under that assumption isn't absurd.

I would imagine one of my showers takes at least 10 minutes. I think if I'm really tired or cold it could take 15-20 minutes.

I am not a morning person.

"Don't send them food, move them out of the desert where nothing grows" might not be funny, it might not be accurate, but one could hardly call it disgusting...

ASP.net? What sorcery! My undergrad website was developed in classic ASP. Our version control was copying files to a networked shared folder.

For an example of how utterly fucked classic ASP is: it has no API for accessing file uploads. If you code it yourself, it disables all of the rest of the parsing (query string, form variables, ...), which you then also have to code yourself. Not to mention the whole "hasn't been supported by Microsoft for a decade" thing.

I personally think the biggest problem with current file systems is lack of ACID semantics. It is a tragedy that you can't rollback a set of file system changes if a shell script fails halfway. Why should I have to bring out SQLite if I want transactions, but don't need relations?

(Also I agree--yes MIME types in filesystem please)

That's awesome about flex-wrap! I have been waiting a long time.

> stable spec

I'd really like to see more vendor prefixes for support. I mean, basic flexbox support was rolled out quickly, and the spec changed like three times. Mozilla has a new 'avoid vendor prefixes' thing, which I think is the wrong approach. I'd rather just use a tool like autoprefixer to generate all of the browser-incompatible CSS until we can all agree.

I can't believe I am praising IE for being forward thinking! (they have full CSS grid support, per the draft)

css grid support, flex-wrap support

https://github.com/eudoxia0/Hylas-Lisp is one example, targeting LLVM

I don't disagree with what you are saying, but I think you are saying something different than the person I replied to.

To me, the statement "What kind of a person even idolizes someone for writing great code?" suggests that programming is not an art, not worthy of further consideration, a mere means to an end to whatever product to be sold. To me, that statement is like saying "Who even idolizes <insert great painter here>? The guys who sold this art didn't even know how to paint!"

I am not saying that is an invalid viewpoint. I just think it's a weird viewpoint to have on Hacker News. For me, mathematics, code, etc is not a means to an end, but its own reward. To me, that is part of what it means to be a hacker. I wish there was a place where everyone felt the same way. Hacker News used to be that place for me, but the demographic has changed a lot. That is sad.

> I guess someday when you're an old man, right before you close your eyes for the last time, you can imagine all that cool code that you wrote, and say what a great life you had. You were a hacker.

I'm also a researcher, and I like to think that the ideas I discover will outlast me and will make a difference.

Your implication is that those who think of software as a 'product' to be sold are making a difference, and those who think of creating software as its own reward are not. Maybe you are right. I just wish there was a place for those of us who appreciate the craft to hang out. Hacker News, for a long time, was that place for me.

> What kind of a person even idolizes someone for writing great code?

Are we on the same site? I've been reading HN since it was called Startup News, and I have never felt such a disconnect before.

> The Instagram founders didn't have a programming background

Instagram could be worth a trillion dollars and I wouldn't give a shit about it. Show me the code. Satisfy me intellectually. Not everything is about money, and that is part of the reason I call myself a hacker--coding for the sake of coding and what not.

I knew what you were talking about (although, to be fair, the poster you linked is a friend of mine)

Their response: http://np.reddit.com/r/IAmA/comments/1qjg3s/we_make_the_game...

That user is not joking, but note that you generally prove that string concatenation is associative once, not every time.

I have faith that this will get better. We need standard libraries of proofs just as much as we need standard libraries of code. I know Coq has made progress on this, but it's still early days.

I do agree with you that there are times when 'full' type checking is inappropriate. Typing is a spectrum, and it's a bit of an art to decide how detailed of guarantees to give for your API.

It depends. In the most general case, you have to prove that the program you have given has the type you have asserted. This is similar to proving a mathematical theorem. Generally, the computer will assist you in this endeavor--for example, if you want to prove that A implies B, and A and B are linear inequalities, this can be solved automatically.

> I don't know if there exists any type that can't be expressed in Scala.

Scala has a very rich type system, but let us not get ahead of ourselves--Scala, being non-dependently typed, cannot type many useful programs.

For an example of a useful dependent type, consider giving division the type Number -> {x : Number | x != 0} -> Number. Giving division the type Number -> Number -> Number is similar to how older Javas would type List<String> as List and require all get operations to cast from Object--in both cases, the type system is unable to guarantee that your program won't crash.

If you want a glimpse of the state of the art of programming with dependent types, try Agda[0].

[0]: http://wiki.portal.chalmers.se/agda/pmwiki.php

> I often hear that researchers don't want to limit access to the paper, but feel they have to, to publish and progress.

I have published in several ACM conferences and this is how I feel. I much prefer USENIX's policies.

> and that while its easy to say 'make it free', it costs money to run an organisation that manages publications.

The actual research is funded by the government or in increasingly rare situations, private companies. Reviews are volunteer labor. Post-review editing (what they used to call 'typesetting') is done by the author. Putting up a PDF somewhere costs more or less nothing. So yes, the essential parts could (and should) be free.

The actual money goes to printing paper (who cares), subsidizing conferences (an event where you hang out with your friends, and then give your speech to an audience of people waiting to give their speech), and subsidizing other ACM stuff (inappropriate for the taxpayer to incur this burden).

Until the ACM makes our work free to those who have paid for it, I will not be a member of their organization. I will publish in their conferences (you have to...), but I will never link to or reference their 'official' copy.

Why not assume the best of your fellow developers, instead of assuming the worst? Here is an interpretation that has nothing to do with "sticking it in women's eyes": https://news.ycombinator.com/item?id=6825193

And can we please put this into perspective? The language you use reminds me of another GitHub comment suggesting that reverting a commit from they -> him is 'erasing women from the community'.

I'm a bit extreme, but I don't own a smartphone, I never have owned a smartphone, and I never plan to own a smartphone. I already know what it will do to my brain, because I spend all day at my computer, and it's a constant struggle to not waste time on the Internet. (Most of my best work has been done on pen and paper while taking a walk.)

Even when I'm not working, I like being disconnected. It gives me a chance to reflect on my life. Where I am, where I want to be. Ideas I have. I find it difficult to produce anything of value to myself or others when I am too busy consuming stuff through my screens.

I think the worst part of smartphones are the cameras. I had an epiphany one day at some aquarium in NJ. The aquarium was mediocre, certainly nothing worth taking pictures of. But yet every group of people had to take videos of the fish, had to pose with the fish with their friends, etc (who knows why, those people will never view those videos ever).

Of course all of this picture taking took so long that people got bored. Why not, they couldn't see the fish, after all. So of course, everyone got on their phones and goofed off, which made the crowds even MORE sluggish, which made the whole affair take longer, and which made the aquarium experience even more boring.

I think that if phones were banned at the aquarium people would have gotten in and out more quickly, seen more fish, and had more fun. It's ironic that the smartphone--which is supposed to be whiz-bang-wow-entertainment-whenever-you-need-it--contributed heavily to making the aquarium experience boring for everyone.

Sorry to ramble! This issue means a lot to me. For a funnier presentation of what I just said, check out Louis CK's standup (http://www.youtube.com/watch?v=zd2sRC3K9Hs).

I don't know if you endorse the message behind that photo or not, but I've never taken someone out to dinner who busted out the newspaper while I was trying to talk to them.

> AFAIK there's no up-to-date comprehensive summary of the state of research on trace compilers. Most papers don't even scratch the surface of the challenges you'll face when building a production-quality trace compiler.

In general, there are few good + comprehensive resources for advanced compilation techniques. I would gladly fork over $$$ if you wrote a textbook on tracing compilers aimed at people who have expert-level knowledge in more traditional compilation methods (aka, not JIT).

> Now that is a clean, friendly design.

I was pleasantly surprised to find that the header wasn't fixed. I can't wait until that fad dies out.

You are reading way too much into this.

I do agree with the quoted statement. I have a lot of experience with machine-verified proofs (in a language called Coq). Even though Coq guarantees that an accepted proof is correct, you still can't necessarily trust it, because your formal model of the program may be not accurate enough, or your statement of correctness is improperly stated.

In this case, it seems like their proof was correct with respect to their model, but their model did not match up with reality. No amount of formalization will ever be able to solve this problem completely. I think the role of testing in this context is to make sure your formalization of the problem says what you meant to say about the world that you meant to refer to. Input/output examples (aka, tests) are a great way of convincing yourself of this.