• 0 Posts
  • 58 Comments
Joined 1 year ago
cake
Cake day: June 13th, 2023

help-circle
  • So far, this isn’t much of anything.

    Telegram already closes public channels reported for copyright violations.

    Some excerpts from this post:

    Compared to other platforms, we do not see the seriousness of Telegram to cooperate.

    . . .

    In May 2023, progress appeared to be going in the wrong direction. Telegram was reportedly refusing to cooperate with the Ministry of Communications and Digital on the basis it did not wish to participate in any form of politically-related censorship.

    . . .

    With no obviously public comment from Telegram on the matter, it’s hard to say how the social platform views its end of what appears to be an informal agreement.

    Telegram will be acutely aware, however, that whatever it gives, others will demand too. That may ultimately limit Telegram’s response, whatever it may be, whenever it arrives – if it even arrives at all.











  • That’s true, but if the transformations have more than one argument, they go after the name

    Yup, I understand. That’s why I’ve not put them in the concatenative section.

    Also, there are more languages with this feature, for example D, VimScript or Koka.

    Thanks, maybe I’ll add them to the sidebar! I hadn’t heard of Koka.

    If you have a suggested heading/description to replace “partially concatenative” I’m interested. Function chaining? And I’m not sure but maybe execline is actually concatenative and needs to be moved out of that section.



  • I may be expressing it poorly and inaccurately, but what I mean is that in Nim you can re-order arguments and functions to start with some data followed by a series of transformations. The following two lines are equivalent:

    parse_int(read_line(stdin))
    stdin.read_line().parse_int()
    

    Roc offers a similar flow with their |> operator. Here’s a snippet from one of my Advent of Code 2022 solutions:

    partOne =
        "input.txt"
        |> getData
        |> Task.await \data ->
            data
            |> getRangePairs
            |> List.keepIf pairHasStrictSubset
            |> List.len
            |> Num.toStr
            |> Stdout.line
    



  • Approval voting simplifies things but also has limitations because it removes any weight/preference people may have.

    Yes, but nowhere near the problems of IRV. If those particular limitations bother you, as I said:

    If you want to take on a little complexity for some further improvement, use delegable yes/no voting.

    . . . don’t let the perfect be the enemy of the good.

    I see zero “good” in IRV, for all the reasons outlined in the rant. Its failures are absurd and beyond unacceptable given that there are strictly better and simpler alternatives. Don’t let something shiny and terrible stop you from using something actually quite good.