You are viewing archived messages.
Go here to search the history.

Jasmine Otto 2024-09-16 23:02:56

I am now blogging about design engineering in organizations that deal with lots of domain knowledge(s). This post covers metrics that don't do what your manager thinks they do, and why interdisciplinary work has trouble finding a good home.

designengineers.substack.com/p/the-myopia-of-professionalism

Kartik Agaram 2024-09-17 01:25:24

I feel like I understand what you're saying for a second, but then I blink and it disappears.


I propose that experts supply and evaluate criticism, just as professionals supply and evaluate metrics.

Are professionals and experts different people here? Earlier in the article it seems like they're just synonyms.


The part that seemed most fertile was the 3 pictures of domains between the two halves.


I don't quite see how the two halves connect. The major connection I see is between translations between domains and boundary objects between teams. Is there more? Perhaps what's missing is an introduction or conclusion that lives outside the two halves. Or perhaps they should be two distinct posts?

Jasmine Otto 2024-09-17 01:46:07

Yes, that makes sense - thank you for unpacking the disconnect there.

I completely skipped over the definition of a domain (following David Ribes' workplace ethnographies). That would set up the second half as a payoff to the first half, because the boundary object solves the problem where the domains hate to explain themselves to each other (because switching languages is really slow and frustrating).

The role of the 'expert' is not grafted quite right into the world of the 'professional' from Stengers' essay. It should be 'public intellectuals', university-affiliated or otherwise.

I expand on the picture of domains at three 'zoom levels' in the BELIV paper! Which is in a dense academic style unfortunately.

Jasmine Otto 2024-09-17 01:51:41

I was between either covering explainability in terms of gesture next week, or the difference between an 'evaluation gap' and an 'execution gap' in debugging practices. But going straight through Ribes is a solid plan, considering I need to brush up on my CSCW.

Konrad Hinsen 2024-09-17 08:54:37

Like Kartik Agaram, I am a bit confused about the roles. I see the issues you raise every day in academia, between scientists from different backgrounds and also between researchers and management. But if academics are "experts", then we have no "professionals" in this situation. I see researchers taking both roles, though not on the same subject.

Jasmine Otto 2024-09-17 16:05:36

Hmm, the tricky thing with researchers is that everyone I've met in academia wears at least four different hats. Multiple inheritance, y'know? Perhaps a set of 'partial roles' e.g. domain practitioner / literature expert / institutional administrator is called for.

Absolutely, this means the incentive structures for each role are actually more complex than 'metrics vs. critique'. Otoh, incentives aren't necessarily blended between multiple roles, because people will take on jobs they weren't hired to do on paper. Therefore, within the context of how do I form a stable niche in my institution , it might actually become a simple taxonomy of roles again? Albeit, rather cynical.

Konrad Hinsen 2024-09-18 05:14:35

Four hats may be true. That's actually an aspect of academia that I like. It's a more diverse environment than the typical business with its more sharply defined roles. And it provides more individual freedom.

And yet, as I said, the core observation of your post applies to academia as well. Maybe the incentive structure matters less than we think? Or is more complex than often described?

Jasmine Otto 2024-09-18 15:55:40

Yes, absolutely. It needn't be a complex set of institutional incentives, even; but your response is not knowable to me, thus you can form a niche that I wouldn't be able to predict. See, if I ascribe someone a fixed utility function, then - first off, that says more about me than about them. But let's say the point of a given role is that I can predict that person's utility function, i.e. what kinds of resource and relationship I can offer in exchange for their labor.

Now if you've got four hats, then I don't know what your switching condition is. Maybe you want to work from home because of family commitments; or conversely, maybe those are pushing you to the office. And all that gives you freedom from the simplifying gaze of post-Fordism and (ugh) scientific management, in terms of being able to defy its expectations. (Not as in being able to make money outside of it.)

Now a really important corollary of the 'freedom of multiple hats' is the ability to switch between metrics, critique, and other evaluation strategies. That's going to make up the part of my tenure packet, or grant proposal, that I can actually design on the spot. It's critical that my strategy be legible to the manager, or the funding source, or whoever is evaluating that. And that's how I hit the impasse where some methods are respectable right now, and some other methods are actually productive for my questions.

Jasmine Otto 2024-09-18 15:59:50

Which is not to say that just browbeating the managers into respecting humanistic inquiry is a reasonable solution for getting grants. (Or conversely, to argue that research artifacts themselves act as repositories of knowledge.) But there's a version of our institutions that rewards broader knowledge than a manager 'really needs' to have, and is capable of addressing the long-running n-cultures problem .

Misha A 2024-09-17 10:36:32

What is "program"? essentially, conceptually.

Denny Vrandečić 2024-09-17 11:32:25

What is the ontology that you accept for answering the question?

It can go from "it is a sequence of instructions" to "it is the human-readable specification of an application that can be executed on a chip" to "it's a valid string according to the grammar of a specific programming language". Is a "program" the same as an "app" or the same as a "source code"? Without context, it is difficult to even start answering the question.

Shalabh 2024-09-17 17:24:56

from a system-centric pov, a program is just a message to a system that modifies the system's behavior. incidentally, data is the same.

Misha A 2024-09-17 18:01:30

Without context, it is difficult to even start answering the question.

fair.

I have a strong lasting feeling that most of daily programming routines I do as developer – are incidental complexity™.

So I am trying to figure out what is the essential complexity™ of programming.

Assuming mapping from program to how-to-run-it-on-hardware is factored out – what is left?

Can that execution mapping really be factored out?

Is there a language for "what is left"?

is it eg. Prolog? TLA+?

What should that language help with?

My take on it so far is "program is mapping from state to state". Which makes it a function?

Is "real" program different from a function only because it is also "mapped onto hardware"? Or is there something else missing?

If program is a function, then programming language is a tool for "convenient" description of state-to-state mapping?

Tom Larkworthy 2024-09-17 18:56:10

no the state-to-state thing is not important IMHO. IO i.e. stdin/stdout, thats the important bit. Moving state around a RAM chip is not useful, its only when the computer is between keyboard and monitor that it becomes useful and interesting. IO, the side-effects, is the point, to me anyway. So I do think the hardware mapping is the important bit.

When considering the internals, I think the state-to-state bit is useful when domain mapping, converting between domain representations and abstraction levels. Then thats when the computer becomes a tool for the mind (coz it unburdens you from doing domain mappings in your head)

Joshua Horowitz 2024-09-17 22:32:48

I’ll just drop in some commentary I made on another forum:

It’s sort of “folk wisdom” in some of my social circles that it is actually very hard to define programming, or to draw clean lines between programming and not-programming.

For example, “programming = writing textual code” breaks down because of visual programming languages, structured editors, etc. The broader “programming = manipulating symbolic representations roughly equivalent to textual code” breaks down because of Drawing Dynamic Visualizations / Wrangler / programming-by-demonstration.

So sometimes I go for ends rather than means, like “programming = authoring dynamic artifacts”. But lol what are dynamic artifacts? Oh, they’re “artifacts that respond differently to changing inputs / interactions / circumstances”, in contrast to “static artifacts”. But

n = 0

for i in range(10):

  i += n

print(n)

only ever produces one output value... Is it a dynamic artifact? Is a HTML website that responds to changing screen size with CSS rules a dynamic artifact? Which of these are programming?

Shalabh 2024-09-17 22:53:57

state-to-state is one model of behavior and in general a program is a representation of some subset of system behavior.

a typical 'program' is missing a lot of aspects. notably any notion of persistence is absent. data lives on longer than programs. newer programs have to contend with data left over by old programs (or earlier versions). this is why i think the typical notion of a program as this transient entity you run, which computes something and then is done, does not get close to covering the entire span of system behavior.

there is a fair bit of incidental vs accidental complexity discussion in the past in this slack if you search the history. there was also the related tarpit episode futureofcoding.org/episodes/063.html

Kartik Agaram 2024-09-18 04:15:27

Joshua Horowitz movies support moving pictures but you can freeze an image or even go to black. Analogously, it seems to me that the dynamism is a possibility the medium provides, whether or not any particular work uses it.

I gather people were making stage plays in the new medium for decades while gradually understanding dawned of all the new possibilities that it opened up.

Joshua Horowitz 2024-09-18 09:25:45

Kartik Agaram I don’t think that quite gets at what’s interesting to me about the Python test case. I don’t see that script as, like, a degenerate program, in the same way that a single-frozen-frame movie would be a degenerate movie. I think that script DOES take advantage of the dynamism the medium provides. But its output is entirely static! This means you shouldn’t judge something to be a “program” or a “dynamic artifact” solely on the basis of its externally visible behavior treated as a black box. Sometimes you care about how the externally visible behavior responds to edits in the artifact itself. But I don’t know how to pin this down.

Duncan Cragg 2024-09-18 09:49:24

@Misha A I think you've basically nailed it in what you said there. This is exactly how I started my journey: looking for "the essence of programming". I described it as seeking a "Target and Domain Independent" programming language: one that was unconstrained by having to execute it on specific hardware Target, and untarnished by the needs of any given Domain. My conclusion was exactly what you're saying: that programs move one state to the next. That's basically it.

Misha A 2024-09-19 02:27:11

re: state vs. IO

it seems to me that IO is state too. The question is: at what point it becomes more useful/convenient to start distinguishing between the two.

What would be the difference?

Should the programming language treat them as the same, but let user introduce the difference when necessary. Or should the difference be baked in already?

What is the difference, again?

What other differences between seemingly same things are better ("better" when, for whom?) to be baked into the language?

It seems that the programming languages game is all about designing syntax(tool) convenience proportionally to task frequency. Seeing a lot of same things as different – breeds proliferation of tools. So maybe seeing similar things as the same would reduce tools ... "fragmentation"? (e.g. java's classes with their personal new-every-time-DSLs vs clojure's "everything is a map, but these several functions is all you ever have to learn")

Mark Dewing 2024-09-20 22:19:24

Related to the 'incidental complexity' question - sometimes I get frustrated with all the code it seems to take to do even simple tasks. I question why there are so many lines of code? Why can't the computer just do what I intend? I've thought about categorizing the lines of code in some of my programs to see what all those lines are doing.

Kartik Agaram 2024-09-21 01:04:10

I've heard this line of reasoning before, and it's worth questioning the premise. For some arbitrary computing task, how do we know how simple it is? I don't think we can, short of building it from scratch for ourselves. And so we can't really make any assumptions about the level of essential/incidental complexity of a task without a lot of careful effort and analysis. It's tedious, error-prone, intricately-detailed work.

It's definitely a common reaction, and I've been guilty of it myself. My best guess these days is that it's a cognitive fallacy related to Moravec's Paradox. People just have really poor intuitions when it comes to computation. Simple things a child can learn without us grown-ups exerting any effort require tremendous quantities of effort for a computer to "learn". And the human reaction is repeated disbelief. That can't be right!

Paul Tarvydas 2024-09-21 03:24:33

Here's how I see it: everything is complicated...

The idea of creating general purpose languages is a loser...

open.substack.com/pub/programmingsimplicity/p/programming-is-too-complicated?r=1egdky&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true

Misha A 2024-09-22 07:00:28

For some reason I get "then it does not matter" from "everything is complicated" comments.

If everything is complicated, why not deal with essential complexity instead of incidental one?

Feels like comparable amount of work, but radically different outcomes.

The Thirty Million Line Problem

Mike Acton "Data-Oriented Design"

Sometimes treating different things the same way makes things easier or even simpler.

Sometimes treating similar things differently does.

but it seems to me, scanning this space of variations is more tractable from the root tree-side, where combinatorics haven't really kick in yet.

Paul Tarvydas 2024-09-23 15:49:43

The Thirty Million Line Problem

I watched this several years ago and deeply disagree with the conclusion. IIRC, Moratori blames USB Plug'N'Play on the exponential rise in complexity in software development. He bases his conclusion on a graph that shows the correlation between complexity and the invention of USB Plug'N'Play. Basic science says that correlation does not imply causation. The fact that the hockey stick curve of complexity jumps upwards at the same time as USB Plug'N'Play was invented does not necessarily mean that USB Plug'N'Play caused the rise in complexity. In fact, a different explanation for this particular correlation might be as a manifestation of incidental complexity caused by something much deeper and invented much earlier (hint: over-use of the function-based paradigm).

[Note that this, also, ties in with bicycles-for-the-mind thread. Programmers have forgotten how the hardware works and have veered off into believing that there is only one way to program hardware - i.e. with lines of code written in programming languages buttressed by operating systems.]

Christopher Shank 2024-09-19 19:13:22

I like this metaphor of translucent software both as a callback to the translucent hardware aesthetic of the 2000s, but also to progressively display the underlying mechanisms of software ~if~ you want to see it.

x.com/lesliexin/status/1836643348490187183

🐦 leslie (@lesliexin) on X: Finally got around to building this :)

Try it at https://t.co/S82Yp0nkKw

Tweet Thumbnail