FreeBASIC Looks Dead

For other topics related to the FreeBASIC project or its community.
marcov
Posts: 3010
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Postby marcov » Jun 07, 2010 13:57

1000101 wrote: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.


It is a good level zero for a compiled OOP language yes.

But there is enough to think of:

* RTTI (reflection)
* interfaces or other kinds of MI
* dynamic dispatch (maybe you already have this due to olevariant/com/idispatch? ) to call scripting languages/idispatch
* variants, mainly for implementing generic database abstraction frameworks.

Personally, but I've echoed that before, think that the reliance on the preprocessor in FB is still to high to name the language complete.

If the language is ok, then I probably wouldn't see so much code using the preprocessor.

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).


Or a non-typesafe one. (which is partially the same, since runtime typing makes for slow code)

Which is where the ghost of generics/templates inevitably comes out of the bottle.

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


True in theory. Not entirely true in practice, very system has its quirks. Windows (and OS/2 to some extend) have messages and COM, OS X really needs Objective C connectivity if you want to make native gui apps, and Amiga/Morphos also has extensions to make system interfacing easier.

If you don't implement such things, you remain an outsider, and the project is only half ported.
boriel
Posts: 7
Joined: Jun 06, 2010 19:43
Contact:

Postby boriel » Jun 07, 2010 14:24

marcov wrote:But there is enough to think of:

* RTTI (reflection)
* interfaces or other kinds of MI
* dynamic dispatch (maybe you already have this due to olevariant/com/idispatch? ) to call scripting languages/idispatch
* variants, mainly for implementing generic database abstraction frameworks.

I agree.
* Dynamic dispatch == virtual methods and function overloading.
* Variants: will allow data containers to contain diferent types (e.g. a single array of "integers and strings", not only of integers).

Regarding to dynamic containers, and HLL, imagine something like this:

Code: Select all

DIM mylist as List

mylist = () ' empty list

mylist = mylist + (1, 2) ' adds a list of 1, 2

mylist = mylist + (3, )  ' need the comma to avoid (3) to be confused
' with a parenthesized expression (many languages allows this, C, C++,
' python, etc..). In fact (1, 2, ) is equal to (1, 2)

mylist = mylist + (mylist, ) ' mylist => (1, 2, 3, (1, 2, 3))

'' List traversal
FOR elem IN mylist
    '(Now will do something with element)
NEXT elem

'' Check if elem is in list
IF elem IN mylist THEN
    '(Now do something)
END IF



This would be a very powerful dynamic data structure. And also, LEN(mylist) should give the number of elements. mylist(i) should return the i-th element (slow linear access compared to arrays), and so on.

There are no visible pointers, no dynamic memory management by the user. Memory cleanup is done automatically by the system on function exit if required.

This is much simpler and less verbose than a C-ish linked list implementation which allocates memories, check pointers, link them, unlink them, etc. etc.

Of course it's just an example of what an object container could be. In fact, if Variant types are implemented (variants could be implemented with OOP and virtual functions, or RTTI), the elem variable in the FOR loop could get a different element type on each loop cycle.
agamemnus
Posts: 1842
Joined: Jun 02, 2005 4:48

Postby agamemnus » Jun 07, 2010 15:29

boriel wrote: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.


For me, I do not consider nor want FreeBasic to be something that is more high level than C or C++. The main strength of the language, I think, is its better syntax format compared to C/C++.
vdecampo
Posts: 2982
Joined: Aug 07, 2007 23:20
Location: Maryland, USA
Contact:

Postby vdecampo » Jun 07, 2010 17:00

agamemnus wrote:For me, I do not consider nor want FreeBasic to be something that is more high level than C or C++. The main strength of the language, I think, is its better syntax format compared to C/C++.


Amen!
anonymous1337
Posts: 5494
Joined: Sep 12, 2005 20:06
Location: California

Postby anonymous1337 » Jun 07, 2010 19:05

I agree with agamemnus and vdecampo: FreeBASIC is like C to me, only better.

What then, is the FreeBASIC philosophy? Why not XXX-basic feature but XYZ-basic feature? Because FreeBASIC's the brain-child of a bunch of guys who were sitting around in their caves drinking beer and thought it was a neat idea.

We've done everything by (almost) general consensus. It's why FB is actually fun to program in - it's where we, not XXX or XYZ philosophy/specification, want it to be. FB isn't just a programming language. It's a community language, and we've stagnated ourselves by trying to make it otherwise.

AWAKE, COMMUNITY LEGENDS! AWAKE FROM YOUR SLUMBER! DRINK THE ALCOHOLIC NECTAR OF UN-HYBERNATION! *summons v1ctor, cha0s, relsoft, dr_d, syn9, blitz, rune, lachie, imortis, plasma, lillo, pe-* damn I ran out of magic points...
boriel
Posts: 7
Joined: Jun 06, 2010 19:43
Contact:

Postby boriel » Jun 07, 2010 21:01

agamemnus wrote:
boriel wrote: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.


For me, I do not consider nor want FreeBasic to be something that is more high level than C or C++. The main strength of the language, I think, is its better syntax format compared to C/C++.


Then FreeBasic could be certainly dead.

I can't see a better syntax (compating to C/C++). If FreeBASIC is just C/C++ with different keywords, it's just C, and will fall into the oblivion. Who wants to learn a new language that does not offer anything new? C/C++ is very popular, and the fact that C is not dead is because it has a niche: OS development (Linux, mainly), and its widespread and multiplatform. FreeBASIC is not that. Other than OS, ANSI C is mostly dead. C++ is mostly used for videogame developments, but yet again new languages (C#) are arising into scene.

And, sorry, but looking into some FreeBASIC source code, its syntax is *VERY* complex and dirty (just look the compiler source code). This is not BASIC anymore. :-( Even Microsoft evolved their basic (VBASIC, VBASIC .NET) on which FreeBASIC is somewhat inspired.

I don't get the point of having a C-backend translator from FreeBASIC, since the language level is the same.

The idea of having a higher lever structures is writting less an clearer code, and be more productive. Even C++ is evolving (slowly, but evolving). Just look the new standard proposals.

If you decide to use pointers to implement lists, then you either have a template / macro system, or have to write your lists methods *every time*. The same applies to any other complex data container, not only lists.

Lists and dictionaries are very basic (pun intended) nowadays, and every new language comes with them already included. I can't see why FreeBASIC must not have them: if you don't want them it's ok, don't use them, but let others do.
1000101
Posts: 2556
Joined: Jun 13, 2005 23:14
Location: SK, Canada

Postby 1000101 » Jun 07, 2010 23:52

Regardless of whether people "think" C is a HLL or not, it is. There are classifications of computer languages high level, low level and very high level. If anything, things like VisualBASIC fall into the very high level category as do java, python, etc. Both FreeBASIC and C are high level langauges.

linked-lists, list, etc are still things which can be added via libraries and aren't needed in the basic language set, imo.

And yes, 64-bit is a compiler consideration but that is the emitter which is a later stage (usually in multipass compilers).

Anyway, I agree we need to add/fix some things but I don't agree with everything everyone wants or at least not where they want it.
Plasma
Posts: 191
Joined: May 27, 2005 5:22
Location: Earth
Contact:

Postby Plasma » Jun 08, 2010 0:46

anonymous1337 wrote:AWAKE, COMMUNITY LEGENDS! AWAKE FROM YOUR SLUMBER! DRINK THE ALCOHOLIC NECTAR OF UN-HYBERNATION! *summons v1ctor, cha0s, relsoft, dr_d, syn9, blitz, rune, lachie, imortis, plasma, lillo, pe-* damn I ran out of magic points...


You rang? :P


My opinion:

1) If something is still in use, it's not dead.
2) Less talkin, more rockin
Imortis
Moderator
Posts: 1729
Joined: Jun 02, 2005 15:10
Location: USA
Contact:

Postby Imortis » Jun 08, 2010 3:20

Someone further up made the statement that programmers should not have to learn how to make linked lists and similar structures. I 100% disagree with that statement. Learning how to do those things yourself makes you a better, more competent programmer. That being said, I don't think you need to make everything from scratch either. I just think the knowledge acquired from making it yourself is far more valuable than the time saved by having it built into the language.

My recent Pet Project is a GUI library, that I'm hoping will be very flexible, and have the option to swap out the output (fbgfx, openGL, allegro, winAPI, TUI, you name it) with none of the API needing to change. I may be a bit too ambitious, and it may be easier to use an already existing library, or to demand that there be one integrated into freeBASIC itself, but the experience I am gaining through my exploring and experimenting with the language and different techniques, is priceless, and I wouldn't have it any other way.

I'm not hibernating: I'm Concentrating. And I am loving every minute of it.
Mysoft
Posts: 779
Joined: Jul 28, 2005 13:56
Location: Brazil, Santa Catarina, Indaial (ouch!)
Contact:

Postby Mysoft » Jun 08, 2010 7:37

well in my opinion OOP is useless, just make programmers think bad...
so might be good for bad humans that dont like to think, but for the rest...

i don't see need to use anything more than the basic... a namespace, and private variables...

so multiples instance of it make it be an object instead of a namespace... and that is as useful as a normal type to better organize variables... or else we would still be doing like ancient basic

Code: Select all

dim UserName(255) as string, UserID(255) as integer, UserAge(255)


etc... so for me, OOP is just higher level than accepted but people will not notice that, since the level of the entire world is increasing while capability of people decreasing, i get ashamed everyday with those noobs that finished university... and seems living blind on what they learned...

but i apology for my roughness, is cuz i dont like to see the world falling down like that... friggin java lusers... i mean users...
marcov
Posts: 3010
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Postby marcov » Jun 08, 2010 10:59

boriel wrote:
marcov wrote:But there is enough to think of:

* RTTI (reflection)
* interfaces or other kinds of MI
* dynamic dispatch (maybe you already have this due to olevariant/com/idispatch? ) to call scripting languages/idispatch
* variants, mainly for implementing generic database abstraction frameworks.

I agree.
* Dynamic dispatch == virtual methods and function overloading.


No it is not. Those are mostly totally static defined. I'm more thinking about COM IDispatch and similar parts in the Mozilla and Java interoperation APIs. Commonly used to interface to scriptinglanguages.

* Variants: will allow data containers to contain diferent types (e.g. a single array of "integers and strings", not only of integers).


Base types and classes probably yes.

While your list-lik esyntax is possible if you have a memory managed array type (e.g. refcounting), IMHO it is not worth the trouble.

There are no visible pointers, no dynamic memory management by the user. Memory cleanup is done automatically by the system on function exit if required.


Very hard for UDT (records,classes). And except for the occasional math testprogram, how often will you use this kind of syntax?

This is much simpler and less verbose than a C-ish linked list implementation which allocates memories, check pointers, link them, unlink them, etc. etc.


I don't think that you can compare the two. Specially since this container.

Of course it's just an example of what an object container could be. In fact, if Variant types are implemented (variants could be implemented with OOP and virtual functions, or RTTI), the elem variable in the FOR loop could get a different element type on each loop cycle.


Variant types are typically a enumfield signalling type and an unions of all basetypes.

One of the more important applicaiton is db support, since it allows you to operate on generic table layouts, that were not hardcoded into the program.
marcov
Posts: 3010
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Postby marcov » Jun 08, 2010 11:06

1000101 wrote: If anything, things like VisualBASIC fall into the very high level category as do java, python, etc. Both FreeBASIC and C are high level langauges.


I would put VisualBasic 6 in the java/C# category. It is not fully interpreted like Python. (though it still has interpreted characteristics)

I'm told that the "compilation" aspect of VB became more and more over the versions, but I only used VB6. And not that much.

Anyway, I agree we need to add/fix some things but I don't agree with everything everyone wants or at least not where they want it.


What do you think that is absolutely necessary aside from inheritance, and why?

I'm obviously biassed toward our own choices (and some of those were made for us by Borland).

My options would be (from important to less important)

- variants : ability to create generic database interfacing layers
- RTTI : for general persistence systems and other automated field access (RAD environments e.g.). Only generate RTTI under a certain define, to avoid blowing up the binary too much
- generics : typesafe containers, parameterising other code is also important, but typesafe containers are the main reason
- dynamic dispatch - interface with COM, CORBA, XPCOM and scripting languages.

Aside from this: a lot more relatively minor additions to get rid of the preprocessor for everyday use as much as possible.
anonymous1337
Posts: 5494
Joined: Sep 12, 2005 20:06
Location: California

Postby anonymous1337 » Jun 08, 2010 16:35

@Imortis & Plasma:

I got a little nostalgiac and thought something might happen if I used capital letters. I like being busy, too, but I wish it was because I was cooking up something for "you guys" rather than trying to maintain :-/

"(SOME HOT ACTRESS)!!" . . . ?
angros47
Posts: 1673
Joined: Jun 21, 2005 19:04

Postby angros47 » Jun 08, 2010 19:13

Stueber already did a precompiler that add inheritance and templates.

And, with templates, linked lists and more become easy. I think that the next step, for freebasic, should be porting that improvements to the core language.

About "easy" linked lists: the only way to implement them that is easier than c++ way, is the solution used in BlitzBasic: every UDT is a linked list, and all variables of that type are always part of that list. That's easy, of course, but limited: you can't, for example, have two lists of the same type; also, you can't have a list of integers. So, this solution cannot be implemented in freebasic.
AGS
Posts: 1284
Joined: Sep 25, 2007 0:26
Location: the Netherlands

Postby AGS » Jun 08, 2010 19:18

Plasma wrote:If something is still in use, it's not dead.


Nuff said.

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 3 guests