Terry, totally get your intentions and support them. The xSharp project is very impressive so far.
And yes having come from VO, not Vulcan, there are lots of road blocks (.NET and Microsoft classes learning curve). Also for me, the current reliance on Vulcan code is one of those road blocks and I hope that is dealt with very quickly.
Another addition could be a xSharp sample/standard app that calls code from a VO DLL.
Cheers,
Paul
What's in a Name
What's in a Name
Hi Paul,
Wolfgang
I don't this is possible if the VO DLL is not a COM DLL or has a C style interface.Another addition could be a xSharp sample/standard app that calls code from a VO DLL.
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
What's in a Name
Wolfgang,
Thanks for the clarification. Ahead of my Ski's a bit--thinking about transition strategies.
Paul
Thanks for the clarification. Ahead of my Ski's a bit--thinking about transition strategies.
Paul
What's in a Name
Just what's needed - great.
Terry
Terry
What's in a Name
Hi Paul,
we have litterally tons of VO code, and we will try to move all applications that are in active development to X#, using the VO GUI classes. Some of these will be moved then to the WinForms based GUI classes.
New development will be made whenever possible, and for some functionality in our VO programs we are writing COM modules in X#. Our most important VO programs are using several of them.
Wolfgang
we have litterally tons of VO code, and we will try to move all applications that are in active development to X#, using the VO GUI classes. Some of these will be moved then to the WinForms based GUI classes.
New development will be made whenever possible, and for some functionality in our VO programs we are writing COM modules in X#. Our most important VO programs are using several of them.
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
What's in a Name
Hello Terry,
Dick
You've absolutely got a point here. X# , as VO/Clipper/etc, is a breeze to use compared to C#. However, I think if people are used to C# actually will consider the name X# as a recommendation. Take for example Nick who recently wrote that he actually currently likes all those points which beginners -and many long time users alike- consider nasty complications, like curly brackets. And those unknown to the horrors of C# will probably also conclude that it must be a professional language because C# is after all used for programming some of the top technology software. Even though I don't like C# and often feel (after years of regular use) that the very design of C# slows me down (e.g. much more look ups needed) compared to all others languages I've used I do consider it the language which can do almost everything.Now for the second point: XSharp is far easier to use (for business apps), due to its narrower focus than say C#. A single module program can itself produce highly capable applications. The learning curve to multi-module (X-Sharp) apps is relatively modest, and subsequent progression to multi-module-multi-language apps, again, a relatively modest step.
Dick
What's in a Name
Hi Dick
Yes - I understand.
It reminds me too of the ADA Language, introduced by the DoD (I assume it's still in use) and made deliberately verbose with the aim of making things self-documenting.
Terry
Yes - I understand.
It reminds me too of the ADA Language, introduced by the DoD (I assume it's still in use) and made deliberately verbose with the aim of making things self-documenting.
Terry
- softdevo@tiscali.it
- Posts: 191
- Joined: Wed Sep 30, 2015 1:30 pm
What's in a Name
I think that X # is a good name, it immediately makes us understand what it is, a language that incorporates the advantages of the net language and the XBase family. I would not change it.
Danilo
Danilo
What's in a Name
Hello Terry,
There are still things X# can't do and probably never will (UWP for example? ) but I think that X# is moving towards the capabilities of C# without the nasty habits of it.
A sample of such a nasty thing: this weekend I lost almost an hour trying to find out why I couldn't use SQLite. First part of the problem (outside that lost hour) was that I downloaded a working UWP solution targeting 16299 which I changed to target 14393 (Anniversary) so it would work on all Windows 10 Phones as well. But Microsoft.Data.Sqlite.Core didn't work and I could not download a NuGet package 1.x which would support 14393. Eventually I solved it thanks to Stackoverflow (see https://docs.microsoft.com/en-us/window ... -databases for future readers having the same problem).
But in the meantime I tried another compatible SQLLite NuGet package which kept giving "Are you missing an assembly reference error". And I had now idea why until I found out that the code was based on SQLite and the new package was called Sqlite. Or the other way around maybe....All because one or another idiot thought on designing C# it was a good idea to make keywords and namespaces case-sensitive.
Good X# isn't.
Dick
There are still things X# can't do and probably never will (UWP for example? ) but I think that X# is moving towards the capabilities of C# without the nasty habits of it.
A sample of such a nasty thing: this weekend I lost almost an hour trying to find out why I couldn't use SQLite. First part of the problem (outside that lost hour) was that I downloaded a working UWP solution targeting 16299 which I changed to target 14393 (Anniversary) so it would work on all Windows 10 Phones as well. But Microsoft.Data.Sqlite.Core didn't work and I could not download a NuGet package 1.x which would support 14393. Eventually I solved it thanks to Stackoverflow (see https://docs.microsoft.com/en-us/window ... -databases for future readers having the same problem).
But in the meantime I tried another compatible SQLLite NuGet package which kept giving "Are you missing an assembly reference error". And I had now idea why until I found out that the code was based on SQLite and the new package was called Sqlite. Or the other way around maybe....All because one or another idiot thought on designing C# it was a good idea to make keywords and namespaces case-sensitive.
Good X# isn't.
Dick
What's in a Name
Hi Dick
Yes – agree with what you say up to a point.
But the case sensitivity and squirlygigs of C#, you are either happy with or not, it is a subjective thing.
From my point of view they make understanding what is going on easier – trying to work things out through the verbosity of a different language only, IMO, adds to difficulty.
But there are two ways of looking at the relationship between C# and XSharp:
Firstly: as an alternative to ways of coding things.
Secondly: by considering C# to be at the hub of all .Net derived languages, with the languages themselves radiating outwards like the spokes on the wheel of a bicycle.
In the case of X# it’s spoke is radiating outwards towards easier use, business application focus and maybe business-type verbosity.
Of course, ease of use is not solely a feature of the language alone, it is very closely tied in to its’ users as they gain more experience in using it.
Looked at this second way, consideration of any direct competition between C# and XSharp is removed.
This change of direction is partly what motivated my original name-change suggestion in this thread, though I have to acknowledge that Wolfgang’s suggestion of using some attribute is much better.
Terry
Yes – agree with what you say up to a point.
But the case sensitivity and squirlygigs of C#, you are either happy with or not, it is a subjective thing.
From my point of view they make understanding what is going on easier – trying to work things out through the verbosity of a different language only, IMO, adds to difficulty.
But there are two ways of looking at the relationship between C# and XSharp:
Firstly: as an alternative to ways of coding things.
Secondly: by considering C# to be at the hub of all .Net derived languages, with the languages themselves radiating outwards like the spokes on the wheel of a bicycle.
In the case of X# it’s spoke is radiating outwards towards easier use, business application focus and maybe business-type verbosity.
Of course, ease of use is not solely a feature of the language alone, it is very closely tied in to its’ users as they gain more experience in using it.
Looked at this second way, consideration of any direct competition between C# and XSharp is removed.
This change of direction is partly what motivated my original name-change suggestion in this thread, though I have to acknowledge that Wolfgang’s suggestion of using some attribute is much better.
Terry