Announcement

**Peter Lameijn** · 14 Mar 2000, 12:35 PM

After your numerous wishlists I couldn't resist to react. Maybe you should first try some in-depth programming with PB to see it isn't too bad as it is. While some wishes are useful, the bulk is more about converting PB into another language. (to have c-type comments isn't really a useful addition...)
Peter

------------------

**K Peel** · 14 Mar 2000, 01:17 PM

And most of the other wishes could come 3rd party, or you could write them yourself, if you were good enough!

------------------
Kev G Peel
KGP Software
Bridgwater, UK.
mailto:[email protected][email protected]</A>

**Enoch S Ceshkovsky** · 14 Mar 2000, 04:47 PM

PB already has "built-in" pointers for functions. It's called a LONG or DWORD.
K Peel brings up an interesting idea. It is very possible to write an OOP system for PB. It can't use MyObject.Method, but use MyMethod(MyObject), unless you wanted to get into writing a "pre-compiler" (ick). MyObject would be a pointer to a UDT in the heap which stores its IIDs and "module level" variables. I used some free time I had today to write a rough model and get it working enough to prove the concept with multiple interfaces, etc. It *should* work as a DLL, too. It's really just a way of organizing everything global/static into UDTs. I'm sure a company like JazzAge could make a visual designer that would produce template code for your classes. (not the COM thing they have now, but similar.)
Yeah, it's extra overhead, but thats what OOP is about. Another layer between you & what's actually going on.

------------------

[This message has been edited by Enoch S Ceshkovsky (edited March 14, 2000).]

**Steve Hutchesson** · 14 Mar 2000, 05:48 PM

I get the impression that this subject has been flogged to death a number
of times.

1. Adding // for comment statement

Why, PowerBASIC already has ' for basic and ; for asm. C++ comments take
longer to type.

build-in pointer as arguments in functions/subs

2. Already has them in the form of arguments passed as either CODEPTR
or STRPTR with the correct data type being LONG. Data type PTR etc..

build-in return a pointer in functions/sub

3. LONG

standaard libraries

4. Yes, most agree here.

advanced syntax checking and highlihting (more colors and font types)
adding printer setup in de IDE

5. Feel free to write your own. PowerBASIC is powerful enough to do it.

buildin datatypes: ENUMERATE, SHORT, OBJECT

6. PowerBASIC has its own data types that correspond to generic size data
types. BYTE, WORD, DWORD, QWORD. It has additional types like STRING.

If you bother to look at the C++ data types, you will see a familiar story

HANDLE equ DWORD
HICON equ DWORD
HACCEL equ DWORD
HBITMAP equ DWORD
HBRUSH equ DWORD
HDC equ DWORD
HFONT equ DWORD
HICON equ DWORD
HMENU equ DWORD
HINSTANCE equ DWORD

Then you can have,

MyDataType equ DWORD
YourDataType equ DWORD
Any_Other_Unnecessary_Data_Type_To_Confuse_Already_Confused_OOP_Programmers equ DWORD
MyByte equ BYTE
YourWord equ WORD
SHORT_Can_Be_Either_INTEGER_or_LONG_Depending_On_16bit_or_32bit equ DUNNO??????

There are a lot more, the currect count for data types in C++ is over 60.
It would be a considerable blunder to follow a path that is responsible
for such an increase in the number of data type and size errors.

Now here is a REVERSE wish list for the type of product that you want
PowerBASIC to emulate.

1. Complete compiler redesign to get rid of the useless code that makes
the programs at least 10 times larger.

2. Removal of any form of dependence on runtime DLLs.

3. Data type simplification to reduce the endless data type errors.

4. Documented reference to the methods of interfacing with proprietry
types of DLLs.

5. Complete removal of tokenised code and replace it with minimum size
binary code.

This wish list could go on forever as well but when it was fully acheived,
you would just buy PowerBASIC, it does not suffer from any of these
problems.

I agree with the other comments here, learn to write the language before
you create a wish list for what it should be. If you want to use OBJECTS,
write them, PowerBASIC is easily powerful enough to do that and without
the phony notation associated with the languages that you would wish it
emulated.

[email protected]

------------------

**Lance Edmonds** · 14 Mar 2000, 07:48 PM

1. Adding // for comment statement
Why, PowerBASIC already has ' for basic and ; for asm. C++ comments take longer to type.

In the current Windows products, you can use either ; or ' for comments that follow inline assembly mnemonics/operands.

Also, lets not forget that we still support the traditional REM statement!

Finally, characters that follow an underscore (line-continuation) character are also interpreted by the compiler as comments.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Matthew Berg** · 14 Mar 2000, 11:24 PM

If you want to use OBJECTS, write them, PowerBASIC is easily powerful enough to do that and without the phony notation associated with the languages that you would wish it emulated.

Ah ha! Someone that actually agrees with me. Despite what many others have said on this BBS and even hints from Dave, I believe PowerBASIC doesn't need the likes of OOP to be a good compiler. It would be unfortunate if we were to end up paying for a "feature" we didn't want or if PowerBASIC's performance were compromised all for the sake of a programmer convenience.

For those that really can't live without OOP, use a language like VB for the OOP code and use PowerBASIC where efficiency/speed is required or write your own pre-compiler. Perhaps a third party pre-compiler supporting OOP could become available in much the same way that COM support is possible through a third-party product.

**Siamack Yousofi** · 15 Mar 2000, 03:10 AM

Matthew

I agree with you too. By introducing OOP Powerbasic may loose as many customers as it may win.

IMHO if OOP is to be introduced it should be done as a separate compiler, designed and written from ground-up and marketed under a different name to safeguard the current reputation and brand recognition of Powerbasic. This new compiler can be written in PB instead of hand assembled code to shorten the development cycle.

The current products can continue to evolve without compromising size/performance/independence formula and the new compiler can try to be everything to everyone.

This way we will have PB/CC, PB/DLL and some thingimigingi++ "proudly brought to you by the makers of PB" and everyone will be a winner.

Siamack

------------------

[This message has been edited by Siamack Yousofi (edited March 15, 2000).]

**Philippe Monteil** · 16 Mar 2000, 08:37 AM

Siamack,

<<I agree with you too. By introducing OOP Powerbasic may loose <<as many customers as it may win.
Why is that? Any C++ compiler can still be used as is to compile pure C code. This could apply to a PB++ compîler as well.

It is always surprising for me to see PB fellows implicitly or explicitly relate OO to bloatware. I would be willing to help clarify and quantify things on this issue. If anybody is willing to upload the code for a PB test DLL, I will produce its C++ equivalent, and we will then compare the two in terms of speed, size, resource requirements, compilation time...

Philippe Monteil
JAZZAge Software

------------------

**Dave Navarro** · 16 Mar 2000, 09:31 AM

By adding objects to PowerBASIC, I don't think we'll lose a single customer. Just because objects are there, it doesn't mean you have to use them.

And Philippe, you can blaim the "OOP = Bloatware" idea on Microsoft. It's true that objects themselves do not mean an app will be bloated. The problem is that Microsoft's implementation of objects in MFC and the poor way that objects are used by many C++ programmers has spawned this universal belief.

It will be *just as easy* for BASIC programmers to misuse the OOP capibilities in a future version of PowerBASIC to create bloated software.

However, I think that PowerBASIC will attempt to do what Microsoft has never done... Educate programmers on the proper use of objects to prevent a "Bloatware" scenario. Microsoft has been so busy telling everyone how easy and wonderful objects are that they downplayed "proper use" in favor of "easy use" (strictly my opinion). Just because you *can* make something an object, that doesn't mean that you *should*. Something a lot of C++ and VB programmers don't understand.

Proper education is the key!

--Dave

------------------
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Chris Boss** · 16 Mar 2000, 09:34 AM

I agree with Phillipe !

I think it is possible to impliment OOP (object oriented programming) in PB with little or no lose of efficiency.

It just has to be done "right", thats all.

Objects are what drive the latest versions of MS compilers and objects used correctly can be very powerful.

Objects allow you to build "components" easier and they are very powerful. I think if PB added both Objects ( handle properties and methods) and Static Libraries, you would see a whole bunch of third party components built for PB.

Third Party developers who build addons to PB are the ones who really need such features. It allows us to create easy to use (and yet powerful) components that integrate easily into the PB language.

------------------

**Philippe Monteil** · 16 Mar 2000, 10:05 AM

Dave,

<<It will be *just as easy* for BASIC programmers to misuse the
<<OOP capibilities in a future version of PowerBASIC to create
<<bloated software.
I fully agree, OO introduces many new and powerful concepts making possible to write safer, more usable, smaller (believe it or not) code provided that you master them.

Philippe

------------------

**Siamack Yousofi** · 16 Mar 2000, 02:17 PM

Philippe

I have no doubt that Philippe Monteil or David Navaro Jr. can write C++ programs that are faster and smaller than any equivalent code I could write in PB or even the Assembler. One good reason is that Philippe and Dave are infinitely better programmers than Siamack.

If PB develops a compiler that gives me OOP without compromising the current achievements in size/performance/independence of code, I will be the first to jump in and you will find me the most vocal supporter and promoter of such a product.

The fundamental difference is the Top-Down approach of procedural programming vs Bottom-Up approach of OOP. It’s the question of which end of the trumpet we chose to blow in.

I can cook food for a thousand people using a central kitchen or can give every person his/her own small kitchen and tell them “people.cook”. If every one is having the same dish then the central kitchen may be a better choice. It has fewer overheads and works faster. Of course where each person fancies a different dish or is on the road then I am better off giving everyone his or her own kitchen. It is the size and complexity of these little kitchens, which dictates the size/performance/independence.

This brings me to Dave’s comment regarding educating the users. It ain’t going to happen Dave. I have been in teaching game for a long time including 6 years as an associate professor when I lived in South Africa. Successful programming requires both knowledge and discipline. You may be able to give them the knowledge but you cannot force them to exercise discipline.

Besides, with the current worldwide skill shortage any dude, who has read 5 chapters of “Programming for Dummies or Visual Basic for the Absolute Idiots or C++ for loonies” hits the road, calls himself a consultant and lands $70,000 a year jobs. Training organizations turn out truckloads of MCSC’s and MCSD’s out of 8-week boot camps!

It will take years to become like Philippe or Dave or Hutch and not everyone can no matter how hard they try.

In the past 27 years I have held positions in all 6 areas of IT namely Management, Programming, Tech Support, Sales and Marketing, Training and Recruitment and have never seen education produce a good programmer. IMHO programming is an Art not a Science and must come from inside.

Every day I receive e-mail from Siberia, India, Fiji, West Indies and many other places offering fixed cost 'off-shore' development or $10/hour programmers on just about any platform you can mention (I even had one offering prolog and lisp! development). These people are actually landing contracts! How are you going to educate programmers working in these sweatshops? A bad programmer out in the market can ruin the reputation of a toolmaker by writing junk code and blaming the vendor. Let us be fair, we all do this to Microsoft from time to time.

I have no disagreement with anyone here. Dave, you come up with an OOPowerbasic that gives me the same output as the current PB and I will include you in my will.

Siamack

P.S. You will inherit a lot of debt of course.

------------------

[This message has been edited by Siamack Yousofi (edited March 16, 2000).]

**K Peel** · 16 Mar 2000, 06:51 PM

Siamack, I agree with most of your last post, except...

Originally posted by Siamack Yousofi:
It will take years to become like Philippe or Dave or Hutch and not everyone can no matter how hard they try.

True, with most 'wannabe' programmers, its just a case of

"I've read a book on some programming (sort of), now gimme a job!"

But if you're more determined to succeed, then you will become a great, or at least half-great programmer.

I have been programming for 5 years now, and yet I still learn something new when I look at other peoples code or programs.

But assembler programmers (such as hutch and others) are getting rarer and rarer

------------------
Kev G Peel
KGP Software
Bridgwater, UK.
mailto:[email protected][email protected]</A>

**Siamack Yousofi** · 16 Mar 2000, 08:05 PM

Kev

You are absolutely right. There are many good self-educated programmers around and you will find most members of Powerbasic community fall into this category. It is the nature of the current PB compilers that separates pros from Amateurs. It is a blessing that we do not have wannabes amongst us.

“Easy” tools become magnets for wannabes who ruin the market, destroy user confidence and harm the product. My response to Dave’s idea of “educating” the developers was in this context. I apologize for any misunderstanding.

Talking about finding good assembly programmers these days, it is like trying to find a virgin in a maternity ward.

Siamack

------------------

...and the Administrator - Please curb your use of expletives.

Dear administrator - I edited the reference that seems to have different usage in Australian English. Sorry and Thank you.

[This message has been edited by Siamack Yousofi (edited March 17, 2000).]

**Steve Hutchesson** · 17 Mar 2000, 01:42 AM

This topic does seem to have improved some. A few of the ideas mentioned are
worth commenting on as they have considerable potential. The notion of
OBJECTS in one form or another has been with us for a long time, well before
the idea of Object Oriented Programming and it is this distinction that is
an interesting one.

Older style programming techniques were generally referred to as
procedural programming and when it was well written, it was modular in its
form to make larger and more complex projects possible. This style of
programming is finally based on the hardware capacity to use the "call"
"ret" syntax which gives you very efficient branching to other blocks of
code which you can return from to the next instruction after it was
called. This is the machanics of SUBs and FUNCTIONs.

Combine this low level capacity with the normal practice of code reuse and
you get very fast minimum size code where you have the choice between
inlining the code for speed and reusing a section of code for size.

To write OBJECTS involves the notion of code reuse so it requires a
language powerful enough to either build libraries or DLLs. Once you have
the capacity to isolate a block of code, whether it be in a library, a DLL
or as in PowerBASIC with the INCLUDE syntax, you can construct more or
less whatever you like and reuse it at a later time.

An OBJECT need not just be interface components either, the range of
things that programmers write is truly massive so in a multitude of areas
where complex data is manipulated, the capacity to write isolated blocks
of re-usable code is a useful approach.

What makes the great divide is not the capacity to write and use OBJECTS
but only being able to use other peoples OBJECTS. Programming languages
that are committed to an architecture they cannot change and OBJECTS that
they cannot fix is the hallmark of modern OOP programming. The idea of
what I personally call "concept programming" is one that is constructed by
other procedural programmers so that "Object Oriented Programmers" can get
a program written.

For the C old timers as Philippe mentioned, at least some of the modern
C++ compilers will still compile straight C code if you can shovel your
way through the notation for C++ to find it but by my comparison of a bare
API from end with a menu and icon, Visual Studio 6 produced an API front
end of 28k, PowerBASIC did it in 9k and MASM does it in 5k. I guess the
numbers speak elegantly as to who has the compiler efficiency here.

OBJECTS in themselves are not the problem if they are well done, its the
normal problems associated with OBJECTS that you cannot fix. The interface
for later windows COM objects is a different concept with a virtual table
that need to be done at the compiler level to be efficient but it is not
in itself the problem if the next version of PowerBASIC has COM support,
its when you can ONLY use OBJECTS and not construct normal procedural
code.

I support the idea of a compiler that does both, the capacity to write
minimum size procedural code as well as being able to interface with the
later style COM objects. If the COM objects are buggy or do not suit what
you want in your program design, you are not forced to use them.

Regards,

[email protected]

------------------

**Niraj Bhatt** · 17 Mar 2000, 02:34 AM

From the above discussion and Dave's comment's I can see OOP coming to PB in next version

------------------
Niraj Bhatt

[This message has been edited by Niraj Bhatt (edited March 17, 2000).]

**Siamack Yousofi** · 17 Mar 2000, 03:04 AM

Originally posted by Steve Hutchesson:
...Visual Studio 6 produced an API front end of 28k, PowerBASIC did it in 9k and MASM does it in 5k. I guess the
numbers speak elegantly as to who has the compiler efficiency here.

Do not forget the 266k msvcrt.dll we have to add to the 28k exe generated by Visual Studio 6 for it to work...

OK Philippe

Here is the challenge you were looking for. Take any of the examples from Petzold (PB translation) and write a C++ version, which is smaller and faster. And to make life easier for you we will ignore the 266k msvcrt.dll.

Siamack

------------------

[This message has been edited by Siamack Yousofi (edited March 17, 2000).]

**Steve Hutchesson** · 17 Mar 2000, 04:04 AM

Phillipe,

As you have the capacity to build DLLs in C/C++, I was interested to see
what the minimum size was that it could build a working 32 bit PE DLL.

Below is the code for 2 test DLLs, one in PowerBASIC that builds at 5632
bytes and below it is the identical code in MASM that builds at 2560 bytes.

Neither uses a data section and the 2 asm instructions in both are identical.

Regards,

[email protected]

Code:

  POWERBASIC code
  
  ' ###########################################################################
  
      #COMPILE DLL
  
    ' -----------------------------------
    ' set correct paths for include files
    ' -----------------------------------
  
      #INCLUDE "d:\pb6\winapi\win32api.inc"
  
  ' ###########################################################################
  
  FUNCTION LibMain(BYVAL hInst    AS LONG, _
                   BYVAL Reason   AS LONG, _
                   BYVAL Reserved AS LONG) EXPORT AS LONG
  
      FUNCTION = 1
  
  END FUNCTION
  
  ' ###########################################################################
  
  FUNCTION TestFunction ALIAS "TestFunction"(ByVal TheParam as LONG) _
                                             EXPORT as LONG
  
      ! mov eax, TheParam
      ! shl eax, 1
  
  END FUNCTION
  
  ' ###########################################################################
  
  ---------------
  MASM code below
  ---------------
  
  ; #########################################################################
  
      .386
      .model flat, stdcall
      option casemap :none   ; case sensitive
  
  ; #########################################################################
  
  TestProc PROTO :DWORD
  
  .code
  
  ; #########################################################################
  
  LibMain proc hInstDLL:DWORD, reason:DWORD, unused:DWORD
  
      mov eax, 1
      ret
  
  LibMain Endp
  
  ; #########################################################################
  
  TestProc proc TheParam:DWORD
  
      mov eax, TheParam
      shl eax, 1
  
      ret
  
  TestProc endp
  
  ; #########################################################################
  
  End LibMain

------------------

**Dave Navarro** · 17 Mar 2000, 05:49 AM

This brings me to Dave’s comment regarding educating the users. It ain’t going to happen Dave. I have been in teaching game for a long time including 6 years as an associate professor when I lived in South Africa. Successful programming requires both knowledge and discipline. You may be able to give them the knowledge but you cannot force them to exercise discipline.

Siamack,

You give me way too much credit. There are programmers on this web site who are much better than I am. I'm just lucky in that I learn things pretty quickly.

One of the "philosophy's" that I brought to PowerBASIC when I came to work here is my belief that if you give programmers both code and information it will make your company and your product worth more. The rich set of code examples we provide and the presense of this web BBS are a small embodiment of that ideal.

And it has worked. When I came to work for this company, we averaged 30 tech support calls a day. And our sales people would have to spend a significant amount of time on the phone explaining to potential customers exactly what our products were and who we were. By putting as many samples as we could muster in the products and as much information as we could create on the web site, we've chopped that down significantly.

I'd guess that the number of PowerBASIC users today is 6 to 8 times what it was back then, but our "support volume" is down.

If we give our customers some *really good* examples of OOP programming and some well written documentation, I think that the majority of our customers who decide to use objects will learn from us and not make most of the mistakes made by many C++ programmers today.

--Dave

------------------
PowerBASIC Support
mailto:[email protected][email protected]</A>

Announcement

Wishlist for all versions of PB

Wishlist for all versions of PB

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment