What objective is being sought in the coming releases?

[Tourist Trap]

If I had to push a feature on the top (a reasonable one), I would ask for (built-in) array comparison:

Code: Select all

if array1=array2 or array1<>array2 then....

[Kot]

Make vbcompat.bi and datetime.bi obsolete.

[caseih]

Make vbcompat.bi and datetime.bi obsolete.

I would push for the opposite. Rather than bloat the FB keyword-space, I'd prefer to see many other things in the runtime library pushed out to .bi files. That way you can use them when you wish to, otherwise leave the symbol names open for the programmer's own use. Most languages have maybe 30-40 reserved key words. FB has many times that. Another solution might be to push many of them into a special namespace.

[Tourist Trap]

I would push for the opposite. Rather than bloat the FB keyword-space, I'd prefer to see many other things in the runtime library pushed out to .bi files. That way you can use them when you wish to, otherwise leave the symbol names open for the programmer's own use. Most languages have maybe 30-40 reserved key words. FB has many times that. Another solution might be to push many of them into a special namespace.

Do you have examples of what you would remove just to make it clearer what exactly you mean?

[greenink]

Hey, everyone wants different things. I kinda would say it none of my business in what direction FB goes. That is really up to the people who work on the source code for free. If you make the effort you get to decide.

[caseih]

Do you have examples of what you would remove just to make it clearer what exactly you mean?

Sure. The main example would be the graphics API. line, draw, pset, bload, screenres, etc. Other built-in functions could be exposed though a .bi file too, such as the various conversion functions like CVI, etc. In fact most of the functions in the runtime library don't need to be part of the language proper. Even MID(), CHR(), and friends. This would leave a nice compact language core and you could still use all the nice batteries that BASIC has traditionally included if you require them.

Now I'm not seriously expecting FB developers to do this. There's far too much inertia. Nor do I think my words carry any intrinsic weight (I agree completely with greenink). But if I were going to do my own FB-like language, I probably would keep things very small and put most things into include-able modules, like all other languages seem to do.

[sancho2]

The language C (and others) has no classes so thats a head start in fewer keywords.

Not in google but my own estmate based on wiki list
Freebasic is 400+ keywords
not including compiler directives (#...)
not including underscored macros (__function__)
including keywords that add on to functions (trans)

From google search:

Code: Select all

Lists of keywords in ...
    ANSI COBOL 85: 357
    SystemVerilog: 250 + 73 reserved system functions = 323
    VHDL 2008 115 reserved words
    C#: 79 + 23 contextual = 102
    F#: 64 + 8 from ocaml + 26 future = 98
    C++: 82
    Java: 50
    PHP: 49
    Ruby 42
    Python 3.x: 33
    C: 32
    Python 2.7: 31
    Go: 25
    Smalltalk: 6 pseudo-variables
    iota: 2

I don't think we should turn this into a features request thread, so please don't post those here.

[Tourist Trap]

Sure. The main example would be the graphics API. line, draw, pset, bload, screenres, etc. Other built-in functions could be exposed though a .bi file too, such as the various conversion functions like CVI, etc. In fact most of the functions in the runtime library don't need to be part of the language proper. Even MID(), CHR(), and friends. This would leave a nice compact language core and you could still use all the nice batteries that BASIC has traditionally included if you require them.

In other words those instructions would be required:

Code: Select all

#include "graphics.bi"
#include "conversion.bi"
#include "string.bi"

Doing that (it's rather radical) would very probably break compatibility and expectations related to a BASIC familly language.
One of the reason people (beginners first) are choosing BASIC, FreeBasic here, is that it doesn't require any "include" until the coder really starts using very advanced additions.
Moreover this is how this was done before (in QB etc...), so if you just write down a program from older times (at least algorithms) and compile it, it will generally work just without any question. If it doesn't, it won't anyway be for an include missing (and what include?).

This would however be an interesting alternative for the fun, or for very special issues, to get a mini-fb, with no command at all. This means you would have to use "crt.bi" and all the C stuff or ASM stuff, alternatively API stuff if you have an API at range. It would be then a C in disguise. But after all, this would probably fill some needs, probably for low ressources embedded systems.
Said differently:

Code: Select all

#lang "minifb"
dim .... ' works
print .... 'not work!

The language C (and others) has no classes so thats a head start in fewer keywords.

Sancho2, it's hard to compare. It's not a question of classes. For instance VB.net has classes. So you will include features via classes, and the class itself will manage with multiple low level includes that are required for his work. So you won't see the includes by just adding an object to your code, but the object definitions will certainly rely on a forest of hidden includes. For instance, if you want to write to the console, you'll need the console class, that will do all includes needed for IO operation at console level (is it CRT, is it windows API?, or something else). But this is different to add an object, than to add an include file. One is natural (hides technical stuff behind the class code), the other is just technical.

Moreover, Visual Studio can manage the includes in the "references" menu, so it can be again hidden. In fact Visual Studio hiddes almost all it can.

FB is not class based as VB.net is. FB has no dedicated IDE (that for instance will automate includes when recognizing an external command). So if you are to include commande files, it will be by hand, like in C. I mean this is really a style that sounds and feels C, not BASIC. As far as I know because I'm not a C programer! Precisely because I could hardly just print "hello world" to get started...

[BasicCoder2]

I'm not a C programer!

C is an easy language to learn with an almost one for one translation to BASIC being possible. I used it for about two years during my MSDOS days. By using a C++ compiler you will also have access to lots of useful objects even if your program itself is not object orientated.

Without a team of enthusiastic developers I see no future for FreeBasic. Indeed last week I decided to stop using it and start playing with more modern and easier to use languages when it came to things not supported by FreeBasic. Like other FreeBasic programmers that have moved on I will probably visit the forum occasionally but as a useful tool for a novice or occasional hobby programmer FreeBASIC has had its day.

.

[Tourist Trap]

I used it for about two years during my MSDOS days. By using a C++ compiler you will also have access to lots of useful objects even if your program itself is not object orientated.

C++ is a very hard language. Seriously you must try and give us your feedback only then. And it's object oriented by design. Or I can't see why one would use it? Ok, you can use a C++ compiler compatible with C. But if you dont do OOP, you will really not do much C++.

Without a team of enthusiastic developers I see no future for FreeBasic. Indeed last week I decided to stop using it and start playing with more modern and easier to use languages when it came to things not supported by FreeBasic. Like other FreeBasic programmers that have moved on I will probably visit the forum occasionally but as a useful tool for a novice or occasional hobby programmer FreeBASIC has had its day.

BasicCoder2, FB has enough power right now to be extended by the users. There will always be a need for core development of course, at least to keep things compatible with newer systems.

My opinion finally, is that you need a trip on C++. Then, once you get used with OOP concepts (building bricks that adds to the language), you will start making collections of objects, and then, you will very probably notice that even in the current state, FB could also have its own of plenty of objects that would empower it ad infinutum.

This is how VB.net is done. So to say it differently, once reached a sufficient amount of OOP capabilities, a language just requires objects development to keep forever growing. It's a total change of scale that you have underestimated until now, but switching to a pure OOP language will soon make you understand my point, I'm pretty convinced.

[sancho2]

I would push for the opposite. Rather than bloat the FB keyword-space, I'd prefer to see many other things in the runtime library pushed out to .bi files. That way you can use them when you wish to, otherwise leave the symbol names open for the programmer's own use. Most languages have maybe 30-40 reserved key words. FB has many times that. Another solution might be to push many of them into a special namespace.

Isn't it true that the compiler vets only the keywords that are used? So, is the only issue is the programmer not being able to use the keywords as variable and function names?
You can get around this with a naming convention in which you custom prefix your variables.

Basiccoder which language did you choose?

[caseih]

I used it for about two years during my MSDOS days. By using a C++ compiler you will also have access to lots of useful objects even if your program itself is not object orientated.

C++ is a very hard language. Seriously you must try and give us your feedback only then. And it's object oriented by design. Or I can't see why one would use it? Ok, you can use a C++ compiler compatible with C. But if you dont do OOP, you will really not do much C++.

Yes and no. Just because you use objects doesn't mean your code is object-oriented. There's nothing wrong with procedural C++ code, or event-driven C++ code. One of C++'s redeeming graces is that it's not like Java where everything is forced into some kind object-oriented paradigm even when that's not appropriate.

[caseih]

Without a team of enthusiastic developers I see no future for FreeBasic. Indeed last week I decided to stop using it and start playing with more modern and easier to use languages when it came to things not supported by FreeBasic. Like other FreeBasic programmers that have moved on I will probably visit the forum occasionally but as a useful tool for a novice or occasional hobby programmer FreeBASIC has had its day.

I guess I don't understand your logic. Mature languages move very slowly, for good reason. The latest revision of C is C11 (2011), nearly 12 years after C99. And many compilers still don't support C99 yet, and many features are convenience features that many programmers may not find essential.

I guess my question is, what more do you want from FB? As a compiler it's just about feature-complete and stable. The last thing any programmer should want is an unstable language!

[marcov]

Without a team of enthusiastic developers I see no future for FreeBasic. Indeed last week I decided to stop using it and start playing with more modern and easier to use languages when it came to things not supported by FreeBasic. Like other FreeBasic programmers that have moved on I will probably visit the forum occasionally but as a useful tool for a novice or occasional hobby programmer FreeBASIC has had its day.

I guess I don't understand your logic. Mature languages move very slowly, for good reason. The latest revision of C is C11 (2011), nearly 12 years after C99. And many compilers still don't support C99 yet, and many features are convenience features that many programmers may not find essential.

C is a very bad example, since it is more driven by OS and embedded developers than by application developers, as well as keeping its place as lowlevel brother of C++.

It makes the pace glacial, and the new feature direction fairly irrelevant for application developers.

[caseih]

Well the same argument applies to C++ as well. It moves at a slow speed, for good reason. C++-17 does add some nice features to the language, ones that are getting used more and more as people embrace an asynchronous paradigm for programming. Even a popular language like Python or Ruby moves fairly slowly. The last thing any developer should want is a language spec that is constantly in flux.

I disagree about C being driven primarily by embedded developers. It may surprise you but C++ is used every bit as much as C in embedded space. C is used in lots of spaces and that alone is why C is kept stable and slow moving.

Again, though, I ask really what more does he want FB to do? A new compiler release every few months doesn't translate into a benefit for developers. Bug fixes in the compiler are far more useful than new features at this point, given that FB is mature and feature-complete. Seems to me most features that aren't really a function of the compiler or language, but of add-on stuff. They want a nice IDE with rapid-application development tools for doing GUIs. This isn't part of the compiler or language. It certainly can involve developers in the community using FB though! And there are some nice tools people are working on, such as FBIde.