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.
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>
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.
Any language that add complexity at that layer loses me, and APL, even with crude visuals is not far from that.
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...
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?
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.
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."
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
It's so weird, though. Everything disagreeable you point out with my comments, I kind of feel like is true of GP's comment. It casually dismisses the content of OP, injecting a strawman about a "metrics". Wore still, it just touts normative and relatively mainstream opinions about better vs. worse thing, without even offering up a hint as to what these supposed metrics are supposed to be measuring.
That's a dick move, IMHO, and a common one at that in these array language posts. I think we as a community do ourselves a disservice by allowing ourselves to propagate such echo chambers.
Which is all a pretty different message than @arcfide (eloquently) attempts.
Please note that nowhere do I attack GP or GP's comment specifically. If you're inclined to reread my comments, please note that I really do try hard to delineate ideas and cultural trends as the target. Heck, I even own up to being part of those trends and culture. Where you have thought I say "you", try rereading it as "we".
Anyway, cheers!
I’ve reread your comments, and they still read like an attack to me, while the top comment does not. You may feel like you’ve drawn a line, but the implications you made were quite clear. Calling it a dick move is a more direct attack, and talking about how it offends you tends to demonstrate that you have been and still are in fact attacking. Using strong language in a direct reply and talking about how wrong the mentality is is always going to be taken as an attack on the comment you’re replying to.
Personally I feel like the “one line” part of the article title is intentionally provocative, and as such, it invites critique, which is what the top comment is. It’s both impressive to fit a sudoku solver on one (short) line, and also at the same time, making a claim that can’t be fairly compared to other languages. As such, it is fair to point out that there’s a more universal way to evaluate the size of Arthur Whitney’s solution that is more compatible with other languages, and combined with the fact that everyone (including you?) already agrees that lines of code aren’t a good metric for anything, it’s not clear why you’ve taken such issue with that casual comment.
The article, disappointingly, doesn’t explain Whitney’s solution in words that non K readers can understand. At a glance, I would assume it’s a more or less brute force search over all possible sudoku boards and then matching against the cells, rows, and columns rules. In a way then, Whitney’s solver might be seen as a succinct statement of the rules of sudoku, which are indeed relatively short in any language.
That said, this exchange will definitely bounce around in my subconscious, so whether or not I explicitly agree, you've definitely moved the needle!
Anyway, whatever happened here, it was a genuine meeting of minds, so much obliged fellow HNer. Be well.
[1] https://en.wikipedia.org/wiki/Algorithmic_information_theory
The parse tree approach is trying to get at a fuzzy notion of useful information and useful density of information.
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