I’ve worked in dozens of languages over my career, and none have felt as amenable to that style of expressive code-as-English-prose as well-written Ruby. This is explicitly alluded to in tools like Cucumber, but only marginally less so in the application and spec code that you end up writing.

Note that I used the adjective expressive rather than verbose; a word which reminds me of my experience with COBOL back in the day. :shudder:

It’s easy to conflate programming languages and true languages, but this is manifestly easier because we’ve chosen to apply the word “language” to machine syntax for lack of a better term. We’re always looking for a good “handle”.

The important point that I take away is
PLs should be “human-machine” methods of communication. That resonates.

First, humans (at least some) and machines (at least some) must BOTH be capable of easily understanding the language.

For communicating what? Instructions for completing some task. Focus on specific types of task can minimize the scope of the language.

For communicating to whom, specifically? Everyone and every machine is ideal, but I believe focus on some subset of humans and machines facilitate simplicity and understanding.

The needs for focus in the message and target audience results in a plethora of – if you will, please – DSLs.

I long for the days when COBOL was used to satisfy most business requirements. I remember fondly code reviews that included end-users (i.e., domain experts), where everyone in the room understood and contributed.

Those days are gone. Conversations between domain and machine experts require translators, and there are very few people that understand both areas well.

We need to strive for PLs that maximize the number of humans than can understand the code (perhaps within a given specific context). I don’t see any obvious examples in todays most prevalent languages.

So-called “computer languages” were invented to “communicate” with machines, not other human beings; their convergence in the last 80~90 years with certain aspects of human languages is minimal, yet.

The very essentials of what makes a human language go beyond the translation of collections-of-glyphs to a finite set of invariant machine-commands that have “intrinsic meaning” only in so far as they are interpreted in the frame of reference of the creators and implementers of the programming syntax, and the hardware systems that underlie it.

A human language is the vehicle for the translation of speech, and glyphs, into “meaning” (morphemes), and is inherently parallel, involves multiple dimensions of “resonance,” and exists in an ever-changing matrix of social-cultural identity, and the enactment of roles (where “role” refers to specific psycho-physical states of perception as well as qualities of behavior and perception in interpersonal communication).

The pasting of a “happy face” on machine-command syntax by equating it with “language” may have served a certain purpose to render people less afraid of computers, programming, programmers, etc. But, it’s a con.

“that’s a niche that” … -> has been little explored.

You’re right that modern PLs avoid low-level stuff, and that this is more and more a thing of the future. I’m not sure that being “more mathematical” is the way to go, though; there will always be people who like to work with an extremely formal notation, but I think they’re the minority. Working formally is extremely taxing to the mind, and it’s not needed essential during most programming steps, just for making sure of verification and correctness – if you look at things like Wolfram Alfra’s “Language for Knowledge-Based Programming” (people who are not suspicious of being anti-formalisms), the things they sell as a radical advance and advantages of their new product are interactive evaluation, categorization and search of primitives, and mixing natural language with data and code. Yes, it has a lot of marketing exaggeration, but I think it’s a valid trend.

“I think much of modern PL research (and with a little poetic license, all of the original PL research) is actually dedicated to developing PLs as human languages for expressing pure, true thoughts.”

Very true. Not all research is like that, though. 😉 As I explain in my other comments, some schools of End-User Development actually try to develop “human-like” programming languages that express muddy, ambiguous thoughts, and still arrive to something useful. EUD doesn’t talk of “programs”, but “software artifacts” (mixtures of code and data) that allow users to build automated behaviors, to avoid repetitive behavior and create events that will happen in the future without human intervention. Those two actions are the essence of programming from this perspective, the real “benefits” of being a developer and not a mere power user of pre-built applications.

Admittedly this is a non-orthodox approach, far away from the main PL trends (so you and I are not talking exactly about the same thing). It’s a shame that few developers are aware of this school, though Bret Victor has made it noticed in the large for the first time. Several development tools are adopting the most useful parts of it, and I think both trends will become unified in some not-too-distant future.

From a developers perspective, these tools look a lot like a programming environment that is always in debug mode and where code and data can be updated on the fly. “Reactive programming” languages are like this, though they still have too formal syntax for my tastes; something like REBOL, with minimal “Tcl-like” syntax is more adequate for non-technical users.

I believe a combination of REBOL (for the syntax) + Federated wiki (for storage and collaboration) + the “Leo/IPython bridge” (for the interaction model) would satisfy the needs of naive users to build simple programs. That’s what I’m most interested about programming languages, because that’s a niche that (Hypercard was the closest popular thing that has existed for this, but it still requires a fairly sophisticated end user).

If you’re not familiar with these tools I recommend you to learn a bit about them; I think in the future programming will look a lot like this, as I’ve seen the trends, and many of them point in that direction (except for the “simple syntax” part, that professional developers will never adopt as it’s not really efficient).

Haskell has the essential prerequisite of being extremely purely declarative, but its read–eval–print-loop IDE is quite primitive from the “semiotic” point of view I’m talking about, and its mathematical approach is the opposite of what I’m thinking 🙂

I know it’s hard to explain, as no tool exists that works exactly like what I have in mind. The “office suite as a programming tool” that I talk about in my Ars Technica comment[1] is what I think of as a user-friendly development environment.

The properties of such language should be something among the lines of Bret Victor’s “Inventing on principle” Learnable Programming, and “always-on debugging” IDEs like Light Table, where the environment blends with the programming language and the data you use to test and debug the program become a part of the program.

The way to work in an environment like this is not by creating an formal set of instructions (either declarative like Haskell, or imperative like Ruby or Python) that perfectly define all the possible behaviors and is understood as “the program”, which is later “executed” on a set of “input data”. That instruction set would be created in the end through the programming activity, but it’s not the main focus of the developer (at least not while building the program, maybe only for verifying that it’s correct).

In my desired approach, functions are defined by the developer performing commands that change a subset of data in the desired way, and then generalizing from there to add more code to handle other edge cases not covered by the first programmed commands.

This exploratory behavior happens to be how inexperienced developers create their programs, by trial-and-error. I know it’s error prone and anti-engineering, but those are the same qualities that make it user-friendly. I expect that by integrating lots of error checks and semi-automating best practices in the environment, the tool would be useful enough to build programs of mid complexity without being too dangerous to their users/developers. And maybe, if this approach is adopted, we could learn enough about it to be able to build robust tools on top of it as well.

The “why” that explain the reasons to create the tool and the shape it takes would not be conveyed only through comments, but also by the very examples of data used to define each function. Ideally this data should come from a real problem the developer was facing, and would provide real-world context for how the program is expected to be used. Classic programming languages are not good at this.

[1] http://arstechnica.com/gadgets/2014/11/preview-office-for-android-tablets-is-like-office-for-ipad-but-on-android/?comments=1&post=28036889

What is “pure and true” in this context? That was the question which originally drove the invention of PLs or logical languages and answers were attempted near the beginning of the 20th century by Russell, Whitehead, Frege, and many others. Church, Curry, and Turing, notable names in early CS, were actually largely driven by *Hilbert*’s mathematical program of formalizing mathematical logic.

So what does this effort look like today? PLs of this pedigree are *barely at all* interested in how binary codes work (unless they are the object of study, of course). Instead, they endeavor to provide valid logical frameworks of massive expressive power. Modern PLs in this vein can formalize mathematical logic through *intuitionistic logic* which is something like the logic most people learned in school but augmented with a notion of the limits of the Halting Problem. This means that it lives nicely between logic and computer science.

So why do we think that PLs are an object of computer commands? Because the popular ones which were both widely implemented and fast had that property. It’s essentially a walk in the park to convert Assembly to machine instructions compared to an intuitionistic logic calculus. We then proceeded not by seeking to make Assembly more like its forebearing languages but instead to layer abstraction after abstraction atop it to make the fundamentally alien task at hand more manageable.

This is ultimately a flawed program judged that way. Furthermore, it’s also less than half as old as the original PL research efforts, but it already had us develop many techniques for efficiently executing complex tasks on a computer. This is an important part of “computer algorithm design” but essentially a side-topic to the larger field of PL research.

I absolutely agree. Thank you for your comment. Are there any particular languages that you feel have come closer to the approaches you outline? Of the languages I have had personal experience with, Haskell comes to mind. But perhaps there are worthwhile efforts I have been ignoring.