111–120 of 210 posts
Earlier quoted context omitted.
Legitimately curious how APL programmers think about maintainability and readability. Is code just thoroughly commented or otherwise documented?
I suspect that if you're fluent in the language, understanding an expression written in it comes just as easily and quickly as reading a sentence in a book does to me.
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.
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.
[flagged]
Gemini also identifies it as J and this is the output for comparison: The programming language used in the code is *J* (pronounced "Jay"). It's a concise, array-oriented programming language known for its expressive syntax and powerful capabilities. Here's a breakdown of the code: *1. Verb Definition:* * `x(,/{@[x;y;]'(!10)^x |/p[;y]=p,:,3/:-3!p:!9 9}')/&~ x` defines a verb (a function in J terminology) and assigns i…
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…
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.
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…
Earlier quoted context omitted.
"Debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" — Kernighan, Brian. The Elements of Programming Style (2e) . McGraw-Hill, 1978.
By becoming even more clever: https://www.linusakesson.net/programming/kernighans-lever/in...
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.
Solvers are useful for confirming that a puzzle you've recieved or generated is solvable. The meditative process can really go sideways when there is no solution for you to stumble upon. Puzzles in commercial collections don't usually have that problem, but those from other sources sometimes do. Solvers also make for a nice craft exercise, as here. Simple but not trivial, you can approach them in a lot of different w…
I would argue that puzzles in commercial collections are more likely to have that problem than ones made freely available by hobbyists, as commercial enterprises inevitably cut corners on things like labour costs for an actual human setter.
I have seen dozens of commercial puzzle games and applications that do not make any attempt to verify the (auto-generated) puzzles as solvable, but I don't think I've ever had the same problem on a site like LMD.
Does anyone have any thoughts on what motivates people to play sudoku or write solvers for sudoku ? I have trouble finding motivation to solve artificial problems. That said I sink hundreds of hours into factorio.
For me personally, I have little motivation to do classical sudokus. They either have a not-so-elegant solve path (usually set by a computer) or are too difficult for me to solve. Variant sudokus on the other hand are a lot of fun. They often have very elegant solve paths and there are many neat tricks you can discover and reason about. Some fun ones, if you'd like to try: - https://logic-masters.de/Raetselportal/Rae…
The last puzzle has no fewer than 9 custom rules, in addition to the regular Sudoku rules, and then it also says “every clue is wrogn [sic]” implying there is some meta out-of-the-box thinking required to even understand what the rules are. That is more a riddle than a logic puzzle.
By contrast, the charm of classical Sudoku is that the rules are extremely simple and straightforward (fill the grid using digits 1 through 9, so that each digit occurs exactly once in each row, column, and 3x3 box) and any difficulty solving comes from the configuration of the grid.
AFAICT AI cannot replicate this, yet, will be interesting when that day comes.
Earlier quoted context omitted.
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…
"A one line solution takes up very little visual real estate. That matters a lot when you are working on some more complex problem." 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.