Yes to pretty much all of the above. It's an extremely terse array programming language in the APL family, but with ASCII primitives and strong distributed programming / IPC support. There are also at least a couple companies that still use K3 (I work at one), and no official support from the author (who went on to make other versions of K that are also awesome but completely different).
IMHO the biggest thing holding K back is lack of a production-ready / batteries included open source implementation. (There are a couple nice open source implementations of K but none of them are as feature complete as this one... Plus this one has at least a start on interoperating with .NET)
Location: NY
Remote: Strongly preferred
Willing to Relocate: Probably not
Technologies: python, js, kdb/k/j/apl, pascal, rust, go, etc.
Resume: https://www.linkedin.com/in/tangentstorm/
Email: michal.wallace at gmail.com
3 decades of experience in web, data, consulting. Currently working on a course to teach programming from the ground up, using assembly language on a virtual machine I've designed, but open to joining the right team.
Thanks to all 3 :) ... Ryelang in sort of "not a concern at this stage" and "go with the flow" way currently has this idea of per project static binary with all dependencies compiled in.
It sounds a little odd at first, but besides being the simplest to implement in Go, this also solves a problem for which Python needs tools like venv, pyvenv, virtualenv, ... that also this blog post mentions. The sheer number of these tools shows that this is a problem and that maybe that the solutions aren't optimal.
It also offloads most of package management (ie. pip like stuff) to just "go mod".
A specific binary per project also has other benefits in terms of securing the running environment, I think ... I'm still exploring this.
This is not yet in focus, but maybe starting from a totally different position will make some interesting or simpler tooling possible.
> Even though you aren’t writing the 3P code yourself, by including it in your project you are committed to understanding it—and refreshing that understanding if you want to upgrade it.
This is a nice thought, but I suspect hardly anyone who uses a framework or library really understands it, or makes the commitment to try.
Obviously, a subset of really talented users eventually learn to understand the framework, but most are at its mercy.
Even then, you can't study every possible framework before choosing one to master - there are too many, and the cost of understanding the foreign code is simply too high.
So I suspect that in general, people try frameworks by taking a leap of faith, and then, sometimes, make the effort to actually understand it later - if and when it becomes necessary.
The main point I'm trying to make here is that even if you're in the "leap of faith" category, you still on some level have to understand the framework constructs (i.e. its API) in order to make use of it. If that API changes with a new version, and you want to upgrade, you're going to have to learn enough about that new API to make the upgrade.
Obviously you benefit from understanding the internals too, but realistically, the more complicated the thing you're using, the less of the internals even a motivated user is going to bother with.
> Obviously you benefit from understanding the internals too, but realistically, the more complicated the thing you're using, the less of the internals even a motivated user is going to bother with.
This is a problem that grows with a large library...An api change has a higher cost than with a smaller library. Smaller libraries also tend to be easier to fully understand. Large libraries tend to be more of a "leap of faith" than small libraries.
IMHO the biggest thing holding K back is lack of a production-ready / batteries included open source implementation. (There are a couple nice open source implementations of K but none of them are as feature complete as this one... Plus this one has at least a start on interoperating with .NET)
reply