Skip to content
HHackerTube.videoSurprise me

A Sudoku Solver in APL

A Sudoku Solver in APL on HackerTube: recommended by 4 Hacker News commenters across 4 separate months, 2015–2022.

Dyalog

demo · intermediate · evergreen

Open on YouTube

A Dyalog demonstration of developing a Sudoku solver in APL, using an algorithm by Arthur Whitney with performance work by John Scholes. The narration steps through the array-oriented solution.

Why Hacker News recommends it

Strongly recommended as a beautiful demonstration that APL can be read and reasoned about step by step.

people recommended it
4
separate months
4
strong recommendations
4
discussed on HN
2015–2022
“I've always liked this video, where one of the Dyalog developers effortlessly writes a Sudoku solver in APL”
— lizardactivist, Mar 2022, in “Dyalog APL 18.2”

What HN commenters said

6 Hacker News comments link this video. Each one links back to its thread.

lizardactivistMar 2022Strongly recommends

I've always liked this video, where one of the Dyalog developers effortlessly writes a Sudoku solver in APL: ▶ this video

in “Dyalog APL 18.2” · View on HN

moonchildAug 2020Strongly recommends

> My point was that general programming usually looks more like writing the sorting algorithm than simply calling it. Thus, I would be more interested in seeing real examples of how the properties of J allow you to write algorithms more concisely or otherwise better. Ah - I see. Here[1] is quicksort in j. John scholes's videos are excellent and very illustrative, though they deal with apl rather than j; conway's game of life[2] and sudoku[3]. > The article showed how J solves some mathematical problems with built in functions or their built-in modifiers. But in general programming, you won't find a function that does exactly what you wanted, maybe with a little adverb. You'll usually have to write that function yourself, to describe how it works in terms of some of those pre-existing functions. Right. This is true, but you generally stay much closer to the builtins in j than you do in other language. > Note that your second example could be expressed as something like > x.OrderBy(y => y[1]) > In C#, assuming x is int[N][M]. I understand that J's version can work with many other shapes of X, but that is hard to appreciate without seeing example of how that comes in handy when writing some other (hopefully well known) algorithm. Right; you mentioned sort predicates, so I was giving an example of a way in which you could sort according to another relation. My point is: being able to change the layout of your data so easily can obviate sort predicates. (Though I do think a sort a

in “J Notation as a Tool of Thought” · View on HN

paliilapAug 2019Strongly recommends

That 1975 APL demonstration is lovely. Much has been preserved in Dyalog and GNU APL - it's very interesting to see how timeless the core APL functions are. I'm very fond of a number of videos by the late John Scholes narrating APL solutions step by step, including the well-known demonstration of Conway's Game of Life in APL (0). His videos on depth-first search (1) and solving sudoku (2) are also brilliant. (0) [link] (1) [link] (2) ▶ this video

in “J can look like APL or English” · View on HN

geocarJul 2019Strongly recommends

APL is great. If you haven't seen them, the late John Scholes did a number of absolutely beautiful demonstrations programming in APL[1], [2], [3]. [1]: [link] [2]: ▶ this video [3]: [link]

in “Non-English-based programming languages” · View on HN

kickMar 2020Cites it

I'm very much a believer in concise notation (more than most people I've worked with), but the advantages of having a name that can be unambiguously spoken are large enough to outweigh a small constant factor. I don't believe this holds up to scrutiny. APL as a language was made to be spoken, and it seems to have succeeded in that. Alan Perlis briefly touched on that in a great paper,[1] and just about everyone who's worked with the language and its derivatives agrees that your statement isn't true. The idea that APL and its derivatives can't be "read and talked about" is frankly ignoring reality by any stretch of the imagination. For example, here's [2] [3] [4] some videos disproving your statement, the first two being APL, the last being k itself. For extra bonus points, see Aaron Hsu's talks [5]; pick any of them, they're all pretty good, and most have a segment in them explaining how that viewpoint is wrong. [1] [link] [2] [link] [3] ▶ this video [4] [link] [5] [link]

in “Stages of denial in encountering K” · View on HN

wickawicJul 2015Cites it

I've noticed that solving a sudoku is something of a rosetta stone for how people program. Norvig's solution is very straightforward in hindsight, but I think that code was either the result of many iterations or of a career of making progressively more readable code. Here are some other sudoku solvers that give more insight into the coder than the problem: Sudoku in APL: ▶ this video Test driven sudoku: [link]

in “Solving Every Sudoku Puzzle (2006)” · View on HN

Topics & tags

Functional programmingAlgorithms & data structuresaplsudokudyalogjohn scholesfunctional programming