On Thursday, 14 March 2019 at 09:25:47 UTC, Seb wrote:
> On Wednesday, 13 March 2019 at 19:22:37 UTC, Francesco Mecca wrote:
>> On Wednesday, 13 March 2019 at 17:50:57 UTC, Seb wrote:
>>> [...]
>>> Though Phobos has been declared "stable" these days, which means that breaking changes can't be done anymore and if you're looking for sth. modern and nice, dub is the place these days.
>>> I wonder if we ever get to the point where we can replace Phobos with a modern standard library...
>>
>> https://github.com/wilzbach/hellas
>> Do you have any plans for this?
>
> Yes, I do (if I ever get time to get it).
> The rough outline is here:
>
> https://github.com/wilzbach/dts/issues
>
> The rough vision of dts is to remove the ugly bits of Phobos that we can't remove or change and make the design/structure more fitting.
> However, there are a few limiting language/runtime issues like D strings being used for exceptions etc.
>
> Anyhow, I should probably point out that Jonathan is pushing a more radical approach with Dragon:
>
> https://github.com/dragon-lang
>
> The main vision of Dragon is to do the radical D3 changes that would never be accepted in mainline dmd, see e.g.
>
> https://github.com/dragon-lang/dc/issues/43

That's interesting!

It is no secret that I am strongly in favor of the evolution of the library / language even with radical changes. And this implies that I am in favor of D3 + an evolution of Phobos.

Sociomantic has its own library, the same Weka, I would like a commercial effort to support and define D3 + Phobos.

Something similar to a common organized work group, very very pragmatic. If this thing were feasible, my company would be interested in contributing.

- Paolo

On Thursday, 14 March 2019 at 10:02:20 UTC, Paolo Invernizzi wrote:
> On Thursday, 14 March 2019 at 09:25:47 UTC, Seb wrote:
>> On Wednesday, 13 March 2019 at 19:22:37 UTC, Francesco Mecca wrote:
>>> On Wednesday, 13 March 2019 at 17:50:57 UTC, Seb wrote:
>>>> [...]
>>>> Though Phobos has been declared "stable" these days, which means that breaking changes can't be done anymore and if you're looking for sth. modern and nice, dub is the place these days.
>>>> I wonder if we ever get to the point where we can replace Phobos with a modern standard library...
>>>
>>> https://github.com/wilzbach/hellas
>>> Do you have any plans for this?
>>
>> Yes, I do (if I ever get time to get it).
>> The rough outline is here:
>>
>> https://github.com/wilzbach/dts/issues
>>
>> The rough vision of dts is to remove the ugly bits of Phobos that we can't remove or change and make the design/structure more fitting.
>> However, there are a few limiting language/runtime issues like D strings being used for exceptions etc.
>>
>> Anyhow, I should probably point out that Jonathan is pushing a more radical approach with Dragon:
>>
>> https://github.com/dragon-lang
>>
>> The main vision of Dragon is to do the radical D3 changes that would never be accepted in mainline dmd, see e.g.
>>
>> https://github.com/dragon-lang/dc/issues/43
>
> That's interesting!
>
> It is no secret that I am strongly in favor of the evolution of the library / language even with radical changes. And this implies that I am in favor of D3 + an evolution of Phobos.
>
> Sociomantic has its own library, the same Weka, I would like a commercial effort to support and define D3 + Phobos.
>
> Something similar to a common organized work group, very very pragmatic. If this thing were feasible, my company would be interested in contributing.
>
> - Paolo

To be frank, even though I'd love the idea of D3, I don't think it's just a matter of Phobos. Phobos is a victim of the underlying ideology of D, which is both it's blessing and a curse. That ideology is the idea that all paradigms are equal and every usecase should be supported. In languages like Java/C#, if someone asks how to do manual memory management, the answer is either "you can't" or "interop with C". In D, the answer is "oh, you can totally do that, just this won't work, and this is needed, and this will probably not compile, oh and no one tested that". It adds a lot of cognitive overhead, and unfortunately there are many points of division like that. @nogc/RC, GC, add to that -betterC too. Which one would a "new" Phobos support? I don't think you can support them all. You'd have to go for the lowest common denominator, which is @nogc, but if stdlib doesn't require a GC, what is the point of a GC at all. Especially since GC is an issue when porting D to Webassembly (need to use -betterC for that right now). I think if D3 was to be successful, it'd have to be a bit more opinionated. I don't mean the language has to become a OOP behemoth (I'd love that though haha) or a functional monadic transformer combinator, but it'd be nice to better define a scope of the language and be able to answer a question "Can D do XYZ?" with "No, it's not useful and you shouldn't do it this way".

Also, some language features seem dubious or hardly used at all. Does anyone really use contracts? I know they're sweet and Eiffel and everything, but does anyone ACTUALLY use them and doesn't stick to good old asserts? Perhaps rather than implementing (and supporting! each feature has to work well with other features which adds support overhead) such features, it'd be more useful to add features like struct initialization outside of assginments, which feels to me like a much nicer improvement to the language.

On Thu, Mar 14, 2019 at 09:32:21PM +0000, JN via Digitalmars-d wrote: [...]
> I think if D3 was to be successful, it'd have to be a bit more opinionated. I don't mean the language has to become a OOP behemoth (I'd love that though haha) or a functional monadic transformer combinator, but it'd be nice to better define a scope of the language and be able to answer a question "Can D do XYZ?" with "No, it's not useful and you shouldn't do it this way".

TBH I like the fact that D is not OOP-centric, because IMNSHO OOP is overhyped far beyond its usefulness.  It has its place, but shoehorning everything into an OO paradigm just because it's the cool thing to do, is silly and leads to stupidity like singleton classes (nothing more than politically-correct euphemism for global functions and global variables) and excessive boilerplate.

And I like the fact that you can write functional-like code in D without being bound in the straitjacket of strict functional purity and immutable values.  Again, such a thing is useful for certain things and has its place, but I'd hate to be forced to write *everything* that way just because the language dictates so.

One reason I chose to use D over other languages is because I'm sick and tired of opinionated languages dictating what I can or cannot do. I want to be able to what makes sense for the problem domain, not to waste time fighting with a language insists that I have to do it Their Way or the highway.

I think a lot of the perceived complexity problems in D come from later additions that invalidate earlier assumptions.  For example, the core language was originally designed with the GC being an inherent part of it, and the foundations of Phobos were laid upon that assumption.  Then the no-GC crowd clamored and clamored for @nogc, so they got @nogc, and suddenly we realized that Phobos was completely incompatible with @nogc, and core language features like arrays, AA's, and exceptions didn't play nice with it too.  But since @nogc is now officially supported, people inevitably clamored for @nogc code to be put on equal footing with GC-reliant code.  Hence a lot of churn just to "liberate" Phobos from the GC. And anyone who has worked with "enterprise" code knows what happens when a foundational assumption of a large, entrenched codebase is invalidated: an explosion of code complexity, special cases, and a labyrinth of dark corners for bugs to hide in.

Similarly, before the range-based idiom entered into the language, you have things like std.string and std.array with freely-allocating functions.  In order to retain backward compatibility, a lot of range functions with similar semantics had to be named differently, leading to ugly names like .joiner (rather than .join), .splitter (rather than .split), and so on.

Had all these features been integrated into the original language design, these special cases and complexities would not be like they are today.

OTOH, though, these twists and turns in the development of the language are also an integral part of what it is; UFCS, for example, came about from a clever hack added in order to make built-in arrays compatible with the then newly-introduced range API. Later on, people clamored for this "hack" to be extended to other types and become officially accepted. It was a huge success IMO. Nowadays, I can't imagine writing D code without UFCS.

But still, you can see the seams where UFCS didn't quite fit with the original core language, e.g., the way it interacts with cross-module symbol resolution, operator overloading, etc..

Redesigning the language with all these things built into its core would eliminate these special cases. But it would also be a huge, monumental task, because each of these features, simple in appearance, actually imply a vast amount of complexity. No thanks to combinatorial explosion, any non-trivial set of features inevitably has unexpected corner cases that may behave differently from what one might expect, and the desire to cater to human intuition is always at odds with making the language simpler and more orthogonal.


> Also, some language features seem dubious or hardly used at all. Does anyone really use contracts? I know they're sweet and Eiffel and everything, but does anyone ACTUALLY use them and doesn't stick to good old asserts?

I do.  They're useful for documenting the intent of APIs, whereas I generally use asserts for internal, implementation-specific assumptions.


> Perhaps rather than implementing (and supporting! each feature has to work well with other features which adds support overhead) such features, it'd be more useful to add features like struct initialization outside of assginments, which feels to me like a much nicer improvement to the language.

What do you mean by struct initialization outside of assignments? D already supports struct initialization syntax of the form S(...) inside expressions.


T

-- 
Those who don't understand D are condemned to reinvent it, poorly. -- Daniel N

On Thursday, 14 March 2019 at 23:06:19 UTC, H. S. Teoh wrote:
> What do you mean by struct initialization outside of assignments? D already supports struct initialization syntax of the form S(...) inside expressions.

https://github.com/dlang/DIPs/pull/71

On 3/14/19 5:32 PM, JN wrote:
> Also, some language features seem dubious or hardly used at all. Does anyone really use contracts? I know they're sweet and Eiffel and everything, but does anyone ACTUALLY use them and doesn't stick to good old asserts? Perhaps rather than implementing (and supporting! each feature has to work well with other features which adds support overhead) such features, it'd be more useful to add features like struct initialization outside of assginments, which feels to me like a much nicer improvement to the language.

FWIW as a new-ish D programmer I used contracts to great effect to quickly write an interval tree library (which I will release soon). The contracts mechanism sped development tremendously, as well as caught several subtle edge-case errors that would have been nightmare to find without.

That being said, I would love struct initialization ...

On Thursday, 14 March 2019 at 21:32:21 UTC, JN wrote:
> On Thursday, 14 March 2019 at 10:02:20 UTC, Paolo Invernizzi wrote:
>> On Thursday, 14 March 2019 at 09:25:47 UTC, Seb wrote:
>>> [...]
>>
>> That's interesting!
>>
>> It is no secret that I am strongly in favor of the evolution of the library / language even with radical changes. And this implies that I am in favor of D3 + an evolution of Phobos.
>>
>> Sociomantic has its own library, the same Weka, I would like a commercial effort to support and define D3 + Phobos.
>>
>> Something similar to a common organized work group, very very pragmatic. If this thing were feasible, my company would be interested in contributing.
>>
>> - Paolo
>
> To be frank, even though I'd love the idea of D3, I don't think it's just a matter of Phobos. Phobos is a victim of the underlying ideology of D, which is both it's blessing and a curse. That ideology is the idea that all paradigms are equal and every usecase should be supported. In languages like Java/C#, if someone asks how to do manual memory management, the answer is either "you can't" or "interop with C". [...]

In Java the answer has also been user java.nio.Buffer, and it will be improved when value types finally become a thing.

In C#, it has always been a thing since the early days via System.Runtime.InteropServices.Marshal and value types, improved later via SafeHandle, since C# 7.x, Midori style stack and manual memory allocation alongside slices and channels.

C# 8 will bring syntax sugar for slices.

--
Paulo

On Thursday, 14 March 2019 at 21:32:21 UTC, JN wrote:
> In D, the answer is "oh, you can totally do that, just this won't work, and this is needed, and this will probably not compile, oh and no one tested that". It adds a lot of cognitive overhead, and unfortunately there are many points of division like that.

@nogc is inherently cognitive overhead.

On Thu, Mar 14, 2019 at 11:23:35PM +0000, Seb via Digitalmars-d wrote:
> On Thursday, 14 March 2019 at 23:06:19 UTC, H. S. Teoh wrote:
> > What do you mean by struct initialization outside of assignments? D already supports struct initialization syntax of the form S(...) inside expressions.
> 
> https://github.com/dlang/DIPs/pull/71
[...]

Ah I see. Well it's a minor syntactic convenience, and we do already support ctor calls (albeit without the ability to explicitly name fields), so I don't consider it a major point at all.  But certainly nice to have.


T

-- 
Some ideas are so stupid that only intellectuals could believe them. -- George Orwell

On Thursday, 14 March 2019 at 21:32:21 UTC, JN wrote:
> Perhaps rather than implementing (and supporting! each feature has to work well with other features which adds support overhead) such features, it'd be more useful to add features like struct initialization outside of assginments, which feels to me like a much nicer improvement to the language.

The problem when designing a language, is that *everyone* says "Stop wasting your time maintaining [feature I don't use], nobody cares about it. You should implement [feature that I want] instead, the language would be more popular that way!", but nobody can agree on which features are the "good" ones.

Eg, some people will say that -betterC is almost useless and we should stop worrying about it, while other people would stop using D if it didn't have that flag.

On 2019-03-14 22:32, JN wrote:

> To be frank, even though I'd love the idea of D3, I don't think it's just a matter of Phobos. Phobos is a victim of the underlying ideology of D, which is both it's blessing and a curse. That ideology is the idea that all paradigms are equal and every usecase should be supported. In languages like Java/C#, if someone asks how to do manual memory management, the answer is either "you can't" or "interop with C". In D, the answer is "oh, you can totally do that, just this won't work, and this is needed, and this will probably not compile, oh and no one tested that". It adds a lot of cognitive overhead, and unfortunately there are many points of division like that. @nogc/RC, GC, add to that -betterC too. Which one would a "new" Phobos support? I don't think you can support them all. You'd have to go for the lowest common denominator, which is @nogc, but if stdlib doesn't require a GC, what is the point of a GC at all. 

This can be solved by pushing the allocation up the call stack. Instead of having a function allocate memory, pass a buffer, delegate, output range or something similar to the function. Then whatever you pass can decide if it should allocate using the GC, malloc or something else.

This will make the API not as nice to work with. But a layer on top of that can be built with a default allocation strategy. I would suggest the default allocation strategy to be the GC. If someone doesn't want to use the GC he/she can use the layer below and decide how the allocation should be done.

> Also, some language features seem dubious or hardly used at all. Does anyone really use contracts? I know they're sweet and Eiffel and everything, but does anyone ACTUALLY use them and doesn't stick to good old asserts? Perhaps rather than implementing (and supporting! each feature has to work well with other features which adds support overhead) such features, it'd be more useful to add features like struct initialization outside of assginments, which feels to me like a much nicer improvement to the language.

I use contracts. But with the current implementation it's only a syntactic difference between an in-contract and a regular assert inside the function body. Instead, the in-contract should be called by the caller, not the callee.

-- 
/Jacob Carlborg