News for hackers. Stuff that matters.
Re:Origins of J by 7thaccount on Thursday January 04, 2024 @11:36AM (#38869034)
This kind of story is what I enjoy so much about HN. I wish Kdb+ or Shakti had dramatically lower costs for those industries that don't have access to banking cash. I know open source versions exist, but I understand them to mostly be toys and not really production worthy.
Re:Origins of J by DrDroop on Thursday January 04, 2024 @11:57AM (#38869335)
K is at the end of the day a fancy calculator, I think for most workloads you can use the open source version called ngn/k
Re:Origins of J by avmich on Thursday January 04, 2024 @12:01PM (#38869387)
This - https://github.com/JohnEarnest/ok - can also be used sometimes...
Re:Origins of J by anotherjhacker on Thursday January 04, 2024 @01:30PM (#38870511)
Sure, a fancy calculator that supports rather efficient execution on ridiculously large machine farms. What some people might call the implementation language for a database engine.
Re:Origins of J by kelas on Thursday January 04, 2024 @01:53PM (#38870772)
> k is a fancy calculator

[put your favorite Java here] is also a fancy calculator by the virtue of Turing completeness. what’s your point?

Re:Origins of J by 7thaccount on Thursday January 04, 2024 @07:49PM (#38874306)
Quant firms don't spend millions on what is just "a fancy calculator". It's more than that. It's a high performance combination of programming language and database that are tightly integrated together and more than the sum of their parts. I wouldn't want to write generic software in it, but it's pretty powerful for analysis.
Re:Origins of J by eismcc on Thursday January 04, 2024 @12:01PM (#38869379)
KlongPy sits on NumPy so gets pretty far. For some features, it’s still early days.

Http://klongpy.org

Re:Origins of J by RyanHamilton on Thursday January 04, 2024 @02:30PM (#38871195)
As the author of an open source version (https://www.timestored.com/jq/) I wish the same but I fear the time has passed. Two factors:

1. The other technologies are evolving to take parts of kdb+ that made it special quicker than kdb+ is evolving. See arrow / parquet / numpy / kafka, they each solve parts but kdb+ had them all 10 years ago in <2MB.

2. The ratio of learners to advanced programmers has increased every year for the last 20 years. The languages that have gained popularity in that time range are those with the easiest learning curve. Most beginners no longer want to sit with a book frustrated on 2 characters for half a day.

Re:Origins of J by tangentstorm on Thursday January 04, 2024 @04:36PM (#38872611)
Oh, interesting! I heard other array programmers talking about jq, and (having not seen your website) went off to study the json transformation language, which is also kind of cool, but nothing to do with kdb or q. :)
Re:Origins of J by bigbillheck on Thursday January 04, 2024 @04:39PM (#38872635)
> Most beginners no longer want

Most beginners never wanted that.

Re:Origins of J by kelas on Thursday January 04, 2024 @06:26PM (#38873684)
guys, my two pennies: most beginners have no idea what they want.

what we know is that what they do not want is to produce more ugly endless code into the world - we’ve produced enough of that before they learned how to locate their asse(t)s.

Re:Origins of J by RyanHamilton on Friday January 05, 2024 @04:30AM (#38877249)
You are correct. I guess it's more accurate to say, most beginners are no longer forced to learn step by step from a book. Now they ask google/SO/chatGPT and use that if it works with a few tweaks. Kdb+ has very few core concepts, most of which since they are symbols are hard to google.