Phobos - breaking existing code

[via Digitalmars-d]

On Saturday, 29 November 2014 at 12:08:08 UTC, bearophile wrote:
> Those "scripting" needs are real, and rather common. Those high 
> level things are worth having in Phobos. On the other hand it's 
> also reasonable to desire something more fit for a lower level 
> kind of coding. One solution is to split Phobos in two groups 
> of functions, for the two usages (and to forbid the lower level 
> functions to call the high level ones), and ship the compiler

"scripting" needs depend on the application area, the core 
standard library should only contain the most commonly needed 
functionality that will work for all applications.

With a big standard library you get this effect:

big monolithic standard library -> other libraries build on it -> 
many libraries are unsuitable for more restricted applications

big monolithic standard library -> hard to keep bug free, 
performant and makes language changes more difficult

What you want is this:

tight standard library -> other libraries build on it if they 
can-> more libraries are suitable for all applications

tight standard library -> high degree of stability -> less 
breakage of other libraries

tight standard library -> better results for library-aware 
optimizations

Then you can have a second optional profile for more unstable 
scripty libraries, a standardized "extras".


> with both parts. There is already "Phobos core", but I don't 
> know if its meaning is the same as you desire (probably not).

No, I think a lot of what is in "core" is really things that 
should either be in the language or as compiler intrinsics that 
the optimizer can deal with.


> Clearly D is not a "better C", it's a "better C++/Java". You 
> can use D as a "better C" but this needs some adaptation, both 
> for you and the libraries.

Yes, but if you can look at D1 as being between C/C++ with GC. I 
think that is a comfortable spot, if you remove the stuff that 
the implies a mandatory GC.

I think D2 is better off by focusing on stability, evolving in 
radical changes is difficult. So the more rational approach is to 
look at the possibility for a D3 on paper and spec a core 
language that is GC-free, but which can have a more "scripty" 
GCish profile built on top of it.

When you have that, it become easier to improve D2 too, because 
you have something (hopefully) coherent to compare D2 against.

If you have something (on paper) that as a whole is a lot more 
consistent than D2 then maybe it will be more convincing than 
arguing tiny feature improvements in isolation. Because those 
tiny improvements might not seem to be worth it alone. But a new 
holistic design that captures a lot of the current practice in a 
cleaner way is going to be much harder to pass on.

> As usual in open source a good way to do things is to start 
> them yourself and look at how many persons are interested.

Sure, I have for many years sketched out various on-paper-designs 
for languages, I am sure many others do to. The problem is 
finding common ground since people have different programming 
styles, experiences and different level of theoretical 
understanding. By starting with D1/D2 as a common ground it might 
be possible to create a paper spec for a tiny-D3 that could both 
support a reduced system language profile and later support an 
extended "scripty" profile.


> But from what I'm seeing Rust is putting itself at a level 
> lower than D, with all its care for its "no runtime", it even 
> has annotations and standard library sections for this kind of 
> usage.

The problem (and advantage) with opinionated languages like Rust 
and Go is that they restrict their application area. I also feel 
that the GC'ed D is constraining, but less so than Rust and Go. 
Ada is also a well rounded language, but it is a bit verbose for 
smaller projects. So I think there is an open spot for a 
streamlined D'ish language between C/C++ with some of the 
qualities of Ada/Go/Rust/etc.

I don't think D is easy to streamline by evolution alone. If you 
want to arrive at something coherent you need to create 
abstractions over existing idioms in D programming (interpret 
current practice through theory) and not create abstractions over 
the language and libraries (the actual code).