Future development

Not true… Swift is becoming available for both Linux and Windows… I have not investigated these (yet), and don’t know how matured (ie. ready for primetime) they are, nor how they address the different control structures… but those versions are coming into existance.

Oh yes, you’re right. The IDE differences will still exist, and you’re still most probably obliged to build (or find) convenience wrappers for a variety of API calls. So please delete this argument from my post. The rest remains valid :wink:

[quote=239779:@Ulrich Bogun]Yes, it’s true, XCode and Swift give you the benefit of the full set of includes. But then you still have to figure out how to use them, which means you have to understand programming styles of at least three decades – or you have to go on a wrapper solution hunt. I am still fighting with my iOSLib tableview implementation, and even if iOSTable makes one miss a few things, I bow my head to the engineers for making that beast so easy to handle.

What I am trying to say: Xojo-izing API calls is a lot of work. Even if the engineers would spend 50% of their time in iOS development, I don’t think they’ll be able to come out with 10 new controls each release.[/quote]

This is absolutely the case.

For example, the original iOSTable class was very different than what shipped and the API that did ship went through several iterations (though the changes were minor at that point). Even then, I think we got it slightly wrong and changing a class that’s shipped is more or less not an option because it would require breaking an unknown number of user projects.

iOSTable … hmmm… I think everyone agrees it is very very very basic atm. iOSTable is one of the controls that needs a HUGE boost. Customising cells (for example with a container?), (basic) swipe support for each cell, … those are essential things to make it useable. iOSTable is now only good for a Hello World type of app unless you use a lot of declares as Ulrich said.

Not usable yet on Windows IMHO. Not much more than .NET for Mac OS X :wink:

hence my use of “is becoming available” as opposed to “is available” :smiley:

But I don’t expect SWIFT to be a major contender on non-Apple platforms for quite some time

If you look at the time it took for C to generalize, it may take some time for Swift to become significant out of the Apple platform. In there, though, it is interesting to note that, already, Swift has passed in front of Objective-C in the Tiobe index.

I wouldn’t say so: Silver

With Silver, you can use Swift to write code directly against the .NET, Java, Android and Cocoa APIs. And you can also share a lot of non-UI code between platforms.

For each platform
    write platform specific ui code
    debug
    build
    release
next    

It’s all a matter of opinion, and I just said mine. Sure, Silver works. Now, if one wants to develop an UWP app, what is the best tool is IMHO where I would rather pick one of the languages in VS rather than Silver. Let alone because all documentation in Msdn is geared toward C#, C++, F# or VB with examples in these languages, and not in Swift. Besides, libraries for the new AppX application model are built in VS, and it makes sense to just let the IDE deal with dependencies.

My point is not to say that Swift does not run under Windows. Just that IN MY HUMBLE OPINION, it is not usable yet. Meaning, unless one has no knowledge at all of the languages provided by VS, it makes a whole lot more sense to go with the tools supported by Microsoft. Note that I do not count Xojo in the game, since it is is not able yet (if ever) to produce UWP apps.

The other way, and apart from Xojo which brilliantly creates Mac OS X apps, I would pick Swift any day over non Apple solutions.

Once again, it’s just me.

Its not always a matter of a rock-solid productivity tool… sometimes and I quote

[quote] the pleasure of discovery. That is what drives people[/quote] :smiley:

Some people dont want to “discover” they just want to complete a task - and the journey to that goal is unimportant or irrelevant

On the subject of Xojo’s future development, seems to me Win32 may not be the bright future anymore than Internet Explorer, which Microsoft announced this week it will stop supporting all versions up to 10.

Windows 10 is based on the new AppX application model, otherwise known as the New API, which drives Universal Windows Programs. Like it or not, UWP will increasingly be the norm, and Win32 the exception.

I know it is somewhat annoying to hear about Xojo Windows, but we cannot rely forever on an application model that dates back to 1985…

//Warning: Own personal very biased opinion//

The installed base is just too huge. Win32 is not going by the wayside anytime soon. Much to the chagrin of Microsoft, I will concede that. I suspect that app virtualization as it is starting to appear in the next release of Hyper-V and also hinted at in Project Centennial Bridge communications, is aiming to encapsulate Win32 apps. That may well become the model to run Win32 apps in the future, but Win32 will remain supported one way or another.

In the end this is what I had to do each time for my larger applications. The built-in toolbar is too restricted, the listbox is non-native, etc. In the last five years I built a large library of enhancements (more than 7.000 declares). The same would be necessary for Swift of course – I don’t see the difference. Cross-platform development always poses the same problems.

Personally I dislike Swift a lot (I wrote two small apps for my company to learn it) and I very much prefer Objective-C.

[quote=239877:@Louis Desjardins]//Warning: Own personal very biased opinion//

The installed base is just too huge. Win32 is not going by the wayside anytime soon. Much to the chagrin of Microsoft, I will concede that. I suspect that app virtualization as it is starting to appear in the next release of Hyper-V and also hinted at in Project Centennial Bridge communications, is aiming to encapsulate Win32 apps. That may well become the model to run Win32 apps in the future, but Win32 will remain supported one way or another.[/quote]

Sure. Legacy still has many years to go. But that is not what I would call the future of a development tool.

Microsoft has been suggesting a number of models supposedly to replace com-based win32, AppX being the latest. If I have to decide on where to invest precious development money, I will wait and see a bit longer before I jump horses, just to make sure I am not betting on the wrong evolutionary branch. There is much mileage left in Win32, and near-term to medium-term development can safely be bet on that model.

I forgot the warning. This is a very biased personal opinion, etc.

Until / unless MS outright deprecates or removes legacy API’s people will continue to use old software until hell freezes over.
Thats part of what has made Windows as dominant on the desktop as it is - you could always buy a new computer with the latest OS and run everything you bought from 10 - 20 years ago.
Personally I still get calls about an app I wrote in 1997 - it should have died long ago but “It just keeps on working” - roughly what this person says to me when they call. I cant fix any bugs in it - but they call anyway.

I think the only things that DONT run any more are Win16 apps from the pre-Windows 3.0 era.

My company’s two biggest competitors are both selling VB6 apps (one of which I co-wrote beginning in the mid to late 90s…). I wish Microsoft would announce the end of Win32 apps but I can’t see it happening any time soon.

My last VB6 project (a big accounting app - think QuickBooks for general contractors) is still in active development on VB6. They won’t upgrade until VB6 won’t run on any computer they own or when MS ends Win32 support. Don’t see it happening any time soon.