JanisErdmanis

Is the Julia part here compiled via JuliaC and if not what would it take to do so?

Cool, can’t wait to try that out in a stable release.

What is this magic, how does it differ from PkgImages Julia already has?

I like the idea behind Flatpak and the ability to sandbox applications. What I don't understand is why they chose to lock the build process so tightly to Linux.

I'm currently on macOS, and while I can cross-compile applications, I can't actually bundle them as Flatpaks. For that, I need `flatpak-builder`, which is so deeply coupled to Linux itself that I don't think it can realistically run on other platforms.

Snaps have a similar issue with `snapcraft`. However, you can still build a snap manually with `mksquashfs`, whereas I haven't found an equivalent low-level option for Flatpak. I may be missing something, though, and I'm still looking.

The remaining oil companies will profit tremendously from the high oil prices. I am sure they will have no problem allocating some of those extra profits to sabotage attempts to consider any alternative energy sources.

This is really funny ;D Gives Tetris vibes and is executed beautifully.

To put it simply if you have a function f(ctx) = ctx.a + ctx.b it is hard to see what are the arguments producing the output. Which are the elements in the datastructure you need to vary in order to have exhaustive tests. Whereas if one refactors it as f(ctx) = g(ctx.a, ctx.b) you only need to test function g with respect to (a, b) whereas forwarding of methods can be simply covered in integration tests without any care whether function g is implemented correctly.

To make such testing strategy to work data structures need to be small. It is better to have multiple small data structures rather than one big universal one where methods are defined at the ctx level making exhaustive tests difficult.

Perhaps, I haven’t been clear. I agree with Pike’s advice strongly. What I am trying to say here is that the Perl’s rule 9 is diametrically opposite of what Pike says.

It’s about coupling and being able to maintain that in the long term. A narrow focus helps to test each individual unit in isolation from each other. It is true that a database appears to be a single datastructure with hundreds of methods from the users perspective and that is fine, because someone else engineered and tested it for you. However if you were to look into how a database is implemented you would get to see the composition of data structures, like btrees that are tested in isolation.

I still firmly believe that one ctx object and hundred functions/methods is as bad as programming with plain variables defined in the global scope. If the ctx is composed from smaller data structures with whom the functions are defined, then all is good. This is the opposite of the rule.

Separation of concerns is still a valid paradigm with a single global datastructure like GUI, Microservice, Database and etc. In such situation one can still seperate concerns via composing the global datastructure from a smaller units and define methods with respect to thoose smaller units. In that way one does not need to wonder whether there are some unattended side effects when calling a function that mutates the state.

One can always look as global variables equivalent to a context object that’s is passed in every function. It’s just a syntactic difference whether one constructs such data structure or uses it implicitly via globals.

What I am getting at is that when one has such gigantic data structure there is no separation of concerns.

With 100 functions and one datastructure it is almost as programming with a global variables where new instance is equivalent to a new process. Doesn’t seem like a good rule to follow.

Yes, energy dissipates. Although one still needs to look out for the distance from the neighbours as your ground can be different from your neighbours ground potential.