OpenAL++ Released 10
Tomas Hämälä writes: "Developed as an in-house tool for spatial audio at VRlab, OpenAL++ is now
released to the public. As the name suggests, the API is object oriented
and built on the portable audio library OpenAL. The libraries CommonC++
and PortAudio are also used. OpenAL++ is released under the LGPL. Features of OpenAL++ include: Object oriented interface, easy thread handling, automatic initialization/shutdown and more. For more information, visit the OpenAL++ homepage. VRlab is a research center for virtual reality and visualization. It is closely connected to the Departement of Computing Science at Umeå
University and High Performance Computing Centre North."
Limiting the audience? (Score:2, Insightful)
Why does everything have to be "object oriented" these days? What about non-OO languages or programmers who feel that OO is mostly hype and a subjective personal preference? With all its techno-cliches, OOP has never proven to be objectively better under code-size counts and change impact analysis.
You narrow your audience when you buzzword-atize stuff beyond use.
oop.ismad.com
Re:Limiting the audience? (Score:1)
openAL++ is an object oriented wrapper around openAL so clearly it needs to be object oriented. the rest of the audience can just use plain openAL.
and what about those that feel OO is mostly hype etc?
just to add something on topic...has anyone played with openAL any or seen any projects making use of it ?
Re:Limiting the audience? (Score:1)
Re:Limiting the audience? (Score:1)
Hey, if they can show that they are just as productive as structured programmers and their software is equally as change-friendly, I won't complain.
I once made the mistake of thinking like you and got a royal chewing out. Here is the result:
Title: Partial Apology to Perl Fans
"Dear Perl Fans,
A couple of years ago I started a "criticisms of Perl" rant on the comp.lang.perl newsgroup. After pondering it for a while, I realize that my criticisms were generally misdirected.
Don't get me wrong, I *still* think Perl is a "write-only language" and I still don't like the idea of using arrays of array pointers for complex collection management; but what I think may be moot. You see, Perl started becoming "mainstream". That made me fear that it would get shoved down programmers throats who were not fond of Perl. OOP did this, and I didn't want to see it happen again. I inadvertently projected this Borg-esque fear onto Perl.
The benefits of paradigms and development tools are largely subjective. Just because developer A works well with tool A does *not* mean that developer B will also work well with it. One-size-fits-all does not work because we all have very different brains. (A new field, "technical psychologist" or "organizational psychologist" is perhaps needed.)
Thus, as long as Perl fans can read each other's Perl code and be productive, it does not matter if I or other non-fans cannot do the same with Perl. Similarly, you perhaps would not like applications that I design. (Note that I have not verified whether Perl fans can read each other's code.)
But, if anybody says that "Perl is for everyone", then I *will* take objection. That is crossing the line. Unless, of course, objective metrics can be provided.
In summary, I hope everybody can learn from my mistake and not over-extrapolate their own preferences onto everybody else. Viva La Difference! (Is my french better than my Perl?)
PS. The "scope" code example that I posted back then indeed was a piece of junk, as somebody later pointed out to me. However, the concept that I was incorrectly trying to illustrate was *not central* to my primary criticisms.
Thank You for your understanding, [sig]"
Re:Limiting the audience? (Score:2)
From personal experience having to maintain both C and C++, with structured and object oriented designs, I've come to the following conclusion:
Object oriented C by a bad programmer is worse than object oriented C++ by a bad programmer. And structured C++ by a bad programmer is worse than structured C by a bad programmers.
Conversely, object oriented C by a good programmer is never as good as object oriented C++ by a good programmer. And structured C++ by a good programmer is never as good as structured C by a good programmer.
First conclusion: write object oriented code in C++ and structured code in C. Second conclusion: if all you know is C then stick to structured programming.
Thus ends the heresy for the day.
Re:Limiting the audience? (Score:1)
Then how is one gonna learn? They are gonna hafta screw up somebody's applications for a while it sounds like. Pitty that company.
BTW, I think I prefer "scriptish" languages over strong-typed compiled ones. They are more expressive and less cluttered with conversion and declaration formalities and easier to adapt to other interfaces IMO.
Re:Limiting the audience? (Score:1)
You narrow your audience when you exclude the Amish!
Re:Limiting the audience? (Score:1)
Assuming you are serious and this is a round-a-bout way to call me a Luddite; what metric do you have that *does* show OOP to be objectively better than procedural/relational and/or functional?
If you don't like code size or change-impact-scenario analyses to compare, then how *do* you know?
If your reply was simply a joke rather than a dig, then I give it a B-