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.

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.

On 11/20/2014 1:55 PM, 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.
> 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.

Monads!

On Thursday, 20 November 2014 at 22:47:27 UTC, Walter Bright wrote:
> On 11/20/2014 1:55 PM, deadalnix wrote:
>> All of this is beautiful until you try to implement a quicksort
>> in, haskell.

[…]

> Monads!

I think Deadalnix meant that you cannot do in-place quicksort easily in Haskell. Non-mutating quicksort is easy, no need for monads:

quicksort []     = []
quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort greater)
    where
        lesser  = filter (< p) xs
        greater = filter (>= p) xs

https://www.haskell.org/haskellwiki/Introduction#Quicksort_in_Haskell

You are a goalspot shifting champion, aren't you ?

On Thursday, 20 November 2014 at 23:22:40 UTC, deadalnix wrote:
> You are a goalspot shifting champion, aren't you ?

Nope, it follows up your line of argument, but the screwdriver/hammer metaphor is not a good one.

You can implement your hammer and your screwdriver at the top if you have a lower level screwdriver/hammer-components at the bottom. That is the good.

Piling together hammers and screwdrivers and hoping that nobody are going to miss the remaining 35% involving glue and tape… That is bad.

On 11/20/2014 3:10 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Thursday, 20 November 2014 at 22:47:27 UTC, Walter Bright wrote:
>> On 11/20/2014 1:55 PM, deadalnix wrote:
>>> All of this is beautiful until you try to implement a quicksort
>>> in, haskell.
>
> […]
>
>> Monads!
>
> I think Deadalnix meant that you cannot do in-place quicksort easily in Haskell.

That's correct.

> Non-mutating quicksort is easy, no need for monads:
>
> quicksort []     = []
> quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort greater)
>      where
>          lesser  = filter (< p) xs
>          greater = filter (>= p) xs
>
> https://www.haskell.org/haskellwiki/Introduction#Quicksort_in_Haskell

Except that isn't really quicksort. Monads are the workaround functional languages use to deal with things that need mutation.

On Friday, 21 November 2014 at 01:09:27 UTC, Walter Bright wrote:
> Except that isn't really quicksort. Monads are the workaround functional languages use to deal with things that need mutation.

Yes, at least in Haskell, but I find monads in Haskell harder to read than regular imperative code. You can apparently cheat a little using libraries, this doesn't look too bad (from slashdot):

import qualified Data.Vector.Generic as V
import qualified Data.Vector.Generic.Mutable as M

qsort :: (V.Vector v a, Ord a) => v a -> v a
qsort = V.modify go where
    go xs | M.length xs < 2 = return ()
          | otherwise = do
            p <- M.read xs (M.length xs `div` 2)
            j <- M.unstablePartition (< p) xs
            let (l, pr) = M.splitAt j xs
            k <- M.unstablePartition (== p) pr
            go l; go $ M.drop k pr


http://stackoverflow.com/questions/7717691/why-is-the-minimalist-example-haskell-quicksort-not-a-true-quicksort

On 11/20/2014 5:27 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Friday, 21 November 2014 at 01:09:27 UTC, Walter Bright wrote:
>> Except that isn't really quicksort. Monads are the workaround functional
>> languages use to deal with things that need mutation.
>
> Yes, at least in Haskell, but I find monads in Haskell harder to read than
> regular imperative code.

Exactly my point (and I presume deadalnix's, too).

On 11/20/14 5:09 PM, Walter Bright wrote:
> On 11/20/2014 3:10 PM, "Ola Fosheim Grøstad"
> <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>> On Thursday, 20 November 2014 at 22:47:27 UTC, Walter Bright wrote:
>>> On 11/20/2014 1:55 PM, deadalnix wrote:
>>>> All of this is beautiful until you try to implement a quicksort
>>>> in, haskell.
>>
>> […]
>>
>>> Monads!
>>
>> I think Deadalnix meant that you cannot do in-place quicksort easily
>> in Haskell.
>
> That's correct.
>
>> Non-mutating quicksort is easy, no need for monads:
>>
>> quicksort []     = []
>> quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort greater)
>>      where
>>          lesser  = filter (< p) xs
>>          greater = filter (>= p) xs
>>
>> https://www.haskell.org/haskellwiki/Introduction#Quicksort_in_Haskell
>
> Except that isn't really quicksort. Monads are the workaround functional
> languages use to deal with things that need mutation.

As I like to say, this troika has inflicted a lot of damage on both FP and those beginning to learn it:

* Linear-space factorial
* Doubly exponential Fibonacci
* (Non)Quicksort

These losers appear with depressing frequency in FP introductory texts.


Andrei