Month: July 2014

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

  1. 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 →

Thoughts On Bridging the “Lacuna Humana”

In my previous post, I discussed the semantic gaps that afflict current programming languages. These gaps are caused by tools focusing on syntax and parsing, and mostly neglecting human factors.[1] I’m not just talking about the fact that languages are clumsy for us to use (more about this later); I’m saying that they ignore our need to talk about important realities of software development: security, coding habits, testability, maintenance plans, dependency management, requirements, intellectual property, and much more.

All this stuff falls within our scope of concern, but none of it is describable in our languages. That’s weird. Imagine we hired a general contractor to build our house, and he was great at swinging hammers and leveling studs. But as soon as we asked him questions about building permits or hiring subs or choosing the right kind of concrete for the foundation, he acted like he didn’t have a clue what we were talking about. We’d be likely to end up with lots of false starts, poorly met requirements, endless kludges, tons of frustration, a heavy QA burden. Hmm… That sounds familiar.

I call this lack of semantic continuity the lacuna humana — the human gap.

The good news is, gaps can often be bridged.

image credit: vestman (Flickr)

I promised I would describe a bridge that has a lot of virtues, and I’m going to begin that work here. It might take us a couple posts to get all the way across, though. Thanks for hanging with me…

Continue reading →

Lacunas Everywhere

I’m told that in Czech, the word “prozvonit” means “to call a mobile phone and let it ring once so that the other person will call back, saving the first caller money.”

Image credit: AstridWestvang (Flickr)

How would you translate this word to someone in New Guinea who has never experienced electricity, let alone a telephone or a bill from Verizon? You wouldn’t. This is an example of a “lacuna“–a translation problem caused by semantic gaps in a target language. Lacunas occur in programming languages. You might know a few; maybe you wish C++ had python-style generators–or that Java had Haskell’s notion of pure functions–or that C supported PHP-style string interpolation. But what if I told you that semantic misalignment between any pair of programming languages is just minor details? What if I claimed that all programming languages I’ve used have numerous, pernicious, and expensive semantic gaps? That we don’t see these gaps for the same reasons that a stone-age hunter-gatherer fails to notice his inability to discuss patterns of cell phone usage? Would you think I’m crazy? Continue reading →