Timeline
Post
Remote status
Context
11
are you sure that's how you escape?
@ceo_of_monoeye_dating @CrayonEater @ElDeadKennedy @Junes @SilverDeth @j I'm not in that thread. I'm just in the quote-post. Quote-posts suck in part because they fuck up threads.
quoteposting.png
quoteposting.png
@p @j @Junes @SilverDeth @CrayonEater @ElDeadKennedy @ceo_of_monoeye_dating
Quote-posts suck in part because they fuck up threads.
Quote posts keeping thread context suck even more, because the thread becomes unreadable with two or more of them.
@phnt @CrayonEater @ElDeadKennedy @Junes @SilverDeth @ceo_of_monoeye_dating @j
> Quote posts keeping thread context suck even more
https://git.freespeechextremist.com/gitweb/?p=fse;a=commitdiff;h=d53e03428ca83d75512f2caae8969b0e7e9d726f
> Quote posts keeping thread context suck even more
https://git.freespeechextremist.com/gitweb/?p=fse;a=commitdiff;h=d53e03428ca83d75512f2caae8969b0e7e9d726f
@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 Mac
ook 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.
> 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 Mac
ook 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
>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
@phnt @CrayonEater @ElDeadKennedy @Junes @SilverDeth @ceo_of_monoeye_dating @j
> That's one of the syntax features I quite like
Until you have to debug and it matters which of the clauses failed.
> Old man
I hated Rails when I was an age that people called me young and stupid and now I say Rails sucks and people say I am old. I hope that eventually people will engage with the things I say instead of guessing which reason *besides* the stated one is the reason I say the things I say.
> That's one of the syntax features I quite like
Until you have to debug and it matters which of the clauses failed.
> Old man
I hated Rails when I was an age that people called me young and stupid and now I say Rails sucks and people say I am old. I hope that eventually people will engage with the things I say instead of guessing which reason *besides* the stated one is the reason I say the things I say.
@p @j @Junes @phnt @SilverDeth @ElDeadKennedy @ceo_of_monoeye_dating when thing I don't might too much although I'm not a huge fan of function overloading, but it reminds me that I really dislike the lack of early return in Elixir, it makes for such horrible code you'd think if was made for forcing hadoken-indentation.
@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:
>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) doIt'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 = var + 5
ret = process_var(var)
Logger.debug("#{__MODULE__} func/1 returning: #{inspect(ret)}")
ret
end
var =
if asdf == true do
var = process_var(var)
Logger.debug("#{inspect(var)}")
else
nil
@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;
}
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;
}
@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.
>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 doYou 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.
is_nil(var) -> do_nil(var)
is_binary(var) -> do_binary(var)
var == 5 -> do_five(var)
true -> do_default(var)
end
Replies
2
@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.
> 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:
>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