digitalmars.D - Too much flexibility is dangerous for large systems
- bearophile (4/4) Jan 18 2011 Found through Reddit, similar things can be said about D2:
- Walter Bright (7/9) Jan 18 2011 I think that article is bunk.
- bearophile (5/7) Jan 18 2011 I agree, the original Java was too much simple, the lack of things like ...
- spir (21/31) Jan 18 2011 Oh, how true!
- Ellery Newcomer (2/22) Jan 18 2011 please elucidate?
- Andrei Alexandrescu (3/28) Jan 18 2011 I think Lisp is in fact rather complex.
- dsimcha (24/37) Jan 18 2011 Ironically, from what I understand (correct me if I'm wrong since I've
- spir (19/39) Jan 18 2011 You are right. The core is simple, or rather "flat"' ;-)
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
bearophile wrote:Found through Reddit, similar things can be said about D2: http://kirkwylie.blogspot.com/2011/01/scala-considered-harmful-for-large.htmlI 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
bearophile <bearophileHUGS lycos.com> 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 Bye, bearophile
Jan 18 2011
On 01/18/2011 12:41 PM, Walter Bright wrote:bearophile wrote: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.comFound through Reddit, similar things can be said about D2: http://kirkwylie.blogspot.com/2011/01/scala-considered-harmful-for-large.htmlI 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
On 01/18/2011 06:46 AM, spir wrote:On 01/18/2011 12:41 PM, Walter Bright wrote:please elucidate?bearophile wrote: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.Found through Reddit, similar things can be said about D2: http://kirkwylie.blogspot.com/2011/01/scala-considered-harmful-for-large.htmlI 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
On 1/18/11 3:01 PM, Ellery Newcomer wrote:On 01/18/2011 06:46 AM, spir wrote:I think Lisp is in fact rather complex. AndreiOn 01/18/2011 12:41 PM, Walter Bright wrote:please elucidate?bearophile wrote: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.Found through Reddit, similar things can be said about D2: http://kirkwylie.blogspot.com/2011/01/scala-considered-harmful-for-large.htmlI 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
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
On 01/19/2011 01:26 AM, dsimcha wrote:On 1/18/2011 7:46 AM, spir wrote: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.comThink 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".
Jan 18 2011