knightni

I don't dispute that windows developers are in the majority - I dispute that other choices are as vanishingly rare as your initial comment suggested.

Anecdotally (I work at a large corp), slightly under half our devs use Linux. You only need to look at the array of software-for-programmers that's available under Linux to see that it's an extremely popular choice - the availability of programming software and libraries is generally better under Linux than it is under Windows.

While linux is certainly a bit more hassle to maintain than windows (I use a mac when given the choice, which i find gives me the best of both worlds), it's still a clearly superior environment for highly technical users. It's only recently with the introduction of Powershell that Windows has stopped being a substantial handicap for developers, imo.

An extremely large number of programmers use Mac and Linux machines. Linux on the desktop is sustained to a substantial extent by a programmer audience - and you only have to look at the availability of software for it to see that it's popular among that group.

Personally, when I'm not using a unix-y environment, it's because I've been forced. Using windows as a programmer feels like having one of my hands chopped off.

I think there's two really great things about retina screens on desktops/laptops:

- Firstly, I definitely notice the difference. The higher res screen is noticeably nicer to read. Sure, you don't need to go to the crazy extremes of some newer high res phones, but standard desktop monitors are noticeably ugly by comparison.

- Secondly, the res is high enough that you can finally change (apparent) resolution. My parents are in their late 60s and have bad-ish eyesight, so they lower the resolution on their screen. The result is incredibly ugly. Unfortunately resolution independent display seems to be a forgotten goal in modern OSes, so having screens that can change res is definitely worthwhile.

You're running into the fact that Postgres doesn't automatically cast ints to floats - so 1/50 = 0. Try using 1.0/50.0 instead.

Hereditary, but not in a strong sense - to quote the american diabetes association:

> In general, if you are a man with type 1 diabetes, the odds of your child getting diabetes are 1 in 17. If you are a woman with type 1 diabetes and your child was born before you were 25, your child's risk is 1 in 25; if your child was born after you turned 25, your child's risk is 1 in 100.

Even if both partners are diabetic, the risk is only 1 in 10 to 1 in 4. This strongly implies that what is heritable is the vulnerability to getting diabetes, rather than getting diabetes itself. There is, presumably, some trigger that also needs to occur.

That's kind of you to say! I think, honestly, that it's great to work with/for anyone who takes joy in what they do.

> Being a programmer is fucking boring ... They want you to spend your time ... optimizing their databases

Honestly, I really fucking love optimising databases. I can't believe my luck that people want to pay me to do that sort of work for 8 hours a day.

To me, hell is having to define and defend my own problem. I would loathe running a startup - I love the feeling, instead, of having people come to me to solve their problems. Fortunately, I've managed to arrange a situation where enough of those problems are reasonably interesting to my apparently unusual tastes :-).

This is not meant as a dig against those who run startups, just a note from someone with a very different perspective.

WITH and window functions are portable (and both awesome - they will change the way you write your SQL for the better). I'm not sure if WITH RECURSIVE is portable - my recollection is that oracle and db2 at least don't need/use the RECURSIVE qualifier for recursive ctes: they just work it out for you.

Time intervals are also in the SQL standard as I recall (although not in the format listed here - postgres supports standard syntax too though). Not sure how fully supported it is cross-database, though.

...data warehouses in general mostly use SQL, and lots of businesses use data warehouses successfully. Teradata, Netezza, Oracle, DB2, etc. I'm not sure why his statement was controversial - SQL's a great language for reporting and analytics.

I would imagine that for your average startup, using solutions that don't even support transactionality will cause greater complexity issues. Especially given the enormous window before db scale out/up becomes an issue on well-designed applications.

> LIMIT OFFSET queries are always going to be hard because you have to generate lots of rows only to throw them away

In fairness, that often depends upon the intelligence of the planner. A lot of sort-limit-offset queries can be reasonably easy and not generate too many rows if the planner works correctly and you have the right indexes.

edit: Assuming you're mostly picking up early pages as opposed to getting late ones, anyway - which is usually the case for, say, a comment system.

...or he could use a dbms that works properly and save himself the hassle.

This is awesome, thanks :-)

The problem is that by punishing companies and rewarding individuals, you tend to create an incentive for individuals to break the law (the risk/reward, on a personal level, gets skewed). In cases like this it's arguable that the individuals involved should be prosecuted.

Oracle and DB2 both offer ways to provide hints to the database about how you want the query processed, and the ability to store those hints independently of the query - Stored Outlines and Plan Stability being the features in question. This is particularly useful when you can't risk the plan changing in production and screwing you over - in that situation it's preferable to experience a gradual degradation->optimisation cycle personally.

It's one thing that I find it frustrating that Postgres (which I otherwise love) doesn't offer - I understand that they don't like optimiser hints, but at least the ability to say 'keep using the current plan until I give you permission to do otherwise' would be invaluable.