FreeBASIC 1.08 Development

[coderJeff]

What I am more worried about, however, is that FB goes into the direction of a BASIC caricature of C++.

Due to some of the features we are going for (and requested) I have no doubt there are going to be some elements of FB that will remind users of C++. Just like pointers and manual memory management will remind them of C. Just like naked subs and inline asm will remind them of assembler.

The one thing that we are borrowing most heavily from C++ is this standard: Itanium C++ ABI. We do not use the full extent of it, but where it applies, we try to follow it. And we can still do things that are outside of this ABI, like strings and arrays and custom operators which have no equivalent in C++ and only exist in fbc.

Another language that uses same strategy is D language, and they have decent write up of the reasoning behind the approach. Interfacing to C++.

[speedfixer]

The issues raised are all beyond me and my needs.

Hi Dinosaur,
Your rant is perfectly understandable. What I am more worried about, however, is that FB goes into the direction of a BASIC caricature of C++. Nonetheless, keep in mind that this thread is about the development of the next FB version, so it's not really aimed at beginners or occasional users.

I agree with the sentiment of the apparent motion toward being a c++ look-alike, but I think that is much more a means-to-an-end as opposed to a target.
To get some things to work well, you need the language to evolve. External library adoption has been one the greatest strengths of FB. Some features not currently easily possible in FB will accrue from the couple of large additions in progress.

But I think this ease of using external libraries has been acting more as a huge impediment to its future.
It is too easy to adopt an external library for those things that should be brought into FB.

If this/any next version doesn't have some features aimed toward new users or beginners - FB is dead.

ESPECIALLY a casual user would want bells and whistles: sound, fonts, media, network.
A beginner needs some instant gratification/feedback.

How many of us got totally/completely hooked by quickly typing some random color block demo on the brand new Apple/C64/TRS80?

Today, that STILL is all that FB can do.

AND it can't even beep!


I love FB, but that's just sad.

david

[angros47]

If this/any next version doesn't have some features aimed toward new users or beginners - FB is dead.

I understand your point, speedfixer: that's why I tried to implement sounds for FreeBasic. Although, of course, another user seemed to dislike this idea: after all, there is no way to make everyone happy: some users want to keep compatibility with older basic, others want to move away from it, but in the end, if they don't know how to code, their opinions remain just opinions, words without consequences.

Anyway, OOP is a feature that surely adds a lot to BASIC: after all, not only FreeBasic, but also RapidQ and Visual Basic used a lot of features borrowed from C++.
Perhaps it would be easier if there were a default set of GUI commands, like in Visual Basic or RapidQ, but that topic had been discussed several times in the past: the issue is not the lack of a GUI, but the fact that there are too many of them. That is the only thing I miss from RapidQ: it had some native functions not only for the procedural commands (PRINT, INPUT.... all things that in basic can be done without external libraries, while in C or C++ need to include something), but also for OOP mode (the forms, the canvas, the buttons and so on). In FreeBasic, no class is available natively without some include file.

How many of us got totally/completely hooked by quickly typing some random color block demo on the brand new Apple/C64/TRS80?

Today, that STILL is all that FB can do.

Well, if it can comfort you, Blitz3D, and RapidQ could do much more natively. Now, they are obsolete, while FreeBasic is still here.

AND it can't even beep!

https://www.freebasic.net/wiki/wikka.ph ... =KeyPgBeep

[caseih]

Many a project has died, or at least got seriously sidetracked (I'm looking at you, Gnome Desktop), trying to cater to mythical new users. My opinion isn't worth much, and I don't actually use FB for anything other than porting some of my old QB and PB programs to Linux for shear nostalgia. But as long as FB serves the needs of its present users, and strives to meet the near future needs of its present users, I think it's doing okay, better than most open source projects. It's true that none of us will be around forever and hence the user base will shrink over time without new users. But surely FB filling a purpose now is just as important as appealing to new users, who may or may not have reason to consider FB.

I can see some future for FB in embedded space. PIC has been programmed in BASIC for a couple of decades (fairly successfully), so there's precedent for a BASIC dialect that compiles to an embedded processor. That certainly won't involve the same type of bells and whistles speedfixer refers to, although there is more a sense of gratification (look it lights up an LED when I push a button! Horray!).

Most of the languages that have shiny things for instant gratification will probably not last as long as FB has; they'll fade out when the new shiny comes along. For example, Macromedia Flash is dead and gone. Web frameworks come and go like the fashions they are.

Looking at the popular languages right now, several of them, including GoLang and Rust, don't really have any bells and whistles as far as fonts, colors, sound, etc go. Even Python has none of those things, although it has easy access to a huge number of libraries that make this sort of thing accessible and fun, such as a framework for making arcade games.

When it comes to "new users" I'm not sure what to think. When I was young, like-minded people picked up new languages and taught themselves because it was fun, despite the primitive nature of computing in general. In Uni the courses expected that we already knew how to program because we did. Now it's not like that at all. I don't know how I feel about modern student expectations nor what this means for the future of admittedly nostalgic projects like FB.

[caseih]

Anyway, OOP is a feature that surely adds a lot to BASIC: after all, not only FreeBasic, but also RapidQ and Visual Basic used a lot of features borrowed from C++.

What about other modern features like coroutines, closures or lambda expressions, or intrinsic asynchrous primitives?

Well, if it can comfort you, Blitz3D, and RapidQ could do much more natively. Now, they are obsolete, while FreeBasic is still here.

Absolutely true.

Another language that uses same strategy is D language, and they have decent write up of the reasoning behind the approach. Interfacing to C++.

Does this method allow D to access a fairly complicated class library like Qt? It would appear so, provided enough of the class definitions were translated. FB can call a C++ mangled function, but since it didn't know anything about C++ vtables last time I tried it, it couldn't handle any real C++ library where inheritance was used.

It would require way too much developer resources, but embedding both a C and C++ compiler (and preprocessor) into FB would be awesome. Then one could just include a C or C++ header file directly and have those symbols exposed to the FB program.

[jj2007]

What about other modern features like coroutines, closures or lambda expressions, or intrinsic asynchrous primitives?

No results found for "intrinsic asynchronous primitives"

Are you sure a BASIC dialect needs a C/C++ feature that is unknown to Google?

[caseih]

Are you sure a BASIC dialect needs a C/C++ feature that is unknown to Google?

Funny! Are you sure you googled for "asynchronous primitives?" By "intrinsic" I mean a fundamental part of the language. They've been a part of C# for quite a while. https://docs.microsoft.com/en-us/dotnet ... pts/async/. They are finding their way into the C++ standard. Even Python recently got into the game. I am not saying FB should add any of those things. I doubt most of us on this forum would ever use them so I wouldn't expect FB to support them. Those that need those things are already using them in other languages, and have no reason to move to FB ever.

[Carlos Herrera]

Perhaps it would be easier if there were a default set of GUI commands, like in Visual Basic or RapidQ, but that topic had been discussed several times in the past: the issue is not the lack of a GUI, but the fact that there are too many of them.

Unfortunately, the lack of a default set of GUI command has became a pitiful trademark of FB.
However, there are two good candidates:

• 1. FLTK, thanks to the efforts of J.P. Peters
  2. Gtk, thanks to the enormous work of TJF

Why not select one of those? I have a dream :
Gtk + GladeToBac distributed with FB as an official (default) GUI designer...

[angros47]

coroutines... something like this?

Code: Select all

#define crBegin static state as integer: select case(state): case 0:
#define crReturn(x) state=__LINE__: return x: case __LINE__
#define crFinish end select



function coroutine() as integer
	static i as integer
	crBegin

	crReturn (1)
	crReturn (2)
	crReturn (3)

	crFinish
end function


?coroutine
?coroutine

[jj2007]

Funny! Are you sure you googled for "asynchronous primitives?"

Yes. I even corrected your spelling error - but I used quotes, i.e. I did a phrase search using "intrinsic asynchronous primitives"

Those that need those things are already using them in other languages, and have no reason to move to FB ever.

That's the whole point. Those who need (and master) the whole C++ toolbox will certainly not wish to use BASIC.

[speedfixer]

@caseih & @angros47

" ... What about other modern features like ... "

This is not the place to reiterate that you disagree with each other frequently.

@angros47:

... It would require way too much developer resources, but embedding both a C and C++ compiler (and preprocessor) into FB ...

Here, I slightly disagree. That is exactly what has been happening slowly, step-by-step. And if I were the developer, and I had the desire for that level of functionality, I would do it also: slowly, step-by-step. Even if it wasn't a *conscious* effort. That's just how a person's mind works. I have no problem with that, as long as the core keywords and syntax remain BASIC.

FreeBASIC is still here because it has some overwhelming strengths:

it is familiar: BASIC - very low learning curve for basic features
relatively few natural language keywords - easy for totally newbie programmer (true: it is English)
very fast compilation - yields very quick gratification of a new idea
easy linkability with c libraries - you don't have to reinvent the wheel to get sophisticated features
relatively small and fast executable - this is what allows the vision for serious projects

The first 3 attract new users whether veteran programmers or complete newbies.
The last 2 keep you coming back.

My point was simply that I don't think this is enough to help FB survive for much longer.
I could be wrong, but the feeling I have is that a large bulk of us that are passionate about FB are old farts that won't be here much longer.
Whether it is nostalgia or that fact that fewer keywords make it a little easier for us old guys doesn't change the fact that it seems we don't seem to have any new Pritchards or other young passionate kids excited about the possibilities that FB promises.

Misquoted or not, Dykstra's comments means no BASIC will ever be a language taught in mainstream education, however powerful it is, unless a VERY complete package can be brought to the table.

FB falls short of that for now. But it does promise that it could be that complete.

dkl and coderjeff have been excellent developers as of late. I may be wrong, but it looked to me like neither one was truly eager to pick up the mantle of developer when they did.

I am very thankful they did, and there is more than one other person recently providing serious code and support to help FB stay alive and - in many people's opinion - move forward. But there is serious stagnation and little excitement *generally* for adding new features to FB. And the stupid little personality conflicts that pop up from time-to-time that cause ***major*** supporters to drop out reveal this to be true.

How many newbies have shown up in the last five years that just can't get enough FB?
I don't remember any.

I was like that when I first arrived here. And I still have that interest. But I am part that 'old fart' set that will fade away. I think I am like the others in my age group: I no longer have the ability to keep a high level of focus for a long period, and feel the future is just not long enough. So, we don't commit to real development of FB. So, that is why several in my age group are using their perception, logic, humor, and other skills to notice faults and problems, help identify questionable code/topics/philosophy and can still be a contribution to the group. But .... very little NEW code.

For me, the add sound to FB project is very exciting. By whatever manor it is brought in to/through the parser/preprocessor. (Really, that part is what establishes the true definition of a language.) Hopefully, the passionate people will go ahead anyway and do it the way they desire whether anyone else agrees or not.

We are rapidly coming up to a time where the underlying video drivers are all going to be obsolete. We are going to NEED some serious philosophy shifts and a lot of code to allow FB to run on the new operating systems of the future. I don't see a new, young, skilled, passionate contributor here yet that is willing to do that.

Please, somebody prove me wrong.

david

[marcov]

I think that indeed way too many of such discussions are about language. Libraries (and by that I mean libraries in FB, not headers for libraries in other languages), quality releases etc are much more important.

And I do agree with Caseih's

Many a project has died, or at least got seriously sidetracked (I'm looking at you, Gnome Desktop), trying to cater to mythical new users

Rarely single features bring in hordes of new users, and even less so if it is language features. (a new application framework just might do it)

[speedfixer]

Yes, internal libraries and quality releases are important. FB has been blessed with some outstanding development efforts.

There are many reasons why a project can die.

Fewer are the reasons that make a project survive.

FB does not support any niche. (Other than providing a fast, small efficient executable. That seems to not be of value, these days.)
FB does not presently or seem to promise any framework of any sort for anyone. (We can't even source a simple modern gui without outside help.)

Absolutely correct: single features won't do it.

scalable fonts - allows a gui
sound - allows media
media - provided a framework for 'modern' communication
network - lets you talk to someone/anyone else
interprocess communications - allows you to escape a one-dimensional attitude toward your programming

Any three of these would be enough strength to consider FB modern and powerful.

The topic *is* language development beyond the current version 1.07.

[marcov]

The topic *is* language development beyond the current version 1.07.

No, it is "fbc 1.08 development". Even if you take that to be the compiler only, there are also things like native backends, ports, optimization etc.

[Juergen Kuehlwein]

@speedfixer

Having a simple framework for a fancy GUI is everybody´s dream, some kind of "create what i want" box . But to my experience it will stay a dream, i have developped a visual designer for Windows, which generates a compilable code skeleton for a GUI implemeting the available Windows controls and their features. Having such a skeleton is one thing, fill it with life is another thing. It´s inevitable to know what happpens where in which order and why. In other words, you must nevertheless have a substantial knowledge of the underlying OS to really use it and use it´s power. The same applies to other approaches like Paul´s WinFBE.

Making this multiplattform will only allow for common features of all supported platforms, platform specific features will always have to be coded by hand. So to summarize it, despite of all efforts in this direction, it´s necessary to have/gain some knowlegde about your OS, effortlessly just won´t work!

I agree on your other points, maybe interprocess communication is not so much a topic for beginners. There is a nice contribution for sound, which could/should be integrated in my opinion some way or other.

Could you expand a bit on media and network, what would you (others) like to have?


JK