Freebasic to everything

[bihai]

Apple's swift has been growing rapidly and will be open source late this year.
Thus it will be portable for many platforms other than ios.
And Jetbrain's Kotlin is also interesting while supporting most platforms, especially for javascript.
Both of them have similar syntax with freebasic.
Even MS is planning to support all platforms in the next generation of programming tools.
Portability is very important for freebasic.
I am working on a version of jvmbasic to see if we can port freebasic to jvm.
The rtlib and gfxlib are written in C. Porting them to java is a nice choice, I think.
If we finally got a jvm freebasic, then we can use robovm and so on to run it under iOS and android.
Waiting for fb to support LLVM and emscrpten, or porting fb to jvm? That's a problem.
If freebasic want to be grow fast, changes have to be made.

[St_W]

Apple's swift has been growing rapidly and will be open source late this year.
Thus it will be portable for many platforms other than ios.
And Jetbrain's Kotlin is also interesting while supporting most platforms, especially for javascript.
Both of them have similar syntax with freebasic.
Even MS is planning to support all platforms in the next generation of programming tools.
Portability is very important for freebasic.
I am working on a version of jvmbasic to see if we can port freebasic to jvm.
The rtlib and gfxlib are written in C. Porting them to java is a nice choice, I think.
If we finally got a jvm freebasic, then we can use robovm and so on to run it under iOS and android.
Waiting for fb to support LLVM and emscrpten, or porting fb to jvm? That's a problem.
If freebasic want to be grow fast, changes have to be made.

It doesn't need Java to port FreeBasic to Android, and by the way there are already successful ports of FreeBasic to Android (but using an alternative UI library instead of FB's gfxlib2; do search the forum) and FreeBasic also already has a LLVM emitter.

I agree that portability is important but FB is already quite portable and I wouldn't consider portability as a unique feature of FB. I don't really agree that FB as a language is similar to modern languages like Swift. FB (the language) has many elements/characteristics that are old-fashioned nowadays and is missing several of today's standard-features of modern languages.

[BasicCoder2]

FB (the language) has many elements/characteristics that are old-fashioned nowadays and is missing several of today's standard-features of modern languages.

And what are those missing standard features?

[St_W]

FB (the language) has many elements/characteristics that are old-fashioned nowadays and is missing several of today's standard-features of modern languages.

And what are those missing standard features?

Lambda Expressions, Closures, Generics, Exception-Handling, Interfaces/Polymorphism, ...

not really a language feature, but still very important: Unicode Support (yes I know there's wstring ptr, but usage is very inconvenient compared to String)

[caseih]

I started a thread in the community forum on Unicode support. I agree having unicode dynamic strings would be ideal. Unicode is complex, though. Not quite as simple as one code point per character. But it's not insurmountable, and it's necessary for the future. Unicode is both a runtime library issue and a language issue, as are many of the things the cool kids are doing these days.

FB certainly has polymorphism. That's part of what virtual methods define. They allow a descendant class to define certain functionality that is called by the base class. FB does not have interfaces in the Java sense, though. Whether or not Java-style interfaces are the way to go is subject to debate.

Another feature that both Swift and C++14 have, that FB is missing is reference-counting resource management. I'm pretty sure FB's OOP model already supports much of what C++ programmers call RAII (Resource allocation is initialization). Reference counting smart pointers would probably be a good idea to augment this. As Swift and C++ both show, you don't need a full garbage collector to do complex tasks. Often reference counting is good enough.

Another increasingly important aspect of modern programming languages is constructs to enable safe use of multiple processes, or threads. As well, asynchronous I/O is popular and getting support from languages like GoLang.

The question always comes down to, what niche does FB fill? If you want a language like GoLang to do cool things, you're probably best off learning and using Go. If you want to write OS X apps, just learn Swift. In fact I don't buy into the idea of one language being the best thing for all applications on all platforms. FB is currently filling two roles well: giving new life to old QuickBasic cold people have lying around, and acting as a low-level C replacement for people who just don't like C (braces are ugly).

[BasicCoder2]

FB (the language) has many elements/characteristics that are old-fashioned nowadays and is missing several of today's standard-features of modern languages.

And what are those missing standard features?

Lambda Expressions, Closures, Generics, Exception-Handling, ...

Right. I guess I don't miss what I don't know about :)
How did they manage before all these new things arrived?
Guess I will be stuck in ye old days with FreeBASIC.

[marcov]

Lambda Expressions, Closures, Generics, Exception-Handling, Interfaces/Polymorphism, ...

meta classes, Variants (runtime typing escape, e.g. for scripting language communication or handling sqldb tables), dynamic dispatch, RTTI/introspection.

But the trick is not if and how, but in what order, and how much of a certain aspect is needed.

E.g. I think Lambda and Closures are a bit unproven. Yes, some closurelike functionality is maybe useful for threadlibs, but
I'm not entirely convinced that therefore every language should be half functional. Yes, it is easy to think of applications, but is it really /needed/? I'm hampered here with only a introductory knowledge of LINQ, since I went embedded while .NET3 was still in beta space.

More clearly, I don't really see the need to expand base type Introspection and dynamic dispatch to full Reflection.

Automated memory management is also a complex issue. It depends on both person and what you do. Personally I like having base reference counting for strings and dynamic arrays, but don't really care about scaling this up.

Same for RAII. I always attributed this to C++'s desire to have no complex basetype, and try every complex type on (variants, strings etc) on a static class with some operator overloading. RAII is IMHO directly related to that approach of language design, and otherwise only marginally important.

[bihai]

Hello again.
Kotlin has become an official android programming language at Google I/O 2017.
How about FreeBasic's next step?
Compiling to LLVM has been good, how about more choices?
Kotlin is similar to Swift and BASIC, with new features.
As FreeBASIC supports a collection of BASIC languages, why not consider importing Kotlin or Swift?
Or just compile freebasic to kotlin / swift, so that there'll be freebasic android / ios apps.
BTW, Kotlin can compile into JVM bytecode, and 100% compatible with java.
Also, any news for emscripten port?
Thanks and best regards.

[TeeEmCee]

Oh, is that the reason? I thought the recent posting about Kotlin everywhere was just a meme.

A few people have compiled FB programs with Emscripten. v1ctor created a branch for it (basically creating an SDL 1.2 backend for libfbgfx), but you don't need to use it to use Emscripten. I haven't tried it yet, but I will, and don't expect much trouble. FB is pretty portable, as long as you don't use libfbgfx.

Compiling FB to the JVM or a JVM language seems like a great deal of unnecessary work, when you can compile as a native android program instead, using the NDK. You will still want to write Java/Kotlin/whatever to access android APIs. Of course, then you still need to interface with your Java code somehow. Probably SWIG or other tools be used to do that automatically.
There's no point compiling to Swift, because all apps on iOS are native. You can just link Obj-C modules to FB modules; I do.