Okay everybody, let's quell the language wars here. All your favorite languages are beautiful snowflakes. ;)
Thanks! --------- Matt Taylor OS Community Flag-Bearer Numenta On Fri, Feb 6, 2015 at 1:35 PM, cogmission1 . <[email protected]> wrote: >> "...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...
