gneuralnetwork
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gneuralnetwork] Parallel Directions


From: Ray Dillinger
Subject: Re: [Gneuralnetwork] Parallel Directions
Date: Fri, 7 Oct 2016 11:19:27 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0


On 10/06/2016 08:05 PM, David Mascharka wrote:
> Hi everyone,
> 
> I've been working on a small library to allow users to more easily specify
> network architectures. You can see the library and square root curve
> fitting example from the gneural/tests at
> https://github.com/davidmascharka/neural-net-playing/tree/master/cpp
> 
> I'm wondering if this is a fruitful direction to head for gneural-network.
> What I've got now doesn't have as many features as the gneural release but
> may be more reusable. What do you think is the best direction to head
> moving forward? I think the C++ version I've been working on allows for
> really nice extensibility/adding layers but if there are good reasons to
> work in C I'm on board with that.

Okay, you bring several important points and I want to
address them individually. So this post will be about choice of
implementation language, and  I'll make another post to address
more important questions of direction in general.

Given the choices available, to the extent that we need to use
an OO language, C++ is the obvious choice.  And we're going to
need C++ wrappers to interface with things that depend on the
OO structure (like runtimes for some other languages, and GUI
frameworks).  And I can cheerfully switch from gcc to g++ to
produce code that's compliant with C++ typechecking and compiled
for use inside a C++ wrapper.

But for the sake of clarity, sanity, and debugging, and for
reasons I'll go into more fully when I address 'direction', I
want there to be a fully working, useful program - specifically
a highly scriptable command-line utility - that works correctly
without any C++ extensions.

OO languages in general have lots of ways to hide behavior.  But
C++ in particular has more ways for a malicious actor to hide
malevolent code in things that look absolutely innocent (until
you trace down a dozen different definitions that each seem
innocent taken on their own) than anything else I've ever worked
with (A hard lesson from working in cryptography & security -
for whatever that's worth to you).

Which, in my opinion, corresponds to more ways for a bunch of
absolutely honest programmers to innocently produce a dozen
different definitions that work together in unexpected ways to
create awful, hard-to-track-down, application-destroying bugs.

Given my druthers, if I were going to an OO language I'd prefer
to use Ada.  I could spend another paragraph explaining why but
it's not relevant.  Almost nobody uses Ada and we'd never get any
other developers working on the project if we did. It's a non-
starter for something where you're trying to attract open-source
devs.

                        Bear

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]