B4x next steps?

[imbault]

Hi @Erel ,

Now, all the 3 IDE have been updated, what have you planned for next releases ?

BTW, do B4i will be able to handle 3D Touch of the new iPhone 6s?

Thanks

Patrick

 

[Erel]

The three products will continue to evolve. For now no revolutions are planned...

BTW, do B4i will be able to handle 3D Touch of the new iPhone 6s?

I haven't checked the new APIs yet however it will most probably be simple to support.

 

[Erel]

BTW, B4J v3.70 BETA has just been released: https://www.b4x.com/android/forum/threads/b4j-v3-70-beta-is-available-for-download.58283/

The same optimizations will be implemented in B4A and B4i as well.

 

[narek adonts]

I think a major feature that is missing is WatchKit Sdk and the ability to use 3rd party library without using xCode.

 

[wonder]

Erel, native libraries (.so files) support.
Please, please, please pretty please!

I understand that it's not a simple thing to achieve, but come on...
there is nothing you can't do, you can create anything!

 

[Roycefer]

What is your idea of native support? B4J and B4A already have native support in the same sense that Java has native support. That is, if you can write a wrapper Java library using JNI/JNA to call native functions, then you can use that wrapper library in your Java/B4J/B4A project (where platform-appropriate).

 

[wonder]

In-line C++ and .so lib support... I know I might be asking too much, but C/C++ is faster than Java and we could really use the extra speed in certain situations.

#IF C++
    #include <iostream>

    using namespace std;

    int main()
    {
        cout << "Hello World!" << endl;
        return 0;
    }
#END IF

EDIT: Ok, In-Line might be really asking too much because it would require an additional compiler, but at least a way to "just add" a .so file to your project with minimal effort.

 

[little3399]

I think if B4X can publicsh their API will be a good to increase the 3rd party library develop ...

 

[Roycefer]

C/C++ isn't really faster than Java in most cases, on the desktop. You have to spend a LOT of time optimizing C/C++ code and setting compiler flags to make it faster than Java whereas the Java optimizer will optimize even sloppily written Java/B4J code. And even when you have fully optimized C/C++ code, you can only expect about a 10% performance boost over the equivalent Java (I'm talking about on the desktop, here). Remember, Oracle's HotSpot JVM will JIT compile performance critical portions of your program to machine code, and this is after quite aggressive optimization. On Android, the overall slowness of the Dalvik Virtual Machine made native code a lot faster by comparison but ART is slowly changing that, as well.

The thing about inline C is that it could probably be done (with great effort) but, in the end, the B4X developer would still have to configure numerous different compilers for different platforms (this is true on the desktop and on Android) and perform a lot of other ancillary tasks that would make the whole enterprise little more efficient than the current method of using native code. It just doesn't seem worth Erel's time for what little gain in programmer ease there is to be had.

It would probably be not too hard to write a tool (this could be done in B4J) that could inspect an .h file and generate a .java file that had a JNI-based wrapper for the functions in the .h file. That could, at least, automate one portion of creating simple wrappers for native libraries.

 

[wonder]

C/C++ isn't really faster than Java in most cases, on the desktop. You have to spend a LOT of time optimizing C/C++ code and setting compiler flags to make it faster than Java whereas the Java optimizer will optimize even sloppily written Java/B4J code. And even when you have fully optimized C/C++ code, you can only expect about a 10% performance boost over the equivalent Java (I'm talking about on the desktop, here). Remember, Oracle's HotSpot JVM will JIT compile performance critical portions of your program to machine code, and this is after quite aggressive optimization. On Android, the overall slowness of the Dalvik Virtual Machine made native code a lot faster by comparison but ART is slowly changing that, as well.
(...)
It just doesn't seem worth Erel's time for what little gain in programmer ease there is to be had.

I was solely thinking about B4A. I agree with you, B4J wouldn't really take that much advantage of supporting native code, especially being a free tool.
B4J is already amazing as it is right now.

It would probably be not too hard to write a tool (this could be done in B4J) that could inspect an .h file and generate a .java file that had a JNI-based wrapper for the functions in the .h file. That could, at least, automate one portion of creating simple wrappers for native libraries.

This would make me a very happy man, a single-click B4A feature/add-on/lib (or as you mentioned, external app) which would allow .so files being imported into your project. I would gladly pay for it.

 

[Informatix]

C/C++ isn't really faster than Java in most cases, on the desktop. You have to spend a LOT of time optimizing C/C++ code and setting compiler flags to make it faster than Java whereas the Java optimizer will optimize even sloppily written Java/B4J code. And even when you have fully optimized C/C++ code, you can only expect about a 10% performance boost over the equivalent Java (I'm talking about on the desktop, here). Remember, Oracle's HotSpot JVM will JIT compile performance critical portions of your program to machine code, and this is after quite aggressive optimization. On Android, the overall slowness of the Dalvik Virtual Machine made native code a lot faster by comparison but ART is slowly changing that, as well.

The thing about inline C is that it could probably be done (with great effort) but, in the end, the B4X developer would still have to configure numerous different compilers for different platforms (this is true on the desktop and on Android) and perform a lot of other ancillary tasks that would make the whole enterprise little more efficient than the current method of using native code. It just doesn't seem worth Erel's time for what little gain in programmer ease there is to be had.

It would probably be not too hard to write a tool (this could be done in B4J) that could inspect an .h file and generate a .java file that had a JNI-based wrapper for the functions in the .h file. That could, at least, automate one portion of creating simple wrappers for native libraries.

I'm not convinced at all. My own experience under Windows proved me the contrary. C++ can be a lot faster. But it depends what you do and how you write it. It's the same problem under Android. As the exchange of data between the Java heap memory and the native memory is very slow, calling a C function very frequently with big chunks of data can be much slower than a pure Java solution. And a good Java code will always be better than a poorly coded C++ lib with big memory leaks. However, one day or the other, you turn to the .so libraries to get higher performance (games, codecs) or better protection (Java is decompiled easily), so that would be nice if it was possible to integrate them with B4A without a Java wrapper.

 

[Troberg]

What I'd like to see in upcoming versions is not very sexy, and not very fun to implement, but it is an extremely important part of a dev environment:

* Improved help. If I place the caret on a method and press F1, I want to get a help page describing that method. Each argument should be described and, if need be, some sample code. Much of this already exist, so it's mostly a matter of building the context sensitive framework.

* Improved error messages. It's not uncommon to get error messages that are either wildly wrong or totally uninformative. Now, this is by no means specific to B4X, but giving better errors means simpler bug fixing.

Sure, there are a lot of other things that would be cool, but most of those are features that only some users benefit from. These enhancements would benefit everyone.

On a side note to the help, making http links in comments clickable would also be a hugely useful thing. That way, one could use a wiki to document the code, and have a clickable link to the relevant section right there in the code. I would also guess it's fairly simple to implement.

I'm not convinced at all. My own experience under Windows proved me the contrary. C++ can be a lot faster. But it depends what you do and how you write it.

Exactly. It mostly depends on what you do. If you are building a 3D Engine or a high performance encryption algorithm, languages like Java, C# or VB will always lose. When it's raw number crunching with high performance needs, you want to be close the machine. Then again, C/C++, PowerBasic and other more low level languages are likely to lose against well written assembly code.

Then again, in most cases, program performance is not as important as developer performance. CPU power is cheap, developer time is expensive, so sacrificing performance but allowing the programmer to be more productive is usually the sensible trade-off.

 

[Informatix]

* Improved error messages. It's not uncommon to get error messages that are either wildly wrong or totally uninformative. Now, this is by no means specific to B4X, but giving better errors means simpler bug fixing.

What do you mean? Error message at runtime? When writing code? When compiling ?

Then again, in most cases, program performance is not as important as developer performance. CPU power is cheap, developer time is expensive, so sacrificing performance but allowing the programmer to be more productive is usually the sensible trade-off.

But how a developer can be productive if he/she sacrifices performance ? You're not productive when you write sluggish code, buggy code, etc. If someone has to rewrite your code some day because it is not fast or robust enough (and I know that well as rewriting bad code was my job during 2 years), then it's more money spent than doing things properly from the beginning. Sacrificing performance is not a choice. Either you don't have time to write good code, and you pay that with angry or disappointed clients, or you don't have the skill to write performant code and you'd better change for another job. However I agree on the idea that having convenient tools can offer more productivity even it's at the expense of speed. We're of course far more productive by writing B4A code than writing assembly code. I think it's what you meant.

 

[Troberg]

What do you mean? Error message at runtime? When writing code? When compiling ?.

Basically, all error messages related to running/compiling. The more accurate the message is at pinpointing the problem, the easier it is to fix.

But how a developer can be productive if he/she sacrifices performance ? You're not productive when you write sluggish code, buggy code, etc. If someone has to rewrite your code some day because it is not fast or robust enough (and I know that well as rewriting bad code was my job during 2 years), then it's more money spent than doing things properly from the beginning. Sacrificing performance is not a choice. Either you don't have time to write good code, and you pay that with angry or disappointed clients, or you don't have the skill to write performant code and you'd better change for another job. However I agree on the idea that having convenient tools can offer more productivity even it's at the expense of speed. We're of course far more productive by writing B4A code than writing assembly code. It think it's what you meant.

A bad programmer is bad, regardless of tool. However, some tools allows things to be built faster, and most applications are not that performance sensitive.

Take, for example, the vast majority of business systems developed by consultants. They are database frontends, with very little performance critical parts. Likewise, they have little or no need of low level hardware access. In other words, there is no need for fiddling around with the bureacracy of C++ (probably in conjunction with some GUI framework and database framework), and also no need for the risks of C++ (for example the risk of memory leakage when there is no automatic garbage collection). Instead, a higher level tool, designed for this use case, will give more results faster and produce less bugs. The end user won't notice any speed difference anyway, as almost all the time is spent waiting for the database engine anyway.

Basically, don't Always optimize for performance. When there is a need for it, sure, do what it takes to get the performance you need, but, in most cases, the limiting factor will be the guy who asks "How much will this cost?".

 

[Informatix]

Basically, all error messages related to running/compiling. The more accurate the message is at pinpointing the problem, the easier it is to fix.

At runtime, some error messages come from the Android API, others come from a third-party library. Erel cannot improve them. If you want a more complete error report, you can look at the unfiltered log by unchecking a box. I can't see what you're asking here.

some tools allows things to be built faster

That's why I continue to use B4A.

Basically, don't Always optimize for performance. When there is a need for it, sure, do what it takes to get the performance you need, but, in most cases, the limiting factor will be the guy who asks "How much will this cost?".

We agree.

 

[Troberg]

At runtime, some error messages come from the Android API, others come from a third-party library. Erel cannot improve them. If you want a more complete error report, you can look at the unfiltered log by unchecking a box. I can't see what you're asking here.

I ask more or less what I ask from every tool: Give me as much and as accurate information as possible when things go wrong.

Good error messages can be a huge time saver. Even simple things like fleshing out a "Invalid value: null" to a "Can't assign null to integer variable MyCounter".

Then again, I understand that runtime errors might be difficult, but every little bit helps.

 

[Informatix]

Good error messages can be a huge time saver. Even simple things like fleshing out a "Invalid value: null" to a "Can't assign null to integer variable MyCounter".

All details provided by the code throwing the exception and by the JVM are already given to you. All context details provided by the OS are also given to you in the unfiltered log. I can't see how Erel could know better than the author of the code the exact reason of the error. And when the exception happens in your own code, you have a debugger to locate it. Concretely, I can't see what can be done more.

 

[RandomCoder]

* Improved help. If I place the caret on a method and press F1, I want to get a help page describing that method. Each argument should be described and, if need be, some sample code. Much of this already exist, so it's mostly a matter of building the context sensitive framework.

"F1" help would be an immense improvement for a part time programmer like me. I spend a very large part of my time searching the documentation and the forum for answers and so this would be of great benefit to me.

+1 from me.

 

[Roycefer]

Exception reporting sometimes includes the line of Java code that caused the exception to be thrown. Where applicable, that Java line could be translated into a line in B4X code.

 

[Troberg]

All details provided by the code throwing the exception and by the JVM are already given to you. All context details provided by the OS are also given to you in the unfiltered log. I can't see how Erel could know better than the author of the code the exact reason of the error. And when the exception happens in your own code, you have a debugger to locate it. Concretely, I can't see what can be done more.

I'm aware that it wouldn't be easy, but I'm also sure that some improvements can be made. Examples:

* Every error found in the compiler should be possible to refine, as they are under Erel's control.
* If possible, try to make messages that appear in runtime not just return the Java error, but also try to give some reference back to the relevant B4X code. It's not always the amount of info that's impossible, it's the usefulness of it.

That said, I don't expect a revolution, but I'm hoping for a slow evolution and the establishing of a mindset of "Let's give as useful information as we reasonably can".