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.

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.

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.

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.

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. :)

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

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

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>

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.

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.

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.