On Wed, 2017-05-31 at 16:37 -0700, H. S. Teoh via Digitalmars-d-learn wrote: > […] > With D, we can have the cake and eat it too. The understandable / > naïve > implementation can be available as a fallback (and reference > implementation), with OS-specific optimized implementations guarded > under version() or static-if blocks so that one could, in theory, > provide implementations specific to each supported platform that > would > give the best performance.
But isn't that the compiler's job? The lesson of functional programming, logic programming, etc. (when the acolytes remember the actual lesson) is that declarative expression of goal is more comprehensible to people than detailed explanation of how the computer calculates a result. Object-oriented computing lost the plot somewhere in the early 2000s. The advance of Scala, Kotlin, Groovy, and now Rust and Go (but only to some extent), which D has, is to express algorithms as declarative requirements in a dataflow manner. One day hardware people will catch up with the hardware innovations of the 1970s and 1980s regarding support of dataflow rather than state. > I disagree about the philosophy of "if you need to go faster, use a > bigger computer". There are some inherently complex problems (such > as > NP-complete, PSPACE-complete, or worse, outright exponential class > problems) where the difference between a "heroic implementation" of a > computational primitive and a naïve one may mean the difference > between > obtaining a result in this lifetime vs. practically never. Or, more > realistically speaking, the difference between being able to solve > moderately-complex problem instances vs. being able to solve only > trivial toy instances. When you're dealing with exponential > complexity, > every small bit counts, and you can never get a big enough computer. There are always places for experimentation, and innovation. Hard problems will always be hard, we just need to find the least hard way of expressing the solutions. The crucial thing is that people always work to remove the heroicism of the initial solutions, creating new computational models, new programming languages, etc. to do it. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
