Which BASIC is more compatible with Quick Basic
-
Psychophanta
- Always Here
- Posts: 5153
- Joined: Wed Jun 11, 2003 9:33 pm
- Location: Anare
- Contact:
Should be good to make a serious comparative in speed and size of executeables.
I must say that time ago i made fast comparatives and for example PowerBasic is faster than GCC and G++ compilers for this routine:
C:
PowerBasic:
I must say that time ago i made fast comparatives and for example PowerBasic is faster than GCC and G++ compilers for this routine:
C:
Code: Select all
#include <windows.h>
int WINAPI WinMain (HINSTANCE hInstance,
HINSTANCE hPrevInstance,
PSTR szCmdLine,
int iCmdShow)
{
long starttime,elapsedtime, I;
float y=5,x;
//starttime=GetTickCount()
for (I=1;I<=500000000;I++) x=x+y*1.000001;
//elapsedtime=GetTickCount()-starttime
MessageBox (NULL, "Hello", "Hello Demo", MB_OK);
return (0);
}Code: Select all
#COMPILE EXE
FUNCTION PBMAIN () AS LONG
DIM starttime AS DWORD
DIM elapsedtime AS DWORD
DIM I AS DWORD
DIM y AS SINGLE
DIM x AS SINGLE
y=5
FOR I=1 TO 500000000
x=x+y*1.000001
NEXT
MSGBOX "Hello, World!"
END FUNCTION
I use both PowerBasic and PureBasic, and all I can say is that both languages
are good, solid performers, but they have relative strengths and weaknesses.
PowerBasic supports far more data types and is particularly strong with ways
for handling strings. With PureBasic, you may find yourselfs handling chunks
of memory in order to support null characters within strings. Does that make
PureBasic inferior? No. It just involves a different concept to achieve the
same end result. They both support inline assembler code, meaning that you
can always go beyond the capabilities of the language itself.
Both languages represent a superset of features and capabilities that go far
beyond those that were found in Quick Basic, and both abandon the need to
write code that resides in 64k segments or that have to overload a previous
module because of memory restraints. They are both fast and compact.
They both benefit if you use an external editor. They both provide a debug
capability, and let you monitor variables and registers during a process of
stepping the code.
PowerBasic actually has two compilers - one, the Console Compiler, is
intended to be most like Quick Basic. The Power Basic Windows Compiler
is designed to work more like a Windows development platform. But over
90 percent of the code handled by the two compilers is identical, and each
compiler costs more than twice what you pay for PureBasic. And with
PureBasic, you decide whether to have it use a Console or not by just
including the necessary statements in your code.
PowerBasic does NOT Require Include files. An Include file is nothing but
a basic source file that you can append to your new program with a simple
#INCLUDE metacommand. Think of #INCLUDE as meaning "Insert here",
and you understand what is meant by "Include". It acts as if it were cut-
and-pasted into your code at that exact point in your program, but does
not occupy additional space in your new source code.
What you are apparently confused by is that PowerBasic has the whole of
the Windows API set up in a series of Include files if you want to include
them in your program,. The Win32API.Inc file has almost every widely
used API call and structure defined in it, meaning that you can include
just that one file and reference about 99% of the API calls normally used
by most programs. This approach means that the PowerBasic compiler
can verify the parameters and types as you attempt to use them in your
program. It permitted PowerBasic and the include files to be developed separately.
I find that the Include files from PowerBasic sometimes helpful, when I am
unable to find sufficient info on an API call or the constants and structures
used with that call. Note that PowerBasic will only include the actual code
required for program compilation and execution, so including a large
include file full of definitions and constants does not have a detremental
impact on program size or execution speed.
The Console Compiler actually has evolved to give the user more control
over the Console size and appearance, and now includes some graphics
capability. Much the same is possible in PureBasic, but some of those
capabilities are not available as language extensions, but must be done
through API calls.
For converting Quick Basic programs, I find the Console Compiler to be a
better choice. The extensive range of data, particularly string types and
operators, also makes Console Compiler a great choice for data
manipulations, management and calculations. It has a number of Array
and Matrix capabilities that strengthen it in that area.
Were I concerned with internet, sound, and video, I would tend to favor
PureBasic. But the nature of the two languages is so different, that I
hesitate recommending both at the same time. Since PowerBasic's
Windows compiler is so similar to the CC version, that pair together might
be considered a set, but then you end up paying a lot more money than if
you bought PureBasic and just went with it.
Keep in mind that PowerBasic retains much of the flavor of older Basics,
but is definately a modern language. Yet PureBasic is much closer to
most other versions of Basic today, since they have evolved to bear a
closer resemblance to some of the attributes introduced with C. The
language attributes found in PureBasic are more akin to the Basics now
used in game development, video, and sound, and that would be a better
fit for many people because of their particular interests. It means a much
easier time adopting or converting code from threads related to those
other languages.
are good, solid performers, but they have relative strengths and weaknesses.
PowerBasic supports far more data types and is particularly strong with ways
for handling strings. With PureBasic, you may find yourselfs handling chunks
of memory in order to support null characters within strings. Does that make
PureBasic inferior? No. It just involves a different concept to achieve the
same end result. They both support inline assembler code, meaning that you
can always go beyond the capabilities of the language itself.
Both languages represent a superset of features and capabilities that go far
beyond those that were found in Quick Basic, and both abandon the need to
write code that resides in 64k segments or that have to overload a previous
module because of memory restraints. They are both fast and compact.
They both benefit if you use an external editor. They both provide a debug
capability, and let you monitor variables and registers during a process of
stepping the code.
PowerBasic actually has two compilers - one, the Console Compiler, is
intended to be most like Quick Basic. The Power Basic Windows Compiler
is designed to work more like a Windows development platform. But over
90 percent of the code handled by the two compilers is identical, and each
compiler costs more than twice what you pay for PureBasic. And with
PureBasic, you decide whether to have it use a Console or not by just
including the necessary statements in your code.
PowerBasic does NOT Require Include files. An Include file is nothing but
a basic source file that you can append to your new program with a simple
#INCLUDE metacommand. Think of #INCLUDE as meaning "Insert here",
and you understand what is meant by "Include". It acts as if it were cut-
and-pasted into your code at that exact point in your program, but does
not occupy additional space in your new source code.
What you are apparently confused by is that PowerBasic has the whole of
the Windows API set up in a series of Include files if you want to include
them in your program,. The Win32API.Inc file has almost every widely
used API call and structure defined in it, meaning that you can include
just that one file and reference about 99% of the API calls normally used
by most programs. This approach means that the PowerBasic compiler
can verify the parameters and types as you attempt to use them in your
program. It permitted PowerBasic and the include files to be developed separately.
I find that the Include files from PowerBasic sometimes helpful, when I am
unable to find sufficient info on an API call or the constants and structures
used with that call. Note that PowerBasic will only include the actual code
required for program compilation and execution, so including a large
include file full of definitions and constants does not have a detremental
impact on program size or execution speed.
The Console Compiler actually has evolved to give the user more control
over the Console size and appearance, and now includes some graphics
capability. Much the same is possible in PureBasic, but some of those
capabilities are not available as language extensions, but must be done
through API calls.
For converting Quick Basic programs, I find the Console Compiler to be a
better choice. The extensive range of data, particularly string types and
operators, also makes Console Compiler a great choice for data
manipulations, management and calculations. It has a number of Array
and Matrix capabilities that strengthen it in that area.
Were I concerned with internet, sound, and video, I would tend to favor
PureBasic. But the nature of the two languages is so different, that I
hesitate recommending both at the same time. Since PowerBasic's
Windows compiler is so similar to the CC version, that pair together might
be considered a set, but then you end up paying a lot more money than if
you bought PureBasic and just went with it.
Keep in mind that PowerBasic retains much of the flavor of older Basics,
but is definately a modern language. Yet PureBasic is much closer to
most other versions of Basic today, since they have evolved to bear a
closer resemblance to some of the attributes introduced with C. The
language attributes found in PureBasic are more akin to the Basics now
used in game development, video, and sound, and that would be a better
fit for many people because of their particular interests. It means a much
easier time adopting or converting code from threads related to those
other languages.
has-been wanna-be (You may not agree with what I say, but it will make you think).
-
Fangbeast
- PureBasic Protozoa
- Posts: 4789
- Joined: Fri Apr 25, 2003 3:08 pm
- Location: Not Sydney!!! (Bad water, no goats)
Finally, someone with a more balanced argument. Oldefoxx; I have one complaint however; it's that you seem to be able to out-talk me and I used to be the king.
(/me now falls to the ground laughing).
P.s. I have used many languages in 20 years of programming (doesn't sound like much does it?) and each have their good and bad points. I am surprised by people getting into spirited discussions about it and not getting on with coding. For those of you with paying customers, don't you get paid to produce something, not to flap your gums about which is better????
(/me now falls to the ground laughing).
P.s. I have used many languages in 20 years of programming (doesn't sound like much does it?) and each have their good and bad points. I am surprised by people getting into spirited discussions about it and not getting on with coding. For those of you with paying customers, don't you get paid to produce something, not to flap your gums about which is better????
Amateur Radio/VK3HAF, (D-STAR/DMR and more), Arduino, ESP32, Coding, Crochet
-
Psychophanta
- Always Here
- Posts: 5153
- Joined: Wed Jun 11, 2003 9:33 pm
- Location: Anare
- Contact:
This is an old code by me, and i updated now.sgsong wrote:It will be interesting to see such a comparison. For those who own both power and pure, this should not be that hard.
If some of you feel like and dare to translate next code, then we can see a good comparison for floats calculation and other stuff.
If some of you translate it to PowerBasic take it as a gift from the PureBasic community
The code into the main loop is extremely accurated for avoiding internal commands which depend on the language (i've eliminated SpritePixelCollision() for example, which is extremely slow in PureBasic, BTW)
The line:
Code: Select all
If mDelay<16:Beep_(200,10):EndIf; <- if MustDelay is less than 16, it means that a routine loop takes more than 0.66666666 millisecs (for a 60Hz VSync)Code: Select all
; 2003-12-25 (Psychophanta)
;-INITS:
Global t1.LARGE_INTEGER,t2.LARGE_INTEGER,SysFreq.LARGE_INTEGER,MustDelay.f,mDelay.b,DispPeriod.f
#ENUM_CURRENT_SETTINGS=-1
If QueryPerformanceFrequency_(@SysFreq.LARGE_INTEGER)=0
MessageRequester("Sorry","No High-res timer allowed"):End
EndIf
PokeQ(@SysFreq,PeekQ(@SysFreq)/1000)
QueryPerformanceCounter_(@t1.LARGE_INTEGER);<- checkpoint1
Macro myFlipBuffers
QueryPerformanceCounter_(@t2.LARGE_INTEGER);<- checkpoint2
!fild dword[v_t2];<-now in st0 is checkpoint2. In st1 is seconds amount per screen frame
!fisub dword[v_t1];<-now in st0 is checkpoint2-checkpoint1. In st1 is seconds amount per screen frame
!fidiv dword[v_SysFreq];<-now in st0 is (checkpoint2-checkpoint1)/SysFreq. In st1 is seconds amount per screen frame
!fsubr dword[v_DispPeriod] ;<-now in st0 is DispPeriod-(checkpoint2-checkpoint1)/SysFreq.
!fstp dword[v_MustDelay];<- MustDelay=DispPeriod-(checkpoint2-checkpoint1)/SysFreq.
FlipBuffers(0)
mDelay=Int(MustDelay)
If mDelay<16:Beep_(200,10):EndIf; <- if MustDelay is less than 16, it means that a routine loop takes more than 0.66666666 millisecs (for a 60Hz VSync)
If mDelay>0
Sleep_(mDelay)
EndIf
QueryPerformanceCounter_(@t1.LARGE_INTEGER);<- checkpoint1
EndMacro
#GravityFactor=0.004:#GravityFactor1=0.00000006; <-Esto seria la cte. de gravitacion universal: 6.67E-11 N*m^2/Kg^2
bitplanes.b=32
SCREENWIDTH.l=GetSystemMetrics_(#SM_CXSCREEN):SCREENHEIGHT.l=GetSystemMetrics_(#SM_CYSCREEN)
If InitMouse()=0 Or InitSprite()=0 Or InitKeyboard()=0
MessageRequester("Error","Can't access DirectX",0):End
EndIf
Structure balls
sprite.w;<-#Sprite
x.f:y.f;<-coordenadas instantaneas
dirX.f:dirY.f;<-Vector director
HalfWidth.w:HalfHeight.w;<-centro geometrico
Dimension.w
Mass.f;<-masa
Kinetic.f;<-energía cinética
EndStructure
Global NewList Capsule.balls()
Cursor.balls
;-FUNCTIONS:
Macro Shock(nball)
DiffX.f=Capsule()\x-nball\x:DiffY.f=Capsule()\y-nball\y;<-Vector de distancia
Distance.f=Sqr(DiffX*DiffX+DiffY*DiffY); <-distancia actual entre las 2 masas
Clip.f=(nball\Dimension/2+Capsule()\Dimension/2)-Distance; <-interseccion existente
If Clip>0; <-Si hay interseccion, o sea, si las masas estan solapadas:
UnClip1.f=(Clip*Capsule()\Mass/(nball\Mass+Capsule()\Mass)):UnClip2.f=Clip-Unclip1; <- lo que cada una de ellas tiene que librar para dejar la interseccion
nball\x-DiffX.f*UnClip1/Distance.f:nball\y-DiffY.f*UnClip1/Distance.f; <-se desplaza una de ellas la cantidad de espacio que le corresponde y en la linea de distancia entre masas
Capsule()\x+DiffX.f*UnClip2/Distance.f:Capsule()\y+DiffY.f*UnClip2/Distance.f; <-se desplaza la otra su parte en el sentido contrario
K.f=(DiffX.f*nball\dirX+DiffY.f*nball\dirY)/(DiffX.f*DiffX.f+DiffY.f*DiffY.f);<-constante de proyección del actual vector del movimiento de Cursor sobre la línea de choque.
dirCursorXK.f=K.f*DiffX.f:dirCursorYK.f=K.f*DiffY.f;<-vector componente en línea de choque de la velocidad de Cursor.
K.f=(-DiffX.f*Capsule()\dirX-DiffY.f*Capsule()\dirY)/(-DiffX.f*-DiffX.f+-DiffY.f*-DiffY.f);<-constante de proyección del actual vector del movimiento de Ball sobre la línea de choque.
dirBallXK.f=K.f*-DiffX.f:dirBallYK.f=K.f*-DiffY.f;<-vector componente en línea de choque de la velocidad de Ball.
CX.f=(2*Capsule()\Mass*dirBallXK.f+nball\Mass*dirCursorXK.f-Capsule()\Mass*dirCursorXK.f)/(nball\Mass+Capsule()\Mass)
CY.f=(2*Capsule()\Mass*dirBallYK.f+nball\Mass*dirCursorYK.f-Capsule()\Mass*dirCursorYK.f)/(nball\Mass+Capsule()\Mass)
BX.f=(2*nball\Mass*dirCursorXK.f+Capsule()\Mass*dirBallXK.f-nball\Mass*dirBallXK.f)/(nball\Mass+Capsule()\Mass)
BY.f=(2*nball\Mass*dirCursorYK.f+Capsule()\Mass*dirBallYK.f-nball\Mass*dirBallYK.f)/(nball\Mass+Capsule()\Mass)
Capsule()\dirX-dirBallXK.f+BX.f:Capsule()\dirY-dirBallYK.f+BY.f;<-se suman, obteniendo el vector buscado.
nball\dirX-dirCursorXK.f+CX.f:nball\dirY-dirCursorYK.f+CY.f;<-se suman, obteniendo el vector buscado.
EndIf
EndMacro
Procedure CreateBallSprite(c.l,size.l,color.l)
CreateSprite(c,size,size)
StartDrawing(SpriteOutput(c))
BackColor(0):R.w=color&$FF:G.w=color>>8&$FF:B.w=color>>16&$FF
For t.l=size/2 To 1 Step -1
R+160/size:G+160/size:B+160/size:If R>255:R=255:EndIf:If G>255:G=255:EndIf:If B>255:B=255:EndIf
Circle(size/2,size/2,t,RGB(R,G,B))
Next
StopDrawing()
EndProcedure
Macro gravity(nball):;<-process gravity simulation (interactiving all masses on all masses).
dx.f=Capsule()\x-nball\x:dy.f=Capsule()\y-nball\y;<-(dx,dy) is the nball->p() vector
D.f=#GravityFactor/Pow(dx*dx+dy*dy,1.5)
nball\dirX+dx*D.f*Capsule()\mass:nball\dirY+dy*D.f*Capsule()\mass
Capsule()\dirX-dx*D.f*nball\mass:Capsule()\dirY-dy*D.f*nball\mass
EndMacro
;-MOREINITS:
BallsDiameter.l=Val(InputRequester("Input","Please input 2D spheres diameter in #pixels (max. "+Str(SCREENWIDTH/3)+")",Str(64)))
Lines.l=Val(InputRequester("Input","Please input number of lines of 2D spheres (max. "+Str(SCREENHEIGHT/BallsDiameter.l)+")",Str(2)))
BallsPerLine.l=Val(InputRequester("Input","Please input number of 2D spheres per line (max. "+Str(SCREENWIDTH/BallsDiameter.l)+")",Str(SCREENWIDTH/BallsDiameter.l-1)));<-Número de Objeto1 por lineas
SetRefreshRate(60)
While OpenScreen(SCREENWIDTH,SCREENHEIGHT,bitplanes.b,"Balls")=0
If bitplanes.b>16:bitplanes.b-8
ElseIf SCREENHEIGHT>600:SCREENWIDTH=800:SCREENHEIGHT=600
ElseIf SCREENHEIGHT>480:SCREENWIDTH=640:SCREENHEIGHT=480
ElseIf SCREENHEIGHT>400:SCREENWIDTH=640:SCREENHEIGHT=400
ElseIf SCREENHEIGHT>240:SCREENWIDTH=320:SCREENHEIGHT=240
ElseIf SCREENHEIGHT>200:SCREENWIDTH=320:SCREENHEIGHT=200
Else:MessageRequester("Listen:","Can't open Screen!",0):End
EndIf
Wend
EnumDisplaySettings_(#Null,#ENUM_CURRENT_SETTINGS,@dm.DEVMODE):DispPeriod.f=1000/dm\dmDisplayFrequency
Cursor\sprite=0
CreateBallSprite(Cursor\sprite,64,$009eae)
Cursor\HalfWidth=SpriteWidth(Cursor\sprite)/2:Cursor\HalfHeight=SpriteHeight(Cursor\sprite)/2;<-centro de Objeto0
Cursor\Dimension=(SpriteWidth(Cursor\sprite)+SpriteHeight(Cursor\sprite))/2
Cursor\Mass=4*#PI*Pow(Cursor\Dimension/2,3)/3;<-masa de Objeto0
CreateBallSprite(1,BallsDiameter.l,$6dae00)
For g.b=1 To Lines.l
For t.w=1 To BallsPerLine.l
AddElement(Capsule())
Capsule()\sprite=1
Capsule()\HalfWidth=SpriteWidth(Capsule()\sprite)/2:Capsule()\HalfHeight=SpriteHeight(Capsule()\sprite)/2;<-centro de Objeto1
Capsule()\Dimension=(SpriteWidth(Capsule()\sprite)+SpriteHeight(Capsule()\sprite))/2
Capsule()\Mass=4*#PI*Pow(Capsule()\Dimension/2,3)/3;<-masa de Objeto1
Capsule()\x=t.w*BallsDiameter.l-Capsule()\HalfWidth+((SCREENWIDTH-BallsDiameter.l*BallsPerLine.l)/2);<-Posición inicial X
Capsule()\y=g.b*BallsDiameter.l-Capsule()\HalfHeight;<-Posición inicial Y
Next
Next
mouseX=SCREENWIDTH/2:mouseY=SCREENHEIGHT*4/5
Cursor\x=mouseX:Cursor\y=mouseY
MouseLocate(mouseX,mouseY);<-Posición inicial de Objeto0
Cursor\dirX=Random(1000000)/100000-5:Cursor\dirY=-Random(4000000)/1000000-1
;-MAIN:
Repeat
ExamineKeyboard():ExamineMouse():ClearScreen(0)
;Mouse move:
Cursor\dirX+MouseDeltaX()/40:Cursor\dirY+MouseDeltaY()/40
Cursor\x+Cursor\dirX:Cursor\y+Cursor\dirY;<-que son estas (se suma el vector director a las anteriores)
; Cursor-Screen limits:
If Cursor\x<=0:Cursor\dirX=Abs(Cursor\dirX):EndIf
If Cursor\x>=SCREENWIDTH:Cursor\dirX=-Abs(Cursor\dirX):EndIf
If Cursor\y<=0:Cursor\dirY=Abs(Cursor\dirY):EndIf
If Cursor\y>=SCREENHEIGHT:Cursor\dirY=-Abs(Cursor\dirY):EndIf
ForEach Capsule()
; Ball-moving:
Capsule()\x+Capsule()\dirX:Capsule()\y+Capsule()\dirY;<-Coordenadas actuales de Ball (se suma a las anteriores el vector director)
; Ball-Screen limits:
If Capsule()\x<=0:Capsule()\dirX=Abs(Capsule()\dirX):EndIf
If Capsule()\x>=SCREENWIDTH:Capsule()\dirX=-Abs(Capsule()\dirX):EndIf
If Capsule()\y<=0:Capsule()\dirY=Abs(Capsule()\dirY):EndIf
If Capsule()\y>=SCREENHEIGHT:Capsule()\dirY=-Abs(Capsule()\dirY):EndIf
; collision:
*i.balls=@Capsule()
While NextElement(Capsule())
Shock(*i)
gravity(*i)
Wend
ChangeCurrentElement(Capsule(),*i)
Shock(Cursor)
gravity(Cursor)
DisplayTransparentSprite(*i\sprite,*i\x-*i\HalfWidth,*i\y-*i\HalfHeight)
Next
DisplayTransparentSprite(Cursor\sprite,Cursor\x-Cursor\HalfWidth,Cursor\y-Cursor\HalfHeight)
MyFlipBuffers
Until KeyboardPushed(#PB_Key_Escape)Sorry, I don't share your interest in comparitive speed tests. It's like
basing a decision on which new car to buy on which was measured to be
fastest in a quarter mile sprint. There are a lot more uses for a vehicle
besides sprinting a quarter-mile, and those reasons should carry more
weight in deciding which one to use. For instance, large family, ability to
load and unload groceries with least effort, accessability for someone with
a handicap, best suited for long trips, best on mileage, etc.
A further problem with comparitive tests is that two languages might
facilitate different approaches to a common problem. So which would be
best; coding an optimum approach in one language, then trying to write
an exact duplicate method in another language, which would cause the
second language to be at less than its best, or to try two reach two
optimum approaches, then just see which is better in terms of raw speed?
And since this would be a selective test, only covering a limited aspect of
each language, how much would it really tell you anyway? Like the car
speed test, it represents a contrived situation that would be outside the
normal range of common useage.
Keep in mind that the initial criteria was which language is most like
Quick Basic? PowerBasic is certainly closer in terms of syntax and the
method of implementing code. In fact, the latest version of PowerBasic
re-introduces certain features from Quick Basic that have been passed
over in other Basics, such as the FIELD statement, which preceeded the
introduction of the static TYPE construction.
I was not trying to state that one language was better than another,
because to do that, you have to presume the WHAT of what it is better at,
and not all languages are equally good at everything. But if a Quick Basic
programmer wants to move forward into Windows programming with the
least relearn effort, PowerBasic is probably his best choice. If he wants
to really get into Windows programming, spend the least money, and be
better positioned to take advantage of code being implemented for the
Windows environment, it would be hard to beat PureBasic.
basing a decision on which new car to buy on which was measured to be
fastest in a quarter mile sprint. There are a lot more uses for a vehicle
besides sprinting a quarter-mile, and those reasons should carry more
weight in deciding which one to use. For instance, large family, ability to
load and unload groceries with least effort, accessability for someone with
a handicap, best suited for long trips, best on mileage, etc.
A further problem with comparitive tests is that two languages might
facilitate different approaches to a common problem. So which would be
best; coding an optimum approach in one language, then trying to write
an exact duplicate method in another language, which would cause the
second language to be at less than its best, or to try two reach two
optimum approaches, then just see which is better in terms of raw speed?
And since this would be a selective test, only covering a limited aspect of
each language, how much would it really tell you anyway? Like the car
speed test, it represents a contrived situation that would be outside the
normal range of common useage.
Keep in mind that the initial criteria was which language is most like
Quick Basic? PowerBasic is certainly closer in terms of syntax and the
method of implementing code. In fact, the latest version of PowerBasic
re-introduces certain features from Quick Basic that have been passed
over in other Basics, such as the FIELD statement, which preceeded the
introduction of the static TYPE construction.
I was not trying to state that one language was better than another,
because to do that, you have to presume the WHAT of what it is better at,
and not all languages are equally good at everything. But if a Quick Basic
programmer wants to move forward into Windows programming with the
least relearn effort, PowerBasic is probably his best choice. If he wants
to really get into Windows programming, spend the least money, and be
better positioned to take advantage of code being implemented for the
Windows environment, it would be hard to beat PureBasic.
has-been wanna-be (You may not agree with what I say, but it will make you think).
-
Psychophanta
- Always Here
- Posts: 5153
- Joined: Wed Jun 11, 2003 9:33 pm
- Location: Anare
- Contact:
Since VisualBasic is in fact an evolution of QuickBasic, and made by the same company, then if a Quick Basic programmer wants to move forward into Windows programming, VisualBasic is probably his best choice.oldefoxx wrote:I was not trying to state that one language was better than another,
because to do that, you have to presume the WHAT of what it is better at,
and not all languages are equally good at everything. But if a Quick Basic
programmer wants to move forward into Windows programming with the
least relearn effort, PowerBasic is probably his best choice. If he wants
to really get into Windows programming, spend the least money, and be
better positioned to take advantage of code being implemented for the
Windows environment, it would be hard to beat PureBasic.
If he wants to really get into Windows programming, and be
better positioned to take advantage of code being implemented for the
Windows environment, it would be hard to beat VisualBasic.
If he wants a more graphics, 2D and 3D programming language i would suggest Blitz3D or DarkBasic.
But:
if he wants an easy language, a really competitive high speed of executeables, and at the same time the smallest size of its executeables, and possibly the highest compiling speed, and also a real multiproposal language, then the best choice of ALL i know is called PureBasic.
So, i don't see PowerBasic for anything. The only one is speed, and that's why i wanted to compare, because in executeable sizes, 2D, 3D, Windows stuff, compiling speeds, etc. there is evident PowerBasic loose before PureBasic.
I disagree concerning VB. VB became an event-driven procedurless
language, which was a radical departure from the procedure-oriented
programming previously done under DOS. The fact that it originated
by the same company that developed BASICA, GWBASIC, QBASIC, and
QuickBASIC does not make it a smooth mirgration path from QuickBASIC.
Like I said, you have to look at the syntax and coding methods that a
language supports, and PowerBasic CC is much closer to QuickBasic than
VB ever was. Another example of a language that dates back to the
same root is RqpidQ, an interpretive language, that unfortunately has
ceased to be supported.
I should make the added point that PureBasic is available as a cross-
platform language, woking with Amiga, Linux, and the Mac OS as well as
Windows. PowerBasic does not, as yet, have a version available for any
ploatform other than DOS and Windows. And its DOS version has been
at 3.5 for years, indicating no further development in that area. So while
you can use it's DOS version under a DOS emulator for Linux, and it is a
very good implementation as far as it goes, the more progressive code
from PowerBasic is limited pretty much to Windows at this time.
language, which was a radical departure from the procedure-oriented
programming previously done under DOS. The fact that it originated
by the same company that developed BASICA, GWBASIC, QBASIC, and
QuickBASIC does not make it a smooth mirgration path from QuickBASIC.
Like I said, you have to look at the syntax and coding methods that a
language supports, and PowerBasic CC is much closer to QuickBasic than
VB ever was. Another example of a language that dates back to the
same root is RqpidQ, an interpretive language, that unfortunately has
ceased to be supported.
I should make the added point that PureBasic is available as a cross-
platform language, woking with Amiga, Linux, and the Mac OS as well as
Windows. PowerBasic does not, as yet, have a version available for any
ploatform other than DOS and Windows. And its DOS version has been
at 3.5 for years, indicating no further development in that area. So while
you can use it's DOS version under a DOS emulator for Linux, and it is a
very good implementation as far as it goes, the more progressive code
from PowerBasic is limited pretty much to Windows at this time.
has-been wanna-be (You may not agree with what I say, but it will make you think).
Speed, reliiability, and capabilities are good criteria for rating any language.
BlitzBasic would not be my first choice for a language, unless you are
strickly into game programming. Even there, it has been topped. PureBasic
offers more extensive examples than just about any other offered language,
and stays near the top in my opinion. But it may not be for everyone.
Your snears at PowerBasic are totally without foundation, and merely reflect
a personal bias that others should be aware of. I imagine far more programs
for commercial purposes are written in PowerBasic than in PureBasic, as long
as you exclude the fickle game development arena. PowerBasic also comes
with extensive source and library code and examples, and has had several
programming and reference manuals written for the language as well. I have been approached several times about PowerBasic programming positions.
but never once about PureBasic.
BlitzBasic would not be my first choice for a language, unless you are
strickly into game programming. Even there, it has been topped. PureBasic
offers more extensive examples than just about any other offered language,
and stays near the top in my opinion. But it may not be for everyone.
Your snears at PowerBasic are totally without foundation, and merely reflect
a personal bias that others should be aware of. I imagine far more programs
for commercial purposes are written in PowerBasic than in PureBasic, as long
as you exclude the fickle game development arena. PowerBasic also comes
with extensive source and library code and examples, and has had several
programming and reference manuals written for the language as well. I have been approached several times about PowerBasic programming positions.
but never once about PureBasic.
has-been wanna-be (You may not agree with what I say, but it will make you think).