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.
