Rene,
Thank you very much for your good comments.
I am not wedded to the Web idea and threw that out there to get people thinking.
It's just the area in which most of the current activity seems to be taking place.
I also did that because the 'Zenario' CMS we are using for the BBF front page is
not at simple as it could be.
What 'tools' do people need? What 'tools' would help the world create robust
applications? If not a 'tool' then entertainment? I don't think that is
an area in which we should be engaged. So what 'tool' or 'tools' are needed?
-Doug
Killer App
-
DGDanforth
- Posts: 1061
- Joined: Tue Sep 17, 2013 1:16 am
- Location: Palo Alto, California, USA
- Contact:
Re: Killer App
I looked a bit more into this, and would like to add a few points:
1) We could build the BBF in OberonScript and/or OberonJS, and this would really be useful. I agree that the browsers then would handle the platform independence, much like with Java. But we could have the same by porting BBF to GPCP for JVM or GPCP for .NET, and I do not think that this would need more time and effort, while at the same time it would give us far better performance and spread.
2) When BBF was first released, its strength was full portability, while retaining the target system's look and feel. Currently, there is nowhere to port to, while we retained the look and feel of 15 years ago.
3) CP is designed as an all-purpose language. As is, the BBF is *not* all purpose. Oberon was designed as a future-state-of-the-art operating system for small devices, desktops and servers. Now, 23 years later, BBF cannot be used for game programming, for server programming and for anything where almost real time program reaction is needed, while most of the other all purpose languages can well be used for it. We are not "all purpose" anymore. Our purpose is, in fact, very limited and isolated.
I hope you don't get the feeling that I am a nay-sayer, or that I want to badmouth the language and framework we all came to love. But I believe we need a very good understanding of the problem, before we can solve it.
I would suggest the following course of action:
1) Compiler-related issues should be dealt with. This of course includes bugs and extensions like “adding module characters”, but also developing a 64-bit compiler, and ports to other systems (JVM, .NET, Dalvik Virtual Machine). Also, with the idea of porting, GPCP introduced new language elements, and should consider, if those new elements are helpful or not. Especially, if we think of porting BBF to GPCP-JVM (or any other JVM version of CP), we need to have a unified language description.
2) As I see it, now, all power goes to fixing known bugs in the framework. While this is important, it is not the most important task, and while we need to do this fast, we also need to analyse (before starting with a solution) what changes in the framework are needed in the next two years, and how these changes may affect the known bugs.
3) Modernizing the framework is another area where we need work done. This includes look and feel, connectivity to databases, office automation and major players (SAP for instance), but also finding ways to make the BBF all purpose again:
A big part will be fixed with a 64-bit compile, but I guess other questions will arise from that change, like:
*) does a larger RAM affect Garbage Collection? Do we need new algorithms to deal with larger RAM, for instance?
*) How will we deal with people who need to develop 32-bit AND 64-bit applications?)
Another thing is how to deal with current processor hardware, which is multicore. How can we use ressources better? I mean, by going multithread, Java, which is not a native compiler language, is faster than CP in some applications! That’s not a selling point for the language. Again, probably real multithreading is not an option, because it is a messy business. But on the other hand, we need a solution. It needs to be in the spirit of Oberon, of course, and it needs to be well thought through, but I do not believe that we can allow Java to stay better in two of three core issues of CP: portability and execution speed (the third being clarity of language, where CP still wins by miles).
4) The question of the Killer-App, Doug, is an important one. We need a proof of concept, and something to get attention. But I do not see that the center can provide it just now. We are too small a group, and there are too many issues to deal with right now. I would suggest that this is a task for the larger community, and we should ask them for help in this. And whatever problems they encounter when creating that App, we as providers for the framework need to step in and find a solution really fast. I think it is time to include the community. The center is established.
1) We could build the BBF in OberonScript and/or OberonJS, and this would really be useful. I agree that the browsers then would handle the platform independence, much like with Java. But we could have the same by porting BBF to GPCP for JVM or GPCP for .NET, and I do not think that this would need more time and effort, while at the same time it would give us far better performance and spread.
2) When BBF was first released, its strength was full portability, while retaining the target system's look and feel. Currently, there is nowhere to port to, while we retained the look and feel of 15 years ago.
3) CP is designed as an all-purpose language. As is, the BBF is *not* all purpose. Oberon was designed as a future-state-of-the-art operating system for small devices, desktops and servers. Now, 23 years later, BBF cannot be used for game programming, for server programming and for anything where almost real time program reaction is needed, while most of the other all purpose languages can well be used for it. We are not "all purpose" anymore. Our purpose is, in fact, very limited and isolated.
I hope you don't get the feeling that I am a nay-sayer, or that I want to badmouth the language and framework we all came to love. But I believe we need a very good understanding of the problem, before we can solve it.
I would suggest the following course of action:
1) Compiler-related issues should be dealt with. This of course includes bugs and extensions like “adding module characters”, but also developing a 64-bit compiler, and ports to other systems (JVM, .NET, Dalvik Virtual Machine). Also, with the idea of porting, GPCP introduced new language elements, and should consider, if those new elements are helpful or not. Especially, if we think of porting BBF to GPCP-JVM (or any other JVM version of CP), we need to have a unified language description.
2) As I see it, now, all power goes to fixing known bugs in the framework. While this is important, it is not the most important task, and while we need to do this fast, we also need to analyse (before starting with a solution) what changes in the framework are needed in the next two years, and how these changes may affect the known bugs.
3) Modernizing the framework is another area where we need work done. This includes look and feel, connectivity to databases, office automation and major players (SAP for instance), but also finding ways to make the BBF all purpose again:
A big part will be fixed with a 64-bit compile, but I guess other questions will arise from that change, like:
*) does a larger RAM affect Garbage Collection? Do we need new algorithms to deal with larger RAM, for instance?
*) How will we deal with people who need to develop 32-bit AND 64-bit applications?)
Another thing is how to deal with current processor hardware, which is multicore. How can we use ressources better? I mean, by going multithread, Java, which is not a native compiler language, is faster than CP in some applications! That’s not a selling point for the language. Again, probably real multithreading is not an option, because it is a messy business. But on the other hand, we need a solution. It needs to be in the spirit of Oberon, of course, and it needs to be well thought through, but I do not believe that we can allow Java to stay better in two of three core issues of CP: portability and execution speed (the third being clarity of language, where CP still wins by miles).
4) The question of the Killer-App, Doug, is an important one. We need a proof of concept, and something to get attention. But I do not see that the center can provide it just now. We are too small a group, and there are too many issues to deal with right now. I would suggest that this is a task for the larger community, and we should ask them for help in this. And whatever problems they encounter when creating that App, we as providers for the framework need to step in and find a solution really fast. I think it is time to include the community. The center is established.