3 ms·

I wonder if there’s a sweet spot for verbosity or if it doesn’t really correlate with bugs or productivity. I end up thinking about this pretty regularly. For

I wonder if there’s a sweet spot for verbosity or if it doesn’t really correlate with bugs or productivity. I end up thinking about this pretty regularly. For example Kdb/q has always fascinated me, my initial reaction was that encoding meaning into fewer symbols surely causes cognitive overload and promotes programmer failure, and yet i saw some python code written by a quant converted to q by a kdb developer. The original python was well written, it relied on pandas and numpy but all fairly garden variety stuff. The q had exactly the same behaviour except some small changes for data ingestion. Around 500 lines of python, 16, not a typo, 16 lines of q. The performance comparison was absurd too.

anonu 6y ago
This has been my experience as well. 10x factor reduction in LOCs and increase in performance when moving to kdb/q
arabelladonna 6y ago
> The q had exactly the same behaviour except some small changes for data ingestion. Around 500 lines of python, 16, not a typo, 16 lines of q. The performance comparison was absurd too. I think this comes down to every symbol having a defined behavior that can be optimized around, rather than building a framework for creating your own symbols (functions). Dyalog APL has some similarly insane "beating C"-type benchmarks. However, if you were to branch out into the more traditional constructs in Dyalog APL or J (K/Q have less of them due to being much, much less generalized), you'd probably see some significant performance decreases simply because they're more generalized. Eg. I doubt that Dyalog APL objects are as optimized as C++ objects. Note: I have no experience designing languages or building compilers/interpreters. I just wanted to put my two cents in, rather than leave this on the somewhat vague and "mystical" note.

3 ms·

I wonder if there’s a sweet spot for verbosity or if it doesn’t really correlate with bugs or productivity. I end up thinking about this pretty regularly. For

by CraigJPerry 6y ago

anonu 6y ago
This has been my experience as well. 10x factor reduction in LOCs and increase in performance when moving to kdb/q
arabelladonna 6y ago
> The q had exactly the same behaviour except some small changes for data ingestion. Around 500 lines of python, 16, not a typo, 16 lines of q. The performance comparison was absurd too. I think this comes down to every symbol having a defined behavior that can be optimized around, rather than building a framework for creating your own symbols (functions). Dyalog APL has some similarly insane "beating C"-type benchmarks. However, if you were to branch out into the more traditional constructs in Dyalog APL or J (K/Q have less of them due to being much, much less generalized), you'd probably see some significant performance decreases simply because they're more generalized. Eg. I doubt that Dyalog APL objects are as optimized as C++ objects. Note: I have no experience designing languages or building compilers/interpreters. I just wanted to put my two cents in, rather than leave this on the somewhat vague and "mystical" note.