_randyr · HackerTrans

el año pasadodiscuss

Yes, but that's exactly why I mention this. By explicitly creating a class (that behaves the same as a lambda) the author might get better names in crash reports.

_randyr

el año pasadodiscuss

I'm not a C++ programmer, but I was under the impression that closures in c++ were just classes that overload the function call operator `operator()`. So each closure could also be implemented as a named class. Something like:

    class OnListItemSelected {
        OnListItemSelectedData data;

        void operator()(int selectedIndex) { ... }
    }

Perhaps I'm mistaken in what the author is trying to accomplish though?

_randyr

el año pasadodiscuss

> - when having non trivial ecosystem one cannot selectively deprecate and get errors, this has to be a human process (remember to replace…)

Apart from some statically typed languages (and even then), most languages have this. Very rarely in any ecosystem does a dependency upgrade not also require manual changing of stuff.

> - when doing umbrella tests on non compiled code seed influences order of compilation > - this order of compilation influences outcome and can lead to buggy code

I've never seen compilation produce odd artifacts, especially not as a result of compilation order. If the code has the proper compile-time deps, then the result seems stable.

> - documentation is hard to use - searching shows random versions and there isn’t even a link to „open newest”

Isn't this the fault of the search engine not having the latest version indexed? There's also a version selector on the top-left of hexdocs. Navigating to hexdocs.pm/<LIBRARY_NAME> also opens the latest version. This seems like a non-issue to me.

> - a lot of knowledge is implicit (try checking if you can dynamically add children to a Supervisor)

Already covered by another commenter, but also: https://hexdocs.pm/elixir/DynamicSupervisor.html I don't think the knowledge is necessarily implicit, it's just that learning Elixir deeply also means learning the BEAM/Erlang deeply, and there's a lot of Erlang docs.

> - sidebar with new ExDocs break for some reason so there is no navigation

Not a universal problem. Perhaps look into why it's broken on your device and report it as a bug?

> - there is no way to browse navigation outside this broken ExDocs which outputs only HTML and LSP

There's iex. For example `h String.codepoint`. Aside from that, I sometimes just open the relevant library in my deps/ directory and search there.

> - Squiggly arrow works weird (i.e. ~0.3 might catch 0.99)

I genuinely don't understand what you mean by this. There's no tilde operator and ~0.3 is invalid syntax. Can you give a code sample?

> - dependency compilation is not parallelized

I think this might be related to the common pattern of code you see in libraries:

    if Code.ensure_loaded?(SomeModuleFromAnotherLib) do
       # Some lib is loaded, add code to integrate with it.
    end

I think that could only be solved if that integration were extracted into another lib with properly setup deps, but due to how common this pattern is I don't think it's ever possible to switch to parallel dep compilation.

> - Dialyzer/dialyxyr typespecs are useless most of the time

A type system is being worked on, and each release lately has added more checks.

I agree that compilation is slow & editor integration is meh, but the rest I don't agree with.

_randyr

hace 2 añosdiscuss

I've also been thinking entirely too much about a good recipe structure.

For now I've ended up on ingredients being more or less recipes themselves, and recipes being recursive (as in, recipes use other recipes to create new recipes). Some recipes you can either buy & make yourself. For example, sweet soy sauce: easy enough to make but you could also just buy it in the store. The resulting structure is basically:

  Recipe:
    directions: rich text
    storageInstructions: rich text
    prepTime: minutes
    cookTime: minutes
    priceEstimateperServing: money
    ingredients: RecipeIngredient[]
    // other fields (e.g. tags, id, name, slug, purchaseableAt, nutrients, etc)

  RecipeIngredient:
    recipeId: reference to recipe
    ingredientId: reference to recipe as well
    // Allows grouping ingredients (e.g. "sauce", although the sauce could be a recipe of its own instead)
    group: string | null

There's some challenges with this though:

- If you have a shopping list, how do you determine in a complex recipe which "recipes" you'll purchase and which you'll make from scratch (UX issue)

- Some recipes may have alternatives instead (for example: if allergic to X, substitute with Y)

- It puts a lot of burden on the recipe writer.

- Some recipes don't scale linearly with just the ingredients, but perhaps also the cookware (baking a cake for example). Cooklang docs talk about this as well.

Scaling of recipes could be done with a measurement-aware type. Something similar to frinklang[0] for example.

[0]: https://frinklang.org/

comments