d-harmonic minor; interval f,h,f+,h,f,h,h,f (sol,la,sib,dod,re,mi,fa)

need an index for delete although a deletion follows an expected order, would require some way to tell the DB to disallow reinserting keys for deleted rows for pending deletes

if it's new data (e.g., ga) they trust, otherwise (e.g., jira board digest) they will distrust

there are three broad type of code, producer, consumer (in duality), and glue code (oblivious); defining primitive types in either packages is annoying

little time to judge a #photo, photos without a clear subjet, lack of intentionality, border; follow the theme binary then jury appreciation

A number of structures exists: bookeeping, control, data. We typically have different ideas about performance/usability tradeoffs of these structures. Would be nice to be able to annotate structures to tell whether some substructure serves a domain need or is artificial.

As stated in the tar-pit paper: there's a combinatorial explosion due to the very nature of mutation, so it can become cumbersome to have a data-type that perfectly espouse the set of valid values. We can go further and say that due to the time there is not a single value but a fluid value where each observer contributes to the combinatorial explosion.

as project matures, even small fixes take more time because you need more preconditions to make some piece of code works (coupling creeps in)

There are really various types of prototypes: pareto-prototypes where you know where you're going (e.g., build a query-language) but aim to grow iteratively and exploration-prototypes where you don't know what you're doing.

balance between repeated code, golang-amounts of repetition means more to review, more to move, increased amounts of refactorings and branch conflicts

there's already some knowledge about boolean blindness in API-design, we should not miss the unit-blindness, when a 'delete operation' occurs for instance, you should return a `Tombstone =~ Unit`

could re-use the table model outside of postgrest-though

people like to dunk on Haskell lazy structures and often don't know what LazyIO is. still encapsulation with 'providers' that then fetch data when needed is akin to lazy IO, rather code should ask for the already-provided data to move fetching to common glue code only

as much as i think code formatter are an advanced in engineering, other tools are a bit lagging/not-ready or there's a mismatch. in particular code reviews and diff tools

when some sloppy code has caveats but it's fine in context, and you need to recreate or reuse the same or similar logic; it hurts when you read, it makes impossible to know whether the sloppiness is acceptable or WAI, and makes it harder to gauge re-use-and-fix or reinvent the wheel

many apis would be better if they were returning tabledump-likes with integrity references rather than json objects

I have some fair amount of null fatigue. When it's in your code you lose a couple of hours a week (still close to 5% of your work). When it's in public-APIs of large services I can't help but feel the scaling factor of these couple of hours across users of the API.

sometimes it feels like you need to add code to remove features, that is you build a feature by restricting a more general tool (e.g., middle-ware skipping logic)

in data-analytics there is a tension between being accurate with whatever data you have and being synthetic and helpful

when you return some code capable of reacting some event, vs when you call the handler code -- mix of dual concepts (e.g., SWR returns a mutate function onFooChanged that is employed as an onClick handler)

- a tool to help with API diffs - and a tool to help with templating live

CSS and layout are global-constraint problems, they do not compose well. hence components are somewhat doomed in complex environments unless the view aspects are constrained to what composes for real. current components merely combine

components dependencies are orthogonal to display nesting would be nice to instantiate components (with their sub components) but allow to nest views independently from the component hierarchy for instances a button inserted in a toolbar actually appears because it is in a component elsewhere in short, components exist in two realms: - hierarchical reasons to exists (a button is an active component because a particular pane is active) - visual embedding (a button is displayed within a particular location) what i want is to define a component with input/output/events/queries like in halogen and separately map that onto HTML+DOM-bindings-with-events

after around a year using it, I still sincerely think that Golang power/weight ratio is pretty bad and doesn't feel modern. Pro: it compiles fast Con: but while doing so it checks so little and provides no affordance Perf-bound, I'd go for Rust, else a member of the ML-family.

discussions on https://news.ycombinator.com/item?id=31310564 seem to tell that one should encode information in the hierarchy, seems like a failure to encode information in the page `meta` headers

good-fast-cheap triangle is a good example to discuss about pareto-optimality

Sometimes having a brutalist solution is good because you can use it all the time with little second thoughts. Our desire to do things right wants us to use parcimony and elegance. However being nit-picky, extra complications arise due to combinatorics. Imperfect on many aspects but no-brainer to use and understand (see: bell-curve meme).

About OOP hiding states. It's pretty common to bundle all dependencies in the object, say a Summarry object. Then there is no distinction between methods that make use of none, some, or all of these dependencies. Even when internally-occurring as private methods. Turns out it makes code-auditing and code-reviewing painful. As time passes, objects accrete more and more dependencies for single new methods. We should have more fine-grained