This is a great way to get to know KDB. As a language it will definitely make you think about problems differently in a functional array context, and as a development platform it will give you some unique perspective on databases as it is much different than many others. And the simplicity of the system will be refreshing.
Probably most importantly it will raise you potential salary :) KDB are really interesting and a door to the finance industry if that interests you.
I tried to learn Q/KDB+ more than once with only online resources and I think this book is definitely something needed. The available wiki was always a bit spare and some parts didn't work in the free package you can download for personal use.
KDB is very interesting and I always had the feeling, if you stare long enough at the code you kinda learn a different way to express algorithms and a different view for how to write code. APL and its successors are probably one of those things that Alan Perlis talked about when he said that you should only learn a programming language that changes your way of thinking.
On the other hand:
I don't know why but it somehow bothers me that KDB+ is not open source. I'm not even someone that demands for anything to be open source and I don't actually use KDB besides thinking about learning it every now and then but it really keeps me off.
For production software I program in Python, C#, Java, PHP, HTML5/JS but to keep my language skills and curiosity happy, I play around with different Lisps (including Clojure/Shen), APLs (including Q), Forths and languages made for formal verification (Idris/Coq). It is very interesting what people do with these languages and I like playing with most of them, but besides niche jobs, I don't cannot use them for production. It is simply not sellable to companies who are not used to them.
I have a copy of the first Q for Mortals (I bought it a while ago); thanks for this one for free.
KDB might be niche, but that niche is finance and there are a decent number of open KDB positions. I get a couple of unsolicited emails a week for them. And they pay very well.
Yes, Clojure (that Lisp variety) as well. Forth for embedded as well. But they are niche; it depends where you live etc on which opportunities there are for each of those. But yes, you are right; Kdb (and Clojure btw) are good in some parts of finance and pay well.
Edit: what i'm basically saying is that practicing any of these languages will help you in potentially more than one way; it will open your mind to interesting paradigms and constructs as well as give you job opportunities you would not think of possibly later on.
> Dynamic typing combined with mutable variables is flexible but also dangerous. You can unintentionally change the type of a variable with a wayward assignment that might crash your program much later. Or you can inadvertently reuse a variable name and wipe out any data in the variable. An undetected typo can result in data being sent to a black hole.
That is not a characteristic of dynamic typing, but of a spartan interpreter implementation and possibly language design aspects not related to dynamic typing.
If a language doesn't distinguish variable binding from assignment, that is a poor design choice which interferes with the ability to trap an assignment to a nonexistent variable and promotes the silly variable re-use alluded above.
If binding is distinct from assignment, we can diagnose the situation when a symbol is assigned that was not instantiated previously by binding.
Moreover, we can use lexical binding to introduce new variables wherever we need them, rather than re-using. We can still choose to write long functions in which variables are re-used for different purposes in different sections, but the language isn't foisting this bad design on us.
6 comments
[ 3.2 ms ] story [ 29.9 ms ] threadProbably most importantly it will raise you potential salary :) KDB are really interesting and a door to the finance industry if that interests you.
KDB is very interesting and I always had the feeling, if you stare long enough at the code you kinda learn a different way to express algorithms and a different view for how to write code. APL and its successors are probably one of those things that Alan Perlis talked about when he said that you should only learn a programming language that changes your way of thinking.
On the other hand:
I don't know why but it somehow bothers me that KDB+ is not open source. I'm not even someone that demands for anything to be open source and I don't actually use KDB besides thinking about learning it every now and then but it really keeps me off.
I have a copy of the first Q for Mortals (I bought it a while ago); thanks for this one for free.
Edit: what i'm basically saying is that practicing any of these languages will help you in potentially more than one way; it will open your mind to interesting paradigms and constructs as well as give you job opportunities you would not think of possibly later on.
Edit2: https://github.com/JohnEarnest/ok is interesting for playing around by the way
> Dynamic typing combined with mutable variables is flexible but also dangerous. You can unintentionally change the type of a variable with a wayward assignment that might crash your program much later. Or you can inadvertently reuse a variable name and wipe out any data in the variable. An undetected typo can result in data being sent to a black hole.
That is not a characteristic of dynamic typing, but of a spartan interpreter implementation and possibly language design aspects not related to dynamic typing.
If a language doesn't distinguish variable binding from assignment, that is a poor design choice which interferes with the ability to trap an assignment to a nonexistent variable and promotes the silly variable re-use alluded above.
If binding is distinct from assignment, we can diagnose the situation when a symbol is assigned that was not instantiated previously by binding.
Moreover, we can use lexical binding to introduce new variables wherever we need them, rather than re-using. We can still choose to write long functions in which variables are re-used for different purposes in different sections, but the language isn't foisting this bad design on us.