I couldn't sleep and 2 strange thoughts came to me, so I got up to write them before I forget. I think they could be fun discussion subjects.
1. Imagine the next version of PowerBasic being sort of like c++, not in the bad way, but in the good way. It allows the option of using classes and object oriented programming. It also still supports procedural programming as we have now. So if you like things the way they are you will be happy, if you want OOP it will be there. Now the fun. If this were the case, then imagine also a directive option to compile to the common runtime language. Again this would be an option, but it would mean working in groups where others feel comfortable in other languages. It would mean being able to write and run apps on any platform Visual Studio can, like smartphones and other small devices. And the icing on the cake, it would open up developing in powerbasic in linux under Mono. I think this could be a neat move. What do you guys think?
2. Second idea is more of question. As an alternative to PowerBasic and perhaps using FreeBasic, have you guys thought about FreePascal? The syntax is very readable. Many libraries are available and it runs on so many platforms. It seems like there is a resurgence going on in Pascal with FreePascal. I think many are finding it is a nice alternative to c++ with some sanity to how OOP works. And of course what Java maybe promised, but it needs that runtime engine. Which seems to need new versions that keep piling up in the add and remove control panel. I thought it might be a nice alternative future language for migration and would love to hear your guys thoughts about it in case PowerBasic sort of stagnates away.
I totally agree with your point about PB adopting the good features of C++. It has, over the years assimilated many C features to be able to use the Windows API and other DLLs . FreeBasic is moving very strongly in this direction and already rides on the back of GCC. The task for developers is to ensure that their software is well constructed enough to withstand being ported from one system to another without falling apart.
We are going to see many changes and a move away from proprietary software towards the open source model. After all, no one owns a language, and its long term development is in the hands of its users. This poses a major problem for companies who earn their daily bread from selling development software.
Charles Simonyi's 'Intentional Programming' may be the long-term future of programming, where development is done by defining the task and allowing the system to do most of the coding, keeping erratic fingers well away from the code itself.
http://www.intentionalsoftware.com/
I can see this working well for business software, at least.
I never used Pascal but I had friends who used it on the Apple IIc in the 80s. It brings back memories of 20 minute compiles onto 5.25 inch floppies and the cat snoozing on top of the monitor.
In the same genre, ADA is another possibility.
QuoteWe are going to see many changes and a move away from proprietary software towards the open source model.
It is one of the reason why I have always choosen SDK over any other propriatary syntax 8)
Patrice Terrier
www.zapsolution.com
About OOP, well I have been forced to used it when I learned C#.
All I can say is that fortunatly I had the chance to have a good knowledge of the low level API to work around the managed limitations as soon as you want to fine tune things.
Also as a matter of comparison the C# Carousel version i wrote, is three time larger than the one I posted here, with less features and the obligation to install first the DotNET run time.
However I like C#, and it has many syntax facilities that I would like to see in PB.
For example:
- DIM sIsString AS STRING = "This is a string"
- or being able to assign a default value to the parameters passed to a procedure (into the procedure)
And what I hate in C#, is its garbage collector.
Interesting thoughts Kent,
I think .NETing PB would make PB authors crazy ( me too ).
First because it would definitely not fit in "smaller, faster" company motto
.NET is not small, speed I cannot comment as I did not work with NET languages so much. But I doubt inline assembly would fit in MS idea of "safe code" :)
Second, because it would be double work for them. PB would compile "as usual" ( optimized, tight, true machine code ) + it would have to work quite differentely when targeting .NET.
I would be happy to see PB on more platforms, but I am not sure if it is real.
PB/Linux is something like Duke Nukem Forever. I still wait for it, but I am not sure it will ever go out.
Regarding OOP as optional way of programming in PB, I think it would be nice.
I would probably not use those features, but I know quite a lot of users would appreciate it.
And it would finally stop university professors asking "why do you not use OOP language" :D
Petr
P.S. Patrice, how does garbage collection work in C# ?
Thanks for the link Charles. I am going to watch the video interviews. I never seen or heard Mr. Simonyi, so this should be great. I didn't realize he was the space tourist to go up a little while ago!
Petr, the compiling to CRL would be optional. If you don't need to compile to CLR you wouldn't. But since most businesses are using Windows Server OS they have .net, Most of the programmers work in a Visual Studio language or Delphi. This would allow PowerBasic to be right there with them in the corporate development arena. The CLR in a way makes it an even field. Now any language developer can compile to the CLR and be useable in Visual Studio and be used anywhere on any device that it supports.
I don't know how the compiler works and how hard it would be to do, but since the powerbasic compiler is so good, it shows they know what they are doing. I am sure they can make one to compile to CLR too.
Garbage Collection sound like a good thing to me, but I don't know enough about it to judge if one Garbage Collector is good or not. Seeing how Patrice is in another league as many of the guys on this forum, I will take his word for it.
I put myself in Mr. Zale's position and there are so many directions that they can go. They also have a long time history with lots of customers over the years. So they need to go in steps not to upset their wishes. But change is hard to accept, and rightfully so on many levels.
PowerBasic is loved because of its C like power but with the nice syntax of Basic. If you put the time and effort you can write anything with it. But to new users, these methods are outdated and way out of pace with what is out there in the competitor's products. I think there is a huge market out there for something like C++, that can be OOP or Procedural. Can be compiled to a fast executeble and be used to develop any type of application necessary, but where the programmer feels in control and not forced down a cattle chute.
It would be awesome to sit in on the meetings going on at powerBasic headquarters in which direction they need to go and how quickly they can get there.
See my comment below in the C# Carousel source code
// Very important the call back must be static
// to prevent from access violation during garbage collection.
// Search for <<Callback Functions>>
static CallBack UseCallBack = null;
protected override void WndProc(ref Message m)
{
// We monitor the GDImage events from there
// And we are doing it from there to protect us from the infamous
// CallbackOnCollectedDelegate
// (rappel effectué sur un délégué par le garbage collector)
MonitorGDImageEvents();
switch (m.Msg)
{
case Api.WM_SIZE:
private void MonitorGDImageEvents()
{
UseCallBack = new CallBack(GDImageCallBack);
// We use a callback to monitor the GDImage control messages
// Create a %WM_LBUTTONDOWN event
GI.ZI_EventMessage(GDImageCallBack, Api.WM_LBUTTONDOWN, true);
// Create a WM_RBUTTONDOWN event
GI.ZI_EventMessage(GDImageCallBack, Api.WM_RBUTTONDOWN, true);
// Create a WM_KEYDOWN event
GI.ZI_EventMessage(GDImageCallBack, Api.WM_KEYDOWN, true);
// Create a WM_MOUSEMOVE event
GI.ZI_EventMessage(GDImageCallBack, Api.WM_MOUSEMOVE, true);
GC.KeepAlive(UseCallBack);
}
From time to time the garbage collector lost the address of my CallBack, I get there:
UseCallBack = new CallBack(GDImageCallBack);
The solution is to move all the code that must rely on a fixed address into an unmanaged DLL.
This is because pointers are considered unsafe, that's ridiculous!
Quote
Petr, the compiling to CRL would be optional. If you don't need to compile to CLR you wouldn't.
Well. Things aren't so easy. You can't write an application using unmanaged code, the Windows API and/or COM and expect that the compiler will compile it to .NET using managed code and the CLR runtime. PB will have to add support for managed code, assemblies, .NET classes, etc., and you will have to write the application using this new support.
What is more feasible is to be able to host the CLR and call .NET classes and assemblies from you PB unmanaged code using COM (please, notice that this is not the same that making a COM callable wrapper; I'm talking of hosting the CLR, that is nothing but a COM server). I have done it with some classes. Need to do more research to load assemblies.
Regarding Linux, currently there is not market for a PB console compiler, in my opinion. To invest lots of time and resources to just sell a few copies will be foolish.
I can't say which OS will come out, but just being tied to Microsoft platforms I think can be dangerous. I think we are on the edge of a major change to portable devices. Even laptops will seem big compared to what can truly be carried around These devices need to be lower priced as being out and about so much they need to be replaced often just from exposure to danger.
We are seeing the next step to the GUI with touch controls as in the iphone and other products coming out. Can you imagine a touch screen that could take the finger print oils, absorb it so it auto cleans the screen and this nutrient is then used as added energy to go into powering the screen or go into the battery :)
I am reading blogs now where programmers are writing simple apps and games, equivalent to developing in the 1980's, for smartphones and making decent extra income.
For individual hobby programmers it is hard to develop killer apps for the desktop alone anymore. But this new emerging market could be the next boom for single hobby programmers to make a name and some extra money from their hobby.
Maybe I should ask... How long can powerBasic survive staying as it is with only few changes or new commands and charge as it does now? They are in a difficult position to decide which way to go.
Who would gain anything from some kind of PB 'compiler' doing .NET?
Any language in Visual Studio calls it's compiler to compile MSIL.
That means: at the end all code is the same, VB.NET c# and so on.. it's all the same.
Therefore there is no real market for a PB.NET unless you like the syntax but that would not make it a real compiler.
>This is because pointers are considered unsafe, that's ridiculous!
Can be but imo it's just a matter of time you'll use the 'native' .net functions instead of your current o-so-easy to reuse dll.
I've seen weird object stuff for ordinary windows message processing and i just have to adjust to that.
The comment about mono is very viable, only your .net managed code will run on that..
So better prepare..
(And no, i don't think i'll see the day me doing a win32 lookalike in .net, me not 'adjusted' yet :) )
PS, what's wrong with the garbage collector?
What do you care if a var is destroyed when out of scope or some time after getting out of scope?
Some objects need to be unset manually, implement the Dispose interface and to make it easy on you use the using(){} syntax.
using( Class1WithIDispose c = new Class1WithIDispose() )
{
} // auto destruct here..
One of the issues which preoccupies me is how to safeguard and carry your intellectual assets ie your programs from one system or language to another. I have lost a number of programs in the past because the machines which ran them became obsolete and the tape/disc formats were incompatible/ With the Web this wont happen, but the software technologies are evolving so rapidly that it is too easy to leave old systems stranded, and uneconomic to maintain.
Vista has made a number of PC and programs inoperable, so that should be a warning sign to us all, not to be totally dependent on one familiar system. Not to mention the stealth installations that MS carried out this Summer, without disclosing to us.
I hope we will be able to conserve the essentials of all the hard work that José, Patrice and all the other contributors have put in here, in a form which will enable them, to be deployed on other systems and devices when they come along.
Did you guys see the C# changes coming for 2008 on the intentional software site? Do you think it is some kind of joke, but the author is Charles Petzold.
What is funny is, if this is not a joke, is taunting coding in xml like syntax. But if you watch one of the video presentations, the lecturer is talking about how everything is being to xml'ized.
That things could be written cleaner etc. So funny seeing 2 diverse views in a way.
http://www.charlespetzold.com/etc/CSAML.html
VISTA instroduce a new concept in programming, that will split the making of new softwares into two parts:
1 - The interface that would be done by designers using WPF and XML to create the graphic chart (like in web design).
2 - The core programming for logic flow and application's features, that's what you are doing right now.
And part 1, will soon become the most important part...
X3D is an example of an XML language. I generated X3D scripts for the dome models. I have to say that while it does the job, it is not a very elegant language, and its predecessor, VRML , with its curly braces syntax looks a lot better.
Fortunately there are 3d browsers that will accept either syntax, so for future projects I think I will go for VRML, which has the added advantage of being a recognised MIME type (.WRL files) and most servers will delivers these files correctly, for use directly in web pages.
http://www.web3d.org/
XML is supposed to be both human-friendly and concise, but it can so easily lose both objectives, especially if there is a committee driving the development.
Kent,
that Petzolds article is joke for sure, check the date of creation - "© Charles Petzold, April 1, 2006" :)
Petr
'Many a true word is spoken in jest'
as they say.
Charles Petzold's Blog is a good read too.
There's a learned exposition on toilet roll sizes, and a number of other topics.
I didn't see the date, good catch Petr, it sounded like a joke but you never know.
For instance, last night i installed vmware player on my notebook. I downloaded the vmware appliance for HAIKU, which is BEOS living on, it is so fast even under vmware on my notebook.
This OS was way ahead of its time and should have been the new OS for the new millenia. I also installed an ubuntu appliance and the boot up time and just reaction to user input is so much better in HAIKU. SO to me a company like BEOS going out of a business is a joke, they had the better product but the world shunned it, makes no sense to me :)
I remember the excitement in '95 (I think), when I read the first article about the new BeOS and seen the first pic of a dual processor BeBox, with its dual column of blinking LED to show the CPUs load!
It seemed a new Amiga-like phenomenon.
(http://www.applefritter.com/images/bebox_full-2616_640x480.jpeg)
(from http://www.applefritter.com/node/2616)
Later, when BeOS have been ported to x86, I used it quite a lot: its speed was really amazing.
Sad to see it disappearing.
Bye!
The AMIGA-OS had some features long time ago (Screens with independent Resolutions) which are not available like that in Windows up to now.
Even the ACORN Archimedes had some funny builtins. One of them was a Basic Compiler that reminds me of Powerbasic.
But it was a Part of the OS and heavily used inside the system.
The Archimedes had its operating system, including many windows features - scaleable fonts etc, and BASIC and inline assembler coded into ROM. It was way ahead of its time. There was even an MSDOS emulator (on floppy) so you could run many standard PC applications on it (at a modest pace.)
Unfortunately, its developers did not engage with the demands of the market, and develop a machine that could compete with the emerging PC clones. Their hardware was overpriced and their service inadequate. So like so many other home computers, they did not make it in the international market.
But the core technology, the ARM processor is to be found in many mobile devices today. These are RISC (reduced instruction set) devices with very low power consumption and were/are very simple to code.
Returning to Kent's 'strange ideas', which many programmers are inclined to have in the early hours, I dont think we will ever get the perfect language that satisfies all our aspirations.
Edwin raised the idea of using a preprocessor to work around some of the limitations of Power Basic. Of course there is the problem that future versions of PB might render the preprocessor incompatible, thereby breaking some of your source code. But as long as you have full control over the preprocessor then I think this idea might be a runner.
The metalanguage supported by the preprocessor could support OOP and Functional or Declarative styles of programming - whatever suits best. Many features would only require static compilation, and the preprocessor would be responsible for generating structures and symbol names. But some operations will require virtual tables and other dynamic structures for which additional modules of code would be incorporated.
This would further make programming lass dependent on any one version of a language. It would be possible, for instance to generate code for PowerBasic, FreeBasic or PureBasic or even FreePascal!
What do you think?
I don't know enough about these matters to really answer your post Charles, but do I understand this correctly; All compiles put out .obj files which are then assembled by the linker to make the final executable. Are all .obj files the same or does each compiler put out its own .obj files?
Taking PowerBasic, since it already has a very popular and fast compiler, is there anything in its output before the final executable is made to allow those files to be linked together with maybe similar files from an OOP language like freepascal?
Could the mix and match of output from different compilers be handled at the point?
As far as I know obj files are a common standard, and used for static linking, ie the object code is integrated into the compiled exe, in contrast to DLLs.
So object files from different compilers can be used together provided they use compatible calling conventions ie stdcall cdecl or pascal and understand each other's function naming conventions.
But PBWin does not support object files, only DLLs.
What I had in mind was just to translate the source code, turning OOP structures etc into source code that PB can understand. Similar to using Macros but far less restricted,the output of the preprocessor would be a straight .BAS file.
I also thought about a Preprocessor long time ago, and even asked Jose that time to support it in SED.
Anyway he did not like the idea much for compatibility reasons, and he only agreed to implement a Post-Processor that time :-).
What a Pre-Processor could do anyway would be to make all those nasty declares, and it would not be incompatible if its not much more. Maybe it could also implement some additional ASM Commands which are actually not supported, like CMOV.
I see bigger problems, when using the Debugger, because at the end you debug code you did not write.
You get two diffrent source codes. One before - and one after Pre-Processing.
When you archive your source-code you need always to keep a actual copy of the pre-processor with the code, because any change in there may render your code useless otherwise.
Anyway at the end - to make it good - you'd have to make a sort of compiler that does not compile to ASM but to PB-Code and to PB-ASM where possible.
While there is no problem in providing the two levels of source code I can see the difficulty that would arise using a debugger.
I think the answer is to get the preprocessor to generate the debug code, something that could be switched on or off. The concept could be taken even further by embedding unit tests for each function. This would provide a formal method for the code to prove its own functionality during development. The embedded tests are then 'switched off', for generating the finished BASIC source.
This could make the programming process a lot more sophisticated and reduce that very time-consuming tail of debugging that can occur at the end of a project.