www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - "Stop Designing Languages. Write Libraries Instead."

reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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

-- 
Тише едешь, дальше будешь.
May 02 2019
next sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
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.


it, not because it's a great language, but because of the .Net 
Framework and its huge list of class libraries.  Take away the 

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
May 02 2019
next sibling parent Mike Franklin <slavo5150 yahoo.com> writes:
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
May 02 2019
prev sibling next sibling parent rumbu <rumbu rumbu.ro> writes:
On Friday, 3 May 2019 at 02:25:47 UTC, Mike Franklin wrote:


 it, not because it's a great language, but because of the .Net 
 Framework and its huge list of class libraries.  Take away the 

 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
May 02 2019
prev sibling next sibling parent reply JN <666total wp.pl> writes:
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 :)
May 03 2019
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
May 03 2019
parent reply rumbu <rumbu rumbu.ro> writes:
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
May 03 2019
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
May 03 2019
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Friday, 3 May 2019 at 07:45:33 UTC, JN wrote:

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

 [...]


 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.

 [...]


I'm not sure the Lisp curse would exist if a package manager had 
been part of the ecosystem from the beginning. Take D - anyone 
_could_ write their own parser library but basically everyone 
uses Pegged.
May 03 2019
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, May 03, 2019 at 04:23:25PM +0000, Atila Neves via Digitalmars-d wrote:

 On Friday, 3 May 2019 at 07:45:33 UTC, JN wrote:

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

 [...]


 
 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.
 
 [...]


 
 I'm not sure the Lisp curse would exist if a package manager had been
 part of the ecosystem from the beginning. Take D - anyone _could_
 write their own parser library but basically everyone uses Pegged.


Confession: I routinely write parser/lexer code, but I don't use Pegged.
I hang my head in shame.


T

-- 
When solving a problem, take care that you do not become part of the problem.
May 03 2019
prev sibling next sibling parent reply JN <666total wp.pl> writes:
On Friday, 3 May 2019 at 16:23:25 UTC, Atila Neves wrote:

 On Friday, 3 May 2019 at 07:45:33 UTC, JN wrote:

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

 [...]


 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.

 [...]


 I'm not sure the Lisp curse would exist if a package manager 
 had been part of the ecosystem from the beginning. Take D - 
 anyone _could_ write their own parser library but basically 
 everyone uses Pegged.


Well, Lisp curse applies mostly to language features. Imagine if 
Pegged required you to pull in "pegged-oop", "pegged-traits", 
"pegged-exceptions" and then you can't use throw because it 
doesn't support it, instead you have to do 
mixin(ExceptionHandler!((e) { writeln(e.toString()) })) to handle 
exceptions. That's what could occur if a language gives too much 
freedom and doesn't standarize on language features.
May 03 2019
parent reply Atila Neves <atila.neves gmail.com> writes:
On Friday, 3 May 2019 at 17:34:59 UTC, JN wrote:

 On Friday, 3 May 2019 at 16:23:25 UTC, Atila Neves wrote:

 On Friday, 3 May 2019 at 07:45:33 UTC, JN wrote:

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

 [...]


 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.

 [...]


 I'm not sure the Lisp curse would exist if a package manager 
 had been part of the ecosystem from the beginning. Take D - 
 anyone _could_ write their own parser library but basically 
 everyone uses Pegged.


 Well, Lisp curse applies mostly to language features.


I'm aware of that. The point that I was trying to make is that D 
has similar (but less powerful) features and there doesn't seem 
to be a D curse. I'm also arguing that I think nobody would have 
written about a Lisp curse either had it had a package manager 
back then. Or Github for that matter because it would have been 
easier to issue a pull request than write one's own library.



Imagine
 if Pegged required you to pull in "pegged-oop", 
 "pegged-traits", "pegged-exceptions"


But it doesn't, and if it did it'd be transparent to the user 
anyway.


 and then you can't use throw because it doesn't support it, 
 instead you have to do mixin(ExceptionHandler!((e) { 
 writeln(e.toString()) })) to handle exceptions. That's what 
 could occur if a language gives too much freedom and doesn't 
 standarize on language features.


Common Lisp and Scheme have standards so I don't know what you 
mean.
May 06 2019
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, May 06, 2019 at 12:34:07PM +0000, Atila Neves via Digitalmars-d wrote:

 On Friday, 3 May 2019 at 17:34:59 UTC, JN wrote:


[...]

 Imagine if Pegged required you to pull in "pegged-oop",
 "pegged-traits", "pegged-exceptions"




[...]

 and then you can't use throw because it doesn't support it, instead
 you have to do mixin(ExceptionHandler!((e) { writeln(e.toString())
 })) to handle exceptions. That's what could occur if a language
 gives too much freedom and doesn't standarize on language features.


 
 Common Lisp and Scheme have standards so I don't know what you mean.


[...]

I think what he means is if D came as a bare-bones, minimal language
without classes, exceptions, or foreach loops, but that's nevertheless
powerful enough to express all these missing language constructs. Then
since there is no standard way of implementing classes or exceptions,
but the language makes it very easy to do so because it's so powerful,
then everybody and his neighbour's dog will invent their own quirky way
of throwing exceptions, their own idiosyncratic style of implementing
classes, etc., and can do so in just a couple of hours.  It will be
great, until they need to interoperate with each other's code, at which
point they discover that their implementation of classes is
fundamentally incompatible with the other codebase's implementation, and
thus the Lisp Curse sets in and the only way to make things work is to
spend tons of time writing shim code to bridge the gap between the two.

OTOH, though, this assumes (1) there are multiple ways of implementing
feature X (classes, exceptions, what-have-you), and (2) each of these
ways are easy enough that most people would easily think of them, and it
would take very little effort to implement them.

If the core language were such that there's really only one obvious way
of implementing classes, then the fact that the language is "overly
powerful" wouldn't be a problem at all -- everyone would just invent the
same implementation of OO and it would Just Work(tm). Of course, this is
an idealistically optimistic view of how things might turn out, just as
the Lisp Curse is a pessimistic view of an "overly" powerful language.

Reality, in all likelihood, lies somewhere between these two extremes.


T

-- 
Mediocrity has been pushed to extremes.
May 07 2019
prev sibling parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Friday, 3 May 2019 at 16:23:25 UTC, Atila Neves wrote:

 Take D - anyone _could_ write their own parser library but 
 basically everyone uses Pegged.


I hadn't realised Pegged is that popular, but it actually sits at 
place 26 of 1551 total packages. That's surprisingly high for a 
parser generator, I don't think Flex/Bison holds a comparable 
position.

https://code.dlang.org/?sort=score&category=&skip=0&limit=26

Bastiaan.
May 03 2019
prev sibling next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.




others code.
May 03 2019
prev sibling parent Chris <wendlec tcd.ie> writes:
On Friday, 3 May 2019 at 02:25:47 UTC, Mike Franklin wrote:

[...]


 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


Yep. Look at this, for example, they're using a Kotlin based DSL:

[For Developers] https://furhat.io/

https://www.furhatrobotics.com/

I think D "has it all", but they can't see the wood for the 
trees. What D needs is a _clean_ and _stable_ implementation with 
a (small) set of the most powerful features. Add to this D's 
C/C++/ObjC interop and you have a very powerful tool. But you 
will need a proper tool chain too (something like Gradle). Have a 
look at Kotlin/Native where you have no JVM/Java libs available, 
it's already very powerful and Kotlin is nowhere near as bloated 
with features as D.
May 08 2019
prev sibling next sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
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.
May 02 2019
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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.
May 09 2019
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
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.
May 09 2019
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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.
May 18 2019
prev sibling next sibling parent reply Ron Tarrant <rontarrant gmail.com> writes:
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


I'd like to see Rails ported to D just because the name would be 
cool. :)
May 04 2019
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, May 04, 2019 at 02:08:48PM +0000, Ron Tarrant via Digitalmars-d wrote:

 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


 
 I'd like to see Rails ported to D just because the name would be cool. :)


Don't D-rail this discussion! ;-)


T

-- 
Тише едешь, дальше будешь.
May 04 2019
parent Ron Tarrant <rontarrant gmail.com> writes:
On Saturday, 4 May 2019 at 14:14:58 UTC, H. S. Teoh wrote:

 On Sat, May 04, 2019 at 02:08:48PM +0000, Ron Tarrant via



 I'd like to see Rails ported to D just because the name would 
 be cool. :)


 Don't D-rail this discussion! ;-)


<smirk mode>
May 04 2019
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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.
May 09 2019