Egregoros

@p @j @Junes @SilverDeth @CrayonEater @ElDeadKennedy @ceo_of_monoeye_dating

That turns them into a reply, sure, but the problem is the same. Once there's a quote post with the same context, the thread usually goes two separate ways making it hard to read through, because there are now two diverging topics. The flatpak v2 systemd thread from a couple days ago is a good example of that I think. There's like three akkoma quote posts in the thread that all keep the same context, including a broken thread thanks to signed fetch.

https://hachyderm.io/users/jorge/statuses/116607961190448307 (https://fluffytail.org/notice/B6Z1k3LoKVhutjVdj6)

I hate Elixir so fucking much.

Yet you really like Ruby. The two aren't that dissimilar. Also there's a third Misskey representation :)

@phnt @CrayonEater @ElDeadKennedy @Junes @SilverDeth @ceo_of_monoeye_dating @j

> Once there's a quote post with the same context, the thread usually goes two separate ways

That happens with threads anyway. It's fine.

As things stand, this is, I believe, an exhaustive list of my options here:

1. Implement quote-posts and then kill myself.
2. Kill all quote-posts by rejecting them at the MRF level.
3. Turn quote-posts into replies.
4. Hack into all servers that implement quote-posting and remove the code that supports this terrible misfeature, thereby killing this problem at the source.

I chose option 3. I didn't like options 1 or 2.

> The flatpak v2 systemd thread from a couple days ago is a good example of that I think.

I haven't seen it.

> https://hachyderm.io/users/jorge/statuses/116607961190448307

hachi derm dot input/output (one of the Individual Eleven) refuses to allow FSE to fetch posts from them.

> There's like three akkoma quote posts in the thread that all keep the same context, including a broken thread thanks to signed fetch.

That's Akkoma's problem.

> Yet you really like Ruby. The two aren't that dissimilar.

Well, I haven't ever downloaded a release of Ruby and found a .DS_Store file in it. Programs I wrote for Ruby 1.6 still work. I have never had to update a separate VM in lockstep with updating Ruby.

"When you mix water and brandy, you ruin two good things." --a guy that thought brandy is good but in any case he is correct about the *principle*

Elixir is like if you took some of the parts of Ruby and shat them into Erlang and then in places where Ruby was nice, you decided to replace it with whatever Python does. As shitty as Elixir is, it's nowhere near as terrible as Phoenix, which attempts to replace sensible Erlang CSP style with shitty Rails shit that sucks and the unrepentant PHP dipshit DHH only made Rails because he couldn't figure out what to click on to see the Logo Turtle when he got a Macook ro. Every time I trace a bug to a five-clause `when` in the Pleroma source code, I get the urge to figure out who is in charge of Elixir and drive to his house.

@p @j @Junes @SilverDeth @CrayonEater @ElDeadKennedy @ceo_of_monoeye_dating

>I haven't seen it.

Nothing of value, like usual. Just a bunch of smug posts from corpo plants in the linux space.

>That's Akkoma's problem.

Including an FSE problem now. But no hard feeling of course, everybody has their own preferences. I'm not a fan of quote posts being used like on twitter either, the "lmao, look at this idiot" trope.

>five-clause `when` in the Pleroma source code, I get the urge to figure out who is in charge of Elixir and drive to his house.

That's one of the syntax features I quite like. It separates the success branch from the error handling below, so they don't mix. Apparently enough people like that feature that Erlang copied it: https://www.erlang.org/doc/system/expressions.html#maybe
fedi-p-old-man-yells-at-webdevs.png

@p @j @Junes @SilverDeth @CrayonEater @ElDeadKennedy @ceo_of_monoeye_dating
>Until you have to debug and it matters which of the clauses failed.

In reality you should wrap it all in a tuple for error handling which makes the issue clear, but it is true that it isn't the case in most code people write, including Pleroma

with {_, true} <- {:check_one, check(var)},
     {_, true} <- {:check_two, check2(var)} do
  process(var)
else
  {:check_one, e} -> {:error, :check_one, e}
  {:check_two, e} -> {:error, :check_two, e}
end

>rails

I think it is fair to say that Ruby is hot garbage. Especially if you need something that doesn't perform awful.

@lanodan @j @Junes @SilverDeth @p @ElDeadKennedy @ceo_of_monoeye_dating
>but it reminds me that I really dislike the lack of early return in Elixir

Yeah, that can be very unintuitive at first. Same with implicit return when you try to log a result of a call the function retuns:

def func(var) when is_integer(var) do
  var = var + 5
  ret = process_var(var)
  Logger.debug("#{__MODULE__} func/1 returning: #{inspect(ret)}")
  ret
end

It's very easy to return the Logger output and then wonder why it doesn't work, especially for someone new that writes something like this:

var =
  if asdf == true do
    var = process_var(var)
    Logger.debug("#{inspect(var)}")
  else
    nil

@phnt @CrayonEater @ElDeadKennedy @Junes @SilverDeth @ceo_of_monoeye_dating @j

> In reality you should

What people *should* do and what they did do are often different; what the language encourages, etc. But I didn't write this codebase. Here it is and I have to deal with it.

>> rails
> I think it is fair to say that Ruby

Ruby isn't Rails. Ruby is nice. Try using the language without touching Rails. It's enjoyable. You fire up irb, load up a JSON parser, walk down a data structure, toss a few transformations at it. It's nicer than ever touching jq.

> Especially if you need something that doesn't perform awful.

Player skill issue.

@phnt @lanodan @ElDeadKennedy @Junes @SilverDeth @ceo_of_monoeye_dating @j

void *do_something(thing **p)
{
if(!p) return nil;
/* We have just added an invariant. We can proceed down the line, gradually narrowing the number of cases we need to deal with instead of branching. You can sort of do this in Elixir but it requires you to name all of the intermediate steps. This makes control flow difficult to read. You look at a big Scheme codebase and they end up simulating this construct with call/cc or something. You can't do that in Elixir, though. */
...
return p;
}

@lanodan @ElDeadKennedy @Junes @SilverDeth @ceo_of_monoeye_dating @djsumdog @j @phnt I mean, not the postfixed condition but the structure.

def gcd x, y
if x < 0 || y < 0; raise ArgumentError, "gcd(#{x},#{y})"; end
if x == y; return x; end
if y == 0; return x; end
if y > x; return gcd(y, x); end
gcd(x-y, y)
end

It's that you can increase invariants as you progress down. You know x-y>=0 because x>y and both are positive by the time you get to the subtraction. You just eliminate case after case as you progress. You replicate that with single-return and you get nesting. (The example is deliberately contrived; it is just that it gives you easy list of conditions.)

@p @j @Junes @djsumdog @phnt @SilverDeth @ElDeadKennedy @ceo_of_monoeye_dating Yeah, I've been wanting to learn Forth beyond the very basics for a while but I guess I just love C too much whenever I deal with system-level stuff.

But well knowing myself it'll probably land into a case where C can be too costy like say writing a bootloader, or wanting an early/trusting-trust assembler/disassembler.
(I know you gave the assembler example for forth once, and seen it quite few times elsewhere as well)

@p @j @Junes @SilverDeth @lanodan @ElDeadKennedy @ceo_of_monoeye_dating
>We have just added an invariant. We can proceed down the line, gradually narrowing the number of cases we need to deal with instead of branching. You can sort of do this in Elixir but it requires you to name all of the intermediate steps.

You do this with a cond clause, no need to name anything. Same thing, slightly different syntax.

cond do
  is_nil(var) -> do_nil(var)
  is_binary(var) -> do_binary(var)
  var == 5 -> do_five(var)
  true -> do_default(var)
end

You don't have to call a function after the match either, you can do the processing right after the match. Put this at the bottom of a function and you have the exact same thing.

@phnt @ElDeadKennedy @Junes @SilverDeth @ceo_of_monoeye_dating @j @lanodan

> You do this with a cond clause, no need to name anything.

You can have giant `if`s but you shouldn't, but you named things in your example. The optimal way to do this, the way Elixir wants you to do it, is to factor it out and use a conditional and unless both clauses are trivial, you make another function; likely, you skip the conditional and you lean on pattern-matching. So you have named the branches `do_binary` and `do_asdf` but you actually do see a lot of things like that in the only Elixir codebase I'm familiar with, and once a dude has three levels of maybe_real_do_uncached_thing (or maybe_drop_authentication_if_oauth_check_ignored or fetch_and_contain_remote_object_from_id or whatever) like, not only is that kind of Railsy but the names are impossible to decipher: they are usually named to fit the conditional so the names make no sense outside the conditional and a lot of them are forced names for intermediate values polluting the module's namespace. It's possible to think this is a reasonable wart, I'm sure, but it's really ugly to me, and I get pretty irritated when the answer to "Why the fuck is this happening to my server?" is delayed because I'm sifting through that shit. (That is to say nothing of the finer points of the differences between `cond`, `when`, `where`, `if`, `case`, etc., and the fact that a nominally *functional* language should have sensible operator precedence.)

> You don't have to call a function after the match either, you can do the processing right after the match.

I'm not sure what you mean to convey. I do know how you do those things in this language; I just don't like that the flow of execution is on rails.

@p @j @Junes @SilverDeth @lanodan @ElDeadKennedy @ceo_of_monoeye_dating

>The optimal way to do this, the way Elixir wants you to do it, is to factor it out and use a conditional and unless both clauses are trivial, you make another function; likely, you skip the conditional and you lean on pattern-matching...

I think that's a fair replacement for early return. If you do it correctly the complexities get resolved elsewhere and all that is left is a descriptive function name and you shouldn't need to care about how it is done. It does have an OOP abstraction smell to it though. That's the point of the `maybe`s, sometimes coupled with the `do`s; do this for me if it should be done, ignore when it shouldn't, I don't care about the details. It tends to remove the 20+ line if/switch statements you get in something like C when you need to do this and avoids dealing with fallthroughs in switch-case. And removes some noise from the function making it more readable/understandable. Of course, there are times where the 20 line case/cond is also more appropriate in Elixir.

>So you have named the branches `do_binary` and `do_asdf` but you actually do see a lot of things like that in the only Elixir codebase I'm familiar with

Kinda, you don't have to do that when the handling is simple like extracting something from a map or a list in a few lines. Arguably if it is more than a couple (10-15+) lines, you should make a function for it anyway. The example I gave above isn't really ideal since I would try hard to not write it. It is terrible design to process multiple types of something in a single function. If it really needs to exist, multiple functions guarded with a when are slightly better at least in my mind.

>fetch_and_contain_remote_object_from_id

You would name that function the same in other languages, because it's basically an entrypoint that does it all, an internal pseudo API. Unless you wouldn't write it all and wrote the same handling multiple times which is worse. Or caught the libc string manipulation function naming disease and called it robjfc_id or whatever. Hello vsnprintf and suckless function names that mean almost nothing at a glance.

>It's possible to think this is a reasonable wart, I'm sure, but it's really ugly to me,

It's a different code style basically. Same endless arguments about different code styles being better than others apply here as well.

>I'm not sure what you mean to convey. I do know how you do those things in this language;

Just that you can also do this, nothing more:

# Bleh, multiple types.
cond do
  is_map(var) ->
    var["some_property"]

  is_list(var) ->
    var[:different_property]

  is_binary(var) ->
    var
end