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
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. 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
May 02
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
prev sibling next sibling parent rumbu <rumbu rumbu.ro> writes:
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
May 02
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
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
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
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
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
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
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
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
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
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
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. 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.
May 03
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
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
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
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
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
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
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
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
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