"Stop Designing Languages. Write Libraries Instead."

[Mike Franklin]

On Thursday, 2 May 2019 at 20:08:01 UTC, H. S. Teoh wrote:
> Stumbled upon an interesting read today:
>
> 	http://lbstanza.org/purpose_of_programming_languages.html
>
> Note: read to the end before jumping to conclusions about what 
> the article is trying to say.
>
> It made me wonder how D fares in terms of being able to 
> implement libraries that are maximally easy to use.
>

Thanks for that; it's a good read.

The author is right on.  People from all disciplines are writing 
code now.  It's become as basic a skill as reading and writing 
for many fields of work and study.  How many professional 
software engineers do you know that started in some other 
discipline, e.g. math or physics, had to write software for their 
work, enjoyed the software development more than that actual math 
or physics, and decided to become professional software 
engineers?  I believe there are few in the D community.

Many of the customers that I support professionally have no 
training in software development but are required to write code.  
They are engineers of other disciplines, pharmacists trying to 
automate their work, entrepreneurs trying to create a new product 
to sell, inventors trying to turn an idea into reality.  Very few 
have formal training in software development, yet they all need 
to write code.  And interestingly they couldn't give a rat's butt 
about what the language is, as long as they can understand it and 
it works.  In fact, many of my customers prefer BASIC, 
unfortunately.

The Arduino is an excellent example.  The Arduino is actually C++ 
(not C as many first assume).  Yet it has taken the world by 
storm as being a platform for hobbyists, students, artists, 
inventors, and entrepreneurs.  Why?  Because the API is so simple 
and well-documented.  The idea is lousy, but it's designed for 
projects that contain only one source file of 1000 lines or less. 
  I write a mechanical keyboard firmware for a 44-key keyboard 
using the Arduino framework and its only 841 lines of code (with 
comments).  Isn't it ironic that the Arduino is using arguably 
the most complex language we know (C++), but has been adopted by 
millions who have very little software development training and 
skills?  Why? Because the Arduino API is so simple.

I program mostly in C#, and I can build things quite quickly in 
it, not because it's a great language, but because of the .Net 
Framework and its huge list of class libraries.  Take away the 
.Net Framework, and C# loses much of its appeal.  I've often 
wanted to write a shim from D to the .Net class libraries just so 
I can use the .Net API from D.  I think others might even 
currently be working on such a thing.  What would be even better 
would be to write a tool that can automatically translate the 
.Net Framework class libraries to D, perhaps built on top of 
Phobos, to achieve platform abstraction.

Anyway, the author's close is great with the following statement:

> The purpose of a general-purpose programming language is to 
> enable the creation of powerful and easy-to-use libraries. The 
> more powerful the language, the easier the libraries are to 
> use. Code that makes use of a perfectly tuned library should 
> read almost like a set of instructions for a coworker.

This is actually what I like about D:  It is so powerful, it 
allows users to make whatever abstraction is ideal for their use 
case.  What I'd like to see is for D to capitalize more on that.

As we near DConf, there is one talk I'm very interested in:  
"Rethinking the Default Class Hierarchy: an Object’s Tale", 
supposedly exploring a new class hierarchy for D with 
`ProtoObject`.  What I'd like to discuss with those working on 
that is "What feature(s) of D are we missing that is preventing 
us from implementing classes in the library?".  This blog post 
(https://theartofmachinery.com/2018/08/13/inheritance_and_polymorphism_2.html) goes quite far with existing features of D.  Don't get me wrong, I love classes, but one thing I learned from D is that with CTFE, mixins, static if, and the culmination of all of that in design-by-introspection, you can reduce the language down to a few super-powerful, composable language primitives and then implement the abstractions you need in the library.  Even if D does decide to go the `ProtoObject` route, I'll be attempting to stick with structs and runtime-less language features to implement what I need, and that is why I'm currently working on achieving Andrei's no runtime, pay-as-you-go, opt-in continuum (https://forum.dlang.org/post/q7j4sl$17pe$1@digitalmars.com).

I think the powers that be are right about D, that we should 
strive for fewer coarse language features and more finer language 
features that would allow us to implement something equivalent to 
those coarse language features in the library.  Then, like 
Arduino, instead of exposing complex language features to the 
users, encapsulate them in the library's abstractions so domain 
users can just focus on understanding the API (which should be a 
model of their domain), and spend less cognitive effort 
understanding the intricacies of the language it was implemented 
in.

Mike