I think Xojo (the company) has been doing a good job trying to keep up with myriad platform issues and make Xojo (the IDE, API, and libraries) better. See Roadmap — Xojo documentation for what’s planned.
But it’s also nice to think about improvements to the core programming language, which hasn’t changed much lately.
I have a few ideas that I’d like to propose for comments - please propose your favorites.
If you are influenced by another language (Javascript, Swift…) please explain.
If there’s wide agreement, perhaps we can submit some feature requests?
My top 3:
Enums should be context sensitive, e.g. I should be able to write: Timer1.RunMode = .Single
instead of Timer1.RunMode = Timer.RunModes.Single
Inspiration: Swift.
Functions within Functions.
Sometimes it’s much more elegant to define a function within a function - it helps keep the namespace clean, hides the function so that it can’t be called by outsiders, helps with debugging, useful in asynchronous programming, etc.
Inspiration: Python, Javascript, Swift
Async Code
In Xojo, to do asynchronous programming it requires a lot of work - for each callback, you have to define new Events and or Delegates (which may be scoped more widely than you wish, see #2 above). This is not all bad, as I find in Xojo the code execution flow if very clear. However it’s a lot of work, and many other languages make it much easier. Compare…
Javascript:
setTimeout(function() {
console.log("This will be logged after 2 seconds.");
}, 2000);
Xojo:
add a Timer to a window
add a callback method to the window
Add an event to the timer which calls the function
Run the timer
Window1.foo
Timer1.RunModes = Timer.RunModes.Single
Timer1.Period = 2000
Timer1.Run Event
Foobar()
Window1.foobar(t as Timer)
system.debuglog " this will be logged after 2 seconds"
In Xojo, it can be done, but it’s a ton more typing and not much fun.
In the past few years, many languages have rolled out ideas such as Promises, Code Blocks (Swift) and Async/Await syntax to make this all so much easier.
You can’t name a method using a character like “+”. Best you can do is:
Module IntegerExtensions
Public Sub Increment(byref extends i as integer)
i=i+1
End Sub
Public Sub Add(byref extends i as integer, value as integer)
i=i+value
End Sub
End
i.Increment
i.Add(3)
You can use addHandler and directly make a timer without putting it on a window or make a subclass. AddHandler can connect a method on the window to the new timer’s run event.
I know, and with pairs too
but it’s not as readable as it could,
and I often do maths in methods, and it would be easier to have this than making classes.
Mike, your suggestions are already at the top of my list. Promises and closures, as they are formally called, would go a LONG way to making Xojo feel more modern.
But there’s one idea that I would not have expected to want to bring into Xojo, but actually think it would be a perfect fit for Xojo’s target audience of “citizen developers” and that is Unreal’s blueprints visual programming.
Unreal’s system is very robust. If you understand the basics of programming and get spend a little time learning how the code flows from one block to the next, you can get the hang of it. It has all the features you’d expect of a programming language like functions, properties, variables, parameters, loops, and even multiple return values. Is it my preferred way to code? No, of course not. But I find I’m just as efficient with it as traditional code, but it’s very approachable to newcomers.
If I were still working on the IDE, I could build something like while needing only one thing from the compiler: multiple return values. I suppose maybe better compiler error information, since you wouldn’t get to see the code the IDE was building.
But yeah, a robust visual programming language would help make Xojo very approachable to those who don’t code for a living.
Adding optional assignment operators to the language would make it much easier to port C, Python, Javascript and C# code and would greatly benefit the wider adoption of Xojo. They are basically an industry standard.
That’s still requiring multiple clicks and generation of a method with the signature.
The Xojo IDE has not very productive options, every step takes alot of clicks, typing etc. For example what @Mike_D has as number 1:
1. Enums should be context sensitive, e.g. I should be able to write:
`Timer1.RunMode = .Single`
instead of
`Timer1.RunMode = Timer.RunModes.Single`
Inspiration: Swift.
Has been a request by me some time ago, this allows for much better readability and requires alot less typing, clicking and checking. The IDE’s context is just not efficient enough so as a developer you have to do this all yourself. With AI around the corner (as a great assitant to this) even that’s not to be found in xojo still.
Productivity is #1 these days, we need more of it.
Tracker #65935 issue has been made over 3 YEARS ago (Still not reviewed!). This is not very productive.
Additional issue #74069 made over 1 year ago, no changes to be seen.
If xojo focussed more on productivty, the would them selfs benefit the most of it.
It seems that xojo wants to keep everyting to xojo, while working with multiple languages is discouraged. Mostly you can’t get around this and this would certainly make the world a better place to use additon options etc.
This can be achieved at the contextual autocomplete level, not language. When the autocomplete is in a context that it can choose from a limited set of options based in a partial match, it can present a greyed match until a complete match found as when you type ( | represents the cursor ): Timer1.RunMode | nothing changes, but you add an “=” and options shows up as Timer1.RunMode =|... autocomplete says you are in the autocomplete context with ellipses, press space Timer1.RunMode = |... still waiting a value, press a “period” Timer1.RunMode = Timer.RunModes.|... press “s” Timer1.RunMode = Timer.RunModes.Single| aucomplete finished it because it was the only option