On Sunday, Mar 21, 2004, at 17:08 America/New_York, Larry Troxler wrote:
On Sunday 21 March 2004 16:35, Frank Barknecht wrote:
Hallo,
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Wed, 10 Mar 2004, Hans-Christoph Steiner wrote:
There are a massive amount of books about programming techniques for procedural and object oriented languages, but there is basically nothing about programming techniques for patcher languages, even though they have been around for 20+ years and are decently widespread in use.
Guys, I've been following this interesting discussion off and on, and forgive me if this point has already been brought up or you disagree: Graphical programing languages don't scale well to large projects. They're strength is in getting highly customized things done quickly and interactively. From what I've seen however, they are generally not the right tool for creating large, general purpose, modularized applications.
Years ago, my company needed to develop an PC spectrum analyzer application for the cable extrusion industry (if their are preriodic dimensional fluctuations in coax cable, the reinforced reflections will create a marked attenuation at a certain frequency). Rather than doing this in C, we contracted a Labview consultant to do the whole thing in Labview. Now, this was a small to medium size general purpose application for which we provided a set of detailed specifcations.
The result, although it worked great, was a big mess, and hard to maintain and modify. Looking at the Labview "patches", it became clear to us that we were trying to stretch a graphical language far beyond its purpose. The next iteration of the product used Labview's C library instead, and was by far easier to maintain.
I think that graphical "programming languages" are great tools for the end user, and not the general purpose application developer.
Well, I just wanted to share that story, and I do realize that it is somewhat tangential.
I agree that current practice with patcher programming languages makes
it difficult to maintain larger scale apps, but I not ready to give up
and say that its an inherent problem with patcher languages.
Procedural programming was established at least 20 years before patcher
languages, and there has been many orders of magnitude more work done
on figuring out how to make manageable, large-scale software projects
in C than in Max/Pd. So there exists a huge body of knowledge about
how to make C programs manageable.
So I think that with efforts such as this one, we can begin to figure out how to manage large scale patcher projects. I concede that patcher languages will probably not be as good as procedural or object-oriented languages at large scale projects, but I think things can get a lot better.
.hc