strange thoughts for fun discussion

Charles Pegge · October 03, 2007, 11:13:39 AM

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

Kent Sarikaya · October 03, 2007, 06:47:39 PM

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

Marco Pontello · October 04, 2007, 01:59:39 AM

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.

(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!

Theo Gottwald · October 04, 2007, 08:45:58 AM

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.

Charles Pegge · October 04, 2007, 10:56:07 AM

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.

Charles Pegge · October 04, 2007, 05:11:10 PM

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?

Kent Sarikaya · October 05, 2007, 06:05:10 AM

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?

Charles Pegge · October 05, 2007, 06:48:32 AM

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.

Theo Gottwald · October 05, 2007, 09:33:30 AM

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.

Charles Pegge · October 05, 2007, 11:03:36 AM

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.