'Q for Mortals' Version 3 book available online

I tried to learn Q&#x2F;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&#x27;t work in the free package you can download for personal use.<p>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.<p>On the other hand:<p>I don&#x27;t know why but it somehow bothers me that KDB+ is not open source. I&#x27;m not even someone that demands for anything to be open source and I don&#x27;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&#x2F;JS but to keep my language skills and curiosity happy, I play around with different Lisps (including Clojure&#x2F;Shen), APLs (including Q), Forths and languages made for formal verification (Idris&#x2F;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&#x27;t cannot use them for production. It is simply not sellable to companies who are not used to them.<p>I have a copy of the first Q for Mortals (I bought it a while ago); thanks for this one for free.

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.<p>Probably most importantly it will raise you potential salary :) KDB are really interesting and a door to the finance industry if that interests you.

In 1.6:<p>&gt; <i>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.</i><p>That is not a characteristic of dynamic typing, but of a spartan interpreter implementation and possibly language design aspects not related to dynamic typing.<p>If a language doesn&#x27;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.<p>If binding is distinct from assignment, we can diagnose the situation when a symbol is assigned that was not instantiated previously by binding.<p>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&#x27;t foisting this bad design on us.