Mountains, Molehills, and Markedness

In my previous three posts, I explained why the semantics of programming languages are not as rich as they could be. I pointed out some symptoms of that deficit, and then made recommendations about bridging the gap. Finally I introduced “marks”–a feature of the intent programming language I’m creating–and gave you a taste for how they work.

In this post, I’m going to offer more examples, so you see the breadth of their application.

Aside

Before I do, however, I can’t resist commenting a bit on the rationale for the name “marks”.

In linguistics, markedness is the idea that some values in a language’s conceptual or structural systems should be assumed, while others must be denoted explicitly through morphology, prosodics, structural adjustments, and so forth. Choices about markedness are inseparable from worldview and from imputed meaning. Two quick examples:
Continue reading →

Introducing Marks

In my previous two posts (here and here), I described how and why programming languages can’t talk about many issues that affect programmers–important issues like product requirements, design constraints, intellectual property, and more. I also inventoried the mechanisms that extend the semantics of languages today, and explored why those mechanisms have limited value. If you haven’t read those posts, please do; what I say next won’t make a lot of sense without that foundation.

In the intent programming language that I’m creating, the solution to this problem is called “marks” (a name which alludes to linguistic markedness). Marks play a role somewhat analogous to adjectives and adverbs in human language; they are crucial enrichers. They resemble decorators or annotations in other languages, though their power is much, much greater.

Without further ado, let me provide a blueprint for this bridge across the semantic gap that I’ve been lamenting–the design guidelines for “marks.” Then I’m going to show you an example of how easy it could be to use marks, and how much power they give you.

image credit: Curious Expeditions (Flickr)

Blueprint

Code and its compiler(s) must have a compile-time API specified by the language.
It’s not okay if Clang generates one type of AST, GCC a second, and MSVC a third; all compilers that support the language must expose a spec-compatible, programmable API for all language constructs. For example, I need to be able to find out what parameters and local variables are declared in a function, and what their data types and other characteristics are. This is similar to what reflection offers, but reflection doesn’t help at all, because I need this before run-time. (Kudos to D, which provides compile-time reflection very similar to what I’m describing…) As I mentioned in my post about making a codebase const-correct, the lack of this feature is really a serious design flaw. Why should code, of all things programmers deal with, be impossible to code against?

Continue reading →

Features are not chunks of code

Before the industrial age, “features” were noteworthy aspects of a face or a geography: a patch of color, abundant wrinkles, a scar… The human brain is stunningly good at identifying and comparing such features–perhaps because that ability has been central to our nurture as children, our bonding into family units, and our survival as a species.

danie-franco-o1PKM7-8AH4-unsplash

Photo by Danie Franco on Unsplash

When we want to say what a face looks like, we describe its features. They are an entrée into experience with it.

At the dawn of the computer age, the advertising and publishing industries were already talking about how products–or aspects of them–could be “featured” in media. Highlighted characteristics were called “features”, and this metaphor transferred seamlessly into digital language. Software product managers now traffic in “features” and “feature sets.”

We use the term so comfortably that we sometimes forget what it has to teach us.