4 ms·

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 vi

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.
dahart 2y ago
Don’t get confused between using smaller keywords and actually understanding the problem at hand. Terse languages do absolutely nothing to prevent over-engineering. They might even contribute by giving a false sense of simplicity and a tendency to prevent certain kinds of code reuse. To prevent over-engineering on large projects, you don’t need a terse language at all, you need the right mentality, the right management & product team, good team culture & cohesion, strong code review process, and job performance metrics that align with not over-producing code. It seems like parent’s metric (size of parse tree) would easily optimize for terseness and penalize bloat, regardless of language, so maybe your reaction was too reflexive. UX of a language does matter a bit, and one that’s too terse incurs development friction and technical debt when used in larger projects. Just study the history of Perl and why it’s not widely used. What a one liner looks like is more or less the worst possible metric to use for large software projects. In any language, the style of code changes the larger the codebase, and cleverness and terseness become a liability. https://www.teamten.com/lawrence/writings/norris-numbers.html https://www.teamten.com/lawrence/writings/norris-numbers.htm...
- xelxebar 2y ago
  > Don’t get confused between using smaller keywords and actually understanding the problem at hand. Absolutely. I'm not arguing for maximal terseness and spent a lot of words attempting to say otherwise. (IMHO, we're both reflexively reacting to our parent comments a bit). What I am wanting to point out is that form affects function and how we think about and use our languages. This in turn shapes our ecosystems and cultures, which influence our heuristics for keeping a pulse on project health and the surrounding support structures. Which all in turn reflect back to affect the forms we like and produce! The mechanics of middle-sized and large businesses naturally incentivize bloat and churn to some degree, not because we necessarily want those things, but because coordination and communication are large information bottlenecks, a la Mel Conway's observations [0]. When our heads are filled with syntax, tooling, best practices, and absolute ideas about what correct code looks like, we make it that much harder to fill our heads with direct problem-domain concerns. While senior engineers can and often do successfully wade through all that, it's a long grind, and anything that empowers team members to get there faster seems like an obvious win. I wish that we as a community could better recognize that our values like "semantics over syntax" or "code review is necessary" or "readability is good" implicitly invoke a large set of contingencies in order to become heuristics that serve well. Tools that violate our common sense and aesthetic values present an opportunity to sanity check those sentiments and potentially sharpen our understanding of them. In my experience, APL and probably K are really excellent at that, offering a new way of thinking that highlights clear disfunctionalities within our current "mainstream" languages and cultures. If true, isn't that something we obviously want to eagerly investigate? So, to bring it back, I think the statement that "AST node count is a better" embodies exactly the kind of values and mindset that make it harder for us to grow. What do we think about readable, maintainable, highly terse code? Does this K sample exemplify that? Why are K and APL successfully (if quietly) running significant portions of our economy? What structural, organizational, and cultural lessons do they embody that we can learn from? [0]:http://www.melconway.com/Home/Committees_Paper.html http://www.melconway.com/Home/Committees_Paper.html

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.

dahart 2y ago

Don’t get confused between using smaller keywords and actually understanding the problem at hand. Terse languages do absolutely nothing to prevent over-engineering. They might even contribute by giving a false sense of simplicity and a tendency to prevent certain kinds of code reuse. To prevent over-engineering on large projects, you don’t need a terse language at all, you need the right mentality, the right management & product team, good team culture & cohesion, strong code review process, and job performance metrics that align with not over-producing code. It seems like parent’s metric (size of parse tree) would easily optimize for terseness and penalize bloat, regardless of language, so maybe your reaction was too reflexive. UX of a language does matter a bit, and one that’s too terse incurs development friction and technical debt when used in larger projects. Just study the history of Perl and why it’s not widely used. What a one liner looks like is more or less the worst possible metric to use for large software projects. In any language, the style of code changes the larger the codebase, and cleverness and terseness become a liability. https://www.teamten.com/lawrence/writings/norris-numbers.html https://www.teamten.com/lawrence/writings/norris-numbers.htm...

xelxebar 2y ago
> Don’t get confused between using smaller keywords and actually understanding the problem at hand. Absolutely. I'm not arguing for maximal terseness and spent a lot of words attempting to say otherwise. (IMHO, we're both reflexively reacting to our parent comments a bit). What I am wanting to point out is that form affects function and how we think about and use our languages. This in turn shapes our ecosystems and cultures, which influence our heuristics for keeping a pulse on project health and the surrounding support structures. Which all in turn reflect back to affect the forms we like and produce! The mechanics of middle-sized and large businesses naturally incentivize bloat and churn to some degree, not because we necessarily want those things, but because coordination and communication are large information bottlenecks, a la Mel Conway's observations [0]. When our heads are filled with syntax, tooling, best practices, and absolute ideas about what correct code looks like, we make it that much harder to fill our heads with direct problem-domain concerns. While senior engineers can and often do successfully wade through all that, it's a long grind, and anything that empowers team members to get there faster seems like an obvious win. I wish that we as a community could better recognize that our values like "semantics over syntax" or "code review is necessary" or "readability is good" implicitly invoke a large set of contingencies in order to become heuristics that serve well. Tools that violate our common sense and aesthetic values present an opportunity to sanity check those sentiments and potentially sharpen our understanding of them. In my experience, APL and probably K are really excellent at that, offering a new way of thinking that highlights clear disfunctionalities within our current "mainstream" languages and cultures. If true, isn't that something we obviously want to eagerly investigate? So, to bring it back, I think the statement that "AST node count is a better" embodies exactly the kind of values and mindset that make it harder for us to grow. What do we think about readable, maintainable, highly terse code? Does this K sample exemplify that? Why are K and APL successfully (if quietly) running significant portions of our economy? What structural, organizational, and cultural lessons do they embody that we can learn from? [0]:http://www.melconway.com/Home/Committees_Paper.html http://www.melconway.com/Home/Committees_Paper.html