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.
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!")
Arthur Whitney's one liner sudoku solver (2011)
141–150 of 210 posts
Re: Arthur Whitney's one liner sudoku solver (2011)
#142Earlier quoted context omitted.
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!")
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
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
Re: Arthur Whitney's one liner sudoku solver (2011)
#143Earlier quoted context omitted.
“Expressive” = like two cats fought while standing on the keyboard
I've been messing with Uiua ( https://www.uiua.org/ ) a good amount recently, and find its sort of dance between having a stack and being an array language somehow gets you to a nice level of legibility despite being a combo of two styles that tend to generate line noise.
Re: Arthur Whitney's one liner sudoku solver (2011)
#144Earlier quoted context omitted.
Well no, not in a non-array programming language. In any language that has a semi-decent type/object system and some kind of functional programming support, `avg a+b` would just be `avg(a, b)`, which is not any easier or harder, with an array type defined somewhere. Once you make your basic array operations (Which they have to be made in q anyways, just in the stdlib), you can compose them just like you would in q, a…
I don't know what you mean by the q array operations being defined in the standard library. Yes there are things defined in .q, but they're normally thin wrappers over k which has array operations built in.
Re: Arthur Whitney's one liner sudoku solver (2011)
#145 def solve(grid):
def find_empty(grid):
for r in range(9):
for c in range(9):
if grid[r][c] == 0:
return r, c
return None
def is_valid(grid, num, pos):
r, c = pos
if num in grid[r]:
return False
if num in [grid[i][c] for i in range(9)]:
return False
box_r, box_c = r // 3 * 3, c // 3 * 3
for i in range(box_r, box_r + 3):
for j in range(box_c, box_c + 3):
if grid[i][j] == num:
return False
return True
def backtrack(grid):
empty = find_empty(grid)
if not empty:
return True
r, c = empty
for num in range(1, 10):
if is_valid(grid, num, (r, c)):
grid[r][c] = num
if backtrack(grid):
return True
grid[r][c] = 0
return False
backtrack(grid)
return gridRe: Arthur Whitney's one liner sudoku solver (2011)
#146Lines 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.
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 navigat…
Any language that add complexity at that layer loses me, and APL, even with crude visuals is not far from that.
Re: Arthur Whitney's one liner sudoku solver (2011)
#147Earlier quoted context omitted.
“Expressive” = like two cats fought while standing on the keyboard
I've been messing with Uiua ( https://www.uiua.org/ ) a good amount recently, and find its sort of dance between having a stack and being an array language somehow gets you to a nice level of legibility despite being a combo of two styles that tend to generate line noise.
Re: Arthur Whitney's one liner sudoku solver (2011)
#148Earlier quoted context omitted.
[flagged]
Array language have been around far longer than any "HN crowd".
Nevertheless you are right, array langueges have been around earlier, for example Matlab itself dates back to the 1970s.
I do not understand the awe some are giving them in the comments, they are an easy to understand paradigm, which is very well suited for certain types of problems. Some having overly terse syntax is a thing, but I do not feel that only geniuses can comprehend array programming, anyone who did learn some university level physics or signal processing has the tools in their belt.
Re: Arthur Whitney's one liner sudoku solver (2011)
#149Earlier quoted context omitted.
[flagged]
The average bank/company would rather have an average solution maintained by 10 easily replaceable average developers than a nutty, smart solution only understood by 1 highly talented developer.
Re: Arthur Whitney's one liner sudoku solver (2011)
#150Earlier quoted context omitted.
[flagged]
The average bank/company would rather have an average solution maintained by 10 easily replaceable average developers than a nutty, smart solution only understood by 1 highly talented developer.