Why is `scope` planned for deprecation?

[deadalnix via Digitalmars-d]

On Thursday, 20 November 2014 at 21:26:18 UTC, Ola Fosheim
Grøstad wrote:
> On Thursday, 20 November 2014 at 20:15:03 UTC, deadalnix wrote:
>> Many language make the mistake of thinking something is the 
>> holly
>> grail, be it OOP, functional programming or linear types. I do
>> think that it is a better engineering solution to provide a
>> decent support for all of theses, and doing so we don't need to
>> get them handle 100% of the case, as we have other language
>> construct/paradigm that suit better difficult cases anyway.
>
> FWIW, among language designers it is usually considered a 
> desirable trait to have orthogonality between constructs and 
> let them be combinable in expressive ways. This reduce the 
> burden on the user who then only have to truly understand the 
> key concepts to build a clear mental image of the semantic 
> model. Then you can figure out ways to add syntactical sugar if 
> needed.
>
> Having a smaller set of basic constructs makes it easier to 
> prove correctness, which turn is important for optimization 
> (which depends on the ability to prove equivalence over the 
> pre/post semantics). It makes it easier to prove properties 
> such as "@(un)safe". It also makes it easier to later extend 
> the language.
>
> Just think about all the areas "fibers" in D affect. It affects 
> garbage collection and memory handling. It affects the ability 
> to do deep semantic analysis. It affects implementation of fast 
> multi-threaded ADTs. One innocent feature can have a great 
> impact.
>
> Providing a 70% solution like Go is fine as they have defined a 
> narrow domain for the language, servers, thus as a programmer 
> you don't hit the 30% they left out.
>
> But D has not defined narrow use domain, so as a designer you 
> cannot make up a good rationale for which 15-30% to leave out. 
> Design is always related to a specific use scenario.
>
> (I like the uncanny valley metaphor, had not thought about 
> using it outside 3D. Cool association!)

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.
Once you acknowledge that, you have 2 road forward :
   - You create bizarre features to implement quicksort in a
functional way. Tge concept become more complex, but some expert
guru will secure their job.
   - Keep your functional feature as they are, but allow for other
styles, which cope better with quicksort.

The situation 2 is the practical one. There is no point in
creating an ackward hammer that can also screw things if I can
have a hammer and a screwdriver.

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.