www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Too much flexibility is dangerous for large systems

reply bearophile <bearophileHUGS lycos.com> writes:
Found through Reddit, similar things can be said about D2:
http://kirkwylie.blogspot.com/2011/01/scala-considered-harmful-for-large.html

Bye,
bearophile
Jan 18 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
bearophile wrote:
 Found through Reddit, similar things can be said about D2:
 http://kirkwylie.blogspot.com/2011/01/scala-considered-harmful-for-large.html

I think that article is bunk. Large Java programs (as related to me by corporate Java programmers) tend to be excessively complex because the language is too simple. Too often people think that with a simple language, the programs created with it must be simple. This is dead wrong. Simple languages lead to complex, incomprehensible programs.
Jan 18 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter:

 Large Java programs (as related to me by corporate Java programmers) tend to
be 
 excessively complex because the language is too simple.

I agree, the original Java was too much simple, the lack of things like generics and delegates increases code complexity and size. But I think that too much flexibility too is dangerous for large projects, as the article says. So I presume for large commercial systems some intermediate point is the optimum. I think C# is very well on this middle point :-) (C# and D purposes are not the same, so I don't expect D and C# to be equal). Bye, bearophile
Jan 18 2011
prev sibling parent reply spir <denis.spir gmail.com> writes:
On 01/18/2011 12:41 PM, Walter Bright wrote:
 bearophile wrote:
 Found through Reddit, similar things can be said about D2:
 http://kirkwylie.blogspot.com/2011/01/scala-considered-harmful-for-large.html

I think that article is bunk. Large Java programs (as related to me by corporate Java programmers) tend to be excessively complex because the language is too simple. Too often people think that with a simple language, the programs created with it must be simple. This is dead wrong. Simple languages lead to complex, incomprehensible programs.

Oh, how true! 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) 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? Denis (*) and if you're happy actual collection lists look like [e1 e2 e3], not (e1 e2 e3) _________________ vita es estrany spir.wikidot.com
Jan 18 2011
next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 01/18/2011 06:46 AM, spir wrote:
 On 01/18/2011 12:41 PM, Walter Bright wrote:
 bearophile wrote:
 Found through Reddit, similar things can be said about D2:
 http://kirkwylie.blogspot.com/2011/01/scala-considered-harmful-for-large.html

I think that article is bunk. Large Java programs (as related to me by corporate Java programmers) tend to be excessively complex because the language is too simple. Too often people think that with a simple language, the programs created with it must be simple. This is dead wrong. Simple languages lead to complex, incomprehensible programs.

Oh, how true! 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.

please elucidate?
Jan 18 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/18/11 3:01 PM, Ellery Newcomer wrote:
 On 01/18/2011 06:46 AM, spir wrote:
 On 01/18/2011 12:41 PM, Walter Bright wrote:
 bearophile wrote:
 Found through Reddit, similar things can be said about D2:
 http://kirkwylie.blogspot.com/2011/01/scala-considered-harmful-for-large.html

I think that article is bunk. Large Java programs (as related to me by corporate Java programmers) tend to be excessively complex because the language is too simple. Too often people think that with a simple language, the programs created with it must be simple. This is dead wrong. Simple languages lead to complex, incomprehensible programs.

Oh, how true! 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.

please elucidate?

I think Lisp is in fact rather complex. Andrei
Jan 18 2011
prev sibling parent dsimcha <dsimcha yahoo.com> writes:
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?
Jan 18 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 01/19/2011 01:26 AM, dsimcha wrote:
 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".

You are right. The core is simple, or rather "flat"' ;-) What I actually meant is the myth <simplicity = facility> is _very_ wrong, especially in programming. But for any reason in everyday speech (not only in english) "simple" tends to be used as synonym of "easy", I guess. Very misleading. I think the notions that should exist in a PL ('s core) are the ones we humans use to think, more precisely to model. Engineers, designers, artists, scenarists, researchers... programmers model. Thus, PL design may be a field of applied cognitive science. But cognitive science is very far to be there :-( (able to tell us anything sensible & useful about how we model). In absence of any such fundament, we are left with absurd choices, wild statements and irrational rationalisations (in the common case) or plain pragmatics (in the best case). [Sorry for the OT] Denis _________________ vita es estrany spir.wikidot.com
Jan 18 2011