FreeBASIC Looks Dead

[AGS]

I don't think that FB is dead.

The only thing I'm concerned about is getting a 64-bit compiler, so things work on Vista & Win 7, (If I EVER move on to those OS's..), but other than that, I just chug along using whatever version of FB I downloaded a year ago.

I use the FBC on Windows 7 Pro (64bit) and have not experienced any problems using FBC or the programs it produces.

[boriel]

I also thought FreeBASIC was dead until I entered this forum today. I've created a compiler for a retro-machine (ZX Spectrum) which is compatible with FreeBASIC syntax (up to some extent).

I think that FreeBASIC language is rather complete now, and adding C++ features like static objects, "templates", or alike is an error. This is not expanding FreeBASIC (which should be a BASIC to learn language, indeed), this is C-izing FreeBASIC (as someone complained in other thread), and so, making hard to program in BASIC so it's better to switch to C++.

BASIC is supposed to be a High Level Language (C is a low-level one, so allows more control of the machine, but requires more knowledge by the user, and a longer learning curve). E.g. in many BASIC implementations, SIN and COS are reserved words of the language. In C they are external functions: users must find a library (ok, math libraries are very common) or implement them themselves.

Things that could be improved (Note: I don't know al the current features of FreeBASIC so some of them might already be implemented!):

These are less important (from my point of view):

• Object inheritance: If it has objects, it makes sense. Inheritance and polymorphism (virtual methods).
• Better (updated) libraries and more platforms. FreeBASIC should be ported to x64 architectures (Linux, Windows, Mac), and also come with more widget libraries.
• Someone should also create a good IDE. Don't know what others use over there, but it's a good idea to have a standard IDE if possible.

Now, the most important for an *evolving language*:

• Strings ByVal and ByRef (my 8bit compiler already implements that, so it's possible). This is high level language, so this should be allowed.
• More high level structures, like nowadays high level languages (e.g. python): Lists (not dynamic arrays, but real lists) and Dictionaries, and even Trees.
• Those containers should contain any kind of object (like a "Variant Type"). I mean, a single array might contain an integer in one position, and a string in another.

This 2nd list is what, IMHO, BASIC should evolve to. Using "pointers", and so on is going to the lowlevel C-ish language (and C/C++ already exists). Going to higher abstract data structures is what current languages do, because that's what's suppose we human do: higher level of data abstraction. Eg. Python, Java and many others (don't use pointers).

If I'm going to manage "a dynamic array of pointers to objects", then I will write such a program in C. This is no "basic" at all, it's advanced instead. But if I'm going to manage "a list of items of any kind" (numbers, strings, arrays, objects or even other lists) then that's BASIC with new features.

Hope I've explained well :( (I'm not a native English speaker, so sorry in advance).

[kiyotewolf]

@AGS

Are you creating 32 bit binaries that still run on 64-bit Win7 & Vista?

If so, then that's awesome, I don't have to do anything.



~Kiyote!

[anonymous1337]

@kiyotewolf:

FYI, most 32-bit applications will run on 64-bit Windows. Just how 16-bit apps ran on 32-bit Windows for a long, long time, except that support seems even better this time around.

Think about how limited 16-bit memory was vs. when 32-bit came around. Memory addressing hasn't changed much this time, so few things need to be changed to retain compatibility.

In addition to this, 64-bit processors support both 32-bit AND 64-bit commands.

[rdc]

I use Vista 64bit and have no problems creating or running FreeBasic (or any 32bit) programs.

[badmrbox]

Same here :).

[McLovin]

I'll have a complete visual designer (100% winapi based) ready for the community very soon. Very similar to Visual Basic. I really hope that once it's out that it will make creating Windows based applications much easier.

I would also like to see a new official FB release.

[Jim Barlow]

"Very similar to Visual Basic"

I like the way VB (and Jabaco), when you double click the widget, creates a sub and puts the cursor right where you need to be coding for that widget or event. Make it do that and I'll use it for sure. Visual C# does the same thing and it makes life very easy.

[aurelVZAB]

I agree with some points which boriel says.
FB must be more basic, less C/C++ like.
I dont know if FB have Linked List implemented like commands
CreateLinkedList.

[boriel]

I agree with some points which boriel says.
FB must be more basic, less C/C++ like.
I dont know if FB have Linked List implemented like commands
CreateLinkedList.

Thanks, aurelVZAB.

In fact, C# is C++ with some nice features (like higher level data structures). So it could be a good example of what I was trying to explain...

[marcov]

I use Vista 64bit and have no problems creating or running FreeBasic (or any 32bit) programs.

Shellextensions and other plugins for 64-bit programs are the problem.

And of course that one program that really needs a lot of memory. But mostly plugins.

And that will get worse when more programs become 64-bit. (e.g. mozilla in fall)

[1000101]

C is a HLL. There is only one LLL for x86 and that is x86 asm (although there are a few syntax differences between assemblers, they are use similar mnemonics). FreeBASIC is not C it is only similar to C in the way PASCAL is similar to C, ie: it's a programming language and supports similar features but has very different syntax and methodology in it's implementation. Just because FreeBASIC has pointers doesn't make it C.

FreeBASIC is pretty close to complete in my eyes, some things which need to be finished off are inheritance, polymorphism and just the plethora of bugs which abound in the compiler and libraries. Adding crud like collision detection is a program logic issue and are implemented within your code and are not the rtl. Some things like linked lists or trees are common enough and used in enough different situations that an rtl implementation may be a good idea though (but god help you if you implement a slow method).

64-bit output is completely unrelated to the language itself, as is porting to any specific platform.

[boriel]

C is a HLL.

It's not, or at least, not as higher as BASIC. Basic has dynamic array support in the language. C requires the user to create the structure itself. So lower level: A C user must write much more code to achieve the same result.

In fact, FreeBasic uses C as a backend (well, it's planned). And it makes sense.

Adding crud like like linked lists or collision detection are a program logic issue and are implemented within your code and are not the rtl.

I don't agree: You're thinking in C: "linked list" is a list made with pointers. A "list", on the other hand, is a HLL data structure (e.g. python), and a BASIC user/programmer shouldn't have to learn how to implement it in the low level (eg. pointers, dynamic arrays, or trees + linked lists as some languages do). For example, you have lists in python, but you needn't to know how they're implemented, nor what pointers are being used, etc.

It is not only related to "linked list". What BASIC needs is an Iterable Dynamic Object Container (of any kind). A Dynamic array could be one of them, by the way.

Other thing that could be useful is Network/XML/Web services libraries (perhaps already done???). But think in a HTTP client capable of download an RSS feed from a host, written entirely in FreeBasic.

64-bit output is completely unrelated to the language itself, as is porting to any specific platform.

It's related to the compiler, and partly to the language if there are data types that make reference to them (Just an example: If Ulong means 32 bits, ULongLong could be 64bits).

I agree with you FreeBASIC is a complete language at this point, that's right. But if you want it to "evolve" in some way, let's think what could be done/improved: Take any FreeBASIC listing, and think how could that listing be reduced without losing legibility.

[ciplogic]

C is a HLL. There is only one LLL for x86 and that is x86 asm

I can say for certain that C is not HLL and just to state this are: function pointers, macro processing, no sane way to get the linker working sometimes (which is much lower level than simply link to a module, as you do with Java's JARs).
I can agree with you that is medium level language, but a lot of things you have to do it manually.
Take for example C++: you have templates and OOP classes which rely on mapping function pointers (the object vtable) and on code expanding (templates). Both can be implemented in C, with your hard work, but you shouldn't.
On a later extend, there are languages (here I mostly think to C++, Delphi/FreePascal language, as native one or C# as a "managed" one) that allow multilple level of abstraction. FPC can let you program with assembly, procedural programming, OOP reference based classes that expose reflection. So you can have LLL, MLL and HLL. On the same extend C# have "LLL" that is "unmanaged code" where you can call native C/C++ compiled DLLs, you have typical if/else code in OOP fashion (with classical OOP or with Generics) and you have functional (Linq, Lambdas, etc.) and dynamic features (dynamic from .NET 4).
Judging this, for certain a year 80s language as is C, is more than a low level language, with the single "feature" that it offer a library that is machine independent (the libc one). Can you implement with low level languages abstractions? For certain, look on GTK+ and C implementations. Wanna a high level language for this package? Try Vala to get a good clearance on this

[Sebastian]

Adding crud like like linked lists or collision detection are a program logic issue and are implemented within your code and are not the rtl.

I don't agree: You're thinking in C: "linked list" is a list made with pointers. A "list", on the other hand, is a HLL data structure (e.g. python), and a BASIC user/programmer shouldn't have to learn how to implement it in the low level [...] For example, you have lists in python, but you needn't to know how they're implemented, nor what pointers are being used, etc.

Good point, boriel.