robconery

I believe we're talking past each other. Big O has nothing to do with "actual run time*. It doesn't care what about the number of inputs you have - just that you have them.

Mathematically, if n=1000 then log n is 10. 10 operations vs. 1000 is, theoretically and time complexity wise, faster.

Our disconnect is "actual" vs. "theoretical" and I want to stress again that Big O is purely theoretical. It's a technical adjective.

The Big O of an algorithm does not change based on data size. Even if your set had precisely 1 record in it - the code you write, if it loops over every item in the set (even if it's only one item) - is still O(n).

OP here - O(N log N) is not O(n^2). If n is 1000 then log n is 10, which is 1000 * 10 which is 10,000. That's a bit less than 1000 * 1000.

OP here. Agree that thinking about code is better than using a rule of thumb, but we need to start somewhere don't we? I tried to make it clear in the post that looping over n items within an n loop is n * n.

OP here - Big O notation is simply shorthand math. When you're discussing things in this way, time complexity and performance are the same thing. When you care about resource usage (memory etc) that's space complexity, which is different. Either way, they're good things to understand.

So no I don't think you should use an O(log n) operation in place of an O(n) operation just because of Big O, what matters is which one is faster.

Mathematically the log n is always faster :). Realistically... well that would be a tough one to prove, even with caching, but I say go for it.

OP here. Big O is indeed "worst case scenario" always, the size of the data set doesn't matter. An O(n) operation doesn't care if the data is sorted - even if it's the first item as you suggest. When you discuss Big O it's always worst case.

Derp. OP here - yep typo and corrected thank you!

OP here - as a matter of fact I try to do just this, starting with the database. I'm mostly a data person so I try to think through, as deeply as I can, what I should expect in every table - there has to be a sensible default and if I can't find one then I rethink my design. You'll probably disagree with me and grunt out another single sentence missive, which is fine, but I think it's worth taking some extra time and using Null as a bit of a warning. It's a crutch! A way to stop thinking and say "whatever I don't know what this value is supposed to be so... it's null. Let's go shopping!"

OP here - OP has checked out (and lived with) trinary logic. Just because you appreciate null doesn't mean it should be kept in programming languages and existing programs.

That there is a logical truism, isn't this fun?

Also: false means not true, zero is a number and null doesn't exist, by definition. We can model true/false/zero easily as they exist. Null is made up, so every language gets to think about what it means in an abstract made up way. Thus the pain, thus the post.

OP here - Yes that's the operation the question wasn't supposed to be a literal one, rather a consistency issue, which illustrates the larger point that different languages deal with null differently because it's not logical and therefore confusing and a pain in the ass :)

it's not true to say they don't exist in other languages

Sounds good, waiting for an example to support this...

It's also wrong to suggest that Null has no place in "logic". Boolean logic is one type of logic, but it's not the only type.

What other types did you have in mind? Given that we work as programmers in a world defined by true/false 1/0 logic, I think you might want to reconsider this blanket dismissal.

OP here - I was going to go into that - it's an interesting story. There are null references, as you say, but there's also the null object pattern and the null type. I decided to just focus on the idea of null, which all three of those things represent. A pointer points to a null space, a type represents a value that can optionally be null, and the object pattern allows you to deal with null in your program directly (like Ruby's nil).

So... yeah I dig it man :) I just left some things out to keep on a pace.

There are a lot debates about this and from my experience the biggest issue with running PostgreSQL on Windows is the “Windows Tax”: background processes and services you don’t need on a DB server soaking up resources. Windows Update comes to mind.

Thanks for the thoughts. As with many others I'll offer to you that my entire post is not about piracy. I've lived with piracy of my stuff for the last 7 years. Part of doing business.

The point of my post was a business profiting from pirates. The people who make the choice to forego bittorrent and just post the pirated stuff for a profit. THAT... is my point.

It's a little different than the simple theft of a TV, although yes you raise a decent point. As I've been saying to people: just a reasonable effort is all I ask.

There is a watermark on the entire video, and you can quite easily tell the voice changes from the intro to the main body (where I also mention Pluralsight a few times). A very, very simple review process would catch this.

Every video I submit to Pluralsight goes through a 3-step review (Peer, A/V, tech) and they catch any possibility of copyright infringement (though yes, things do get through).

Udemy is not doing anything this way, and have admitted it publicly (see the post, I updated it at the bottom). They flatly say that they rely on their users to tell them if something has a copyright problem.

Yes, I did. As did Troy. No reponse (now as then).

You entirely miss the point of the article - it's not about piracy, it's about a marketplace for pirated goods. That's what Udemy does. Sorry if I'm not nice about it.

Define "dangerous". Listen mate, if you make money on something and that something is stolen - you are responsible. Udemy created this marketplace for stolen things; people steal things and sell them there.

the correct course of action is to sue

Nope. That's what people do in a dispute to solve the dispute. The correct course of action is something else entirely as we're talking about copyright law, not pissing on your neighbors orchids.

It's fractionally slower, true, because of the serialization hit (string to binary). The real juice comes from the GIN index - and if you apply it to specific columns instead of a complete document, you have a rocket ship on read.

The first function matches any call to it with an error - this is how (apparently) you pass error information on to the result. There's no graceful exit with an error.

The keyword list is pointless with an error function.

OP here - I wanted to offer a comparison of the SQL vs. the ReQL query. Indeed if ACID is something you need, then yes a horizontally-scaling DB is probably something that deserves longer thought.

This is a broader discussion to be sure, and it's been had. Given that PG now supports jsonb, it does mean that yes, we get to have these discussions more.

OP here - many NoSQL/document DBs will trade off write acks for eventual consistency. I really liked their approach to pushing toward durability by default - that in particular was the thing that impressed me, which I should have been more clear about.

I think experience is one thing I'm not short of.

Nope - been at this for 24 or so years now. I wish I was an "underclassman" again - everything was quite fun back then... which I suppose is the point of the post which sort of sailed over your head :).

The feedburner feed was spelled wrong (fedburner)... that was sorta dumb of me, sorry!

Yikes! Fixing - wow that's not good...

OP here... I should say that I wrote this post rather late with a glass of wine in my hand and perhaps didn't use all the exact words to convey my point clearly. But let me address your points.

"Thinking too much" seems to have hit a button for you; sorry about that. I do think this is a pretty common thing: The Paradox of Choice. That's sort of what I am feeling as I know quite a few languages and frameworks, and it's difficult for me to stop diddling over "what should I use" and just write it.

I've spent my career creating things - I haven't created a language yet and to be honest I don't think I have the ability to do so. Not sure what that has to do with my point, but OK.

Also - thank you for the new Twitter bio. You've motivated me to be a better person. I shall never forget you Mr. 5-day old HN account...

You, on the other hand, are amazing.

The entire post is satire. Guess you missed that.

The post is satire of sorts, although in the course of writing it I found such a common cause with Yehuda it was crazy. His pain learning Vim was my pain learning Ember. And the payoff is just as fun (to me at least).

Read this post here: http://yehudakatz.com/2010/07/29/everyone-who-tried-to-convi...

And hopefully you'll see the genesis of the post.

OP here - this post is almost a year old and I don't know why it got pushed to HN again. It's taken a year :) but I think I've come to finally understand Ember... and I very much like it.