Just wanted to mention about Java, as it's something I feel has very good qualities for long term software. It's fairly fast, has IMO the best development tools (refactoring capabilities in IDE's, static analysis tools, etc.), by having a virtual machine is shielded from changes in hardware technology (I can run a Java application developed on Win 98 on 64-bit Vista or OSX), etc. It's also GPL and the OpenJDK has reached full compatibility with the previously closed source version. The big value for me is I compile once and run everywhere regardless of OS, hardware architecture, etc. I can also package the application to have all required libraries with the app. I'm not sure how easy that is to do with say a python application written with wxWidgets and other libraries, if you can package that all together, and have it run on each OS so easily. Beyond all that, there's a whole lot of businesses who have invested a great deal of time and money into Java technologies, particularly on the server. With the amount of deployed code now in Java, I have a very strong feeling that it will be around for a very long time. So from my point of view, Java is actually one of the safest languages and development platforms for building long-term software. steven On Wed, Jul 23, 2008 at 6:17 PM, DavidW wrote: > > On 24/07/2008, at 4:52 AM, Michael Gogins wrote: > ... >> >> Obviously, open source tools are essential for serious music that has some >> aspiration to live for more than a few years. > > I agree completely! Not just for the music to live, but also for composers > to be able to continue to develop their thinking to a certain depth and > integrity over a period of time longer than the period to the next OS > upgrade! I'm sure there are others than me on this list that have written > software in numerous languages only to find they had to waste years > converting both accrued tools and whole environments as obsolescence set in. > If it wasn't for the importance (to my way of thinking) of having an > interpreted language. I would have just stuck to C(++) for decades. Each > move through APL Forth to Python for this work was taken deliberately to > maintain the interpretative aspect. Else, just go back to C. This is the > reason why I personally have never really seen the need for Java. The > situation is different today than in the pre-realtime audio days: all those > 1000's of hours hacking Z80 and 680X0 assembler don't bear thinking about! > None of which should be interpreted as wanting to discourage > experimentation: Its essential! Processing is fun and a Csound interface to > it is exciting, but it is still experimental and so needs to be handled with > risk aversion strategies, like not entrusting one's entire finances to > coffee futures! >> >> The hope is that basic programs such as Csound and Python will continue to >> be maintained with backward compatibility, and if backward compatibility >> breaks, it will still be possible to rebuild the older versions from sources >> and run them, if necessary on emulators. After all, people are still making >> "chip tunes" for the Yamaha SID and Commodore 64 on PC emulator software. >> This is the model for us! > > And importantly, if/when C/python outlive their usefulness, that their > replacements will be long enough coming to be seen coming. There is a > corollary to this and that is the power of embracing the 3rd-party library > approach. I've written about this elsewhere (eg ICoMCS paper at > http://www.avatar.com.au/sonipy/) so I won't bang on about it here other > than to say that the library modularisation of Csound is a significant step > in ensuring its long-term viability, and thus attractiveness. The more > general routines can be 'outsourced' to wider software-concerned-others, the > greater the survival chances. This is one reason (apart from the horrible > sound) that I won't do any serious work in Max. What happens when Cycling > falls over? > Also, whilst open source is a necessary condition, it is not a sufficient > one. A simple example suffices: Suppose I find I need to do some > multidimensional data manipulation and I'm working in that other beautiful > child of MusicV, Supercollider. No such tools exist within that environment, > so what choice do I have? Well, I could take some time out and get on with > the task of writing the tools myself, perhaps encouraging others to get > involved. Fine, but what about the next time, or what about having to > maintain it when the SC and/or OS changes? And all the time I know that out > there Numpy exists and is probably better than what I would write, and is > maintained by its own fanatics (bless them) and likely to evolve through OS > upgrades. And when python becomes obsolete, as it will, all the people using > Numpy will need something to do what it currently does. For me the choice is > clear: tinker with custom exotics in the spare time and use as much > bog-standard tools as possible without compromising musical integrity > otherwise. > > And the same can be said for Portaudio, UIs and OSs. Isn't it interesting > that C and unix are still around and in-fact have been revived? I'm > currently working on an intel Mac but the moment Apple decide to depart > Unix, I'll be out of here asap unless it is to a more universally adopted > environment. We all know that just making Csound libraries instantiable on > various current platforms is time-consuming enough! > > D. > ________________________________________________ > David Worrall. > - Experimental Polymedia: www.avatar.com.au > - Education for Financial Independence: www.mindthemarkets.com.au > Australian research affiliations: > - Capital Markets Cooperative Research Centre: www.cmcrc.com > - Sonic Communications Research Group: creative.canberra.edu.au/scrg > > > > > > Send bugs reports to this list. > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe > csound" >