codesections's recent activity

  1. Comment on Sigils followup: semantics and language design in ~comp

  3. Comment on Sigils are an underappreciated programming technology in ~comp

    codesections
    Link Parent
    Oops, you're entirely correct; thanks.

    Oops, you're entirely correct; thanks.

    1 vote

  4. Comment on Sigils are an underappreciated programming technology in ~comp

    codesections
    Link
    😀 I've read about it but never used it (or any concatenative programming language, for that matter, though I keep meaning to). I agree that this deserves consideration. For Algol-family languages,...

    Just wait till the author learns about Color Forth.

    😀 I've read about it but never used it (or any concatenative programming language, for that matter, though I keep meaning to).

    Also, a certain accessibility problem arises? with some of the symbols? What are they read as by screen readers?

    I agree that this deserves consideration. For Algol-family languages, with their abundance of brackets, semicolons, and other special characters, I don't believe that the addition of $, @, % and & sigils is likely to make an overwhelming difference – especially since Raku can be a bit less symbol heavy in other respects. But I don't face that accessibility challenge; I'd welcome correction from someone more knowledgeable. Of course, a programming language that pervasively use very few special characters would be in a different situation.

    How do you easily insert characters when coding, or does this mandate IDEs?

    That's obviously not an issue for $, @, %, and &. But Raku does have Unicode operators; the way we handle that is to have ASCII fallbacks that you can enter, though they may not be as readable (e.g. (elem) instead of ∈

    Also, this is a bit of a tangent from sigils, but on the general topic of accessibility, there are different accessibility problems with programming languages that only allow ASCII identifiers. A number of Raku users greatly appreciate being able to name variables in their native language.

    2 votes

  6. Comment on Unix philosophy without left-pad, Part 2: Minimizing dependencies with a utilities package in ~comp

  9. Comment on What’s the point of pointfree programming? in ~comp

    codesections
    Link Parent
    This is an entirely fair critique and raises several good points. In particular, I really like what you have to say about "aesthetic punctiliousness" (a nice phrase, by the way); I probably am too...

    This is an entirely fair critique and raises several good points. In particular, I really like what you have to say about "aesthetic punctiliousness" (a nice phrase, by the way); I probably am too drawn to code that's "pretty"/fits my aesthetic sensibilities. I try (perhaps unsuccessfully?) to prevent this from interfering with clarity.

    A couple more specific replies:

    [T]o the reader who is illiterate in Raku, [the rewritten program] is absolutely line noise.... The main issue I have with the point free style of the rewritten version is that ... modifying or refactoring the point free version would be so much more difficult than the 101 version. ... But for any code that is going to be read (esp. by multiple different human readers), I think avoiding line noise is a much higher priority than aiming for any sort of aesthetic punctiliousness.

    I think the concern about readability and density of language-specific idioms is a major reason why languages like Raku are avoided for larger programs that are intended to be used, reused, and extended/modified.

    If I'm understanding you correctly, you believe that a program should not only be clear to someone well versed in a particular language but should also be clear to someone who is new to the language/unfamiliar with the language specific idioms. Is that correct?

    That view is extremely widespread -- and I agree that it is often correct. In particular, that seems to be correct in a large team/high turnover/corporate environment: if you have a lot of different people joining a team and many/all of them aren't experts in the particular language, then readability in that sense is extremely important. (In my view, it's not at all a coincidence that the high turnover environment I described is basically a description of Google, and golang is one of the most readable languages in this sense.)

    In my opinion, however, there's another way to program -- a way that isn't as good a fit for the sort of programming done in large organizations, and thus isn't as well served by mainstream languages funded by those organizations. When writing code using a low-turnover methodology, clarity of the code is still paramount, but it's clarity to someone steeped in the idioms of the language, not clarity to a newcomer. (Ok, "steeped in the idioms of the language" sounds way more pretentious than I wanted; all I really mean is "someone who has programmed the language 6+ months".) And that's the sort of clarity I'm aiming for.

    I've written about this at more length previously.

    what if I wanted to modify each version of this program to change the order that results are printed so that the players with the most wins are at the bottom rather than top of the list? Scanning the program to find the part that is relevant is so much easier because there is a very obvious line where the sort order is determined:

    my @sorted = @names.sort({ %sets{$_} }).sort({ %matches{$_} }).reverse;

    Whereas, in the point free style, we would want to remove this line:

    ==> reverse()

    But, we’d basically have to read and grok the entire pipeline to establish the context in order to interpret that line.

    I don't think that's entirely fair. The way I'd put it is that instead of changing

     my @sorted = @names.sort({ %sets{$_} }).sort({ %matches{$_} }).reverse;

    you'd change

      ==> sort({.<matches>, .<sets>, .<name>})
  ==> reverse()

    (Yes, this concept is formatted as one line in the original and two in the revision. But it could easily have been one in the revised version if I hadn't been optimizing for narrow screens. And, in any event, it's one logical unit regardless of the linebreak.)

    IMO, ==> sort(...) is just as clear a signpost for "this is the code that does the sorting" as my @sorted = ... -- maybe even a bit easier to find when skimming the code.

    (By the way, .<matches>, .<sets>, and .<name> aren't named captures; they're the keys in each of the hashes in the array we're sorting. I agree 100% that giving those keys names like x, y, and z would make the code much less readable.)

    3 votes

  10. Comment on What’s the point of pointfree programming? in ~comp

    codesections
    Link Parent
    I both agree and disagree with you here. On one hand, I agree that Although I didn't make this point explicitly in the post, that's part of what I was getting at when thinking about "names as...

    I both agree and disagree with you here. On one hand, I agree that

    It's often a good idea to use local variables to name intermediate results, and perhaps write out their types explicitly if it helps readability.

    Although I didn't make this point explicitly in the post, that's part of what I was getting at when thinking about "names as emphasis". If everything has a name, then naming an intermediate result doesn't call any attention to it. But when just a few things have a name, adding an intermediate named variable can offer a nice pause point for the reader, and emphasize that the data is now in a meaningful state for them to consider.

    When working on the shell you often build them up interactively, so you see the output of each stage in pipeline before adding another stage to the end.… But a code reviewer can't see that when they are reading a pipeline expression in checked-in source code.

    I'd hope that they can see that it's a pipeline based on the syntax/formatting of the code and can inspect the output at various points through the pipeline (either by running the program or via tests). With a shell pipeline, that might involve the tee command; with Raku ==> chains, it would probably involve adding ==> { .say; $_ }() (which prints its input and then passes it on unmodified).

    5 votes

  11. Comment on What’s the point of pointfree programming? in ~comp

    codesections
    Link
    I find pointfree programming (also called "tacit programming") really powerful, but most/all of the descriptions I've found are way more abstract than I'd prefer. This is my attempt to talk...

    I find pointfree programming (also called "tacit programming") really powerful, but most/all of the descriptions I've found are way more abstract than I'd prefer. This is my attempt to talk through the advantages in the context of a real-world example.

    2 votes

  13. Comment on Why Raku is the ideal language for Advent of Code in ~comp

    codesections
    (edited )
    Link
    This post is day 1 of the 2020 Raku Advent Calendar, so there will be another 24 daily posts on Raku-related topics between now and Christmas. The article links to the Advent of Raku 2020, which...

    This post is day 1 of the 2020 Raku Advent Calendar, so there will be another 24 daily posts on Raku-related topics between now and Christmas.

    The article links to the Advent of Raku 2020, which is collecting Raku solutions to Advent of Code; so far, the solutions have already presented multiple different approaches – just as you might expect from Raku!

    3 votes

  16. Comment on Using Vim to take time-stamped notes in ~comp

    codesections
    Link Parent
    Thanks—I noticed the copy-paste error just too late to correct it myself!

    Thanks—I noticed the copy-paste error just too late to correct it myself!

    1 vote

  18. Comment on Share Your Mastodon IDs! in ~talk

    codesections
    Link
    I'm pretty active on mastodon (even though I mostly just lurk here on tildes). I'm @codesections@fosstodon.org over there, and toot mainly about tech/programming/foss (I'm learning rust right now,...

    I'm pretty active on mastodon (even though I mostly just lurk here on tildes). I'm @codesections@fosstodon.org over there, and toot mainly about tech/programming/foss (I'm learning rust right now, so a lot of my recent toots have been about how fun that's been).

    Also, if you're looking to join mastodon and are at all interested in tech, I really recommend fosstodon.org. We've got a pretty good thing going there—with a community that's pretty similar to what tildes is going for.

    3 votes

  19. Comment on How to send keybase chats from inside Vim in ~comp