No, because you could have most likely done it even faster in a free language. And the Commodore 64 even had it's own bloody OS (GEOS). Blitz Basic sucks.

We are comparing a programming language that runs on win 95 and up with the commodore 64?

Yes I do know Blitz Basic is dummed down beyond belief. I wish that it had LOTS of things such as more data types, and COM, as well as multithreading or asynchronization. Then it would be a decent RAD development language for hobby projects.

I think blitz is a toy that has many uses, but I wish it was a better toy.

Hell, maybe I should write a COM wrapper and extend the command set, that way I could use TrueVision with blitz without having to write a wrapper for TrueVision.

Then this would have asynchronization since the DLL does all the loading. Or perhaps not, I don't know, I'm not going to try it.

In summary - Engineers don't have time to program when they're employed. Our companies hire programmers to make software (we have 2 blokes who do this) and engineers to, you know, do the maths. It's dead easy to knock up a quick chunk of MATLAB code to do little tasks for you, but in all honesty most things of that scale can be done in Excel far quicker anyway...

for some reason im reminded of a guy i know who thinks extacy and mdma are two different drugs

hahaha

What you're describing is C#, Delphi, Java and every other RAD-capable language in existence.

I have tried C# and yes, its good and not very hard to understand, but its by far more complex than Blitz and would take me longer to get the grasp of.

As for Delphi and Java, I couldn't say.

why are you in this thread giving advice about c++

Even PHP supports forking at least. Blitz fails.

A good benchmark for the suitability of a language is how easily it allows you to deliver functional software. Since Gold isn't going to deliver functional software whatever language he uses, Blitz is just as good as any other.

besides electrical/computer engineers i imagine, most engineers use programming mainly for the purposes of numerically solving systems of differential equations for complex systems. thus, matlab is by FAR the best choice. there is pretty much no question. something that will take you on the order of hours in C++ will take 20-30 minutes in matlab. as an easy example, matlab has built-in code for taking the inverse of a matrix or, similarly, performing gaussian elimination. assuming you've taken linear algebra already, solving Ax=B is as easy as x = inv(A)*B or x = A\b. matlab includes a ****-ton of these programming shortcuts geared towards (applied) mathematics. with C++, i imagine you'd have to write the code for these functions yourself, among other things.

save yourself some grief and learn matlab, and later when you become a big boy and realize matlab has a lot of programming overhead, you can start learning fortran.

My Fluid Dynamics professor was one of the programmers for the F-16 Vista and using a 10-line MATLAB script to replace servers that crunch numbers for days is what got him the job in the first place. Fortan programs as well.

The F-35 flight control systems were written in MATLAB/Simulink.

Even those engineers tend to stick to assembly languages or a HDL because it's more applicable to what they're doing.

People like to talk up C++ if they aren't aware of the alternatives. I'm not predicting its doom or anything, but C++ isn't useful outside of a very specific problem domain (even though that domain represented a huge portion of the software development industry until very recently). The reduced run-time overhead of C++ (which only applies for very specific applications with very specific usage patterns) comes with a vast and unreasonable swath of other design-time, development-time, compile-time and run-time overheads.

If a person has any reason to learn C++ they wouldn't need to ask.