Name-Oriented Programming - [Are We There Yet?]

Sometimes I like to cook. And I never needed to name my knives to chop some carrot.
On other hand I sense “a names obsession” in our current state [of software development].

Isn’t it funny that we start def with a name (aka symbol) instead of a value. And maps with keys.
Values are always on the second place. Silver medals, gold medals are for access keys.

What do you care more about: result (sum of several numbers) or exact name of a func in your current situation (+, plus, adder, the-best-adder-of-2018)?

Yeah, I know, names/namespaces are refs/links/keys, we need them to remember how to access/retrieve values. Fast enough to not interrupt our flow.

We prefer terse over verbose. But while it works only. And quite often it doesn’t.

The funniest part for me is that we have a quite different approach (I call it right one) in databases:

  • entity by attributes
  • value of values (old value override)
1 Like

I can’t see your point.

@alexandrkozyrev Do you like core.logic or prolog?

@linpengcheng, I like this one

@lxsameer, Sameer, it’s a watercooler rant.
I’m looking for a person who had/has similar feeling/mindset/worldview and can share his/her own experience, approach to resolve

f.i. a macro that rewrite a defn, so ret value goes first, then implementation, then args, and the last is func aliases

it’s just one example, but I don’t know how to explain in details in less then couple hours

THE closest credo:
“Programs must be written for people to read, and only incidentally for machines to execute.”
― Harold Abelson, Structure and Interpretation of Computer Programs

1 Like

this one is also good

“Every reader should ask himself periodically ``Toward what end, toward what end?’’ – but do not ask it too often lest you pass up the fun of programming for the constipation of bittersweet philosophy.”
― Alan J. Perlis, Structure and Interpretation of Computer Programs

Consider the point-free style, which many functional programmers and at least some Clojurists tend towards. Names are to be minimized because good names are hard and bad names are costly.

2 Likes

I think most people think in names. Names are an abstraction. One word to mean much more. Though you’re right, thinking in formulas, while less familiar, can be helpful for computing. But I’d say either have names or don’t, point free style, not sure of the advantage of moving the name after the value in a defn.

Remembered an old idea of mine.

I believe names are complected in programming. I’ve talked about this on the mailing list before. Names are used for computer reference, and for us to understand what the function does at a glance. These two use case often interfere with one another.

My idea to decomplect this is for the computer references to be computer generated, and the name to become a doc-name that accompanies the doc-string.

The way I thought Clojure could be extended is that defn would take a reference-id and a doc-name like so:

(defn 989382-a638d827-273u28827
  multiply
  "Multiplies a with b"
  [a b]
  (* a b))

If you wanted to use this function, you’d have to call it with its reference-id:

(989382-a638d827-273u28827 10 20)

For convenience, tooling would magically replace all reference-id by the doc-name. So in your idea you could do:

(multiply 10 20)

But the file content would actually have the reference-id in it.

That way, humans can have a name, you could even internationalize the doc-name, giving humans a name in their preferred language. You would be free to change the name whenever, without breaking any reference, no more need to refactor.

Ideally all Clojure def would support this. Maybe symbols could actually be extended to have a doc-name and a symbol, that might allow this pattern everywhere.

Also, I thought of a way to do it without change to Clojure. Come up with a common file format, something called name-reference-map.edn for example. Put it in the root of your project. Inside, a map from name to reference-id would be stored.

{989382-a638d827-273u28827 multiply}

Tools could all learn to support this. So for example, clj-fmt could automatically replace all name to their reference as it formats based on the file. And then Cider would automatically replace all reference by the name in the buffer.

Reference-id don’t have to be a guid loke that. They just need to never change. So this can be backward compatible. Namespace/reference-id is the real reference. Clojure.core/+ for example can be taken as a reference, but you could change its name

{user/989382-a638d827-273u28827 multiply
 clojure.core/+ sum}

So now to humans with such a name-reference-map they’d see + as sum everywhere, and coukd call it with sum, but in the source file it would always be +. The code you see is a human projection. This style could allow a hybrid approach, where the first good enough name is the source reference, which would work for tools who don’t yet support the name-reference-map, but by convention you would never change a name after you committed it, instead you’d refactor with the name-reference-map.

1 Like

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.