VFP has stirred something

[lumberjack]

Hi all,
I see my recent VFP has stirred some views, well actually already more than 250. So how about all the lurkers just do a little post...
I am Johan Nel, from South Africa.
I have been programming since 1986 using dBase III+, moved on to Clipper/VO/Vulcan and now X#. I feel excited about what I see in X#, a true .NET compiler using my favorite xBase syntax but with the opportunity to consume the whole .NET world.
I believe X# is the xBase version of The next best thing to sliced bread.

[Terry]

Hi Johan

> I believe X# is the xBase version of The next best thing to sliced bread.

OK so my two pennyw'rth.

X# does all you say. To me it is a Business Oriented language, and as such is the .Net version of COBOL.

Many here, understandably, seem to look at XSharp as bringing the past (Clipper/VO, Vulcan etc) up to date. That, of course, was the idea behind it.

But by bringing things up to date, it has just as importantly arguably more so, opened the door for future AUTOMATIC program updating in the future.

Tools to do this are in their infancy at the moment. The techniques to "future-proof" applications at the moment, though well established, have to be implemented manually, which requires huge amounts of time: Not consistent with business demands to change things at the drop of a hat.

This will change. Just as in real life, when we can't do something within a reasonable time scale we get someone else to do it for us, in our programming endeavours all we need is the right software tool.



Terry

[lumberjack]

Hi Terry,

> I believe X# is the xBase version of The next best thing to sliced bread.
X# does all you say. To me it is a Business Oriented language, and as such is the .Net version of COBOL.
Many here, understandably, seem to look at XSharp as bringing the past (Clipper/VO, Vulcan etc) up to date. That, of course, was the idea behind it.

I fully agree with you, we have a language on par with c#, but bring those nice XBase functions with it, Space(), Replicate(), PadL(), PadC() etc.

But by bringing things up to date, it has just as importantly arguably more so, opened the door for future AUTOMATIC program updating in the future.
in our programming endeavours all we need is the right software tool.

I totally agree, you and I and a couple of others hypothesize sometimes about that ideal "Think for itself" solution. I dare say I am excited about my usage of X# in realizing some of those ideas.

With X# running on top of the c# compiler and with the knowledge gained in perfecting the XBase syntax on top of Roslyn opened up new opportunities, it is the ideal environment to even do a XSharp.Delphi and dare I say XSharp.Cobol language extension. Yes there are some hurdles that might be difficult, but a community that work towards a common goal with the backup of the X# team can only go from strength to strength.

Regards,

[wriedmann]

Hi Terry,
it is not always possible to forget the past and restartfrom scratch.
For many applications it would be possible, but for many not.
I'm pretty sure the sources of Windows or Microsoft Office contain a lot of 20 years old code, and the same for sure is true for the Linux kernel/subsystems and OpenOffice, for example.
If you work in a niche like me, you cannot even propose to customers to trash their investments in software, and therefore I need a development language that allows me to maintain and modernize the applications withou rewriting them entirely.
Of course sometimes it would be the best thing, but we are not in an ideal world, and need to stick with what we have.
Wolfgang

[FFF]

but we are not in an ideal world, and need to stick with what we have.
Wolfgang

Right. Plus, i have seen way to many "solve it all, automagically and without any effort" pills to digest another. The idea behind is as old as mankind, but since we left Eden, it's a dream .
Carlos Rocha, i think, said years ago on the NG: "with VO, we were almost there", and i agree. It's not, that there was no need for deep (and possiby long thinking), prior to the first line of code, but, when coding started, you were almost instantly ready, compared with e.g. a C guy...
Looking forward to the VPF people coming, having started my encounter with databases using Fox, a lot of years ago :cheer:

[Terry]

Hi Wolfgang

> it is not always possible to forget the past and restartfrom scratch.

Totally agree with you there.

But this is my whole point. With the endgame programability of the Roslyn compiler you won't have to.

By addressing just that end bit you don't have to change most of your code. Just that part of it that addresses the final part. By that I mean in a business application you can change, potentially automatically, just that bit that addresses those final "business targeted" functionality of your program.

Most of the code remains the same. Indeed it must.

And clearly the target of your program must remain in the same ball-park. i.e. Business for Business and so on.

Trashing customer investment is not the name of the game. Modernising them Quickly is.

Terry

[wriedmann]

Hi Terry,

By addressing just that end bit you don't have to change most of your code. Just that part of it that addresses the final part. By that I mean in a business application you can change, potentially automatically, just that bit that addresses those final "business targeted" functionality of your program.

I'm really sorry, but I don't understand what do you mean exactly, or how this should be accomplished.

Wolfgang

[Terry]

Hi Karl

See my response to Wolfgang.

Pipe Dream no longer. OK I'm only talking managed code. But all the other stuff (if indeed it has to be updated) can be left as it is.

There is no reason to suppose, in the fullness of time, that our managed code cannot become as efficient as anything that has gone before.

Also, believe me, it is quite possible, using MS stuff (Roslyn etc), to implement a runtime test environment that will check every aspect of running program code.

I expect MS to integrate this sort of thing into VS.

Terry

[FFF]

Sorry, Terry,
but you lost me. I think you talk now about automated testing? Earlier it was, AFAIU, automated coding? Prior to that, IIRC, it was mind mapping to code?
I read your posts with interest for years, but either you'll present something to put "hands on", or i'll have to call: "the emperor is naked".

Karl

[Terry]

Hi Wolfgang

I'll try and explain by analogy. It would take me a long time to "prove" it all to anyone. That is one of those things best done in face-to-face discussion. But I hope the following makes sense:


In real life we may leave home, go to work, pick up tools from somewhere, arrive at work, use tools and our own skills to do the work.

Then we go home.

All that matters is the work we do when we get to our place of work. Essentially just us and our skills.

Believe me, that can be mapped logically into what our program code is doing. Going from home to work, jumping all over the place to pick up tools and so on. All that is intrinsically within our code base.

All that matters is what we do. Manipulating the modules in managed code (using Roslyn) does just that final bit.

If we change the final bit only we can do all the rest just as we've always done. ie Don't change the code that gets us to work.

Sorry for mixed metaphors.

Hope it makes some sense.

Terry