Announcement for programmers...

Discussion about: tracktion.com
Post Reply New Topic
RELATED
PRODUCTS

Post

Karbon L. Forms wrote:Strikes me there must be good reasons why C++ is hugely popular and even Borland is letting pascal die. Not sure what they are though. I like C++ despite the fact that it regularly f**ks with my head. (The bird does that too and I like her).
I predict the death of C++, too. The principal platform for C++ is/was MS Windows standalone apps. C# is the new language of choice there, and given a choice, I think most developers would prefer C#. It's simply a much cleaner, more modern language. C++ does have an efficiency advantage, but it's narrowing and few people care with today's machines. On the other hand, people who want fast code and lower level control are much more into C - witness most Linux applications, including the kernel.

Someone says they like C++ because it's corss platform. It's actually quite hard to write programs of any complexity that don't require a million #if's and a complex build system (autoconf/automake on linux for instance - holy cow!).

However, there are reasons even more fundamental: Application development is shifting from the desktop to the internet. Slowly of course, and there will always be standalone desktop applications. But features such as built-in web services and ease of integration with web applications become more important in a language. Few people would want to write a web application in C++.

The real problem I see with C++, though, is that it has no culture around it. It's a nice language in its own right. A bit low-level for some (and for some tasks), but a nice language. Very powerful. Very logical and clean. But also very hard to learn well enough to be able to benefit fully from all that (I've seen so many C++ programmers who really only have a partial idea of what they're actualyl doing).

However, the standard library is really only an inclusion of features which are considered "built in" in other languages (Valley, std::string is no worse than any other string type in any other language, bar perhaps a few specialised operations). Compare that to Java, C#, Python or other modern languages, which have huge and genuinely useful languages. And from this stems a language culture. Java programmers all write code the same way, they all use the same notation and style. It makes interoperation in the Java world a reality. There are good libraries available for C++, for use, but they are disjoint and don't gel nearly as well as libraries do in Java (for obvious political, cultural and corporate reasons).

The net result is that the vast majority of programmers who aren't biased with years of experience are a lot more efficient in languages like C# or C++. I used to really love C++; I used to consider it the only "proper" language to use for making a decently complex standalone application. Now I just think, why would I want to manage my pointers or roll my own data structures or use ones from libraries which use a different coding style and different conventions to my own when there's C#, Java, Python and other alternatives out there?

It's a bit sad really, I used to really like C++...
"Life is both a major and a minor key"
-- Travis, Side

Post

optilude wrote:Valley, std::string is no worse than any other string type in any other language, bar perhaps a few specialised operations.
Now to be fair, I never actually said that C/C++'s string handling was particularly wanky, just that Pascal's is particularly good[1] and that right there is one of the reasons I like Pascal.

As for C#, I'm dubious of entirely MS centric programming languages, so I'll probably pass on that. I totally agree on Java and Python[2] though.

@KLF, no the string type in pascal is not technically a primitive (it is still an array of char at heart) it is as near as damnit from an implementation POV. Pascal arrays are particularly pleasant things to code with making strings by extension, particularly pleasant to use, which brings me back round to...


[1] unless compared to, say, Perl. ;)

[2] only a couple of days ago I persuaded one of our math scientists to use python for a stats algorithm he is writing, 'cos IMV it is a great language for code that is likely to be taken and modified by a number of people over a period of time.
Someone shot the food. Remember: don't shoot food!

Post

optilude.
So we'll still need C++ to write all those virtual machines or common language runtimes etc. Oh and operating systems. The oil industry here in Aberdeen certainly does'nt look like switchinf for a while either.
And this is a plug/host forum. Who gives a toss about webapps! (cept the forum obviously!) We need our audio DSP to run like shit of a shovel. Which means c++, delphi, assembly etc.
I would'nt punish myself by writing a non-DSP desktop app in C++, of course I'd use C# or Java.
I've just woke up so I may be blethering shite (again).
.................................
"Hell is other People" J.P.Sartre
.................................

Post

@Valley: Agree that tying yourself to MS is a scary though. http://go-mono.com. If I *ever* get a few days of spare time (not likely in between day job, freelance development job and every weekend spent in the studio on my album) I want to do a project in C# using Mono and GTK# (and thus making it Linux-specific) to see if it stands up to the task.
Karbon L. Forms wrote:optilude.
So we'll still need C++ to write all those virtual machines or common language runtimes etc. Oh and operating systems. The oil industry here in Aberdeen certainly does'nt look like switchinf for a while either.
And this is a plug/host forum. Who gives a toss about webapps! (cept the forum obviously!) We need our audio DSP to run like shit of a shovel. Which means c++, delphi, assembly etc.
I would'nt punish myself by writing a non-DSP desktop app in C++, of course I'd use C# or Java.
I've just woke up so I may be blethering shite (again).
You are right of course. This is the niche which C++ will fill, at least on Windows. In Linux, C fills this niche. I don't really see why one can't write DSP in C#, but I guess for many applications, the extra performance penalty is significant. For anything which interacts directly with hardware, C and C++ are unrivalled, of course. It's just that in the grand scheme of things, these types of applications are fading in numbers. How many new VMs are written? There are a fair few plugins being written, granted, but compared to the amount of "business" applications, the number is tiny. I didn't mean to say that C++ would disappear off the radar completely in the near future. But a friend of mine was under the impression that if you didn't learn C++, you weren't really programming properly (from a Windows desktop application perspective). A few years ago, I may even have agreed with him (Delphi notwithstanding), but now I've told him to learn C# and get good at programming and design before even thinking about C++, because most likely he'll never need it, and he'll find C# a lot easier to use.

Martin
"Life is both a major and a minor key"
-- Travis, Side

Post

Your cross platform GUI and multimedia API seems simply excellent jules :D what I like the most when I tried tracktion was its innovative GUI (well, I discovered later that in fact it looks a lot like Live, but that's not the point here ;-)
It's highly probable that after being popular in the music community, you will become popular in the developer community :D

By the way it seems that there are many developers here but some posts here are just surprising :-o About the linking with the VST SDK, I can't see why it can be a problem :
1) if you distribute a VST done with JUCE with source code, as required by the JUCE GPL license, simply don't include VST SDK
2) if you compile the VST and distribute it (if you pay a license to jules or if he gives you permission) well that's exactly like if you develop a VST using synthedit, or raw C++, or anything else

I'm not totally sure about point 1) (I don't read all posts in detail) but I'm totally sure about point 2) ...

Post

Deed wrote: I'm not totally sure about point 1) (I don't read all posts in detail) but I'm totally sure about point 2) ...
at risk of repeating myself, the issue with point 1 is that the GPL itself requires that the VST stuff be distributed under a GPL compatible license. This is one of the fundamental points about GPL, and is how Microsoft can run it's "GPL is viral: don't be infected by Linux" campaigns.

From the GPL POV, this 'viral' nature is an essential aspect of ensuring that the spirit of GPL software is maintained, and that GPL developers do not see their code being used in proprietary commercial applications.

The GPL FAQ basically has this advice when trying to use code that is released under the GPL, and code that is released under a non-compatible license within one of your own projects: don't.

As for point 2, you are of course entirely correct. I'm just waiting to see what license deals Jules wil offer. :)
Someone shot the food. Remember: don't shoot food!

Post

I'm not totally sure valley but it seems like you mistake distribution of source code and distribuation of binaries
GPL itself requires that the VST stuff be distributed under a GPL compatible license
it would be the case only if you want to release the VST SDK along with your source code. But of course you can write code that use different libraries (MFC, VST, anything else), and release ONLY YOUR source code under the GPL license. Of course your program will be totally useless without these third party libraries, but that's not the point here ... (in a general manner, source code is totally useless except for developers !)
All windows applications use native calls to windows, or libraries that wrap these native calls. Windows is not GPL. So if you were right, it would be impossible to distribute GPL applications under windows, isn't it ?
This is one of the fundamental points about GPL, and is how Microsoft can run it's "GPL is viral: don't be infected by Linux" campaigns.
we all (developers) know that microsoft is shit and talks shit :D i've never heard about this campaign but i'm afraid that windows IS the virus (there were many jokes about that, before the xp release that bring some stability to windows :lol: )

Post

So if you were right, it would be impossible to distribute GPL applications under windows, isn't it ?
i reply to myself :wink: ... maybe valley is right and maybe it is impossible to release GPL applications under windows ... maybe it is one of the reasons of the LGPL license ? Do someone know a windows GPL application ? I can't remember one a this time

Post

Deed quoth I'm not totally sure valley but it seems like you mistake distribution of source code and distribuation of binaries

No I dont think he does...
it would be the case only if you want to release the VST SDK along with your source code.

No, it would be the case if you were to distribute code that is derived from the VST SDK.

But of course you can write code that use different libraries (MFC, VST, anything else), and release ONLY YOUR source code under the GPL license.

As has already been pointed out, this comes down to the difference between linking to a library and use of derivative code.

If you derive code from something with a license incompatible with the GPL, and use that in conjunction with code derived from something which is GPL'd, you cannot redistribute it without breaching the terms of the GPL.

Of course your program will be totally useless without these third party libraries, but that's not the point here ...

Its not the point, because you've misunderstood the difference between a linked library and derived code.

(in a general manner, source code is totally useless except for developers !)

Irrelevant.

All windows applications use native calls to windows, or libraries that wrap these native calls. Windows is not GPL. So if you were right, it would be impossible to distribute GPL applications under windows, isn't it ?

Incorrect. Consult the GPL FAQ...
However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
Last edited by whyterabbyt on Mon Aug 16, 2004 9:52 pm, edited 1 time in total.
An idiot on Set Theory:
"In some cases there is an object called red that contains everything that is red. In much the same way a pot is a plate."

Post

again, repeating myself, but the GPL does make exceptions for kernel components.

A GPL app can link to dynamic libraries that form part of an OS without needing the linked library to be GPL.

Under certain circumstances it is *may* be possible to link to proprietary libraries with GPL code even when they are not part of the core OS, but I'm not aware of any.

The VST SDK though is neither a library or core OS, and as such is a completely different animal that the GPL specifically includes in its' list of "thou shalt nots".

LGPL exists entirely to allow one to to write open source libraries that can be used by closed source code. The point here is that the library itself cannot be modified or distributed without recourse to the LGPL license, but works that use that link to that library themselves are not bound by the LGPL. The LGPL is only relevant to library writers.

LGPL is deprecated by the Free Software Foundation, though I personally feel it still has utility.
Someone shot the food. Remember: don't shoot food!

Post

oops, the Rabbyt beat me to it, and answered far more concisely. :oops:
Someone shot the food. Remember: don't shoot food!

Post

so it appears that i was wrong and that i can't write a GPL VST ! damn it :lol:
btw isn't jules afraid that someone use JUCE to write a GPL tracktion like ? :-o :D

Post

I've read through the GPL again and agree that releasing a VST under the GPL would be against the license. HOWEVER, under a different license, non GPL, granted by Jules, you could use Juce with VST and have no problem. If this is incorrect, please show me, because I've read through many times now.

Also, if you release a VST under the GPL, and still only put header files and the like in to link to the library, but still have function calls and such within your code from the VST SDK, would you still be breaking the license? It seems to me that you would not, because you are not releasing any of the classes, libraries or whatever included with the VST SDK. Maybe I'm just confused. Cheers!

Koolkeys

Post

koolkeys wrote:I've read through the GPL again and agree that releasing a VST under the GPL would be against the license. HOWEVER, under a different license, non GPL, granted by Jules, you could use Juce with VST and have no problem. If this is incorrect, please show me, because I've read through many times now.
The operative word there is "could". ;)

As long as the licenses are compatible you have no problem. Right now your only choice for a compatible license is to pay for the non-GPL JUCE.
Also, if you release a VST under the GPL, and still only put header files and the like in to link to the library, but still have function calls and such within your code from the VST SDK, would you still be breaking the license? It seems to me that you would not, because you are not releasing any of the classes, libraries or whatever included with the VST SDK. Maybe I'm just confused. Cheers!
That's a very grey area. *I* wouldn't do that, but then for me that is as much a moral decision as a "covering my ass" decision. I'd be surprised if either Steinberg, or the FSF felt the need to jump all over you if you do this, but be aware that legally they could.
Someone shot the food. Remember: don't shoot food!

Post

I kinda figured that it wouldn't be doable, after I re-read what I wrote. And trust me, I wouldn't want to break any rules or licenses. I just hope that Jules doesn't want too much for a different license, as I'm not exactly rich.

I guess we'll just have to wait until he gives us different options. Thanks for helping to clarify everything. Cheers!

Koolkeys

Post Reply

Return to “Tracktion”