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