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.
