101–110 of 332 posts
Earlier quoted context omitted.
Yep. And if what you have is an Abelian Group, then you also get distributed computation as well (thanks to commutativity).
While true, that's too strict. An Abelian group (like any group) needs inverses. You get distributed computation if you've got an Abelian semigroup.
Earlier quoted context omitted.
Using array based data structures also get you more cache hits. For smaller data sets, this may well be faster than a fancy algorithm.
This is true only if you are iterating over the entire array often. If you only rarely need to access one data member the array will not be in cache and so you have less to load from memory. Depending on how your data is structured the array may or may not save time even in small sizes.
In long-lived systems (systems that run for many years) it's almost impossible to choose the "right data structures" for the ages. The sources and uses of your data will not last nearly as long as the data itself. What to do about this? Two things: STORE YOUR TIMESTAMPS IN UTC. NOT US Pacific or any other local timezone. If you start out with the wrong timezone you'll never be able to fix it. And generations of progr…
CPU's have a lot of logic for making in order data access very fast.
Earlier quoted context omitted.
You can distribute the computation on just a monoid as well but it needs more bookkeeping. In particular, your reduce function should know * lhs is before rhs * There is no data between lhs and rhs
One way of looking at it is that equipping our data with that bookkeeping gives us something that commutes.
At the moment of computation, you can build a new structure that commutes by enumerating the data. I guess it's true that you need a commuting intermediate data structure to be able to distribute.
> Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming. That one hits me in the feels because I think a lot of folks focus on algorithms (including myself), and code patterns, before their data and as a result a lot of things end up being harder than they need to be.…
It's worth noting the same holds true for UI: data dominates. Design your widgets, layout, and workflow around the data.
I couldn't agree more.
I think the current state of UI programming is like the pathological case to be honest. Too often folks are concerned with representing their database 1-to-1 in their UI instead of representing their view.
If anyone is suffering from brittle UI code, where somehow caching issues and stale data are affecting your application, this is very likely why. You have muddled your persistence and view concerns together and it's not manageable or pretty. What this means for folks using something like React- don't directly use your persistence models in your views, create "view models" which directly represent whatever the hell it is you're trying to display. Bind your data in your view models, and not your views, and then pass the view model in as props.
Earlier quoted context omitted.
> Bad programmers worry about the code And yet, I see a whole swath of the industry hyper-focused on various linters/styling/rules.
And that’s because it’s Bad Programmers who need help!
> Tony Hoare's famous maxim "Premature optimization is the root of all evil." Actually that was Donald Knuth - it's an urban legend that it's an urban legend that it was originally Knuth. Hoare was quoting Knuth, but Knuth forgot he said it, and re-mis-attributed the quote to Hoare.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."