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.

This is all great, but… for system level programming (e.g. embedded) you most likely will either write your own or people will have a library-platform that is very specific for the target.

In general, good maintained libraries require critical mass. Which is why shitty languages can do ok in terms of usability once they reach critical mass.

Perl and Php were at one point the best options for doing web-related programming (1993-2003). Critical mass. Today I wouldn't start any new project with those languages.

I am not sure if I buy the notion of "general purpose programming".

The thing is, language syntax, semantics and runtime is closely linked to the application area if you want to support the domain in the most user-friendly way.

Just take a look at the Arduino language which is C++ with syntactical sugar. Why is there a need for something like that?  Well, there is a need for it.  I know C++ fairly well, but if the Arduino language is sufficient, it still provides for a better experience and more rapid prototyping. Yes, it is just a very simple layer on top of C++, but it still matters.

You see the same in web-programming now. New languages built on top of the existing languages. One example is Angular. Angular is essentially not just a library, but a markup-oriented language built on top of or in concert with typescript. Same thing with React. Domain specific languages built on top of the critical mass language used in the application area.

It is to be expected that we will see more domain-specific languages being developed as it becomes easier to create such tooling. Perhaps acting in concert with a critical mass host language so that they can draw on existing infrastructure.

Ola.

On Friday, 3 May 2019 at 04:14:56 UTC, Nick Sabalausky (Abscissa) wrote:
> For example, most languages, including "Node"'s JavaScript, just aren't *capable* of what makes Vibe-d awesome.

Are you thinking about the ability to utilize the hardware or something specific to web programming?

I only use node.js for prototyping, but it is built on top of Chrome's engine which does support a lot of EcmasScript6 and thus more advanced TypeScript usage. (ES6 improve on JS by providing classes, generators etc). I haven't really gotten to use generators much, but for web programming I'd say that is a massive improvement.

Ola.

On 5/9/19 5:42 AM, Ola Fosheim Grøstad wrote:
> On Friday, 3 May 2019 at 04:14:56 UTC, Nick Sabalausky (Abscissa) wrote:
>> For example, most languages, including "Node"'s JavaScript, just aren't *capable* of what makes Vibe-d awesome.
> 
> Are you thinking about the ability to utilize the hardware or something specific to web programming?

I'm referring to the no-callback behind-the-scenes approach to async.

On Thursday, 9 May 2019 at 16:39:32 UTC, Nick Sabalausky (Abscissa) wrote:
> On 5/9/19 5:42 AM, Ola Fosheim Grøstad wrote:
>> On Friday, 3 May 2019 at 04:14:56 UTC, Nick Sabalausky (Abscissa) wrote:
>>> For example, most languages, including "Node"'s JavaScript, just aren't *capable* of what makes Vibe-d awesome.
>> 
>> Are you thinking about the ability to utilize the hardware or something specific to web programming?
>
> I'm referring to the no-callback behind-the-scenes approach to async.

I haven't done async in node.js, but I thought you could use TypeScript/EcmaScript 6 with async/await?

In that case I think it is supposed to use generators/yield, which basically is the same as coroutines? So no callbacks?

So you would set up promises and await that they end before responding by using:

const promises = [callAsync1(), callAsync2(), callAsync3() ]
results = await Promise.all(promises)

or something like that.