Hi all; On Tue, Mar 22, 2011 at 7:14 PM, William A. Rowe Jr. <wr...@apache.org>wrote:
> On 3/22/2011 7:19 PM, Keith Curtis wrote: > > > > I guess some might consider a solution like that no worse than any other > but I think > > endorsing such a stack goes against a good policy. If you are going to > make a policy, you > > should love the results it endorses. That is all I was trying to suggest. > > See, I guess that's where I think this discussion has gone off the rails > for an Apache Software Foundation discussion. > > In large measure, ASF participants are pragmatists. This isn't a culture > you might find in the Gnome or other FSF projects which seek to win an > entirely free (as in beer) ecosystem. Linus himself is exempted from > this gross over-generalization, as he does not come down against allowing > vendors to interface closed source with his kernel or running his kernel > on top of closed systems, so I'd place him in this same pragmatist culture. > I try to be pragmatic as well but free software is better and cheaper and so these worthy goals and reasons should be reflected in the policies on a topic. > You might find this is orthogonal to our public letter to Sun with respect > to Java, the TCK and the Apache Harmony project. But this was not; the > letter simply sought the terms promised by Sun and their compliance to the > JSPA which Sun authored. Had those promises and JSPA contract not existed, > the ASF would have been just as likely to never attempt the Harmony > project, > yet it was still developing code in Java. > Since I'm off-topic, I'll mention that I wrote a chapter in my book on why Java should be abandoned. (http://keithcu.com/wordpress/?page_id=2228) Whatever you are working on with Oracle I hope is not distracting you. Sun never invested nearly as much into Java as MS did in .Net, and I can't imagine Oracle improving things. I live in the world of PHP, Python, and the Linux desktop, so don't run much ASF technologies I think you guys should make a goal of moving towards the Python community: http://scipy.org/Topical_Software Note this can be done in a pragmatic way. The point is to first have goals and then figure out how to get there. If you have "pragmatic" goals you are aiming too low. It is important to be practical about means but not about the ends. > Advocacy for open source and/or completely open > solutions is fine, but the two are not identical. And until there is > an open chipset design for their target architecture, the "entirely 100% > open solution" champions are being disingenuous, IMHO :) > I have found that the hardware doesn't matter. A computer is happy to add 0 + 0 billions of times per second all day long. It is the software that matters. And the most important software is the programming language that you write your other software in. -Keith P.S. Here is a chunk of something I wrote about programming languages that is relevant here: ----------- http://keithcu.com/wordpress/?p=1691 The most popular free computer vision codebase is OpenCV, but it is time-consuming to integrate because it defines an entire world in C++ down to the matrix class. Because C/C++ didn’t define a matrix, nor provide code, countless groups have created their own. It is easier to build your own computer vision library using standard classes that do math, I/O, and graphics, than to integrate OpenCV. Getting productive in that codebase is months of work and people want to see results before then. Building it is a chore, and they have lost users because of that. Progress in the OpenCV core is very slow because the barriers to entry are high. OpenCV has some machine learning code, but they would be better delegating that out to others. They are now doing CUDA optimizations they could get from elsewhere. They also have 3 Python wrappers and several other wrappers as well; many groups spend more time working on wrappers than the underlying code. Using the wrappers is fine if you only want to call the software, but if you want to improve the underlying code, then the programming environment instantly becomes radically different and more complicated. There is a team working on Strong AI called OpenCog, a C++ codebase created in 2001. They are evolving slowly as they do not have a constant stream of demos. They don’t consider their codebase is a small amount of world-changing ideas buried in engineering baggage like STL. Their GC language for small pieces is Scheme, an unpopular GC language in the FOSS community. Some in their group recommend Erlang. The OpenCog team looks at their core of C++, and over to OpenCV’s core of C++, and concludes the situation is fine. One of the biggest features of the ROS (Robot OS), according to its documentation, is a re-implementation of RPC in C++, not what robotics was missing. I’ve emailed various groups and all know of GC, but they are afraid of any decrease in performance, and they do not think they will ever save time. The transition from brooms to vacuum cleaners was disruptive, but we managed. C/C++ makes it harder to share code amongst disparate scientists than a GC language. It doesn’t matter if there are lots of XML parsers or RSS readers, but it does matter if we don’t have an official computer vision codebase. This is not against any codebase or language, only for free software lingua franca(s) in certain places to enable faster knowledge accumulation. Even language researchers can improve and create variants of a common language, and tools can output it from other domains like math. Agreeing on a standard still gives us an uncountably infinite number of things to disagree over. ---------
