ztzuliios
95
35
ztzuliios has not written any posts yet.
ztzuliios has not written any posts yet.
Writing algorithms that are 50 lines of code seems like one definition of fluency, and one that is probably relevant in compilers/backend, but this also rings a little hollow to me, in terms of the pragmatics of real software engineering.
In my experience, most software engineering is using libraries, not language features; how would you describe fluency over libraries? Is "glue code" like command-line flags or CRUD web app routing subject to this? Should that code also "just flow"? In my experience truly powerful developers are able to do this, but even many Google L5s will just look up this code every time. Is that "fluent"? Is there a better concept to be applying here other than "fluency"?
My impression is that this is outside the scope of what you're describing, "implementing algorithms." This is an important part of software engineering, but I would say it's not entirely overlapping with what I would call "building <things/tools/products>". Would you agree? How would you relate these two aspects?
A talented developer can fluently translate a high level description of an algorithm into code in a language or ecosystem they are familiar with.
Could you say a little bit more about what "fluency" is in this context? It's doing all the work in this section but I'm not sure I understand what you're trying to communicate.
California is not capable of extracting tax revenue from companies like Google in any meaningful way, so we shouldn't expect them to be capable of taking stronger, less directly self-benefiting action. If they can't get Google to pay them, they can't get Google to stop AI.
What is California's great track record in this space? They have caused "May cause cancer in California" to be printed many times. We shouldn't expect them to save us.
In general, committing to any stance as a personal constant (making it a "part of your identity") is antithetical to truthseeking. It certainly imposes a constraint on truthseeking that makes the problem harder.
But, if you share that stance with someone else, you won't tend to see it. You'll just see the correctness of your own stance. Being able to correctly reason around this is a hard-mode problem.
While you can speak about specific spectra of stances (vegan-carnist, and others), in reality, there are multiple spectra in play at any given time (the one I see the most is liberal-radical but there are also others). This leads to truthseeking constraints or in a word... (read more)
I think the critical difference is that while marital rape might not be a legal crime, and might not be seen as wrong by people who aren't subjected to it, it's obviously wrong for the person suffering it, and obviously identifiable as coercive and abusive even to the perpetrator.
The spectrum then becomes (recognized as wrong x feels wrong) -> (not recognized as wrong -> feels wrong) -> (recognized as wrong x doesn't feel wrong) -> (not recognized as wrong x doesn't feel wrong).
I think people are only talking about quadrant 3 when saying "sexual abuse attitudes could be [bad]." And that is, like you point out, something that people experience differently, and... (read more)
The firearm use is a weird thing to point out. The usual explanation I see here is that social programming directed towards women drives them to value appearance more highly and use methods that are not as disfiguring, which means no firearms, but also no trains, bridges, high buildings, and so on.
Control is not a constant, and ability to effectively control depends on the social context. The state itself has acted as a counterweight to parental control for hundreds of years, and capital also acts as a counterweight -- if you don't want to live the way your parents want you to live or marry who they want you to marry, you can run away to the city and live free, which is easier if there are strong laws preventing you from being hunted down and honor-killed and jobs waiting for you in the urban center. Control was arguably at all-time lows in the late 60s and 70s. But the 80s are a... (read 555 more words →)
You're quite welcome.
I honestly have no idea. It might be in Expect Resistance somewhere, which if not directly about this topic, is generally about it.
I may have been (edit: was probably) thinking about The Promise of Defeat, by Moxie Marlinspike, anarchist cyrptographer sailor extraordinaire and the author of the Signal protocol (and the original Signal app, though he's no longer with the project).
I personally don't feel "fluent" programming this way, and maybe it is my own perfectionism, but this and the other replies, while certainly understandable and defensible, ring a little more hollow than I would like. I think going down below the level of "just know what APIs broadly exist" and actually being fluent at that lower level is usually necessary for the true 10-100x devs I've seen to work at that level. Usually this is achieved by building lots and lots of practical, deployable systems, but this just means it is implicitly taught through experience, and I wonder if there is a better way. Anyway, trying to figure out if it was this popular, but IMO flawed, type of fluency you were referring to was my original question, and I thank you for your answer.