January 14, 2019
On Monday, 14 January 2019 at 07:50:32 UTC, Walter Bright wrote:
> On 1/13/2019 9:31 PM, Paul Backus wrote:
>> Scheme is probably the language that takes this idea of a minimal "core language" with powerful metaprogramming facilities the furthest, and the result is a fragmented ecosystem that makes writing portable, non-trivial programs close to impossible. (See "The Lisp Curse" [1].)
>> 
>> When something like an object system is made part of the language (or at the very least, the standard library), it becomes a focal point [2] that the community can coordinate around. Due to the diverse, distributed nature of any programming-language community, trying to coordinate through explicit communication is not really a viable option, so having these kinds of focal points is very important if we want to be able to work together on anything.
>> 
>> [1] http://winestockwebdesign.com/Essays/Lisp_Curse.html
>> [2] https://en.wikipedia.org/wiki/Focal_point_(game_theory)
>
> Interesting cites, which provide a basis for why I've opposed AST macros, and why Ddoc and unittest are builtin (and a few other things).
>
> Also, before std::string came along in C++, everyone invented their own string class, and as a result, nobody could share code.

This is exactly the argument to get a database driver (mysql,postgres...) and probably a webserver in std.

But to avoid getting std.lib to big, the D Foundation might adopt some third party libs as core libraries, so they get maintained within the D Foundation Git account to make them somehow official.

We are now approaching the 1500 Dub package, and the ecosystem becomes more and more complex.

(https://code.dlang.org/  1482 packages: The search for mysql now returns 23 packages. Please tell me which to use for the back end, of your own vibe.d app. I give you 5 minutes...:-)
Regards mt.
January 14, 2019
On Monday, 14 January 2019 at 05:31:27 UTC, Paul Backus wrote:
> [1] http://winestockwebdesign.com/Essays/Lisp_Curse.html

This part always feels familiar to me in D (just replace Lisp with D and Haskell with say Rust):

Answer: 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. Some will show great promise before being abandoned while the project maintainer goes off to pay his bills. Several will beat Haskell along this or that dimension (again, a different one in each case), but their acceptance will be hampered by flame wars on the comp.lang.lisp Usenet group.

also this one:

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.
January 14, 2019
On Monday, 14 January 2019 at 10:06:48 UTC, Mike Franklin wrote:
> On Monday, 14 January 2019 at 05:31:27 UTC, Paul Backus wrote:
>
>> When something like an object system is made part of the language (or at the very least, the standard library), it becomes a focal point [2] that the community can coordinate around. Due to the diverse, distributed nature of any programming-language community, trying to coordinate through explicit communication is not really a viable option, so having these kinds of focal points is very important if we want to be able to work together on anything.
>>
>> [1] http://winestockwebdesign.com/Essays/Lisp_Curse.html
>> [2] https://en.wikipedia.org/wiki/Focal_point_(game_theory)
>
> I think D's structs are a sufficient object system for such a focal point.  With design by introspection, `alias`, templates, `alias this`, `static if`, CTFE, mixins, and a few new D features, classes would be unnecessary.  Rust and Zig are pretty good examples of this.

Do people really use Rust in production beyond the safety die hards (of course Mozilla and few uses here and there, mostly C guys...lowlevel purists)? Its such a weird,complicated and academic lang... doubt it'll ever be mainstream like D is supposed to be.

January 14, 2019
On Monday, 14 January 2019 at 13:07:35 UTC, aberba wrote:
> Do people really use Rust in production beyond the safety die hards (of course Mozilla and few uses here and there, mostly C guys...lowlevel purists)? Its such a weird,complicated and academic lang... doubt it'll ever be mainstream like D is supposed to be.

Actually, a lot of people do. Many big companies are getting interested in Rust and many game developers are investigating its capabilities. Rust seems to be mostly appealing to C/C++ programmers who are looking for an alternative.
January 14, 2019
On 1/14/19 5:18 AM, Martin Tschierschke wrote:
> On Monday, 14 January 2019 at 07:50:32 UTC, Walter Bright wrote:
>> On 1/13/2019 9:31 PM, Paul Backus wrote:
>>> Scheme is probably the language that takes this idea of a minimal "core language" with powerful metaprogramming facilities the furthest, and the result is a fragmented ecosystem that makes writing portable, non-trivial programs close to impossible. (See "The Lisp Curse" [1].)
>>>
>>> When something like an object system is made part of the language (or at the very least, the standard library), it becomes a focal point [2] that the community can coordinate around. Due to the diverse, distributed nature of any programming-language community, trying to coordinate through explicit communication is not really a viable option, so having these kinds of focal points is very important if we want to be able to work together on anything.
>>>
>>> [1] http://winestockwebdesign.com/Essays/Lisp_Curse.html
>>> [2] https://en.wikipedia.org/wiki/Focal_point_(game_theory)
>>
>> Interesting cites, which provide a basis for why I've opposed AST macros, and why Ddoc and unittest are builtin (and a few other things).
>>
>> Also, before std::string came along in C++, everyone invented their own string class, and as a result, nobody could share code.
> 
> This is exactly the argument to get a database driver (mysql,postgres...) and probably a webserver in std.

I don't like the idea of it, because there are so many approaches. Even different approaches among one server protocol.

> 
> But to avoid getting std.lib to big, the D Foundation might adopt some third party libs as core libraries, so they get maintained within the D Foundation Git account to make them somehow official.
> 
> We are now approaching the 1500 Dub package, and the ecosystem becomes more and more complex.

This is true, I searched yesterday for a decimal package that fits my use case (I'm getting decimal numbers as strings in a JSON library, with no limits as to what number of decimal places are supported). There were probably 4 or 5 that implement the general concept of a decimal type, but I was faced with a couple issues:

1. Is it maintained? Some of them are really old, some are old-ish, but could potentially be pretty stable
2. Does it have all the features I want? I am hesitant at this point to select something that has overflow problems, because I don't actually know how much would be too much.

With one central package, I can be sure that 1 is answered, but then I don't actually have any choices for whether it works for me or not. If it doesn't implement the features I want (basically, I want completely arbitrary precision AND number of digits), then I still have to roll my own.

Some packages are hard to solve every, if not most, requirements. Really that should be the defining feature of whether it goes into the standard library.

> (https://code.dlang.org/  1482 packages: The search for mysql now returns 23 packages. Please tell me which to use for the back end, of your own vibe.d app. I give you 5 minutes...:-)
> Regards mt.

That's a bad example :) The clear answer is mysql-native, which is what vibe.d recommends.

-Steve
January 14, 2019
On Monday, 14 January 2019 at 05:31:27 UTC, Paul Backus wrote:

> Scheme is probably the language that takes this idea of a minimal "core language" with powerful metaprogramming facilities the furthest, and the result is a fragmented ecosystem that makes writing portable, non-trivial programs close to impossible. (See "The Lisp Curse" [1].)

Much as I hate to disagree with folks on the internet, this is an explanation in search of an example. Scheme was originally created as a toy language so Steele and Sussman could have an object oriented language with actors.[1] It later turned out to be a good language for SICP. Macros did not even appear in the Scheme standard until R4RS, and they were not part of the standard until R5RS in 1998, 23 years after initial work started on Scheme. That's not to say that individual implementations didn't have Common Lisp macros prior to R5RS, but the metaprogramming thing was more of a Common Lisp thing than a Scheme thing.

To me, it's obvious why Scheme has never taken off. It wasn't created as a language for widespread commercial usage. That was the realm of Common Lisp, and to some extent Common Lisp succeeded. CL was not killed by excessive use of macros.

I'll also note that R started as a dialect of Scheme, but it was designed for practical use from the start, and it has millions of users. D has little hope of ever achieving the popularity of R. You can do all kinds of metaprogramming with R. I got tired of R's lack of proper tail call support, so added a working implementation of Clojure's recur in a couple of hours.

Extrapolating from Scheme to D is simply not the best use of one's time.

[1] See page 33 of https://dreamsongs.com/Files/HOPL2-Uncut.pdf
January 14, 2019
On Monday, 14 January 2019 at 03:58:37 UTC, Mike Franklin wrote:

> Because design by introspection allows us to "assemble programs atomically", perhaps high-level language features like classes and interfaces can become obsolete, and the language itself can be reduced simpler primitives that don't require the overhead of a runtime.

Only a small sliver of programming involves anything where "overhead of a runtime" is an issue. I hope you intend this comment as pertaining to Better C usage.
January 14, 2019
On Monday, 14 January 2019 at 10:06:48 UTC, Mike Franklin wrote:
> On Monday, 14 January 2019 at 05:31:27 UTC, Paul Backus wrote:
>
>> When something like an object system is made part of the language (or at the very least, the standard library), it becomes a focal point [2] that the community can coordinate around. Due to the diverse, distributed nature of any programming-language community, trying to coordinate through explicit communication is not really a viable option, so having these kinds of focal points is very important if we want to be able to work together on anything.
>>
>> [1] http://winestockwebdesign.com/Essays/Lisp_Curse.html
>> [2] https://en.wikipedia.org/wiki/Focal_point_(game_theory)
>
> I think D's structs are a sufficient object system for such a focal point.  With design by introspection, `alias`, templates, `alias this`, `static if`, CTFE, mixins, and a few new D features, classes would be unnecessary.  Rust and Zig are pretty good examples of this.
>
> D's implementation could even be improved to keep its runtime, yet still allow D to be used as I'm suggesting, without introducing any breakage for anyone.  I made some significant progress in that direction when I was working on the compiler in the 2017~2018 timeframe, but my abilities ultimately fell short, and I couldn't see a way forward without support.
>
> Mike

Killing classes will kill my interest and investment in D.
Alex.
January 14, 2019
On Monday, 14 January 2019 at 14:56:00 UTC, bachmeier wrote:
> Only a small sliver of programming involves anything where "overhead of a runtime" is an issue. I hope you intend this comment as pertaining to Better C usage.

Real D is the true better C. These improvements can improve in various situations.

That said though, I'd be against removing built-in classes and interfaces. They are useful in a lot of places built in... though I kinda wish the runtime code was a bit thinner and lighter too.
January 14, 2019
On 1/14/19 10:57 AM, Adam D. Ruppe wrote:
> On Monday, 14 January 2019 at 14:56:00 UTC, bachmeier wrote:
>> Only a small sliver of programming involves anything where "overhead of a runtime" is an issue. I hope you intend this comment as pertaining to Better C usage.
> 
> Real D is the true better C. These improvements can improve in various situations.
> 
> That said though, I'd be against removing built-in classes and interfaces. They are useful in a lot of places built in... though I kinda wish the runtime code was a bit thinner and lighter too.

Some of the old crufty features of classes can be jettisoned like toString and toHash, and object.factory.

-Steve