howto count lines - fast

Russel Winder via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Thu Jun 1 00:39:07 PDT 2017


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.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20170601/9a9bd4ad/attachment.sig>


More information about the Digitalmars-d-learn mailing list