Its not really that one language is faster than another - its how they are coded (look at their code) and what libraries they use. Really what this article says is speed depends on how you white stuff, not what language you use. Someone spent a lot of effort to write those bits of code to solve a very specific propblem. Generally all compiled languages making use of good libraries will be similar speed, but with hard work any of them can be made faster for specific task, even C# wich does use JIT IL which is now extremely well optimised. Interpreted languages will generally be slower, stuff like Python, but it has a fantastic set of libraries.
SB does stand alone as very slow, but it is a learning language - having said that if we compare it with other 'introductory languages initially targetted at children like Scratch' it is fantastically powerful, fast and the skills learned are way more relevant. Ultimately though, if you want speed then move to almost any other language with suitable libraries for the architecture you want to run it on.
In most cases on modern PCs speed is irrelevant. For complex 3D games you have to write code with the GPU - there are very good libraries, but for the very best performance you would write your own taylored to specifics of your game which is very time consuming specialised work that is expensive. For weather forcasting you need enormous memory and massive parallelisation and massive amounts of money. To tease the most performance it is often about contiguous memory access and pipelining commands and data efficiently to the processors - optimisers are pretty good at this, but an expert will do better.
Do NOT choose a language because someone says it's fast, choose it because it is best for the task, which may simply be you are experienced using it. For you and me the biggest difference is not the language, but the algorithm and how it is coded which is one reason SB is fun - it forces you to work hard at making it efficient. So in many cases SB is 'best' because it's slow it's fun!
To make SB faster we would have to move away from single type (Primitive) and impose variable types on beginners, all extensions written would not work, its not really about MS not supporting it - sure they could fix the bugs, but we get round most of them. SB users who crave better performance should look at taking their SB programming skills and playing with perhaps C# - the Graduation or other decompiling methods help, but they decompile to .Net VB/C# using the Primitive type and SmallBasicLibrary.dll, which when compiled in C# will be no faster than the original SB. I think the best approach is to decompile SmallBasicLibrary.dll and start to see how it does things, maybe write their own extension as a starting point just as you and I have done. There are also loads of getting started stuff out there, including CoPilot or similar.
SB does stand alone as very slow, but it is a learning language - having said that if we compare it with other 'introductory languages initially targetted at children like Scratch' it is fantastically powerful, fast and the skills learned are way more relevant. Ultimately though, if you want speed then move to almost any other language with suitable libraries for the architecture you want to run it on.
In most cases on modern PCs speed is irrelevant. For complex 3D games you have to write code with the GPU - there are very good libraries, but for the very best performance you would write your own taylored to specifics of your game which is very time consuming specialised work that is expensive. For weather forcasting you need enormous memory and massive parallelisation and massive amounts of money. To tease the most performance it is often about contiguous memory access and pipelining commands and data efficiently to the processors - optimisers are pretty good at this, but an expert will do better.
Do NOT choose a language because someone says it's fast, choose it because it is best for the task, which may simply be you are experienced using it. For you and me the biggest difference is not the language, but the algorithm and how it is coded which is one reason SB is fun - it forces you to work hard at making it efficient. So in many cases SB is 'best' because it's slow it's fun!
To make SB faster we would have to move away from single type (Primitive) and impose variable types on beginners, all extensions written would not work, its not really about MS not supporting it - sure they could fix the bugs, but we get round most of them. SB users who crave better performance should look at taking their SB programming skills and playing with perhaps C# - the Graduation or other decompiling methods help, but they decompile to .Net VB/C# using the Primitive type and SmallBasicLibrary.dll, which when compiled in C# will be no faster than the original SB. I think the best approach is to decompile SmallBasicLibrary.dll and start to see how it does things, maybe write their own extension as a starting point just as you and I have done. There are also loads of getting started stuff out there, including CoPilot or similar.