• Welcome to Powerbasic Museum 2020-B.
 

News:

Forum in repository mode. No new members allowed.

Main Menu

Future of powerbasic

Started by Sutthisak Phongthanapanic, September 01, 2013, 12:10:38 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Patrice Terrier

#315
Do you know of any PureBasic demo(s) that would knock my socks off ?

All the demos i have ever seen are looking more like those of DOS days.

If you have any screen shot(s) or link(s) that you could share, i would be very happy to revise my opinion.

Thanks

...
Patrice Terrier
GDImage (advanced graphic addon)
http://www.zapsolution.com

Brice Manuel

Quote from: Bob Houle on December 06, 2014, 02:38:33 PM
Theo,
I have read most of your posts and Brice is correct.
You say you want a 64-bit compiler, you get it... then you say everything negative that you can!   ???

I am a few days away from my 11th year anniversary of using PureBasic.  During that time it has continued to grow in functionality and the number of platforms supported (some old platforms like the Amiga and the PowerPC Macs have been dropped) and it has continued to adhere to traditional BASIC as much as possible.  All this has been done with one price and not being subjected to a shakedown for more money every year or two for things that should have been included to begin with.  A language that continually grows and is actively supported will always attract new users eliminating the need for trying to make all of your money off of existing customers instead of seeking new ones.  The introduction of the LTS version has been VERY welcomed as it allows you to use the stable version for any serious work, but still play with the "bleeding edge" version so you can get used to the new features when the time comes that you will need those features.  The only weak point for me is I dislike the included GUI designer and there is no longer a decent third-party GUI designer being sold.  Most people simply don't use a GUI designer for their GUIs, so I am definitely in the minority with this "dislike".  That said there is nothing wrong with the included GUI designer and those that use it love it.  I am just very picky when it comes to GUI designers. 

For those who do NOT want a BASIC compiler that properly supports modern hardware and technology and would prefer a legacy BASIC that never really progresses, True BASIC is still being sold and actively developed and it is the original BASIC (all other BASICs have been imitators).  I would never recommend it for anything but hobby use and I would never recommend it for anything you intend to actually release (even for free).

Bob Houle

Quote from: Patrice Terrier on December 06, 2014, 03:22:16 PM
Do you know of any PureBasic demo(s) that would knock my socks off ?

All the demos i have ever seen are looking more like those of DOS days.

If you have any screen shot(s) or link(s) that you could share, i would be very happy to revise my opinion.

Thanks

...

Patrice,

I've been a user of your Winlift program (2003), so I know you don't impress easily. {grin}

Would the ability to use PostgreSQL or SQLite out of the box knock your socks off... it doubt it.

But that's my point... as a 'bare metal' programming tool PureBasic probably outshines PowerBASIC, only because it provides much more OUT-OF-THE-BOX.

But, I've included a few graphical examples (Zipped) to show what's possible...

Patrice Terrier

Bob--

Thank you for the ZIP file.

...
Patrice Terrier
GDImage (advanced graphic addon)
http://www.zapsolution.com

José Roca

Quote
Would the ability to use PostgreSQL or SQLite out of the box knock your socks off... it doubt it.

I already have headers and a class for SQLite, and translating the headers of PostgreSQL would not be a difficult task.

My problem with these cross-platform compilers, such PureBasic and FreeBasic, is that they are not well suited for the kind of programming that I do.

Theo Gottwald

#320
Why do you get religiouse here, folks?
In fact i did not say anything negative. A Macro Assembler is nothing negative.

Now think a minute. If Fred would make Purebasic a second time - would he do it the same way?
I think not. He started that time, and what you get is a large toolbox.

What was exactly negative?
A Macro Assembler is one of the best programming tools you can get and PureBasic is built on one "as an enhancement" somehow.
And it does not go so far above it if you look into difficult to compile code.
My problem with it was that just any time when i used it, i crashed into some limitations that a "real compiler" like PB doesn't have.

If i use Gosub and i run into an error - due to the stack frame that PB uses, the compiler will clean it up when i leave the procedure.
And of course i can use real GOSUB/RETURN. I use it very often.
All needed types of variables are there. Yes some types were later added in Purebasic, but it did not look to me as if it really fits together like in PowerBasic.

And the String-Engine in Powerbasic saves me most of the problems i have in other languages.
I have tried that in PureBaisc as well, but it never worked for me as expected.
The Strings are just not like the PowerBasic strings.

Having said that about the "Core" of the compiler, (and thats where i would like to see changes),
i add that the many libraries from all sorts of uses are a great tool set for people who want to build applications in some sort of "construction set" style.

And while the system is different from PowerBasic, its still usabel and i have also done some applications in PureBasic where i needed 64 bit.
Its just different. And ... yes i prefer PowerBasic.

Let me add that if i would use Purebasic for so long time like others, possibly i would know workarounds for most problems.
Its like in any sort of programming language. At the end its the programmer - not the tool.

Steve Hutchesson

I confess to being very disappointed in what has happened with the PB forum lately. I see Gary as a good guy who tried very hard to get the SDK/API subforum going and we saw code from Jose, Patrice, a number of the PB forum members and I managed to get a bit of stuff done as well but the endless trolling, arguments, insults and general influence peddling have done the damage and very few are game to post API based code any longer as the talking heads just put the boot into it.

Like Jose, I am not dependent on the PB forum and can post PB example in the MASM forum which is now a better choice as no nonsense is allowed in the MASM forum at all. What has p*ssed me off the most is there have been a lot of very good programmers in the PB forum in the past who faded away with the flooding of DDT code who could have come back and posted decent API based code but with the endless cr*p going down, they just stopped bothering or in fact did not bother at all.


Patrice Terrier

Steve--

You know what, i always had a hard time to read the DDT proprietary syntax.
And i am amazed to see how the fagocited DDTers are bashing us SDKers, perhaps because they realize now that they have made the wrong choice ;)

...
Patrice Terrier
GDImage (advanced graphic addon)
http://www.zapsolution.com

Steve Hutchesson

Patrice,

I don't have any beef with DDT, I think Bob hit the mark of a simplified system for people who could not put in the effort to learn API style coding but we have a very similar view of the folks who thought that peer pressure would ever effect those who put in the effort years ago to learn how to write Windows code properly. I have not won any friends by labeling this nonsense as membership of the "Mickey Mouse Club" but eventually you get tired of people who keep trying to cripple the language to maintain their own flavour of influence peddling.

32 bit PowerBASIC is in its twilight as Bob never had the chance to finish the 64 bit version but it is still a very good tool in the 32 bit area yet trying to promote its advanced features in the PB forum is like p*ssing into the wind and wondering why you get wet. I feel sorry for Gary as he has tried hard to get it going again but the "Mickey Mouse Club" will continue to sob into their chardonnay until it turns into the "Grapes of Wrath" and will take down the viability of the language until there is no-one left.

I think you said it all a long time ago, behaving like "beached whales".  ;D

Patrice Terrier

QuoteBob never had the chance to finish the 64 bit version

Because he spent too much time on DDT rather than enhancing the compiler itself, this has been my main dispute with Bob several years before his passing. And the main reason why the most advanced programmers have left the boat since long.

...
Patrice Terrier
GDImage (advanced graphic addon)
http://www.zapsolution.com

Theo Gottwald

We had several disputes with Bob in the past.
Most of all, however only people that have been very close to Bob and the PB Company know all of the truth.
What we see as outsiders, is that:
1. About 32 bit - PB is still usable and a very good program
2. About 64 bit we need to look around

How is Charles Pege doing?
Some time ago he told me, he could make his compiler to compile (non-DDT) PB-like Code into 64 bit.
Did anybody test his newest creations?


Steve Hutchesson

I basically agree with that, while 32 bit bit is in its twilight there is still a lot of life left in it and the current versions of PB are both very useful tools. Now its not that I am biased but in the 32 bit area, MASM is a truly wonderful tool once you get used to its many bad manners. It has never been softened to a friendly consumer toy, pelts unintelligible error messages at you, has a macro engine that has very few peers but at the price of being only ever vaguely intelligible, buggy and under documented. It was clearly designed for the backroom boys and girls at Microsoft where you had to know its quirks but it does force you to write technically correct code.

64 bit is the future but its not coming all that fast and for compilers it has a lot to do with its incredibly messy stack design. Where 32 PE files had STDCALL, C and any flavour of FASTCALL you wanted to use with a 4 byte aligned stack, Win64 has a 16 byte aligned stack where you first have to allocate stack space under the current location then call API functions using 4 specified registers then the stack for any others while maintaining 16 byte stack alignment. Where 32 bit PE format was designed by the old VAX guys and was clean, clear full 32 bit design, Win64 is a mess something like the old 16 bit NE format was for Win3.?? except that its a 32/64 bit hybrid.

We won't see real 64 bit performance until we have full long mode and hardware with terabytes of memory, 32 gig of ram in Win64 is akin to what 4 meg was in win16, Whoopee !  ;D

Charles Pegge


I totally agree, the 64 bit calling conventions are horrid, and break the minimal conformity between Linux systems and Microsoft, which we had with CDECL.

It would be far better, in the long term,  to adopt a 64 bit CDECL as the universal standard for libraries, and leave the kernel developers to do their own thing. I hope this happens with the next generation of hardware (memristors?)

Patrice Terrier

Steve--

QuoteWe won't see real 64 bit performance until we have full long mode and hardware with terabytes of memory

Then, what about the speed difference between a 64-bit application running on a 64-bit OS,
and a 32-bit application also running on the same 64-bit OS.

...
Patrice Terrier
GDImage (advanced graphic addon)
http://www.zapsolution.com

Steve Hutchesson

Its not a simple question to answer Patrice as there are both hardware and software considerations. Almost exclusively anything to do with multi-media will do better with base 64 registers and twice as many registers but it is coming at the price of other stuff getting slower. I have 3 quad core boxes handy, the i7 I have win7 64 on, the 3 gig core2 quad which was my last dev box with XP SP3 and a NAS box with XP which is a 2.5 gig Q6600 quad.

I regularly benchmark algos and while SSE is clearly faster on the i7, some algos are faster on the much slower Q6600. later hardware is giving more silicon to SSE and less to the integer instructions that use the 8 GP registers.