Too much flexibility is dangerous for large systems

[dsimcha]

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?