Out of curiosity, really faster?

I have read many times here or in TOF that some changes to the language would help coding faster. Like for example allowing to write
instead of
i = i + 1
(For example, see https://ifnotnil.com/t/if-you-were-going-to-add-to-the-xojo-language/1205 )

My experience (admittedly, not a very extensive one) is that I spend very little time writing the code compared to the initial design time and testing and debugging time. So the argument that writing a few less characters allows you to code faster seems moot to me.

I would like to hear the opinion of (more experienced) programmers, if you care to share it.

Thank you.



Writing code fast is not the same as writing fast code :stuck_out_tongue:

Some things, like ++ and --, are just “sugar”

Others, like generics, are much more useful since they permit you to do things in a generic but type safe way so the compiler can help you by pointing out errors at compile time.

1 Like

personally I do not like the syntax of
x++ and x-- and REALLY hate ++x and --x
as a matter of fact Swift 1.0 had all of those, and Apple has since removed them
but I do admit I sometimes use
x+=1 instead of x=x+1
In Swift of course… I don’t know, but the compiler might actually deal with those differently

1 Like

Most computer languages that I have created high-performance applications are exceptionally fast at maths. Large formulas and iterations typically take nanoseconds to complete.

Almost always, poor performance is with the way graphics are drawn (thousands of nanoseconds). The general rule of thumb from the slowest performance is:

  1. slowest are custom drawn graphics in a custom canvas
  2. next is custom drawn graphics on a native canvas
  3. better performance is then with a game engine (Unity)
  4. fastest is a graphics language like openGL, vulkan that uses graphics card rendering

Edit: there are many sub-categories within the above list, and this list is a good starting point.

Edit: changed microseconds to nanoseconds. Thanks for catching it Markus.

I must have made my question as clear as mud because I meant to ask you about the overall time gain during the coding phase you would expect by those language changes, I was not talking about producing faster code.

Like this post by Walter in the thread I meantioned before:

"E.g., instead of having to type…

Dim i as integer = 5

Dim s as string = “hello”

Dim t as some.Long.Framework.Class = foo() // returns an sLFC instance
…it’s a lot easier and almost always completely understandable to just type:

i := 5

s := “hello”

t := foo()
The := construct is the way Go does it, but there are other options. However it’s done, it makes coding quicker and reading code generally easier."

There he said that would make coding quicker, and my question is whether it really makes it any quicker.

Writing your code FASTER is rarely the productivity boost it seems

Writing lots of code really fast isnt the same as writing GOOD code quicker
Or even better, IMHO, is writing less code because your software design encourages that

1 Like

I agree.
But doesn’t Xojo support i += 1 like VB?

Only the verbose

    i = i + 1

Seems unlikely. There are plenty of terse languages out there for folks to use. I suspect folks choose languages like Xojo, in part, because it’s more verbose than adding wingdings. Readability is a feature so long as it’s reasonable.

1 Like

Datattype inference has its drawbacks (I prefer the code be explict in this regard)

x := 5

what is it? an integer, a double? a float?
ok… assume it is an integer, (which is what most would infer it to be)
how about


Double? float? single?

For Xojo none of this is really important, since it automatically casts a variable depending on where it is used… But not all languges will do that

Integer since thats how you write an integer literal

Double more than likely since thats possibly the “default” floating point type and this is a floating point literal

x:=“this is a string”
would be a string

would be a color

Some languages, like C/C++, have type hints you can put on literals (the trailing L F etc) but I’d avoid those

there are weird ones as well like
x:=&h70 // infer unsigned int 8 ?
x:=&h7ff0 // infer unsigned int 16 ?
x:=&h7ff099 // infer unsigned int 32 ?
x:=&h1122334455667788 // infer unsigned int 64 ?

not sure what types those would infer. maybe unsigned of a sufficient size as I noted ?

I just prefer to be explicit, so the compiler doesn’t infer the wrong thing at the wrong time. Swift has bitten me a few times (but it is more strict about datatypes)

1 Like

Umm … graphics that need several seconds to draw? :roll_eyes:

you using crayons to do that ? :stuck_out_tongue:

1 Like

never seen that… I’ve had custom graphics where I got up to 60fps but NEVER something as slow as you infer…

Oops. I meant thousands of nanoseconds.

Thanks for catching it Markus. :slightly_smiling_face:

1 Like

This is my #1 complaint with API 2.0 and Xojo’s attempts to force existing users to adopt it. Writing is difficult for me, I am lucky if the words come out at all, if the words come out in the correct order and if the letters in the words come out in the correct order. Something I’ve struggled with for 30 years.

Code completion really helps me a lot, but now I no longer get that for new projects or projects that I use Save As as it defaults to API 2.0. In some cases I’ve stopped trying to fight the IDE and allowed it to use API 2.0, but that incurs other problems as API 1.0 and API 2.0 are not 100% compatible.

All in all, API 2.0 just adds frustration to a career that is becoming more difficult every year.

I know Xojo isn’t going to adopt this, but I would appreciate it if I could I could use loops and declarations from other languages. There are at least another 2 “development” languages I use and frequently end up mixing them together. My brain doesn’t see any problem (just like when mixing API 1.0 and API 2.), but the various tools do.

I know Xojo wants to be a entry level tool, but they could really benefit from developers of platform specific languages using their tool to provide x-plat development. It would of course require investment in the engineering team (I am sure some VC investment would really help).

From experience , I can tell you that using drawpicture
by taking part of a big image, and displaying it on another graphic at a different size
is slow.
When compounded by using that technique to draw (eg) 400 x 400 cells on screen
it it very much slower.
The workaround was to create the smaller images in a pre-calculation loop, then display the whole of a smaller image in each ‘cell’

Its been reported and verified, but I doubt any other Xojo user has the same issue, so it will never be looked at.

I’d switch to OpenGL or similar except every time I look in that kind of direction, I hear there is no common cross-platform solution

Vulkan - the successor to openGL
There are versions for macOS Windows & Linux Android and probably others

1 Like