Announcement

Collapse
No announcement yet.

Wishlist for all versions of PB

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Wishlist for all versions of PB

    hi Dave,

    Adding // for comment statement
    build-in pointer as arguments in functions/subs
    build-in return a pointer in functions/sub
    standaard libraries
    advanced syntax checking and highlihting (more colors and font types)
    adding printer setup in de IDE
    buildin datatypes: ENUMERATE, SHORT, OBJECT

    Kind regards,
    Stephane

  • #2
    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


    ------------------
    Regards,
    Peter

    Comment


    • #3
      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>

      Comment


      • #4
        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).]

        Comment


        • #5
          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]

          ------------------
          hutch at movsd dot com
          The MASM Forum

          www.masm32.com

          Comment


          • #6
            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>
            Lance
            mailto:[email protected]

            Comment


            • #7
              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.
              If you try to make something idiot-proof, someone will invent a better idiot.

              Comment


              • #8
                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).]

                Comment


                • #9
                  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



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

                  Comment


                  • #10
                    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>
                    Home of the BASIC Gurus
                    www.basicguru.com

                    Comment


                    • #11
                      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.



                      ------------------
                      Chris Boss
                      Computer Workshop
                      Developer of "EZGUI"
                      http://cwsof.com
                      http://twitter.com/EZGUIProGuy

                      Comment


                      • #12
                        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


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

                        Comment


                        • #13
                          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).]

                          Comment


                          • #14
                            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>

                            Comment


                            • #15
                              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).]

                              Comment


                              • #16
                                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]

                                ------------------
                                hutch at movsd dot com
                                The MASM Forum

                                www.masm32.com

                                Comment


                                • #17
                                  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).]

                                  Comment


                                  • #18
                                    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).]

                                    Comment


                                    • #19
                                      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
                                      ------------------
                                      hutch at movsd dot com
                                      The MASM Forum

                                      www.masm32.com

                                      Comment


                                      • #20
                                        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>
                                        Home of the BASIC Gurus
                                        www.basicguru.com

                                        Comment

                                        Working...
                                        X