You don't just have to learn it (that's the easy part); you actually have to grok it, and that's the hard part.
The piece of code |/0(0|+)\ (all 9 characters of it) efficiently computes the maximum subarray sum[0] of an array using Kadane's algorithm. You'll either have to learn K or trust me on that.
While it is possible to break it down to multiple parts and document each, it is idiomatic to just use it and document the whole line. Or not document it at all, because experienced K people know that already. Why call a function "average" (7 chars) when an implementation (+/x)%#x is only 6? Furthermore, you know from reading it what the average of a zero length list is (NaN). Do you know what a function called "average" would return in this case?
I would say the answer to your question is that K is very different than other programming languages, and requires a different mindset. Somehow, attempts to give it a more mainstream face (e.g. article author's "Kerf" project) do not seem to take off.
I don't know either party but I'd hazard a guess that they're not really offering 500k for a K developer.
They're more likely offering 500k for someone who has a lot of experience managing financial tick data in a KDB environment.
The catch will be that not everyone who has read the KDB for Dummies book (OK, I made that up) will be able to walk into a stat arb hedge fund and add 500k of value.
Yes, I was wondering the same thing. Some guesses: some people may not be comfortable with the somewhat un-conventional syntax / semantics (e.g. no operator precedence, just right to left or as they call it, left of right :) (I'm fine with it myself), or might think you can only get jobs using kdb+/q/k in big cities like New York / London, and may not want to move there. Possibly low market demand (compared to mainstream languages), although high comp, may be another reason. Also people may think you need finance knowledge too, and may not have it. Those are some guesses, that's all. Interested to hear if anyone else has some ideas on this.
Edit: Just saw beagle3's comment after posting mine. Some interesting points there. Still wonder about the non-tech factors though, as listed in above part of my comment.
What's the point in getting all those $$$K if a single major medical event (like cancer) will bankrupt you?
Ah, and I just checked my retirement calculator. It claims that once I retire at 67 I'll have to pay $8K/month for my medical insurance.
Seems like the absolute maximum for that is a bit over $1k/month, and that's only if you didn't Medicare taxes for less 10 years, have an income of over $214k/year and get the most expensive part C and part D coverage. A typical amount would be roughly $200/month, less than even someone in their early 20s would typically pay for health insurance.
That’s the number adp.com gave me. Note that it’s like 35 years from now and yes, it includes (I think) C and D parts. Of course a lot of things may change in the next 35 years.
Keep inflation in mind. I don't know how old you are, but that's probably going to be more like $3k/month in inflation-adjusted dollars, which honestly isn't much more than my employer pays to cover my family now.
ORM stands for Object-Relational Mapping (wikipedia). It is just a way to map domain objects to tables. There is no "promotion the use of state" in that definition. It is your choice to start using state in a (mis)designed manner but please don't blame ORMs for that.
Sorry, I should have been more precise. Not all ORM's are designed the same, far from it.
Many ORMs are built using the Unit of Work / Data Mapping patterns. Such ORM's map your data into a separate domain model and manage this model for you. If your orm has something like an "EntityManager" it has likely implemented this Unit of Work pattern.
A key thing the Unit of Work achieves is to commit changes to the database in a single transaction. You often need to update multiple records in an atomic way within enterprise software.
You might not be faced with such challenges in a simple app, but in monolothic enterprise software it's a core feature of what a good backend server does.
Active Record-based ORMs or query builders aid you only a little in this task; they expose the transaction handling logic so much so that it starts to read as a normal SQL database transaction (and might only be cumbersome to use at worst). Here you, the programmer manages it, similar to a normal SQL transaction.
The Unit-of-Work based ORM is more intelligent. It manages the database transaction for you and figures out any changes that were made to the managed entities. In my experience all Java-built enterprise software (I used Hibernate, EclipseLink and Toplink) are designed this way and make heavy use of it. I've used it with Doctrine in PHP quite a lot, and my guess is C#'s Entity Framework is also built around such concepts. That is a big slice of the ORM market.
Here is where the state comes in; different parts of the applications contribute to creating a single database transaction until flush-time. You as a programmer should know when "flush time" actually happens and understand which entities were marked dirty. That is a lot of hidden state that is managed for you; it is in fact the core of what such ORM's do; managing state until it's ready to be flushed. To make it really advanced, powerful ORMs (the popular enterprisey ones) do a lot of caching too, at different times and at different scopes.
When tackling with such tools the distance to normal SQL becomes very large. I think that is where quite a bit of the hate comes from. It's become very powerful magic.
I've been in places where I had to really understand how this magic works to solve serious performance issues with it. I learned a lot, solving problems that shouldn't have existed in the first place.
I don't like magic. It makes me hide in the corner and cry a little.
My comment was targeted towards the UoW / Data Mapper stuff and much less so to Active Record ORM's.
