bulatb

Theoretical computer science can inform the use and design of practical tools that apply it, same as any other field. Theory is for asking questions and looking for answers. Application is for understanding real-world implications of the answers. Practice is for putting them to work.

The issue in the US education system is that we have one degree we call "computer science" which teaches all three of those pieces, each of which insists it's the real piece, and the students, faculty, administration, and employers all have very different expectations about what it means to have the degree.

You don't lose a single point for using tools that fit your needs, no matter how much any gatekeeper says different.

The "accounting" features in the source code may be finished and bug-free, but if the outside world has changed and now the user can't install the software, or it won't run on their system, or it's not compatible with other current software, then the software system doesn't grant the capability "accounting," even though the features are "finished."

Nothing with a boundary is ever finished. Boundaries just keep the outside world from coming in too fast to handle. If you don't maintain them then eventually the system will be overwhelmed and fail, a little at a time, or all at once.

If you're trying to explain how they can do it with the least amount of extra work, to minimize the impact of the extra expectation, please consider that not everyone has hobby projects. Even fewer people's hobby projects are presentable, and even fewer still can trust the other person not to draw some wild conclusion based on anything that might be in there.

I think everyone is clear on how the situation works, but not everyone is happy with it working that way.

> For the same reason artists do

They're asking more how it would happen, less for what purpose.

Artists automatically accumulate portfolios by doing work that gets displayed in public. Programmers who work on closed-source programs don't—unless they supplement their work-for-pay in ways that artists aren't expected to. The artist's history of work itself is how they get more work; the programmer's isn't.

You can make an engine as effective as the laws of physics let you, but you can't solve the limits of thermodynamics. You can only do your best within them. Same with this, for maybe the same reason.

When it gets a little closer, you can tell at least which half it's on, the left or the right. Now your estimate is either 0% or 50%.

Closer still and you tell which lane it's in, so now you're sure.

When someone says that X should be a right, is making it a right the ultimate goal? (What specifically does "should be a right" even mean? What do they think rights are? What do I?) Usually there's something else that making X a right implies, a goal for which the right is just an instrument. If making X a right results in Y, and Y is good, and that's why X should be a right, then why not argue directly for Y?

Otherwise you make a purely moral argument that only works on people who already share your values. What if they don't? That happens all the time with moral framings. One side doesn't understand the other doesn't care about their values and repeating or restating them in different ways won't change that.

Calling X a right is a position statement, not an argument. If you want to use it as a premise in an argument that "X is a right, therefore Y," you have to make a separate argument that X is actually a right. You can't just assert it.

Borrowing the moral weight of humans rights most people recognize, attaching it to an asserted right most people don't, and using that to argue for an outcome based on their support for "human rights" is turning human rights into a stick to hit them with. The more it's used, the more they learn to roll their eyes at arguments invoking "human rights." What happens when they start to roll their eyes at human rights?

It lets you say "I really, really think that X is good" but act as if you're just reporting "Everyone agrees with me that we should do whatever 'X is good' implies." It muddles the meaning of rights, tarnishes the concept by equating the support for rights in general with a specific, controversial position many people will reject, and all to make an argument that won't stand up to scrutiny and makes your audience feel cheated.

It's confusing even trying to describe what's normative and what's descriptive in the headline. Arguing descriptively that something is a right, which isn't widely thought to be a right, because it ought to be a right, because then your claim would be accepted, is too convoluted. It's making a descriptive claim about what normatives I do accept that's actually a normative claim about what normatives I ought to behave as if I accept. What?

If you want argue for specific action, just do it. Don't try to tell the audience what they believe.

The framing also means that people argue about rights instead of whatever the point was, like we're about to do here.

The query builder makes composable SQL syntax trees from raw text or Python objects. Executing those as queries gives you rows of tuples.

If you teach it the shapes of your data with the data mapper, you can query in terms of your tables (instead of ad-hoc column names) and get rows of populated custom objects.

On top of the mapper, the ORM defines your application-level data model, manages relationships and loading strategies, and powers up the query builder with the usual stuff like automatic joins (if you want them). You can still build composable queries, now against your application objects, but you can also work directly with the model like a standard ORM.

If you know you want the whole thing from the start, Declarative will let you do the mapping and the ORMing all at once by defining a class.

If I have to teach Hypothesis (by writing strategies) which pieces of these complex values matter and which combinations of those pieces are needed to cover the space, is it still worth it? Am I chopping up essential complexity and pushing it around, or am I gaining coverage? Brevity? Clarity? Correctness? A promotion?

Will it hit the database a hundred extra times to cover combinations that don't matter when I could have just enumerated ones that do?

Will the next maintainer know if tests aren't failing when they should because my primer to Hypothesis was subtly wrong?

https://en.wikipedia.org/wiki/Interstellar_travel#Wait_calcu...

He does address the stonework point in [1] at 6:36[^]—though he says it's not true. He also says at 3:43[*] that archaeologists can make mistakes and don't know everything.

Anyway, I'm not here shilling for the channel. I just found the background info relevant and useful.

[^] https://www.youtube.com/watch?v=1dHNq8SURTU&t=396s

[*] https://www.youtube.com/watch?v=1dHNq8SURTU&t=223s

He keeps it pretty civil, but he makes it clear when takes are bad or purposely misleading.

[0] https://www.youtube.com/@WorldofAntiquity

[1] https://www.youtube.com/watch?v=1dHNq8SURTU

[2] https://www.youtube.com/watch?v=R9PpokN1b58

[3] https://www.youtube.com/watch?v=BqhMGVLUSB0

[4] https://www.youtube.com/playlist?list=PLjhctHjnIbUgvin0ZlrsH...

Instead of showing you a graph and letting you change it.

It's mainly used by people who would say they're writing software, not manipulating graphs.

It also doesn't tell you this is happening, so people coming from another VCS don't even know there's this whole other part they should know. They memorize commands that seem to work, it goes ok, and then one day they ruin everything. Silly, that command means something different in the context you had no idea you were in. Duh.

Their experience with Git is that it's hard to make it work and then it randomly blows up. It's not because they're stupid or lazy. They're normal people dealing with a system that from their perspective is almost cartoonishly hostile.

They might wonder why they need to care about some underlying data model just to save their work instead of what they're doing now. If you have an answer that will make them want to switch, I suggest you spend a good while showing them pictures of history trees and ways you can change them. Name things slowly: this node is a "commit," this state change is a "reset," this transformation is a "rebase." If you have a workflow on top, draw more pictures of its states and changes using those terms. Then (re)introduce Git, a tool that does what you've shown them. Then set them up with a client where they have that flow with those terms and a graph they can look at, if not manipulate directly.

For anyone interested, a good search term is "anchoring" or "anchoring effect."

Improving either is an uphill battle when decision makers don't value the work, at best, or at worst are committed to resistance. And you don't even get paid.

Group A makes a bold claim. Group B thinks it over, finds issues, and comes back to A with objections they need to address for B to agree.

A does not address them to B's satisfaction, or maybe just ignores them, and repeats the original claim. B objects again. A repeats the claim or adds new claims B also objects to.

After a few rounds of this, B becomes exasperated and stops giving a compete rebuttal. The longer it goes on, the shorter and more flippant B's responses get.

At some point B decides that A is acting in bad faith. Since their objections haven't been addressed, B starts to combat the claim. They reject it out of hand with no apparent effort to consider it, make aggressive counterclaims, and openly question A's motives.

New members of A, who may have never made the claim before or heard the objections, see B's immediate hostility and think they never gave the claim a chance. Some elements of A encourage this misunderstanding and make new claims that B is biased.

B sees this as further evidence of A's bad faith and starts to openly attack the group, not just their claims. A continues to say B is hostile and unfair, and also keeps making the claim.

Eventually it's just a giant mess of different subgroups at different points in this cycle and no more discussion can happen.

And the mess is hugely magnified if A or B or both are really full of bad-faith actors.

For many achievements, most credit belongs to the role, not the person. In other words, the counterfactual of "if we didn't all agree that somebody will do this" would better prevent the achievement than "if one specific person didn't have their talent." We have phrases like "the time is ripe" because we know this. When conditions are in place, things happen.

The person in the role is who society has given the permission and the means to do the thing, whose doing of the thing is accepted and even expected, so it's mostly unremarkable when that specific person is the one who does it. That's who we supported in getting it done.

No one is surprised when every major fire was put out by firefighters, every touchdown pass was thrown by the quarterback, or every US law was passed by Congress and signed by the President.

Maybe Alice is uniquely qualified to be the president, and President Bob is a stooge. He's still the one to sign the law, though, and the law still gets signed. No amount of merit Alice has can change this. Society has still arranged itself to have a person in this role and Bob is just the person.

The arrangement (and the unavoidable path-dependence of history) is what magnifies the tiny contribution of the individual's abilities and makes them seem so necessary to the outcome. Given the prerequisites we've hidden in the role are met, the individual is all that's left.

Newton was a genius who invented calculus—but so did Leibniz. Einstein was a genius who invented relativity, but arguably so did others whose work we lump in with his; it makes a better story. They all had social institutions to support them achieving whatever they could. Their ability to get it done provided that support was clearly not unique.

It's more important that the roles to do the work have people in them, the conditions are in place for someone to do it, than exactly who is in which role.

Which I guess just brings us back to the top of the question. My bad.

You may be better off not knowing anything and knowing that you don't.

Edit: Not to say it's good not to know things in general. Just that there's some minimum you need to know for it to practically help you, and sometimes it's a lot.