Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Arthur Whitney's one liner sudoku solver (2011)

dfns.dyalog.com

Post reply on HN
Print view View original

191–200 of 210 posts

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

#191

Post by vrighter »

Etherlord87 wrote: post #115
xelxebar wrote: post #112

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…

Why not create a programming language, that uses all possible unicode codepoints to further decrease the number of characters used? That would be so much more readable!

How about having a "binary operator" codepoint, that is then specialized by a following combining character codepoint. That way it's also intrinsically obvious that the thing is a binary operator at first glance. Even more expressiveness!

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

#192

Post by nosianu »

dotancohen wrote: post #124
nosianu wrote: post #86

Earlier quoted context omitted.

This view is too static. That is not possible, because the environment can (and at some point always will) change which wasn't planned for due to a lack of working crystal balls. Data, user behavior, the network, the system(s) the software runs on can all change over time. Also, it is way too expensive to try to cover every single conceivable possibility, so we deliberately leave holes. For non-trivial things we ofte…

I believe that you are addressing maintainability, not debugging.

In your book, debugging problems is not part of maintenance?

What even is the difference, apart from trying to start a discussion about definitions (I'll let somebody else comment on that terribel habit: https://www.lesswrong.com/posts/7X2j8HAkWdmMoS8PE/disputing-...).

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

#193

Post by dotancohen »

nosianu wrote: post #192
dotancohen wrote: post #124

Earlier quoted context omitted.

I believe that you are addressing maintainability, not debugging.

In your book, debugging problems is not part of maintenance? What even is the difference, apart from trying to start a discussion about definitions (I'll let somebody else comment on that terribel habit: https://www.lesswrong.com/posts/7X2j8HAkWdmMoS8PE/disputing-... ).

Debugging problems is part of maintenance, but a small part. Extensibility is probably a much larger part, and what I think of first when someone says "maintenance".

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

#194

Post by rak1507 »

sudosysgen wrote: post #188
rak1507 wrote: post #187

Earlier quoted context omitted.

There are semantic differences too with a lot of the primitives that are hard to replicate exactly in Julia or numpy. That's without mentioning the stuff like tables and IPC, which things like pandas/polars/etc don't really come close to in ergonomics, to me anyway.

Do you have examples of primitives that are hard to replicate? I can't think of many off the top of my head. > tables and IPC Sure, kdb doesn't really have an equal, though it is very niche. But for IPC I disagree. The facilities in k/q are neat and simple in terms of setup, but it doesn't have anything better than what you can do with cloudpickle, and the lack of custom types makes effective, larger-scale IPC diffic…

None of the primitives are necessarily too complicated, but off the top of my head things like /: \: (encode, decode), all the forms of @ \ / . etc, don't have directly equivalent numpy functions. Of course you could reimplement the entire language, but that's a bit too much work.

Tables aren't niche, they're very useful! I looked at cloudpickle, and it seems to only do serialisation, I assume you'd need something else to do IPC too? The benefit of k's IPC is it's pretty seamless.

I'm not sure what you mean by inefficient hacks, generally you wouldn't try to construct some complicated ADT in k anyway, and if you need to you can still directly pass a dictionary or list or whatever your underlying representation is.

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

#196

Post by dahart »

xelxebar wrote: post #189
dahart wrote: post #154

Earlier quoted context omitted.

Don’t get confused between using smaller keywords and actually understanding the problem at hand. Terse languages do absolutely nothing to prevent over-engineering. They might even contribute by giving a false sense of simplicity and a tendency to prevent certain kinds of code reuse. To prevent over-engineering on large projects, you don’t need a terse language at all, you need the right mentality, the right manageme…

> Don’t get confused between using smaller keywords and actually understanding the problem at hand. Absolutely. I'm not arguing for maximal terseness and spent a lot of words attempting to say otherwise. (IMHO, we're both reflexively reacting to our parent comments a bit). What I am wanting to point out is that form affects function and how we think about and use our languages. This in turn shapes our ecosystems and…

I don’t know what you mean, and currently do not agree with the idea of parse tree size being a bad mentality or making it harder to grow, and I don’t feel like you’ve provided any objective evidence to back up that claim. Parse tree size seems like a better metric than terseness, for the reasons I and others have already mentioned, despite the fact that sometimes tight small code has some advantages that might be invisible if your only metric is AST size. (Neither parent nor I made such a claim, but your argument depends on that assumption.) K specifically is unreadable by most people, and somehow examples never seem to come with comments or error handling. Is it the best poster child for programming progress as a whole? I have my doubts, even though it might be very useful for some people in some situations.

I would be willing to bet that Excel spreadsheets are running more of our economy than K code, likely by orders of magnitude. I’d also be willing to bet that COBOL exceeds K use by similar multiples. Business/economic use doesn’t seem like a very good metric for what you’re talking about.

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

#197

Post by xelxebar »

dahart wrote: post #196
xelxebar wrote: post #189

Earlier quoted context omitted.

> Don’t get confused between using smaller keywords and actually understanding the problem at hand. Absolutely. I'm not arguing for maximal terseness and spent a lot of words attempting to say otherwise. (IMHO, we're both reflexively reacting to our parent comments a bit). What I am wanting to point out is that form affects function and how we think about and use our languages. This in turn shapes our ecosystems and…

I don’t know what you mean, and currently do not agree with the idea of parse tree size being a bad mentality or making it harder to grow, and I don’t feel like you’ve provided any objective evidence to back up that claim. Parse tree size seems like a better metric than terseness, for the reasons I and others have already mentioned, despite the fact that sometimes tight small code has some advantages that might be in…

The original post I replied to made an explicit claim with zero evidentiary support, so your demands for rigor are a bit lopsided. But more to the point, I'm really not saying anything about which metric is better or whatnot. What does it even mean to be a "better metric" when we have no consensus on what criteria we're using for comparison?

In effect, replies here effect to provide some criteria, but each is slightly different and somewhat begs the question, since said criteria can be easily chosen to support whatever conclusion you want.

When the object level discussion (i.e. in this case, the comparison of code size metrics) is ill-defined, the only natural thing we can reach for are cached ideas, heuristics, memetic trends, etc. That is, the discussion essentially becomes an implicit sharing of which cultural ideas we consider salient and important.

That is why I keep going on about culture and values in my previous replies. I'm not saying anything about ASTs vs. token count or whatever. I'm trying to say, "Hey, fellow devs. You know all the obvious ways that K and APL violate our sense of what good and proper code should look like? You know how they feel wrong? Well, actual experience by APL and K devs provides us evidence that we're potentially wrong and should give these languages more open-minded attention."

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

#198

Post by BoiledCabbage »

mlochbaum wrote: post #157
upghost wrote: post #155

Earlier quoted context omitted.

God bless, my hat goes off to you sir. I have trouble wrapping my head around the concept of first class functions in ndarrays, let alone implementing it in hardcore APL. That has to be a feat on par with Hsu's Co-Dfns. Don't suppose you can point to any resources to help wrap your head around BQN, do you?

Well this is pretty much the goal of the BQN website so my best attempts are there. I might point to the quick start page https://mlochbaum.github.io/BQN/doc/quick.html as a way to feel more comfortable with the syntax right away. And the community page https://mlochbaum.github.io/BQN/community/index.html collects links by others; Sylvia's blog in particular focuses on the sorts of flat array techniques that are usef…

While I've seen BQN mentioned previously on pages that discuss APL, K & J I finally took a look at it.

I've got to say, it's a really impressive language. Very well thought through, it brings some nice ideas. And as someone still newer to the space, it seems to do a great job of eliminating some of the unnecessary complexity of other languages. The straightforward approach on syntax / parsing is really fresh air.

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

#199

Post by dahart »

xelxebar wrote: post #197
dahart wrote: post #196

Earlier quoted context omitted.

I don’t know what you mean, and currently do not agree with the idea of parse tree size being a bad mentality or making it harder to grow, and I don’t feel like you’ve provided any objective evidence to back up that claim. Parse tree size seems like a better metric than terseness, for the reasons I and others have already mentioned, despite the fact that sometimes tight small code has some advantages that might be in…

The original post I replied to made an explicit claim with zero evidentiary support, so your demands for rigor are a bit lopsided. But more to the point, I'm really not saying anything about which metric is better or whatnot. What does it even mean to be a "better metric" when we have no consensus on what criteria we're using for comparison? In effect, replies here effect to provide some criteria, but each is slightl…

All programmers think they have culture and values. Getting them to agree on what those are and to prioritize them the same is the hard part. Having an open mind is great, and if you’d said that from the start I totally would have agreed, but you didn’t, you dismissed the GP’s comment with relatively strong language as being very wrong headed on behalf of the entire community, and doubled down on that stance in your followup comment, without acknowledging (or maybe without even realizing) that the suggestion might ultimately align with your message, that you might be picking a fight with someone who agrees with you. I don’t feel like the top comment required any evidence, partly because the claim is nearly tautological and quite easy to agree with, and partly because it wasn’t shitting on someone specific or being mean. You made a much bolder and more antagonistic claim and called their message a “scourge” and framed your point of view about over-engineering in opposition to their comment (which seems like straw man and very presumptuous), so yes I think your argument does require some evidence if you’re going to do that.

There’s a famous couple of comments by @arcfide defending the extremely terse K/APL style of coding, and it really makes a strong case. From what I can tell, this might be what you’re trying to say. I would just say to take note that he does not try to make the poster of the comment he replied to feel wrong headed, he focuses on the positives of his own approach, and he does not project his style on everyone else or make any claims that everyone should use it, he focuses on why it works for him. https://news.ycombinator.com/item?id=13571159

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

#200

Post by xelxebar »

dahart wrote: post #199
xelxebar wrote: post #197

Earlier quoted context omitted.

The original post I replied to made an explicit claim with zero evidentiary support, so your demands for rigor are a bit lopsided. But more to the point, I'm really not saying anything about which metric is better or whatnot. What does it even mean to be a "better metric" when we have no consensus on what criteria we're using for comparison? In effect, replies here effect to provide some criteria, but each is slightl…

All programmers think they have culture and values. Getting them to agree on what those are and to prioritize them the same is the hard part. Having an open mind is great, and if you’d said that from the start I totally would have agreed, but you didn’t, you dismissed the GP’s comment with relatively strong language as being very wrong headed on behalf of the entire community, and doubled down on that stance in your…

First off, thanks for continuing this exchange with me. Text communication between strangers is fraught with miscommunication perils left and right, so hanging in there is a really nice gesture. Cheers.

It's so weird, though. Everything disagreeable you point out with my comments, I kind of feel like is true of GP's comment. It casually dismisses the content of OP, injecting a strawman about a "metrics". Wore still, it just touts normative and relatively mainstream opinions about better vs. worse thing, without even offering up a hint as to what these supposed metrics are supposed to be measuring.

That's a dick move, IMHO, and a common one at that in these array language posts. I think we as a community do ourselves a disservice by allowing ourselves to propagate such echo chambers.

Which is all a pretty different message than @arcfide (eloquently) attempts.

Please note that nowhere do I attack GP or GP's comment specifically. If you're inclined to reread my comments, please note that I really do try hard to delineate ideas and cultural trends as the target. Heck, I even own up to being part of those trends and culture. Where you have thought I say "you", try rereading it as "we".

Anyway, cheers!

Post reply on HN