FreeBASIC Discussion December 2017

[marcov]

Since I'm not a real user, from me more an project architecture perspective:

I like it (still) has a native backend.

I also like the Native RTS effort immensely (and I think even in the GCC backend case, it is important to have as much as possible natively)

Documentation is also fairly ok it seems. Could always be better, but that goes for any documentation, even commercial offerings that have had fortunes poured into them.

[StringEpsilon]

Part 1 - Strengths

The language and RTlib:

* The type system is really solid, without too much complexity
* The syntax is rather consistent
* It's reasonably easy to learn while also being "close to the metal".
* The runtime library covers a lot of boilerplate functionality - but without feeling bloat.
* It's completely open source (many other BASIC-dialects aren't)
* It's general purpose / very versatile.
* Multiplattform-support.

And not direclty a strength of FB itself, but a big factor in what makes it attractive:

* The documentation is pretty good
* The community is pretty centralized, making it easy to ask questions and get an expert for the topic quickly

[panoramic]

Part 1 - Strengths

FreeBasic is:
- free
- easy to learn
- easy to use
- portable
Its new releases are backward compatible.
It has a good documentation.
Its community (forum) is active.
It has a large library of softwares (sources).

[MrSwiss]

Part 1 - Strengths

What hasn't been mentioned so far, but important (IMHO):

FreeBASIC allowes, to write Library's (dynamic or static), independent of:
any other Language(s), aka: native FB code ...

[BasicCoder2]

Has the easy to read and write BASIC style with the kind of speed and power of C and some of the features of C++. C-like extensions to squeeze out extra performance when required. Ability to make use of C libraries. Nice innate super fast easy to use 2D graphics and image commands.

[badidea]

FreeBASIC is awesome!
(now waiting for part2, tomorrow)

[coderJeff]

Part 1 is now concluded; Thank-you to everyone for sharing your posts about FreeBASIC strengths. The intent of part 1 was to get everybody looking at what fbc & community are doing well. I think it is important to recognize those strengths before the criticism and discussing all the weaknesses.

START OF PART 2

Here we want to identify where FreeBASIC compiler or community need to improve and preferably offer a suggestion on how we might accomplish that goal. 1 post per user gives everyone a chance to voice their opinion.


My Post:

FreeBASIC Weaknesses & Improvements

1) fbc development: the compiler can be built to several targets within a single development tree. for example both 32bit and 64bit. but only produce a single output executable - I find that difficult to work with. Some minor changes to the build/makefiles would allow multiple targets to co-exist within same tree, mostly keeping object files in separate directories and naming the newly built fbc compiler have different name per target. Changing the way fbc gets built potentially affects many users so needs a discussion.

2) FreeBASIC community: I think users (new or old) should make an effort to solve problems to the best of their ability on their own; they should expect to make some effort to learn new things (read the manual, etc). And the community at large should be prepared to respond to the questions or the lack of information when the questions are asked; making updates to tutorials, the documentation, etc. I think everyone can help with this by being patient and diplomatic, and promote that attitude.

3) Wiki Logins: wiki logins don't work, new users can't be easily added. Something I am working on improving myself, but I am very slow.

4) FreeBASIC documentation: Over the years documentation has been improved and evolved, but it is also looking inconsistent throughout. Some of the example codes are quite lengthy and could be simplified. One idea, create a checklist of criteria that each topic needs to meet. When a person is reviewing a topic, they can validate the topic content against the checklist. More of a content guide than a style guide.

[panoramic]

Part 2 : FreeBASIC Weaknesses & Improvements

In my point of view, I regret that Freebasic is not available for OSX.
I found an unofficial FreeBasic 1.04.0 OS X release, but I'm not able to use it.

An improvement would be that somebody adapts the compiler to MAC OSX. In that case, I write an IDE for this compiler.

[jj2007]

FB weaknesses:
- documentation all over the place; I needed Google and the help of forum members to find the manual (and there are clever members who complain that users don't read the FM)
- lack of crispy little demos that could attract n00bs and help more experienced users to get started
- strange that FB needs a C compiler a) as a backend and b) to build itself
- too much influence from the C/C++ world; empty stuff like

Code: Select all

constructor rect()
end constructor

that is supposed to look "professional" is simply awful. BASIC used to be a simple and beautiful language...

[lizard]

In the beginning it seems simple. With little experience you understand you can download the compiler and do a "fbc <name>.bas" at commandline to produce an executable. Basic Syntax is well documented in a .chm file or online.

If you delve in further it all seems to become more complicated. If you try to use further libraries most things seem not to work out of the box. Mostly the user has to figure out which and how to use an IDE, how to get the libs, .dll, .so., .a, .lib files or whatever. At this point many people will give up i believe and try other languages.

[JohnK]

Generally agree with what has been said but specifically

1) Forum needs a better search. You can't search 'Qt' or 'IUP' What?????

2) FB is great if you like old-style QB language, but for FB to grow (and continue to be relevant) it needs a powerful native GUI or at least a large sample of code files using a specific library. FLTK came close, but nobody posts code using it.

Visual Basic is arguably the de-facto BASIC language and has probably the largest sample code base. I dislike .NET but like VB6, so I wished FB had gone in a more VB6 direction. You really can't translate a lot of VB code to FB because of no native GUI. That we don't have a multi-platform IDE written in FB highlights this. To achieve this requires a real commitment of several developers, not just one person.

3) No surprise here... support of C++ libraries in a BASIC like syntax... but I realize that may never happen. This would be great...?
DIM Form AS QT_Form
Form.Size(1200, 1000)
Form.FontName = "Ariel"
Form.Text(20, 20, "Hello World")
App.Show

4) I like sample code easily accessed by a webpage (for example http://rapidq.phatcode.net/examples/). Looking for the most up-to-date sample code on FB Forum is really painful.

5) sample code requiring dependencies needs to clearly state that, and should provide instructions on how to download/install the libs/dll files. I spent hours trying to get the GTK samples to run. Never got them to work... gave up. You just don't want that with new users.

[sancho3]

There is a lot of wish-list type stuff I would like for the language.

Here is a couple of things where the first two, not much can be done about:
1. My number 1 concern is the stagnant development (or near stagnant).
2. There is a lot of sample code out there but a lot of it is outdated, not maintained or the links are dead.

3. FB keywords are not in their own namespace. This would free up some keywords that are naturally variable names, without resorting to undefines and other tricks.
4. It seems to be that certain types of variables are built for nearly every program. An point/x,y type of variable should be native.
I would like to see a list type built into the language.
5. Since FB has native basic graphics commands, it should also have some native sound commands.

Probably none of these items are very easy to implement. Item #1 is most important.

[Lost Zergling]

Hi all,
Preliminary remarks
I shall notice : rules here : "If you like this idea, please participate. If you don't like this idea, please do nothing."...
Well, IT IS CLEAR we just are a small group of FB users here. Many "strong" profiles are missing :-( and this must make us humble.
I'm participating in this discussion about "the FreeBASIC Compiler & Community; it's strengths and weaknesses, and future actions" because I like the idea of an overhaul in a very open discussion.
This because Dkl is inactive and we do need "official" packages.
-----------------
I do not feel very concerned by builts, repository, git hub and so on. About FB "community" : I am not convinced by the idea of rules...
I like honesty and politeness so I try to respect others as I expect to be same respected. Sometimes using provocation and humor, that's thrue.
Wiki login and documentation issues does not interest me very much.
-----------------
I feel more in agreement reading sancho3's post.
I totally agree with him on two points : near stagnant development and a list type built into the language
About the second point :
A powerfull list support is a very important feature (up to my mind), that's why I'm working on a solution and I already have a far better version of my old LzListsEngine (viewtopic.php?f=17&t=24645)(serious bugs). I'm still working on it. It will be opensource and free for FB environment (but lgpl or lgpl compliant). I am aware that what I put months to code (test and debug), others would do as well or better in a lot less time. Specifications are efficiency with no need to be "built into the language". Would be great anyway a list solution out of the box included in package
-----------------
I agree with JohnK : FB needs a standard & official GUI and FLTK is probably (one of) the best candidate
I like TinyDialog very much as well as a complement because of licence, portability and efficiency (few memory load) so it is usefull for developping Tools, toolboxes and so on.
-----------------
About the future of FreeBasic ? (In my opinion, open discussion)
Common point between Java and Python : powerfull list type.
Common point between different list type implementation : memory virtualization (What's close in mind to Map/Reduce algo).
I am of the opinion that the Basic language is intended to take place between the two aforementioned languages.
This implies a reflexion on libraries with scientific vocation as well as on the idea of a sandboxed runtime with a limited version but likely to work on a browser. And so on. Other ideas welcome !
Best regards

[Carlos Herrera]

Weakness:
The Battleship FreeBasic is tugged to her last berth to be broken up in the harbour of abandonware.
Salvation:
Windows fork, maintained by gentle people who are refugees from the Raft of the PowerBasic

[counting_pine]

* For the most part, FB doesn't rely on any external libraries, and instead implements its own code for everything.
The main advantage is that it prevents end-users having to worry about additional dependencies, both in terms of library files and licence agreements.
The obvious downside is that everything in the runtime library has to be implemented from scratch, based only on the standard libraries that come with each system.

* In a similar vein, FB has not officially embraced any external libraries. There are many libraries where it provides basic C header translations, but there have been no (official) efforts to take advantage of FreeBASIC's additional feature set, e.g. packaging things up in classes.

* Another problem that's harder to fix is the lack of template support, meaning we can't easily provide things like versatile collections.
It would be great to have datatypes like maps, or sortable arrays, but without templates all we can do is:
- provide macros that construct the class and methods for each type
- provide generic containers that work only with pointers, and gets passed a set of all the functions it needs to create/destroy/look up members within it
- hard-code it all inside FBC (which makes the compiler more complex, and we can't really add many more features anyway, without adding new keywords - see the next point)

* A related problem is that FB currently has a restricted keyword space - we don't like adding keywords in case it breaks code, which makes it hard to add new functionality.
(If most of the keywords could all somehow be put inside a namespace, that could be a solution to this problem.)