xsharp.eu

Hi Thomas
Thank you for your detailed reply.

Yes – it reflects the dilemma faced by us all, and is of course written from your perspective as a developer.

My comment was based upon what I would guess to be the perspective of the development team. It is just that - a guess - I have no direct involvement with them.

It has been obvious to me for some time that as things seemed to be evolving at ever increasing rate, some way of perceiving application operation was needed. Even if justification of such understanding required a bit of mental gymnastics, final perception should be easy.
My recent chit-chat post entitled “Jack and the Beanstalk” outlined my thinking on this.

Firstly I’d like to endorse the comments made by Wolfgang.

Secondly, your earlier comments re the road map: the road map was drawn up some time ago and based on rather broad statements made by MS at that time. My interpretation of them would have been the same as yours.

Thirdly being based on C#, X# will be able to follow a “route to the future” for business applications.
This third statement is, of course purely subjective, so I must do my best to justify it.
Our coding constructs, particularly in the business arena, tend to be 2 dimensional. It requires manual fiddle-faddle to cope with anything requiring 3-D thought. (perhaps in WPF).
Progress to Net Core via C#8 brings in the missing 3rd Dimension. A bit of cross-thinking leads me to view this as a completion of the typing set: e.g. none/usual, strict, and now duck as per Python. X# could follow at sensible pace.
If we all agree on a simple way of visualising 3-D operation (see J&B ) then suitable software tooling could be developed making things easier for all.
I hope these “thought snippets” make some sense.

Terry

Hi Wolfgang

wriedmann wrote:even if I come from Clipper/VO through Vulcan.NET to X#: X# has its benefits for business applications offering things that C# or other languages don't have:

Me ogling C# should not be interpreted as me disliking X#, but stems from 2 (rather large) influences:
I am currently not fit in the mixture of C# and VO/Vulcan allowed by the X# compiler and I have to fine tune general knowledge on programmin with DotNet specifics - MS docs, Stackoverflow, GeeksForGeeks often. There I find examples in C# and wonder if/how to move to X#. IlSpy installed and running should eliminate 70%, but I still have to verify if certain features are in Framework 4.6. Also multiple inheritance is not as bad as Java proponents always told until default methods surfaced. It is a good tool if you don't overdo it, using a more Mixin style, so that lures me to C#8 at the moment.
Second is: market for X# probably is even more limited than vfp. I have programmed in Fortran, various Pascal and ModulaII dialects, C, Fox2, Vfp, Java, Python and Javascript: after a few days basic constructs are no problem again - but I have to check how big the target market is. Own projects done typically either as learning expirience in new environment or do it in any interpreter for dev speed.

[*]a language that is really easy to read

Second that totally - at first was sceptic on ":" as member divider, but I am sold when comparing "runtime usable code" vs "vfp compatible code". I might even take up -> alias again, so Dot signifies packages/modules.

[*]a small development team that answers fast and reacts on development requests

No complaints here as well

[*]a preprocessor that permits to save a lot of writing

Definately more than nice to have the option - although I try to keep it for last level, as to use it early lures you on slippery path. But I never tried to implement close dialects - that problem more suited to preprocessor than my usual stuff.

[*]the use of some XBase language constructs like arrays

You probably read Roberts misgivings on vfp array implementation
As I can remember fudging arrays in dbMan by appending numbers to variable names, even murky first implementations were welcome, but in vfp the better intermediate storage either is the cursor or a scattered object. Certainly nice to have more options again - esp if they are markedly faster than local storage, which vfp arrays are sometimes, but not always. .

[*]a inbuilt powerful runtime compiler

Something used often in vfp as well - not tested the scope of possbilities in X# yet. In vfp we also have macro compilation, Execscript or can compile dynamic parts, for instance built from memo fields. Definately the easy way to build your own dynamic rule engine...

[*]libraries to access legacy DBF data

My main target - not as remote data storage (SMB pitfalls make that to dangerous), but as client side cache, SQL stage table intermediate step, lookup storage and more. For purely local usage dbf is not legacy to me - I just argue strongly to not use it via remote or server side from client process directly. Also IMO an option dismissed to early as protocol - XML grew warts as well.

From architecture subsets of normalized relational tables are much better than program first developed object trees, where impedance creeps in from both sides. Model the tables until they fit and leave out ORM or similar stuff trying to "correct" persisted data structures. No change of modeled persistance between front and database is my target - select only needed parts but define structures in persistance well enough to work with it as VM cache - if program stays more KISS, all the better.

These are the things that are coming to my mind immediatly - and therefore I'm using X# in many applications in the Core dialect - without using the X# runtime.

Similar to my idea of usage - I miss the immediate response of vfp interpreter when developing, esp. if target is nothing more than a chain of SQL datapruning steps. Probably for such tasks feeding special SQL via text files into ADO.Net might get some of the dev speed back, will see.
As compiling takes more time IAC, get the most out of it for program quality by ditching USUAL vars, parameters and return values from code and staying with Core, RDD and strict typed functions. Best if dbf can accomodate all data types directly, which ADS seems to do best at the moment, so that would be first enhancement to dbf to ask for. So for vfp compatibility, I'll add some more overwrite methods with correct method signature.
But supreme for me was having the code as open source - not again depending on a black box (although at the moment I understand only small part of X# internal machinery...) After Lianja switched course to implement "cursors" only as JS cursors with added methods for ARM and web, I was unable to do anything and left - here I can at least bang my head against already existing code if I am the only one interested in specific enhancement

regards
thomas

Hi Terry,
quote="Terry" post=13823]Firstly I’d like to endorse the comments made by Wolfgang.[/quote]
I'll answer here only few points, as I wrote a lot on Wolgangs comments.

My comment was based upon what I would guess to be the perspective of the development team. It is just that - a guess - I have no direct involvement with them.

My point is that I am afraid the things luring VO/Vulcan devs here might not be that tempting to remaining (perhaps should say persevering) vfp devs. Despite the syntax similarities there marked differences in creating applications. Only a few vfp devs writing here, I'd hoped more would chime in.

It has been obvious to me for some time that as things seemed to be evolving at ever increasing rate, some way of perceiving application operation was needed. Even if justification of such understanding required a bit of mental gymnastics, final perception should be easy.
My recent chit-chat post entitled “Jack and the Beanstalk” outlined my thinking on this.
Secondly, your earlier comments re the road map: the road map was drawn up some time ago and based on rather broad statements made by MS at that time. My interpretation of them would have been the same as yours.
Thirdly being based on C#, X# will be able to follow a “route to the future” for business applications.
This third statement is, of course purely subjective, so I must do my best to justify it.
Our coding constructs, particularly in the business arena, tend to be 2 dimensional. It requires manual fiddle-faddle to cope with anything requiring 3-D thought. (perhaps in WPF).
Progress to Net Core via C#8 brings in the missing 3rd Dimension. A bit of cross-thinking leads me to view this as a completion of the typing set: e.g. none/usual, strict, and now duck as per Python. X# could follow at sensible pace.
If we all agree on a simple way of visualising 3-D operation (see J&B ) then suitable software tooling could be developed making things easier for all.
I hope these “thought snippets” make some sense.

On the topic of GUI, if given task and funds to start from zero, I'd probably aim for something close to Cell.Js or Jasonette from Ethan Glichtenstein - interesting read if you don't mind reading up on concepts which failed to get enough public traction...
Adding Python and duck typing again - current resolve is to get a firm standing in Dotnet-strict typing again, then perhaps look gain at USUALs, static type called dynamic or adding an interpreter again, which might be Python or C# based. Waaaay in the future.

regards
thomas

Hi Thomas

I look at things slightly differently. There may be a different way in to dot Net which suits Vfp programmers.

Having said that, I would encourage those programmers to look at XSharp as a staging post to the future. Which, as I see it, will be .Net based.

It has a competent and enthuistic development team, and user community with broad rnge of backgrounds willing to help (as quiclky as possible) with any transitioning problems.

The exact path along which future development trends will take us is difficult to predict. One thing I am certain of is that no object has more that 3-Dimensions to address and MS driven (.Net) technologies cover all aspects. All derivative languages of CSharp can potentially follow at their own pace.

I know nothing about Vfp, but FWIW if you think Cell.js is a better route I'd suggest looking to see if there are any initiatives tackling the problem of using it's scripting libraries on the CLR platform. (eg as per IronPython).

Things will evolve - both software tooling and programming techniques. Just how remains to be seen.

Terry