On Feb 5, 2015, at 12:00, Gurvinder Singh <[email protected]>
wrote:
> May be I was not clear enough. I am with you on that Nupic does not
> need translation to any other language to be disributed. Java is more
> than enough. What I meant was that Nupic java implementation can be
> used with framework like Apache Spark to get disributed. ...
I think we may be conflating some issues and thus talking at cross-
purposes. Here are the issues I see and my positions on them (ducks):
-r
Implementations
I really like the idea of multiple NuPIC implementations as a way to
try out ideas, learn what works best for what problems, etc. Some of
these implementations may be academic, experimental, specialized, etc.
So, for example, a message-based implementation in Clojure or Elixir
might not be as performant as a highly-optimized Java implementation.
However, it may have other benefits (eg, acting as executable pseudo-
code and a very malleable workbench for trying out modeling notions).
At least one implementation (preferably more) should have recognized,
"official" releases. Although language-specific bindings are welcome,
any official release should be conveniently usable by applications that
use other languages and/or frameworks. A message-based interface which
supports streaming of structured data seems like an obvious choice. It
should build on popular, well-supported standards, whenever possible.
To qualify as an official release, an implementation should pass a
specified set of tests. That is, I'd like to see a language-neutral,
executable specification that contains both required and optional tests.
Languages and Frameworks
In large part, these are a matter of taste. I like Elixir, for various
reasons, but I don't argue with aficionados of other languages. However,
Elixir inherits some unique features from Erlang, BEAM, and OTP. OTP,
for example, provides a well developed and thoroughly tested concurrency
and process management framework. I don't know of anything equivalent,
either in the JVM or elsewhere (eg, Golang).
Of course, Elixir may just be my current "Blub" (:-):
Blub ... was used by Graham ... to illustrate the difficulty of
comparing a programming language one knows to one that one does not.
-- Paul Graham (computer programmer) / Blub
https://en.wikipedia.org/wiki/Paul_Graham_(computer_programmer)#Blub
See also: Blub Paradox
http://c2.com/cgi/wiki?BlubParadox
--
http://www.cfcl.com/rdm Rich Morin [email protected]
http://www.cfcl.com/rdm/resume San Bruno, CA, USA +1 650-873-7841
Software system design, development, and documentation
