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.


T

-- 
Тише едешь, дальше будешь.

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

On Friday, 3 May 2019 at 02:25:47 UTC, Mike Franklin wrote:

> The idea is lousy, but it's designed for projects that contain only one source file of 1000 lines or less.

Well, that was a horrible typo.  That was supposed to read "The IDE is lousy..."  The *idea* of Arduino is excellent.  Sorry!

Mike

On 5/2/19 4:08 PM, 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.

First of all, I want to emphasize: That article's title is *incredibly* misleading. The double-quotes around the title are FAR too easy to overlook and ignore, and for this article, that makes all the difference in the world.

Turns out, my knee-jerk reaction to the title was *exactly* the very same point the article is making: Sure, libraries are a major key, *BUT* it's the language's features that make a good library even possible in the first place. It's the *language* that determines how good the libraries can be.

I think that Phobos ranges and Vibe.d are perfect examples of how D does a fantastic job of providing a solid basis for excellent libraries.

For example, most languages, including "Node"'s JavaScript, just aren't *capable* of what makes Vibe-d awesome.

And very few languages could support the modeling power Phobos Ranges without sacrificing one (or both) of our range API's other key pillars: Type safety and Efficiency.

On Friday, 3 May 2019 at 02:25:47 UTC, Mike Franklin wrote:
>
> 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.

Tried this [1], but there is a lot of stuff missing from Phobos to replicate 1:1 the .Net Framework. From what I remember, these were the challenges:
- culture sensitive string is a first class citizen of .net framework. This involves Unicode comparisons, normalization and all the ugly stuff you can find in std.uni;
- decimal data type is a built-in numeric type; I created my own decimal implementation [2]
- the .net framework Console is a beast compared to the phobos which simply calls the C library to write something on the screen which results in a lot of problems (that you cannot use a different decimal separator)
- again, culture sensitive info is missing from phobos (and I'm not referring to strings here). You cannot have a decent calendar or time zone information.

In fact the main problem is that .net classes are highly interconnected, and you cannot jut write one class without digging in another 1000. Just implementing a simple toString functionality will lead to string management, which will lead to unicode, which will lead to culture information for formatting and so on...

[1] https://github.com/rumbu13/sharp/tree/master/src
[2] https://github.com/rumbu13/decimal/tree/master/src

On Friday, 3 May 2019 at 02:25:47 UTC, Mike Franklin wrote:
> 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.

So does Lisp. And one of the main criticism of Lisp is that every programmer invents their own programming language features and it's very hard to reuse code or libraries because everything is written in different style.

Remember Lisp curse http://www.winestockwebdesign.com/Essays/Lisp_Curse.html

" Lisp allows you to just chuck things off so easily, and it is easy to take this for granted. I saw this 10 years ago when looking for a GUI to my Lisp. No problem, there were 9 different offerings. The trouble was that none of the 9 were properly documented and none were bug free. Basically each person had implemented his own solution and it worked for him so that was fine."

"Some smug Lisp-lovers have surveyed the current crop of academic languages (Haskell, Ocaml, et cetera) and found them wanting, saying that any feature of theirs is either already present in Lisp or can be easily implemented — and improved upon — with Lisp macros. They're probably right."

"The Lisp Curse kicks in. Every second or third serious Lisp hacker will roll his own implementation of lazy evaluation, functional purity, arrows, pattern matching, type inferencing, and the rest. Most of these projects will be lone-wolf operations. Thus, they will have eighty percent of the features that most people need (a different eighty percent in each case). They will be poorly documented. They will not be portable across Lisp systems. "

replace Lisp with D in these quotes and it sounds interesting :)

On Friday, 3 May 2019 at 02:25:47 UTC, Mike Franklin wrote:
> 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.

https://github.com/thewilsonator/dflat

Almost done, currently stuck on https://github.com/dotnet/coreclr/issues/24216#issuecomment-488682958
any insight into the metadata of PE headers much appreciated.

Note that calling C# will probably butcher your perf because you have to disable the D GC on entry to C# code and and manually unpin C# objects from D to avoid the two GCs stepping on each others code.

On Fri, May 03, 2019 at 07:45:33AM +0000, JN via Digitalmars-d wrote:
> On Friday, 3 May 2019 at 02:25:47 UTC, Mike Franklin wrote:
> > 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.
> 
> So does Lisp. And one of the main criticism of Lisp is that every programmer invents their own programming language features and it's very hard to reuse code or libraries because everything is written in different style.
> 
> Remember Lisp curse http://www.winestockwebdesign.com/Essays/Lisp_Curse.html

This is a valid concern, and I've been thinking about it. The problem here is standardization vs. flexibility.  The more generic a piece of code is, i.e. the wider its scope, the more standard its API must be. Imagine if D ranges were implemented not in Phobos but some 3rd party library.  Inevitably people would reinvent the wheel in all shapes and sizes, all somewhat equivalent but all slightly incompatible with each other. Some projects use one API but others use another.  It would be utter chaos as balkanization sets in.

But currently, we have a standard range API that, in spite of some warts, is universal across all D code. Everyone writes their API around it rather than reinventing their own.  The Lisp Curse doesn't set in, and everyone reaps the benefits.

Widely-applicable things like this *need* to be standardized.

A negative example of this is the historical Tango vs. Phobos divide, and the subsequent fallout. Some things need official endorsement, and cannot be left for the masses to fight it out.

Eventually, what all this means is that we need a process by which widely-applicable 3rd party libraries / frameworks get official endorsement and standardization by the leaders of the community. This doesn't apply to your typical library, but to high-impact, highly generic code that has universal scope.


T

-- 
You are only young once, but you can stay immature indefinitely. -- azephrahel

On Friday, 3 May 2019 at 12:52:43 UTC, H. S. Teoh wrote:
>
> But currently, we have a standard range API that, in spite of some warts, is universal across all D code. Everyone writes their API around it rather than reinventing their own.  The Lisp Curse doesn't set in, and everyone reaps the benefits.
>

Sorry, but I'm among the D users hating how the range stuff was designed and I try to avoid phobos as much as I can in all my projects and to rewrite bits of phobos replacement code to cover my needs. The fact that phobos is endorsed by someone is equal to nil as long it contains errors in design and sometimes even in implementation.

One of the reasons: https://forum.dlang.org/thread/ktdfnvoonjuzswryofsk@forum.dlang.org?page=1

On Fri, May 03, 2019 at 02:14:21PM +0000, rumbu via Digitalmars-d wrote:
> On Friday, 3 May 2019 at 12:52:43 UTC, H. S. Teoh wrote:
> > 
> > But currently, we have a standard range API that, in spite of some warts, is universal across all D code. Everyone writes their API around it rather than reinventing their own.  The Lisp Curse doesn't set in, and everyone reaps the benefits.
> > 
> 
> Sorry, but I'm among the D users hating how the range stuff was designed and I try to avoid phobos as much as I can in all my projects and to rewrite bits of phobos replacement code to cover my needs. The fact that phobos is endorsed by someone is equal to nil as long it contains errors in design and sometimes even in implementation.

Expecting perfect software is a pipe dream.


> One of the reasons: https://forum.dlang.org/thread/ktdfnvoonjuzswryofsk@forum.dlang.org?page=1
[...]

To quote Jonathan in that thread:

	The only reason that you're even hitting this issue is because
	you're explicitly avoiding importing all of the range primitives
	together and are trying to grab certain ones individually, which
	was never an intended use case. So, if you're doing that and
	running into problems, I'm sorry, but you're trying to use the
	library in a way that it was not designed to be used.

You can't pull out a random piece of a complex machinery and expect it to work by itself independently of the other parts.

But to address your point: this is one of the reasons I really, *really* want to kill autodecoding with fire.  Then we can put array range primitives in object.d where they belong, and this will no longer be an issue.


T

-- 
Having a smoking section in a restaurant is like having a peeing section in a swimming pool. -- Edward Burr