PureBasic Forums - English

This is not the point of this thread. If I wanted a cross platform development I would use something different or PureBasic. We talk exclusively about Windows platform, more precisely professional office applications developed for companies. Windows Vista and 7 comes with pre-installed .NET framework, so why you keep bringing this up all the time (XP users are converting at a steady pace - in April 2012 only about 25% usage of all computers). Everyone got used to VB6 libraries so its the same situation with .NET. Times change libraries get bigger as well. Oh and please, I think it is ridiculous that everyone keeps complaining about the fact that programming languages and software is getting better and better, it's just an excuse not to follow with the world and stay behind still pushing bits in the assembler.

My point was to draw attention to certain improvements and optimizations that could be implemented in PB's compiler and yet people see this as anti PB rhetoric. We're lucky that Faintaise is so devoted to PB but as history has shown nothing lasts forever and it's better if you master multiple languages and be able to swiftly convert if such scenario is played out. Long live PureBasic.

TI-994A wrote:The geniuses at Fantaisie Software listen to us

Really? There's a lot of good feature requests that are years and years old that have never been acknowledged let alone listened to
From what I see the team does the features they want to do which is good, but I wouldn't go so far to say we're 'listened to'. Maybe sometimes on small things.

Olby wrote:Windows Vista and 7 comes with pre-installed .NET framework, so why you keep bringing this up all the time (XP users are converting at a steady pace - in April 2012 only about 25% usage of all computers). Everyone got used to VB6 libraries so its the same situation with .NET. Times change libraries get bigger as well. Oh and please, I think it is ridiculous that everyone keeps complaining about the fact that programming languages and software is getting better and better, it's just an excuse not to follow with the world and stay behind still pushing bits in the assembler.

A lot of the users (who complain about that) on here don't have the computer space or speed for .NET

Must be on Celerons and Pentiums

moogle wrote:A lot of the users (who complain about that) on here don't have the computer space or speed for .NET

That explains the hostility

Olby wrote:We talk exclusively about Windows platform, more precisely professional office applications developed for companies. Windows Vista and 7 comes with pre-installed .NET framework, so why you keep bringing this up all the time (XP users are converting at a steady pace - in April 2012 only about 25% usage of all computers). Everyone got used to VB6 libraries so its the same situation with .NET. Times change libraries get bigger as well. Oh and please, I think it is ridiculous that everyone keeps complaining about the fact that programming languages and software is getting better and better, it's just an excuse not to follow with the world and stay behind still pushing bits in the assembler.

Hello again. We are talking about nothing less than professional commercial business applications, where solutions should be quickly and easily deployable throughout organisations, and even across networks, without the hassle of ensuring framework compatibility. Time is money, so speed is key.

Although the VB6 runtimes were also a pain in its day, how do you compare a one megabyte dependency with such a massive framework, which often requires multiple versions to be installed. You're right, times change, and we have to change with it, but to accept bigger libraries and less efficient compilers would be a change in the wrong direction. There's no doubt that VB.Net is a powerful RAD tool, but it is not a professional programming tool. Professional developers do not use or require the framework, even to utilise COM; the CLI only facilitates the RAD model.

Hi moogle. One thing that I've noticed about the team is that they take the basic and essential functionalities very seriously, as these form the foundations and building blocks that will allow the scalable development of almost any type of application. Perhaps the feature requests that you're referring to are more of RAD elements. Their current direction towards bug fixes and more stable releases is clearly more important.

TI-994A wrote:Hi moogle. One thing that I've noticed about the team is that they take the basic and essential functionalities very seriously, as these form the foundations and building blocks that will allow the scalable development of almost any type of application. Perhaps the feature requests that you're referring to are more of RAD elements. Their current direction towards bug fixes and more stable releases is clearly more important.

An example of what was asked for was a bit more core network features such as binding to an IP/interface to help make a more professional server/network program using PB (instead of having the program bind to all IP's on a given port). I think the original post by the owner is from 2003 and he left.

Also another user made their own code to 'detect' a connection close which works cross platform (PB can't detect a network disconnect unless the client sends the 'PB' disconnect so for example Apache webserver doesn't do so) and it's something where the work is already done but it's never implemented.

There are many that I have thought of posting, then searched the forum to find out it has been said years ago and I never post them because if they are that old then I think the team probably doesn't want to do them.

I know the team is working on PB but I just have no idea in which direction

TI-994A wrote:We are talking about nothing less than professional commercial business applications, where solutions should be quickly and easily deployable throughout organisations, and even across networks, without the hassle of ensuring framework compatibility. Time is money, so speed is key.

You said VB.NET is a RAD tool which stands for "rapid application development" than how come you say PB is more versatile when it comes to speed of development. I guarantee that if you would do a comparison of development time required for a specific office solution than the winner would definitely be any of the .NET languages. PureBasic will speed up the deployment in some cases but mostly it will loose out tremendously due inefficient/incomplete native libraries.

TI-994A wrote:how do you compare a one megabyte dependency with such a massive framework, which often requires multiple versions to be installed. You're right, times change, and we have to change with it, but to accept bigger libraries and less efficient compilers would be a change in the wrong direction.

How can you say that if we just made a conclusion (in this thread) that VB.NET and C# compilers are more optimized and efficient than PB. Oh and I'm an ex VB6 developer so am perfectly aware that VB6 had different runtime versions and incompatible OCX library issues. Imho it's quite stupid to compare VB6 and .NET framework because you can't do even half of the stuff that .NET offers in VB6 (hence the increased dependency size). We're not going in the wrong direction, we're towards something bigger and better.

TI-994A wrote:The latest version of the framework needs up to 2GB of drive space! Not many users are willing to jump through hoops and make changes to their systems simply to run an app; they'll abort as soon as they see the Microsoft .NET Framework x.x is required... message.

The bottom line is that .NET comes preinstalled in Vista and W7 computers, and over 90% of new pc's have one of those installed on it. So when you say "not many users are willing..." you pretty much are only describing those clinging to XP. With .NET, you can write once, sell to 90%... Even though I only chose PB for its cross-platform capability, I am fully aware that it did not open very many doors.

moogle wrote:An example of what was asked for was a bit more core network features such as binding to an IP/interface...
Also another user made their own code to 'detect' a connection close...

Hello again moogle. To be honest, IP binding and detecting network disconnection aren't exactly core functions; useful perhaps, but not foundation. In the first place, IP binding is a virtual function, and has to be translated. As for detecting of network disconnection, even WinSock does not have that natively. Like you said, there are doable workarounds.

Olby wrote:You said VB.NET is a RAD tool which stands for "rapid application development" than how come you say PB is more versatile when it comes to speed of development. I guarantee that if you would do a comparison of development time required for a specific office solution than the winner would definitely be any of the .NET languages.

Hi Olby. You must have misread; I made no reference to PureBasic's development speed, only deployment. Of course you'd be able to "drag & drop" an application much faster with VB.Net; that's why it's called rapid application development, and that's why your app footprints are so huge. However, the main difference in deployment time does not lie with the executables themselves, but rather with the dependencies, of which PureBasic has none.

Olby wrote:PureBasic will speed up the deployment in some cases but mostly it will loose out tremendously due inefficient/incomplete native libraries. How can you say that if we just made a conclusion (in this thread) that VB.NET and C# compilers are more optimized and efficient than PB. Oh and I'm an ex VB6 developer so am perfectly aware that VB6 had different runtime versions and incompatible OCX library issues. Imho it's quite stupid to compare VB6 and .NET framework because you can't do even half of the stuff that .NET offers in VB6 (hence the increased dependency size). We're not going in the wrong direction, we're towards something bigger and better.

Your reference to "inefficient/incomplete native libraries" has absolutely no bearing on deployment; it only affects development time. Even then, PureBasic can get the job done more efficiently. And efficiency is not measured by the ability to run a loop faster by two seconds, but rather by the overall application development and deployment. Rapid development cycles are always good, but when they have to depend on countless libraries and functions and objects and methods, that's definitely not efficiency.

Also, the comparison between the small VB6 runtimes and the massive dot net framework was made to illustrate the level of inconvenience, and not functionality. In this respect, I don't see how you could still think that bigger is better.

Tenaja wrote:The bottom line is that .NET comes preinstalled in Vista and W7 computers, and over 90% of new pc's have one of those installed on it. So when you say "not many users are willing..." you pretty much are only describing those clinging to XP. With .NET, you can write once, sell to 90%... Even though I only chose PB for its cross-platform capability, I am fully aware that it did not open very many doors.

Hello Tenaja. 90% of new PCs may have the framework installed, but that does not equate to 90% of PC users. In addition to the Vista fiasco, where many users reverted back to XP, there are also many Vista/7 users who opt to remove/clean the framework from their machines. These are among the people who will abort a re-installation attempt.

Referring to your last line, are you saying that apps developed in VB.Net will open more doors?

TI-994A wrote:Referring to your last line, are you saying that apps developed in VB.Net will open more doors?

No, PB's cross platform feature opens more doors... but since less than 10% (or something like that) of PC users are on Linux or Mac, those 10% are very few doors.

TI-994A wrote:90% of new PCs may have the framework installed, but that does not equate to 90% of PC users. In addition to the Vista fiasco, where many users reverted back to XP, there are also many Vista/7 users who opt to remove/clean the framework from their machines. These are among the people who will abort a re-installation attempt.

That's the point we're not talking out some hardcore geek who wants to strip naked his Windows installation and be in charge of every byte CPU processes. We're talking about companies that will install .NET and run framework based software. I have worked with and for dozens different type of companies and majority run .NET based software and internally develop .NET software. Majority of regular computer users will have it installed no matter if they like it or not.

Application development time is far more important and more costly than deployment. You would spend more time with PB to do an app you could easily create using .NET. Explain that to your management when they want everything cheaper and faster. Let's put it that way. PB has it's roots in the old school days of software development, everything about it is old school. It doesn't mean it's incapable but in 21st century when time is money PB's advantage over .NET is arguable.

Okay, this entire thread is borderline trolling, but it has made me laugh sooooo hard, I'll forgive it.

So then entire argument is that VB.net/C# is:

• * Better compiler that filters out stupid loops (and therefore faster)
  * Faster due to better jit
  * Has a better rad toolkit
  * The additional features of the framework enabled everything to be made faster and run faster

Okay, so lets put it on the line. Lets do a REAL speed comparison.
Rules:

• * No direct memory manipulation, ASM, or other "cheats"
  * Can only use built in commands for the speed test - no api calls or shortcuts

So what can we test that would give us a "real world" example?

Well, I have been recently working on a blur routine that uses the API to get a screenshot as a base, and then the rest are loops, calculations and built in graphic manipulation control.

See here for the PB version, and due to this thread I've ported the entire thing across to .net 3.5, which you can grab here

Now using my laptop as the control base (single screen, 1280x800, Core Duo cpu with MMX, SSE1, 2 & 3), with a blur radius of 2 (as set as default in the programs) this gives me a very fair comparison.

PureBasic only uses the basic of basic instructions, so you can run it on whatever machine you come across - this obviously comes at the expense of speed, and demonstrated by the speed demons who use ASM and direct memory manipulation to gain a x5+ speed increase.

On the other hand .net uses whatever it can use, with an intelligent multi-pass compiler, a semi-sentient JIT, and all the goodness of framework at it's disposal. Remember that.

So, we'll run the compiled exe (release mode for vb.net) outside of the IDE. The number supplied is JUST the blur, nothing else getting in the way.

Here we go:

• PureBasic clocks in at a massive: 1,312ms.
  .Net 3.5, it takes... *giggle* 40,297ms.

I should perhaps mention that using the .net framework for manipulating images is not advised, but using LockBits and direct pointer memory manipulation instead.

Bad Microsoft! Bad!

Here's why: http://www.bobpowell.net/lockingbits.htm

Start/StopDrawing in PB locks the bitmap in memory for fast access. In your .NET version you try to access every pixel "the slow way". Change it to work with lock bits and it should be a lot faster (getting rid of the colour = pImageIn.GetPixel(x, y) command makes it almost instantaneous). Oh and I was talking about office applications - this is quite different from what I do.

Where on earth would you have massive looping calculations in office software?

Well, if you read the thread again then you'll notice that I've started the thread to discuss the reason behind the speed difference as I always considered .NET to be inferior at least speed wise. As I also said in my very first post this wasn't a real-life comparison and if we wanted to do one then it would involve different commands and libraries. I suggest we do a comparison of an application centred around database. For example create a new database, add a table, insert 1000 random records, save database, close it. Open database, read records, run some string comparisons/replacements, update data, close database. For me that would be a real-life scenario.