Why is `scope` planned for deprecation?

[via Digitalmars-d]

On Thursday, 20 November 2014 at 21:55:16 UTC, deadalnix wrote:
> All of this is beautiful until you try to implement a quicksort
> in, haskell.
>
> It is not that functional programming is bad (I actually like it
> a lot) but there are problem where it is simply the wrong tool.

Sure, I am not arguing in favour of functional programming. But 
it is possible to define a tight core language (or VM) with the 
understanding that all other "high level" constructs have to be 
expressed within that core language in the compiler internals. 
Then you can do all the analysis on that small critical subset of 
constructs. With this approach you can create/modify all kinds of 
convenience features without affect the core semantics that keeps 
it sounds and clean.

Take for instance the concept of isolates, which I believe we 
both think can be useful. If the concept of an 
isolated-group-of-objects it is taken to the abstract level and 
married to a simple core language (or VM) in a sound way, then 
the more complicated stuff can hopefully be built on top of it. 
So you get a bottom-up approach to the language that meets the 
end user. Rather than what happens now where feature requests 
seem to be piled on top-down, they ought to be "digested" into 
something that can grow bottom-up. I believe this is what you try 
to do with your GC proposal.

> Obviously, this has a major drawback in the fact you cannot say
> to everybody that your favorite style is the one true thing that
> everybody must use. That is a real bummer for religious zealot,
> but actual engineers understand that this is a feature, not a 
> bug.

Well, I think this holds:

1. Good language creation goes bottom-up.
2. Good language evaluation goes top-down.
3. Good language design is a circular process between 1  and 2.

In essence having a tight "engine" is important (the bottom), but 
you also need to understand the use context and how it will be 
used (the top).

In D the bottom-part is not so clear and could need a cleanup, 
but then the community would have to accept the effects of that 
propagate to the top.

Without defining some use contexts for the language I think the 
debates get very long, because without "data" you cannot do 
"analysis" and then you end up with "feels right to me" and that 
is not engineering, it is art or what you are used to. And, there 
are more good engineers in the world than good artists…

If one can define a single use scenario that is demanding enough 
to ensure that an evaluation against that scenario also will work 
for the other less demanding scenarios, then maybe some more 
rational discussions about the direction of D as language could 
be possible and you could leave out say the 10% that are less 
useful. When everybody argues out from their own line of work and 
habits… then they talk past each other.