11–20 of 210 posts
Sudoku was always a meditative thing for me. It’s impossible not to win so long as you pay attention. Optimizing solutions seems contrary to the point to me.
I’ve often wondered about languages like APL/k, are the programmers actually able to think about problems more efficiently?
Not knowing K, am I correct in assuming this is a backtracking brute force solver?
Sudoku was always a meditative thing for me. It’s impossible not to win so long as you pay attention. Optimizing solutions seems contrary to the point to me.
Meta: No need to DV a comment you don't like for no reason. Engage instead. Why not have a chat?
I’ve often wondered about languages like APL/k, are the programmers actually able to think about problems more efficiently?
For example, when working with arrays of data it certainly is easier to think and write “avg a+b” to add two arrays together and then take the average.
In a non-array programming language you would probably first need to do some bounds checking, then a big for loop, a temporary variable to hold the sum and the count as you loop over the two arrays, etc.
Probably the difference between like 6ish lines of code in some language like C versus the 6 characters above in Q.
But every language has features that help you reason about certain types of problems better. Functional languages with algebraic data types and pattern matching (think OCaml or F#) are nicer than switch statements or big if-else-if statements. Languages with built-in syntactic sugar like async/await are better at dealing with concurrency, etc.
> Advocates of the language emphasize its speed, facility in handling arrays, and expressive syntax.
Sudoku was always a meditative thing for me. It’s impossible not to win so long as you pay attention. Optimizing solutions seems contrary to the point to me.
Meta: No need to DV a comment you don't like for no reason. Engage instead. Why not have a chat?
While I myself found an opportunity to reply to the GP and didn't down vote them, their comment only engaged with the article in a shallow way and only then, seemingly, to just dismiss the concept of solver altogether.
It wasn't a offensive comment, but it didn't really contribute to the site in the way many people digging into deep technical walkthroughs like this expect to see.
Some downvotes weren't guaranteed, but they're not surprising and they're probably helping new readers stay engaged with more topical and technical alternatives.
It's not the end of the world to get a few downvotes, and it's almost never personal. It certainly isn't here.
Sudoku was always a meditative thing for me. It’s impossible not to win so long as you pay attention. Optimizing solutions seems contrary to the point to me.
Meta: No need to DV a comment you don't like for no reason. Engage instead. Why not have a chat?
I’ve often wondered about languages like APL/k, are the programmers actually able to think about problems more efficiently?
As a kdb+/Q programmer I would say it depends on the type of problem. For example, when working with arrays of data it certainly is easier to think and write “avg a+b” to add two arrays together and then take the average. In a non-array programming language you would probably first need to do some bounds checking, then a big for loop, a temporary variable to hold the sum and the count as you loop over the two arrays,…
There are limits, of course, and it’s not without downsides. Still, if I have to code in something all day, I’d like that “something” be as expressive as possible.
> Advocates of the language emphasize its speed, facility in handling arrays, and expressive syntax. Indeed. https://en.m.wikipedia.org/wiki/K_(programming_language)