On 1/18/2011 7:46 AM, spir wrote:
Think at Lisp, for instance, probably one of the most simple languages ever. This simplicity, precisely, forces to create tons of abstraction levels just to define notions not present in the language --due to simplicity-- but absolutely needed to escape too low-level programming. This is on the semantic side. On the syntactic one, all of these "custom" notions look the same, namely (doSomethingWith args...) (*) instead of each having a distinct outlook helping the reader & decode the code. Great! (if (< IQ 150) findAnotherPL haveFunWithLISP)
Ironically, from what I understand (correct me if I'm wrong since I've never used Lisp beyond the toying stage), Common Lisp does most of the work for you here, by putting all this abstraction in the standard library. This works because, while the core language is simple, it's extremely flexible. However, the standard library is for many purposes part of the language and therefore Common Lisp has a reputation for being "bloated" and "complex".
On the other hand: which notions & distinctions should be defined in a language? D2 may have far too many in my opinion, but which ones should stay, and why?
IMHO anything that is clearly useful and cannot be defined well in a library should be defined in the language. Of course the notion of "well" is somewhat subjective. Furthermore, when deciding how good is "good enough" for a library implementation, it's important to consider how widely used the feature is. Thus, we have arrays in the core language even though they could be done fairly well in a library.
IMHO D2 does not have too much in the core language. The nice thing about it is that the more complex parts are only important for generic code, doing low level/performance critical work and providing automatically checkable guarantees about code. None of these can be implemented well in a library. If you're just writing run of the mill application code and don't care about fancy compiler checked guarantees or writing generic code, low level or super efficient code, it's pretty obvious what subset of the language to use. This subset is also extremely easy to use. Of course performing deeper magic requires deeper knowledge, but when has that ever not been true?
