Re: [fluid-dev] Fluidsynth changes

[Ebrahim Mayat]

On Apr 22, 2007, at 5:16 PM, Miguel Lobo wrote:

> > Anyway, I believe in the usefulness of the "show me the code"
> > approach in these situations.  Many people have strong opinions on
> > some technical issues, but not so many are usually willing to
> > translate those opinions into actual working code.
>
> Hmm, interesting opinion. Could you be more specific.
>
> Sure.  I just mean that talk is cheap.  Technical flamewars on OSS  
> mailing lists tend to involve many people with strong opinions,  
> even people whose contribution to the project in question in terms  
> of code are slim to none.  That doesn't mean they can comment, of  
> course, but when technical disagreement seems unsolvable, as is so  
> often the case, it's time to see who is willing to support his  
> opinions by writing code and who isn't.  This approach has been  
> followed in the Linux kernel and the KDE project with (IMO) good  
> results.

You have forgotten one very important aspect: Before one can  
contribute in terms of code; compile errors, runtime errors, bugs,  
critical performance bottlenecks, maintenance problems, etc. have to  
be identified.  A program/app is only as good as its performance in  
the real world. This feedback can only come from the end-users who  
are after all, the people for whom the program is written for. In  
addition, feature requests in most cases come from users who need  
certain features to ease their workflow. In other words, the end  
user- coder relationship is of capital importance. If the fanciest  
algorithms do not enhance ease of use or make any detectable  
performance improvement, what's the use?


> For the moment, as far as Fluidsynth is concerned, I'm one of those  
> people who is all talk and no code, so I can understand that Josh  
> and others may have reservations when I'm proposing big changes.  I  
> believe that by showing a complete working C++-ized Fluidsynth I'll  
> be able to better support my position, so I was suggesting than if  
> Josh can postpone the decision, he can wait to see my code and then  
> decide if those criticisms to my approach are applicable or not.

Fair enough. My one criticism for your proposition is that I cannot  
see how changing the code base from C to C++ will help when using the  
program. Have you also considered how code transparency might be  
affected? At the moment, it looks like you want to re-invent the  
wheel because you have certain coding preferences?

What would the advantage of MSVC compatibility be for OSS? Is MSVC  
freely available? On which OSes can MSVC be used?
Autotools are freely available and work on a multitude of OSes  
including all the Linux flavors and UNIX OSes.


> As always, no offence is meant to anyone.  Reasonable people can  
> disagree and all that.
Right, no offence meant.

To my knowledge, C++ is a superset of C so I would imagine that any  
code enhancements that you propose could easily be "translated"  to C  
if all the objects, containers, methods etc. are clearly defined. If  
you know C++ very well, the transition to C in theory would be rather  
effortless.


> Regards,
> Miguel

Regards,
E