> > "...Costco carries economy packs of Java programmers..."
I'm really not going to fan the flames but the above is kinda insulting as if Java's very popularity and success can possibly serve as an invalidation? That's ironic! So I guess they sell 6 packs of C programmers at Walmart? And by contrast, Erlang programmers are pitched on Late Sunday Night infomercials? :-P Anyway. The main goal as I see it arises on a few fronts. 1. That which will accelerate the development (given that time to market with a mature product in as little time as possible, is a good thing). 2. That which will keep the codebase relevant for a long time and increase its compatibility with future hardware / technological innovations. 3. That which will attract the largest most efficient pool of open source developers. I think everyone here has made interesting points regarding the above, don't get me wrong - I just have always felt that a Java implementation would be a crucial adrenalin shot for NuPIC and would like to see the involvement grow in that arena because I have strong intuitions about how that interest would increase the viral spread of NuPIC. I think NuPIC is severely hampered by platform configuration issues as it stands, and the men and women who have dedicated themselves to developing in that environment have put forth a valiant effort to move it forward. I just wouldn't want to see efforts diluted or compromised any further by "shiny looking segues"... I just really think it deserves to succeed because it is truly an outstanding scientific distinction. 'Course I like cool stuff as much as the next nerd don't get me wrong. :) On Fri, Feb 6, 2015 at 2:47 PM, Rich Morin <[email protected]> wrote: > I basically agree with Kevin, with various additions and quibbles: > > Personal taste in languages and frameworks is much more important in > an open source project than in a proprietary venture. If I'm looking > for free help in experimenting with notions about distributed NuPIC, > I'd want to pick a language and framework that makes it easy and fun. > For me, this would be Elixir, Erlang, OTP, etc. > > However, I recognize that others have different tastes. More to the > point, many enterprises and projects have already made irreversible > (at least in the short run) implementation decisions. However, if you > look inside these operations, you will often find components written > in "non-standard" languages and frameworks. CouchDB and Riak, for > example, for example, are both written in Erlang: > > http://couchdb.apache.org > https://www.erlang-solutions.com/products/riak-nosql-database > > This software is typically connected to the rest of the code base via > network-friendly communication protocols (eg, messages, REST). This > is why I am arguing for an interoperable, message-based interface (eg, > Cap’n Proto), along with any desired language-specific bindings. A > substantial, open-ended test suite that uses this interface is also > critical, as it keeps the implementation options open. > > > On Feb 6, 2015, at 07:42, cogmission1 . <[email protected]> > wrote: > > How does Elixir/Erlang speak to the network issue? > > What about state monitoring across network nodes? > > What about debugging nodes on a network? > > What about ease of setup and distribution? > > What about interoperation on heterogenous architectures? > > We're talking about ease and maintainability here... > > Erlang was developed a few decades ago at the Ericsson Computer Science > Laboratory. It is used worldwide to support telephone switches. These > systems run 24/7, with extremely high reliability. So, for example, it > isn't generally OK to reboot a switch handling bazillions of calls. > > Consequently, Erlang and OTP have some unusual approaches and tools. > Developers can log into a running system and edit the code. The new > version will be brought into play in a controlled manner. Servers > can be added (or removed) "on the fly"; application code does not need > to be written in a special manner to take advantage of this. A system > of supervisors and monitors provides support for fail-soft designs. > > Erlang runs on most Unix and Unix-like systems and on the currently > popular flavors of Windows. Many people run Erlang on many different > types of embedded systems such as mobile telephones, telecommunication > switching equipment, and in-car electronics. For more details, see: > > http://www.erlang.org/faq/implementations > > > Elixir is a recent addition to the Erlang universe. It borrows ideas > from Clojure, syntax from Python and Ruby, etc. It provides the usual > sorts of tools that (say) a Ruby on Rails programmer would want (eg, a > REPL, a build tool, integrated support for documentation and testing). > > Elixir is a pragmatic, impure functional programming language. It is > dynamically typed, with optional static typing. Storage locations are > immutable (with structural sharing), but variables can be re-assigned. > There is no shared mutable state; lightweight processes replace threads. > > Unlike JVM languages, Erlang's VM supports tail-call optimization for > efficient recursion. However, the common practice is to use list > comprehensions, lazy data streams, pattern matching, etc. > > I have been working on a page that shows Elixir's intellectual history: > > http://wiki.cfcl.com/Projects/Elixir/Provenance > > > > The JVM's appropriateness for this task is as apparent as gravity... > > I don't see how this can be disputed? We want to take advantage of > > the wealth of development talent, and time-to-market ease of > > developing in Java - not introduce another level of obscurity? > > I am NOT suggesting that the NuPIC community leap into Elixir, Erlang, > and OTP. I just want the ability to use them myself (along with anyone > else who likes the idea). > > -- > 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 > > > > -- *We find it hard to hear what another is saying because of how loudly "who one is", speaks...*
