[nine_k]

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.

[xelxebar]

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]

"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]

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]

There is noise and there is self explaining code. One liners for complex problems are a nice challenge, but are seldom clear to read.

[dahart]

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.htm...

[xelxebar]

> 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

[dahart]

I don’t know what you mean, and currently do not agree with the idea of parse tree size being a bad mentality or making it harder to grow, and I don’t feel like you’ve provided any objective evidence to back up that claim. Parse tree size seems like a better metric than terseness, for the reasons I and others have already mentioned, despite the fact that sometimes tight small code has some advantages that might be invisible if your only metric is AST size. (Neither parent nor I made such a claim, but your argument depends on that assumption.) K specifically is unreadable by most people, and somehow examples never seem to come with comments or error handling. Is it the best poster child for programming progress as a whole? I have my doubts, even though it might be very useful for some people in some situations.

I would be willing to bet that Excel spreadsheets are running more of our economy than K code, likely by orders of magnitude. I’d also be willing to bet that COBOL exceeds K use by similar multiples. Business/economic use doesn’t seem like a very good metric for what you’re talking about.

[xelxebar]

The original post I replied to made an explicit claim with zero evidentiary support, so your demands for rigor are a bit lopsided. But more to the point, I'm really not saying anything about which metric is better or whatnot. What does it even mean to be a "better metric" when we have no consensus on what criteria we're using for comparison?

In effect, replies here effect to provide some criteria, but each is slightly different and somewhat begs the question, since said criteria can be easily chosen to support whatever conclusion you want.

When the object level discussion (i.e. in this case, the comparison of code size metrics) is ill-defined, the only natural thing we can reach for are cached ideas, heuristics, memetic trends, etc. That is, the discussion essentially becomes an implicit sharing of which cultural ideas we consider salient and important.

That is why I keep going on about culture and values in my previous replies. I'm not saying anything about ASTs vs. token count or whatever. I'm trying to say, "Hey, fellow devs. You know all the obvious ways that K and APL violate our sense of what good and proper code should look like? You know how they feel wrong? Well, actual experience by APL and K devs provides us evidence that we're potentially wrong and should give these languages more open-minded attention."

[dahart]

All programmers think they have culture and values. Getting them to agree on what those are and to prioritize them the same is the hard part. Having an open mind is great, and if you’d said that from the start I totally would have agreed, but you didn’t, you dismissed the GP’s comment with relatively strong language as being very wrong headed on behalf of the entire community, and doubled down on that stance in your followup comment, without acknowledging (or maybe without even realizing) that the suggestion might ultimately align with your message, that you might be picking a fight with someone who agrees with you. I don’t feel like the top comment required any evidence, partly because the claim is nearly tautological and quite easy to agree with, and partly because it wasn’t shitting on someone specific or being mean. You made a much bolder and more antagonistic claim and called their message a “scourge” and framed your point of view about over-engineering in opposition to their comment (which seems like straw man and very presumptuous), so yes I think your argument does require some evidence if you’re going to do that.

There’s a famous couple of comments by @arcfide defending the extremely terse K/APL style of coding, and it really makes a strong case. From what I can tell, this might be what you’re trying to say. I would just say to take note that he does not try to make the poster of the comment he replied to feel wrong headed, he focuses on the positives of his own approach, and he does not project his style on everyone else or make any claims that everyone should use it, he focuses on why it works for him. https://news.ycombinator.com/item?id=13571159

[Etherlord87]

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]

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]

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.

[smokel]

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/

[tromp]

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

[jodrellblank]

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.

[skrebbel]

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]

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

[mlochbaum]

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

Q: https://github.com/search?type=code&q=language%3Aq

Implementation: https://aplwiki.com/wiki/List_of_open-source_array_languages

[jodrellblank]

https://news.ycombinator.com/item?id=39546175