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. 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. 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 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. 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.
