Live data from Hacker News

Arthur Whitney's one liner sudoku solver (2011)

dfns.dyalog.com

141–150 of 210 posts

Re: Arthur Whitney's one liner sudoku solver (2011)

#141
post #90

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!")

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

Re: Arthur Whitney's one liner sudoku solver (2011)

#142
post #141

Earlier 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

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

Re: Arthur Whitney's one liner sudoku solver (2011)

#143
post #94
post #20

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

Thanks for the link, it looks like a fascinating language

Re: Arthur Whitney's one liner sudoku solver (2011)

#144
post #25

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

I don't consider an interpreted language having operations "built-in" be significantly different from a compiled language having basic array operations in the stdlib or calling a compiled language.

Re: Arthur Whitney's one liner sudoku solver (2011)

#145
It's cool in a novelty way that it’s so short, but I would infinitely prefer something like this for actual work and understanding:

  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 grid

Re: Arthur Whitney's one liner sudoku solver (2011)

#146
post #90

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.

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…

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.

Re: Arthur Whitney's one liner sudoku solver (2011)

#147
post #94
post #20

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

The front page there has examples like “÷3/+∿⊞×⊟×1.5.220×τ÷⟜⇡&asr” - is that closer to noise, or does it actually look more readable than K once you get used to both? I’m kind-of intrigued by the built-in multimedia output, but still this language looks scary and impractical at first glance. How does it compare to using numpy & jupyter? Do a lot of people prefer the extreme tenseness over using typeable keywords? I’m curious why it lets you type the readable operators but wants to turn them into glyphs; wouldn’t it be more approachable, more readable, and make more maintainable code, if it just used the keywords instead of glyphs?

Re: Arthur Whitney's one liner sudoku solver (2011)

#148

Earlier quoted context omitted.

[flagged]

Array language have been around far longer than any "HN crowd".

Which is totally orthogonal to the original statement, and my reflection to it, which was on one hand statig that seemingly array languages tend to be letter soupy, for which I replied that a selection bias is at play, as array languges are used widely, most notably Matlab is used widely which is not a letter soup. It is simply not regurgulated on the site as it does not seem so hardcore.

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)

#149

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

Which was precisely my point (and I agree with all the responses in this thread), though my wording and light sarcasm seems to have been a bit too dry, and didn't quite take up as intended.

Re: Arthur Whitney's one liner sudoku solver (2011)

#150

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

Keeping skill barriers low keeps wages low as well.
Post reply on HN