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.
"one data structure" doesn not have to mean "all data it one instance". Each of 100 functions could take a slice of data, or use a separate datastore which has the same structure. Separate instances of one structure can be passed by reference or value, and the receiver, because all 100 functions use the same data structure, understands what to do with what it received.
In languages without generics, like C, people tend to build a custom list type that only holds their particular type. This leads to a proliferation of list types each with sparse feature support.
It is better to have one collection type and use it everywhere directly.
Some Java developers had a tendency to encapsulate collections in <Type>Manager classes that grant limited operations/access to the list type. In practice this doesn't really buy you anything and you could have had a regular List<Type> instead.
The scope of where that data structure or functions are available is a different concern though, "100 functions + 1 data structure" doesn't require globals or private, it's a separate thing.
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.
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.
Seems like one is backpedaling because one was just talking about one's separation of one's concerns and now one is defending one's separation of concerns with respect to one's global data structure.
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.
You keep saying you believe it, but that is literally what a database is, game state manipulation, string manipulation, iterator algorithms, list comprehensions, range algorithms, image manipulations, etc. These are all instances where you use the same data structures over and over with as many algorithms and functions and you need.
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.
It’s about coupling and being able to maintain that in the long term.
What does that mean? This is all the kind of abstract programming advice that sounds nice until someone needs an example.
A narrow focus helps to test each individual unit in isolation from each other.
A function operating on a data structure is already a narrow focus.
It is true that a database appears to be a single datastructure with hundreds of methods from the users perspective
And also from a reality perspective because it's literally what a database is about.
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 don't know what point you're trying to make. Data structures should be tested? I don't think anyone is saying they shouldn't.
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.
To make such testing strategy to work data structures need to be small.
Why would that be true?
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.
I don't think you are backing this up at all, you just keep saying it over and over. It's also not even about big data structures it's about having fewer data structures and using them over and over. You can see where this is effective even in javascript and lua with their tables that have hash maps and arrays.
Another perspective: we should install whole house surge protectors if we can afford them, not only for ourselves, but to help our neighbors - even if in reality the help is minimal and they need their own as well. In the best case scenario, if everybody in a neighborhood has them, each individual house will be more resistant to surges than if they were the only house with one (five houses with surge protectors nearby is a lot better than one) - everybody wins.
Why? If the voltage spikes on the grid (that's what I understand a power surge to mean), wouldn't even more of it end up in your house (that is: the grid voltage spike even higher) if the neighbors have equipment that doesn't let their devices consume some of that energy?
Edit: wait, maybe I figured it out: those devices must be consuming the excess rather than blocking it. Is that it?
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.
Yes, that puts it down perfectly. That’s why some don’t ever see the benefit of installing their surge protector whereas others install one way too small for their situation and find them useless anyway.
> Another reason ignoring the literature can be helpful is that sometimes a bunch of work tries to solve some problem, and so everyone assumes it must be hard---just because no one has solved it yet, even though no one has really tried a fundamentally different approach
How does one approach collaborators in this situation? Like, hey, I have this idea that solves the problem you have been trying to solve in a fundamentally different way that invalidates all the legacy approaches you have invested in, BTW. My emails that follow this spirit tend to get ghosted.
Sometimes you don't need a collaborator if you have the idea. If the other party is not at all working on the angle that you're interested in, it's probably not the correct collaboration to ask to.
Also, a collaborator is usually not a stranger over the internet, it's often someone who you know and you already worked with, so it is not that ackward to expose a new idea and propose to work together.
It takes time and social skills to make long lasting collaborations, the two parties must trust each other in order to collaborate. In this context, exchanging ideas is not really an issue.
I felt this was why math textbooks pose open problems without mentioning them as such. I feel Karatsuba for example was able to come up with his multiplication scheme because he wasn't aware a mathematician had written a false result proving impossibility of faster than quadratic time multiplication.
Or more concretely that famous story where a student had solved certain open problems in statistics thinking they were homework problems.
As long as someone else does the porting and maintains the compatability between both subecosystems of thoose who prefer using Jax and thoose who prefer depending on the NumPy. Also not having zero overhead structs that one can in an array handicaps types of performance codes one can write.
A significant obstacle to adoption is that cryptographic research aims for a perfect system that overshadows simpler, less private approaches. For instance, it does not seem that one should really need unlinkability across sessions. If that's the case, a simple range proof for a commitment encoding the birth year is sufficient to prove eligibility for age, where the commitment is static and signed by a trusted third party to actually encode the correct year.
I agree. I've been researching a lot of this tech lately as a part of a C2PA / content authenticity project and it's clear that the math are outrunning practicality in a lot of cases.
As it is we're seeing companies capture IDs and face scans and it's incredibly invasive relative to the need - "prove your birth year is in range". Getting hung up on unlinkable sessions is missing the forest for the trees.
At this point I think the challenge has less to do with the crypto primitives and more to do with building infrastructure that hides 100% of the complexity of identity validation from users. My state already has a gov't ID that can be added to an apple wallet. Extending that to support proofs about identity without requiring users to unmask huge amounts of personal information would be valuable in its own right.
> It took me days to get that build to work; doing this compilation once in CI so you don't have to do it on every machine is trickier than it sounds in Julia
You may be interested in looking into AppBundler. Apart from the full application packaging it also offers ability to make Julia image bundles. While offering sysimage compilation option it also enables to bundle an application via compiled pkgimages which requires less RAM and is much faster to compile.
Such tedious derivations used to be a work of poor PhD students who were instrumentalized for such tasks. I envy those who do PhDs in theoretical physics in the age of AI, people can learn so much about their field quicker via chat than reading obstructing papers.
In essence liquid democracy makes votes a transferable currency bringing it fairly close to what money already is. It would be really hard to prevent existence of an exchange rate between money and vote transfer making that a capitalist dream (until markets themselves gets monopolized).
reply