
Into the Tar Pit - tosh
https://einarwh.wordpress.com/2020/05/19/into-the-tar-pit/
======
naringas
Best tidbits from the article:

> Software developers should provide expertise [...], but also in the
> externalization of mental models to facilitate communication and enable
> collaborative modelling.

> Software development is largely a communication problem. [...] We should
> contribute to better concepts and a richer language to describe the domain.

A while back I understood my work as a web developer as a translation from
"business speak" into the language of some web framework. An activity not so
different from translating a novel from it's original language into some
other.

The key point being that one needs to fully understand the "business speak"
side of things before one can write it out as computer code.

> We should lead in this effort, not wait for someone else to do it for us.

But neither can we, software developers, do this on our own.

I guess something I had been missing before is the feedback aspect (i.e. the
externalization of mental models). However, in my experience most people in
the 'business side' aren't interested in understanding the software side, so
they are not receptive of what the software engineers have to say about the
problem domain (i.e. the business side of things).

~~~
throwaway_pdp09
Definitely this. I'd had it hammered into me that I need to understand the
business to be a good dev, and it's _true_. That domain knowledge is essential
to do a decent job, or even do the job at all.

Rhe reciprocity, though, is mostly missing. An attempt to understand the IT
side is essential for managers but most often they can't be bothered (or
bothered to understand the principles of user interfaces, for that matter,
anything that falls outside their domain). The few bosses I have had that did
try were very good to work for indeed, but such are rare.

~~~
thiagocesar
The problem is that a developer doesn’t really understand the business
complexities and nuances - he studied computers, not business.

I feel there is a gap to be crossed, and settling into a common language and
common communication practices are ways to bridge it, but I could never say I
understand the business.

I get some basics. We have lots of areas, we need workflows, we design parts,
then make them, then sell them. But I certainly don’t have enough knowledge to
really understand it.

~~~
lmm
Translation needs to involve at least one person who is native-level in each
language, and you're lucky if it's possible for both of those to be the same
person.

An effective team needs people who understand the computers and people who
understand the business. Though it can sometimes end up a little like
[https://www.youtube.com/watch?v=yfSnaY1Wp_U](https://www.youtube.com/watch?v=yfSnaY1Wp_U)
.

------
j-pb
The author miss-understands the paper for some call to formalise everything
and then continues to ramble on how complex the world is and how futile
formalisation is.

This is not what "Out of the Tarpit" is about. Out of the tarpit is about a
clear separation between the currently complected aspects of "what" do we want
our software to do, and "how" do we make it do that with the best possible
performance. There is no arguing against that if you currently want to
describe a website you'll have to learn some model of how the browser renders
stuff, how react or vue or whatever performs update calls, and redraws, and
state management and and and.

Out of the tarpit simply argues that these things are relevant but accidental
to the problem that we want to solve, and proposes a functional logic-
programming hybrid approach which focuses on declarative programming,
separation of concerns, and immutable state management.

All of the above are pretty well known best practices by now, even though
they're not implemented verbatim as the paper proposes there are still ideas
that have found it into mainstream programming.

React is a functional reactive and mostly declarative library that takes care
of a lot of state management for you.

Clojure is a functional programming language with heavy emphasis on
simplicity, state management and functional programming, with logic
extensions.

Differential Dataflow is declaratively describing computation and reactively
executing it across clusters.

People rediscover the virtue of relational programming and write more SQL than
ever, with ORMS becoming out of style.

If the author had argued that the proposals made in the paper are necessary
but not sufficient, fine. But arguing that it's "wrong", because they perceive
that the sources of complexity focused on by the paper, are not as important
as the ones they choose, is just silly.

He even makes the point for them, by quoting:

> There is no point in using exact methods where there is no clarity in the
> concepts and issues to which they are to be applied.

This is exactly what the paper is about.

"In order to program something, I should not have to formalise it to the
degree that I have to formalise it currently. I should not be forced to choose
data-structures, and algorithms that I care about tangentially.

Those should be specified as an afterthought, when the need arises, and when
performance, reliability, resource consumption become a concern."

This whole Post reminds me a bit of Tim Minchins 'Storm':

"Programming is full of complexities, yeah But there are answers out there And
they won't be found By people sitting around Looking serious And saying 'Isn't
code mysterious?' Let's sit here and hope Let's call up the fucking Pope Let's
go watch Oprah Interview Deepak Chopra

