language_fan wrote:
On Sun, 04 Oct 2009 04:28:35 -0500, Andrei Alexandrescu wrote:
language_fan wrote:
On Sat, 03 Oct 2009 16:39:29 -0400, Justin Johansson wrote:
People might remember that when I picked up D and joined this forum
just some 3 or so weeks ago I made mention of being a Scala
refugee.*** When asked what I didn't like about Scala I commented
about there being too many language constructs.
Compared to D that is not even true. The Scala language spec lists 40
keywords + 10 additional reserved tokens. D 2.0 spec lists 106 keywords
+ a bit over 60 reserved tokens. In general there are no features in
Scala that are not built around those keywords and tokens. The keywords
and token are not more heavily overloaded than in D, on the contrary in
my subjective opinion.
So how I see things is that the language core in Scala is about 75%
smaller, faster to learn, and easier to reason about. I have to admit
that the features often are more powerful than in D. You need to
recognize concepts like contra/co/invariance, higher order functions
and kinds, and algebra that is based on terms discussed in lambda
calculus books.
I agree that a hemorrhage of keywords is of dubious value, and Walter
has been much more generous with keywords than I would have ever liked.
Assuming you're not hanging out in this group just to feel smug: what
steps do you think we could take to make D a better language than it
currently is?
I would concentrate on combining and generalizing the core constructs and
types to cut down language complexity. Starting from basic algebraic
facts, D lacks built-in first class sum and product types. Higher order
type operators also feel like a hack. The level of orthogonality is often
very poor -- this is the result of the uncontrolled language evolution. D
was not designed to be very orthogonal in these respects. Practical
languages are rarely built with types in mind. Same applies to rationale
behind built-in meta-properties of types and free function like
constructs.
Well this is a bit vague to act on. So, you say D lacks built-in
first-class sum and product types. Yet Tuple is a product type. In spite
of appearances, it's a built-in type, just that it has no literal. I
don't see that a deal breaker. Then I fail to find fault for Algebraic
(in std.variant) as a sum type. I need to add visitation to it, but
other than that I don't think Algebraic is worse than a built-in type.
I agree that the language is unorthogonal but realistically there isn't
a lot we can do about that now.
Even though templates and string mixins provide some kind of macro
facility, I would like to offer something more Scheme like, with Template
Haskell like flavor. String mixins are powerful, but unfortunately they
do not provide any kind of meta-level type system. As a result the
compile errors on the wrong abstraction level. It also fails at capturing
symbol references in a nicely scoped manner. Andrei, I remember you also
suggested all kinds of macro systems, but the discussion died ages ago.
It hasn't died. We just concluded that it would take many months to
define and implement a decent macro system. We also had a ton of other
things to do, so we decided macros have to wait.
In OOP I have found Scala and some prototype based OOP languages to
behave in the most elegant way. You should read the OOP articles by
Odersky. For instance, try to find a solution to the Node-Edge subtyping
problem in D. Experiment with traits to see how powerful they are. Try to
find justifications for the lack of genuine new features of Scala (self
types, etc.).
I am very familiar with much of Odersky's work and have a lot of respect
for it. But then Walter created D and has brought his world view in D,
not someone else's. We can't go like, hey, let's wheelbarrow whatever's
good in language X into D. That's why I specifically asked "what steps
we need to take" hoping for much more detail and aim at integration than
"Scala is good".
Regarding the Node-Edge subtyping problem, I'd appreciate a link. The
first relevant result returned by Google is your own post :o). Is this
relevant?
http://www.jot.fm/issues/issue_2008_06/article3.pdf
I cannot foretell how changing the low level abstractions changes the
overall look and feel. Probably some constructs become unnecessary,
others will remain. I do not have the skills to build a full language
that works optimally in all possible ways.
I guess you're in good company - nobody quite does.
The keyword comparison was a bit unfair. I find it acceptable for a lower
level language to have a bit more keywords since there are many hardware
capabilities that need to have a mapping on the language level.
I don't know. I agree that D's relative abundance of keywords doesn't
seem to be a huge problem in practice, but I also think we shouldn't add
many more lest a phase shift of sorts occurs. And then just like you I
prefer orthogonality, and abundance of keywords is abundance of magic
and exceptions. I'd prefer "classinfo" to be an identifier like any
other and obey the same rules that every symbol in its scope does. I'm
very happy that Tomasz Stachowiak revealed to me that in-situ class
allocation can be elegantly defined as a library facility. I don't care
for foreach_reverse because foreach (e; retro(r)) actually does better.
The popping of "length" in scope inside slice bounds is about the most
distasteful hack there is, which gives the "length" keyword an
almost-keyword status. And so on...
Andrei
