Downside of using FreeBASIC

[BasicCoder2]

As programming is just a problem solving exercise for me, and as an old low level QBASIC programmer, FreeBASIC fits like a glove. However it struck me that any commercial software written in FreeBASIC will have the weakness of not having any on going support should the author lose interest or become ill. This is due to the sparsity of FreeBASIC programmers. The code becomes fossilized without anyone to update or tweak it for any new or particular applications that may be desirable or required by law changes. I think any programming language that has this weakness will forever rule it out as a language worth learning, no matter how good it is, for these kinds of applications.

[Tourist Trap]

However when responding in another post by Gablea about the best way to page (scroll) lists in his point of sale software it struck me that any commercial software written in FreeBASIC will have the weakness of not having any on going support should the author lose interest or became ill.

The issue you're pointing out would be in my opinion the same for all commercial projects. The owner then, is in its own right to let its project freeze , slow down, or go in a way that none user would agree with.

For open sources projects, this is different. Freebasic remains a nice choice since very much has been done to ensure it to be compatible with very important development libraries, such as windows.bi, opengl.bi and may others. So at project level, freebasic doesn't seem to me to be cursed in any maneer. Extend a fb code in most of cases would be possible (if not easy) even after the death of the author. The crucial point is somewhere else anyway.

From what I've been able to observe (browsing sourceforge) , a project, to get continuity must have sufficent interest, originality, and also have reached its critical mass. The critical mass is what ensure that your project cant anymore be reset, and should be preferably continued rather than restarted of forked - unless some serious wound occures, like change of licence (see how oracle has hampered openoffice by its change of licence) .

In any language, for a program, originality, interest, and critical mass are difficult to meet. But if they do, the language is rarely an issue, not to say never. Look out how Fortran libraries are still flying around over the mathematical applications, not to speak about Cobol (for bankers?)... This all said to temper a little this midnight pessimism!

[BasicCoder2]

Extend a fb code in most of cases would be possible (if not easy) even after the death of the author.

It was just a thought bubble and by all means pop it.

[caseih]

If the program is sufficiently interesting, and if the source code is available, then others could pick it up and maintain it if they chose, easily. However it's not enough that the source code is available somewhere. The author has to grant permission for others to use it after his death. This would be in the form of a license of some kind. Perhaps one that says if the work is ever abandoned you can have the source, or if the author dies, or it could be some kind of open source license. In many cases, only the binary was available in the wild, and when the author died and his descendants cleaned up his things the source code was lost. And that truly orphans a work forever. It's certainly happened before.

In all honesty, this is a reason why basing a business on open source software is sometimes less risky than picking a proprietary solution. Even if an author does not die, the product certainly could die of neglect or fold under competition. I'd wager we have more than a few PowerBASIC using FB, especially now that the company's future is very uncertain.

As for the choice of language itself, FB is not an unusual language as far as structure goes. Almost any programmer (professional at least) could pick up some FB source code and understand what it's doing in fairly short order, even having never seen it before. A less popular language does make a project less likely to be picked up and maintained by others (less interest), but it certainly doesn't prevent it.

[BasicCoder2]

Almost any programmer (professional at least) could pick up some FB source code and understand what it's doing in fairly short order, even having never seen it before.

Indeed this is the case. I was exchanging image processing ideas with a professional c++ programmer who had no problem reading my FreeBasic code even though he had never learned BASIC. His attempts to get me to learn advanced c++ however failed. It does say something about the simplicity and readability of a BASIC like language.

[jevans4949]

This is always a problem for any large organisation which develops projects using "niche" languages. It's why IBM is still able to sell hardware; banks and other large businesses have invested millions in applications developed in its assembler and language dialects over 50 years, and can't afford to re-write them. Often they haven't got resources to investigate exactly all the things the present applications actually do. A shipping company I worked for decided to replace its IBM systems by beefing up a Unix version developed by its subsidiary in Australia; when it went live in the UK, staff on the ground found there was no mechanism for send empty containers back to China.

Also, applications often contain code built for efficiency that are specific to particular software or hardware systems.

Real problems arise when you need to move your old software to new operating systems and hardware. Bad enough with popular compilers / databases / GUIs. If you then tell management: "We need to convert the compiler to the new hardware before we can port the application - and by the way, nobody here knows how the compiler actually works - and since we last compiled, there have been 5 new releases of the compiler." ...

[marcov]

As programming is just a problem solving exercise for me, and as an old low level QBASIC programmer, FreeBASIC fits like a glove. However it struck me that any commercial software written in FreeBASIC will have the weakness of not having any on going support should the author lose interest or become ill.

This is also the case with other languages. If nothing has been arranged, you need to hire new people, and they will have to do a post mortem evaluation of the product with only the information that has been recorded somewhere (usually: not much).

At that point the new people always will want to kill the old and create the new. Language, new language level concepts (think of stuff like LINQ etc), new libraries different GUI libraries etc etc. And basically that is everything if a package is ten-twenty years old (since the whole thing with programmers dying is a long term business anyway)

20 years ago, STL was not standardized, GCC was fragmented, .NET had not been invented, people coded win32 apps by hand in VB6 (now also deceased).

IMHO it is just an argument for people to justify their choices, and except for some sweat shops that rely on a constant flux of just graduated new programmers (because the old ones are too expensive, and thus retraining for any non standard at the moment is a serious cost) it really isn't as black-and-white as most people make it out to be.

In reality if such event really happens, you won't be able to put a green as grass person with only the knowledge-du-jour on it anyway, simply because production software is generally in the technology of at least 5 years ago. Usually more.

[marcov]

Almost any programmer (professional at least) could pick up some FB source code and understand what it's doing in fairly short order, even having never seen it before.

Indeed this is the case. I was exchanging image processing ideas with a professional c++ programmer who had no problem reading my FreeBasic code even though he had never learned BASIC. His attempts to get me to learn advanced c++ however failed. It does say something about the simplicity and readability of a BASIC like language.

I do vision in Delphi for a living. Yes, that means once an year I need to translate an header for a new camera, and I can't e.g. do some proof of concept code with opencv (for production it is usually to generic and slow anyway), or at least it is less convenient (through a C wrapper with the loss of generic types)

I guess if you start from zero, C++ might be easier, because all the free frameworks are in C++. But once you get going and have your own code for most things, the burden is not that high.

[BasicCoder2]

I do vision in Delphi for a living.

Delphi was often offered on the CD's stuck to computer magazines but I could never get it to work.
Giving vision to a robot had always been a dream to me. The closest I have seen available to a hobbyist is RoboRealm.
Nine to ten years ago the c++ programmer I mentioned introduced me to the idea of simplifying the image and breaking it into areas (faces) and vertices, edges and quad trees to end up with tables to traverse all over the image. I don't know if you use any of that stuff?

[marcov]

I do vision in Delphi for a living.

Delphi was often offered on the CD's stuck to computer magazines but I could never get it to work.
Giving vision to a robot had always been a dream to me. The closest I have seen available to a hobbyist is RoboRealm.
Nine to ten years ago the c++ programmer I mentioned introduced me to the idea of simplifying the image and breaking it into areas (faces) and vertices, edges and quad trees to end up with tables to traverse all over the image. I don't know if you use any of that stuff?

No, we do more quality assurance and less logistics automation. Our main product is a beer bottle dimension inspector.

The primitives are mostly blobs, edges and projections, and in the dimension inspector a lot of FFT. Nearly everything we do uses 8bpp grayscale. We do a lot of linescane at higher resolutions (say 2048x5000 or so, the y dimension synchronized with an quadrature encoder) at framerates from 7 to 20, and 1-8 cameras. Area scan is typically in the 1300x700 magnitude, though higher res cameras are coming, up to 25 frames, 3-4 cameras. (the linescan cameras often have more optimized performance)

[BasicCoder2]

@marcov,
Although I have read about the use of Fast Fourier Transformations in image processing I don't understand the math to actually use them.

I can see that a line scanner would work well for a continuous movement or bottle spin.

After googling the subject I see bottle scanning can be a very complex process with many different problems to solve.

[Dinosaur]

Hi All

Just felt a need to respond on this issue.
I have been programming applications for Industrial Weighing machines (using FreeBasic) for 10 years or more,
and QuickBasic & Assembly for 15 years before that.

When I retired I contacted every customer, and gave them an option of purchasing a cd for au$200 that included
every drawing / purchase order / supplier detail associated with that machine.
It also included the source code , the FreeBasic environment and any libraries I used.
In fact they could duplicate the machine with the detail provided.

Of the 400 something machines I sold worldwide, at least 200 are still in production environments
BUT only about 30 customers responded and bought the cd.

So, when the others break down, they have expensive boat anchors, but I did the right thing and gave them the option.

Also one of the reasons my machines were never PLC driven, was that the software of my very first machine written
for a 8088, will run on the latest Industrial CPU boards without having to re-compile. So hardware upgrades are not an issue.

So, the issue of backup is in the court of the buyer, as in what the conditions of the purchase included.
Some of the larger organisations that bought equipment from us (International Mining giants) insisted on the source code option.
I am talking here about a two person company.

The attraction of your product for THAT customer is how well you have interpreted their needs and translated
that into a solution with all contingencies.

[BasicCoder2]

I do vision in Delphi for a living. Yes, that means once an year I need to translate an header for a new camera ...

That is another downside for FreeBASIC. It depends on someone who can translate headers. As one of my interests involved grabbing images from multiple webcams I would not have chosen FreeBASIC had Joshy not made escapi.bi for that is something I could not have done myself. With Java or Python there is always that sort of support because so many people use the language.
.

[marcov]

@marcov,
Although I have read about the use of Fast Fourier Transformations in image processing I don't understand the math to actually use them.

The bottle is scanned while standing on a spinning plateau. The bottle is never perfectly centered on the plateau, and the plateau and its axis is also never perfect. The measurements typically have 0.02 mm tolerances. The off center spinning is a sinus ->FFT.

I can see that a line scanner would work well for a continuous movement or bottle spin.

The line scan is mostly for so called web applications, where a sheet of material is going though a machine. Some weld inspection too.

After googling the subject I see bottle scanning can be a very complex process with many different problems to solve.

Don't get me started :-)

[marcov]

I do vision in Delphi for a living. Yes, that means once an year I need to translate an header for a new camera ...

That is another downside for FreeBASIC. It depends on someone who can translate headers. As one of my interests involved grabbing images from multiple webcams I would not have chosen FreeBASIC had Joshy not made escapi.bi for that is something I could not have done myself. With Java or Python there is always that sort of support because so many people use the language.
.

I never saw a Java or Python interface with any of industrial cameras. I actually never saw somebody use Python professionally, OR use Java outside a really big company (an enterprise) or something related to government or educations. Small and midsized companies don't seem to use Java, and certainly not for anything technical related like Vision. Java is the language of big administrative systems, not engineering. (or at least it was, I exited that market 10 years ago. Maybe Python is now pervasive in it too, but as said, I never encountered it in the wild)

Very rarely I see Java use (and C#/VB.NET) in homegrown HMI programming at our customers.

Usually the SDKs is based on one or two versions of VS C++ only (typically now 2008 or 2010) , sometimes with a more generic (and thus slower) driver like activeX, directshow or something dedicated for labview. About 3/4 of them provide a plain C interface (also because of VS C++ version independence).1 in 5 has a kernel module for Linux (but with a list of distro and version limitations that scares me).

The managed languages (typically C#, sometimes LabView, VB.NET is getting rarer) typically use the generic, not the serious^H^H^H native driver. The generic drivers are easier to install, and not the drivers that require to install a special (DMA) driver that keeps CPU use under control at higher framerates.

Note that C++ is not all peachy too. Many of those SDKs are complicated due to multiplatform and -version reasons. As long as most keep shipping plain C headers, the Delphi solution isn't actually that bad.