7 ms·

Lines of code is a poor metric, because languages use lines differently. A much better measure would be the number of nodes in a parse tree, of semantically me

by nine_k 2y ago

Lines of code is a poor metric, because languages use lines differently. A much better measure would be the number of nodes in a parse tree, of semantically meaningful non-terminals like "a constant" or "a function call". An even better measure would also involve the depth and the branching factor of that tree.

tromp 2y ago
The preferred measure of information content is simply number of bits as used for instance in Algorithmic Information Theory [1]. [1] https://en.wikipedia.org/wiki/Algorithmic_information_theory https://en.wikipedia.org/wiki/Algorithmic_information_theory
- jodrellblank 2y ago
  By that measure naming a variable “objUser” instead of “user” is better because it has more information, and naming the same variable “cgjkkytdvjkftujmhffetb” is even better because it contains more information. The parse tree approach is trying to get at a fuzzy notion of useful information and useful density of information.
smokel 2y ago
The built-in functions and API to a system library spoil these metrics. As an example, consider HQ9+, which is pretty good at printing "Hello, world!" for instance. https://cliffle.com/esoterica/hq9plus/ https://cliffle.com/esoterica/hq9plus/
xelxebar 2y ago
Just... no. What are you even trying to compare? UX of a language matters. Clarity, thinking paradigm, expressability etc. all matter and are affected by the visual size of code. A one line solution takes up very little visual real estate. That matters a lot when you are working on some more complex problem. Flitting your eyeballs around a screen takes orders of magnitude less effort than scrolling around and navigating files. Cognitive load is important. We really need to burn this vague "only semantics matter" scourge that's creeped into our programmer values these days. I'm sorry, but I care about things like incentives against over-engineering, ease of directly thinking in the problem domain, and simplicity of the encompassing ecosystem. A terse one-line solution tells me there is virtually no room for over-engineering. Even without knowing K, I can see obvious constants side-by-side, telling me it's likely using a direct data representation of the problem in its code. Does K culture encourage code like that? Does programming in K bias you towards directness and simplicity? Then please, I want some of that special sauce on my team. </rant>
- lukan 2y ago
  "A one line solution takes up very little visual real estate. That matters a lot when you are working on some more complex problem." When I work on some more complex problem, I like to think about the problem, not spend energy decoding condensed text. Scrolling a bit more verbose, but clear code, is faster for me.
  - cenamus 2y ago
    I think the difference is not a bit of scrolling, but rather the whole program on half a page vs 10 files à 200 lines of mostly noise
    - lukan 2y ago
      There is noise and there is self explaining code. One liners for complex problems are a nice challenge, but are seldom clear to read.
      - deleted 2y ago
        [deleted]
- Etherlord87 2y ago
  Why not create a programming language, that uses all possible unicode codepoints to further decrease the number of characters used? That would be so much more readable!
  - vrighter 2y ago
    How about having a "binary operator" codepoint, that is then specialized by a following combining character codepoint. That way it's also intrinsically obvious that the thing is a binary operator at first glance. Even more expressiveness!
- agumonkey 2y ago
  I mentally work like what parent described. I plug ast node in my mind when I read. I like operating with combinators, graphs/trees of them that I almost naturally understand the results of. Any language that add complexity at that layer loses me, and APL, even with crude visuals is not far from that.
skrebbel 2y ago
This oneliner was obviously done for the giggles, and nobody pretends it's reasonably readable code. Getting anal about definitions here is entirely missing the point. (which is "look, K lets you write extremely dense code!")
- wk_end 2y ago
  I don’t know if that’s the case, simply because all code that I see written by array language programmers looks like code golf. Even the language implementation itself! https://code.jsoftware.com/wiki/Essays/Incunabulum https://code.jsoftware.com/wiki/Essays/Incunabulum
  - mlochbaum 2y ago
    Is this because all the code you see is through HN or similar? No one's going to share something titled "an unremarkable script I use to help run my business" here. Not sure what your threshold for code golf is, but you can see APL written in a variety of styles by searching Github. It doesn't recognize K but does have Q, which is basically K plus keywords, obviously promoting more verbose code. Whitney originated the dense style of implementation shown at your link, and a few other implementers (including myself in the past) have picked it up, but it's not that common. For example April, GNU APL, Kap, Goal, and Uiua all use an idiomatic style for their implementation languages. APL: https://github.com/search?type=code&q=language%3AAPL https://github.com/search?type=code&q=language%3AAPL Q: https://github.com/search?type=code&q=language%3Aq https://github.com/search?type=code&q=language%3Aq Implementation: https://aplwiki.com/wiki/List_of_open-source_array_languages https://aplwiki.com/wiki/List_of_open-source_array_languages
  - jodrellblank 2y ago
    https://news.ycombinator.com/item?id=39546175 https://news.ycombinator.com/item?id=39546175

by nine_k 2y ago

tromp 2y ago

The preferred measure of information content is simply number of bits as used for instance in Algorithmic Information Theory [1]. [1] https://en.wikipedia.org/wiki/Algorithmic_information_theory https://en.wikipedia.org/wiki/Algorithmic_information_theory

jodrellblank 2y ago
By that measure naming a variable “objUser” instead of “user” is better because it has more information, and naming the same variable “cgjkkytdvjkftujmhffetb” is even better because it contains more information. The parse tree approach is trying to get at a fuzzy notion of useful information and useful density of information.

smokel 2y ago

The built-in functions and API to a system library spoil these metrics. As an example, consider HQ9+, which is pretty good at printing "Hello, world!" for instance. https://cliffle.com/esoterica/hq9plus/ https://cliffle.com/esoterica/hq9plus/

xelxebar 2y ago

Just... no. What are you even trying to compare? UX of a language matters. Clarity, thinking paradigm, expressability etc. all matter and are affected by the visual size of code. A one line solution takes up very little visual real estate. That matters a lot when you are working on some more complex problem. Flitting your eyeballs around a screen takes orders of magnitude less effort than scrolling around and navigating files. Cognitive load is important. We really need to burn this vague "only semantics matter" scourge that's creeped into our programmer values these days. I'm sorry, but I care about things like incentives against over-engineering, ease of directly thinking in the problem domain, and simplicity of the encompassing ecosystem. A terse one-line solution tells me there is virtually no room for over-engineering. Even without knowing K, I can see obvious constants side-by-side, telling me it's likely using a direct data representation of the problem in its code. Does K culture encourage code like that? Does programming in K bias you towards directness and simplicity? Then please, I want some of that special sauce on my team. </rant>

lukan 2y ago
"A one line solution takes up very little visual real estate. That matters a lot when you are working on some more complex problem." When I work on some more complex problem, I like to think about the problem, not spend energy decoding condensed text. Scrolling a bit more verbose, but clear code, is faster for me.
- cenamus 2y ago
  I think the difference is not a bit of scrolling, but rather the whole program on half a page vs 10 files à 200 lines of mostly noise
  - lukan 2y ago
    There is noise and there is self explaining code. One liners for complex problems are a nice challenge, but are seldom clear to read.
    - deleted 2y ago
      [deleted]
Etherlord87 2y ago
Why not create a programming language, that uses all possible unicode codepoints to further decrease the number of characters used? That would be so much more readable!
- vrighter 2y ago
  How about having a "binary operator" codepoint, that is then specialized by a following combining character codepoint. That way it's also intrinsically obvious that the thing is a binary operator at first glance. Even more expressiveness!
agumonkey 2y ago
I mentally work like what parent described. I plug ast node in my mind when I read. I like operating with combinators, graphs/trees of them that I almost naturally understand the results of. Any language that add complexity at that layer loses me, and APL, even with crude visuals is not far from that.

skrebbel 2y ago

This oneliner was obviously done for the giggles, and nobody pretends it's reasonably readable code. Getting anal about definitions here is entirely missing the point. (which is "look, K lets you write extremely dense code!")

wk_end 2y ago
I don’t know if that’s the case, simply because all code that I see written by array language programmers looks like code golf. Even the language implementation itself! https://code.jsoftware.com/wiki/Essays/Incunabulum https://code.jsoftware.com/wiki/Essays/Incunabulum
- mlochbaum 2y ago
  Is this because all the code you see is through HN or similar? No one's going to share something titled "an unremarkable script I use to help run my business" here. Not sure what your threshold for code golf is, but you can see APL written in a variety of styles by searching Github. It doesn't recognize K but does have Q, which is basically K plus keywords, obviously promoting more verbose code. Whitney originated the dense style of implementation shown at your link, and a few other implementers (including myself in the past) have picked it up, but it's not that common. For example April, GNU APL, Kap, Goal, and Uiua all use an idiomatic style for their implementation languages. APL: https://github.com/search?type=code&q=language%3AAPL https://github.com/search?type=code&q=language%3AAPL Q: https://github.com/search?type=code&q=language%3Aq https://github.com/search?type=code&q=language%3Aq Implementation: https://aplwiki.com/wiki/List_of_open-source_array_languages https://aplwiki.com/wiki/List_of_open-source_array_languages
- jodrellblank 2y ago
  https://news.ycombinator.com/item?id=39546175 https://news.ycombinator.com/item?id=39546175