PMFJI
An interesting exchange of views here.
The fact is that any No Net language itself "contains" .Net features. Whether C# or any derivative, the language provides access to the full gamut of .Net features.
To illustrate I have extracted a few diagrams from a document designed to show how we can architect any program whilst thinking in real-world terms.
Just my two penn'orth in the debate.
Terry
X# or C#?
X# or C#?
- Attachments
-
- Diagrams.pdf
- (424.13 KiB) Downloaded 87 times
X# or C#?
Hello Chris, Terry,
Just including one or more X# DLL's to have access to a ready-to-use X# function is a very interesting idea however. I am going to try this!
By the way Terry: you put a lot of effort in your diagrams!
Dick
Ok, I admit I exaggerated a bit. But a fact is, unfortunately, if there's a imaginary balance between the benefits gained from .Net features (like the enumeration you gave) and the daily functions etc I need in my all my programs which are not readily (and easily) available in C# then the balance is heavily tipping over to the right - the extra time I nearly invariably need to search workarounds for something I need done has much more impact than the time I save (or real usable improvements I can implement etc.) through those .Net features.Chris wrote:But the statement "There's about nothing in .Net ready to use" could not possibly be any further from the truth...
Just including one or more X# DLL's to have access to a ready-to-use X# function is a very interesting idea however. I am going to try this!
You are right in that: as written in my reply to Chris I do realize that there's some (but very little) advantage to me in everything .Net has to offer but many disadvantages to using C# (including what Chris also experiences as disadvantages of C#), for daily practice. I did write this however to point out that although using C# may seem a logical choice to work with if you are searching for a successor for VO (and do not need to convert existing VO code or access DBF files) but X# is a lot more useful than C#. And that's probably more interesting than our (Chris & me) difference of opinion how much you can really benefit from what .Net offers. Something like .Net/VS/X# versus VO is a whole different discussion :cheer:Terry wrote: The fact is that any No Net language itself "contains" .Net features. Whether C# or any derivative, the language provides access to the full gamut of .Net features.
By the way Terry: you put a lot of effort in your diagrams!
Dick
X# or C#?
Hi Dick!
Anyway, I seriously believe that if you find the disadvantages moving to .Net are more than the advantages, then there's nothing wrong with staying with what you like using more. No point using something if you dislike it and you do have the option to use it or not.
But I still did not understand which are the functions that you daily use and are moving from .Net. Left() is already here with Substring(nChars), Right() is also available, although admittedly less intuitive because it needs 2 params. Which are the other ones that you are missing? I am geniounly curious about this!
Hehe, "a bit"!ic2 wrote: Ok, I admit I exaggerated a bit. But a fact is, unfortunately, if there's a imaginary balance between the benefits gained from .Net features (like the enumeration you gave) and the daily functions etc I need in my all my programs which are not readily (and easily) available in C# then the balance is heavily tipping over to the right - the extra time I nearly invariably need to search workarounds for something I need done has much more impact than the time I save (or real usable improvements I can implement etc.) through those .Net features.
Anyway, I seriously believe that if you find the disadvantages moving to .Net are more than the advantages, then there's nothing wrong with staying with what you like using more. No point using something if you dislike it and you do have the option to use it or not.
But I still did not understand which are the functions that you daily use and are moving from .Net. Left() is already here with Substring(nChars), Right() is also available, although admittedly less intuitive because it needs 2 params. Which are the other ones that you are missing? I am geniounly curious about this!
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu
X# or C#?
Hello Chris,
Well you asked for it, here we go B)
These are a few samples but on working with C# I am almost always held up because something is not available or not working as I expect. Sure, part of it is because I have worked much longer with VO than with C#. But everything together I hardly have the feeling that a lot is present in C#/.Net. Also of course, my Photo program would probably have been difficult to create in VO, although maybe FabTools would help a lot already. And I do realize that for future projects, I must work in X#/.Net. So even if find working in VO more comfortable in nearly all respects, I will be working in .Net languages more and more the next few years.
Here's a selection of what I missed in C# or had to search quite some time for before finding a solution:
Left
Right
Occurs
Crypt
ApplicationExec(ExecWhileEvent)
I know that in some cases there is even a 1 line solution but the sole fact that people ask it and multiple solutions are offered, often multi line and not really readable later is a huge disadvantage.
Example: If anyone would ask for VO: I need the number of times a substring occurs in a string he would get one simple and understandable reply: Occurs.
But in C# you get many solution, none of which are clear to understand at a glance, e.g. the only 1 line suggestion I found:
Regex.Matches(input, "value").Count
That means that I often have to spend time searching the internet (while in VO/X# I can find a solution in the help usually quickly, even if it's a function I hadn't used before, and then when I read my code later, Occurs is understandable and Regex.Matches(input, "value").Count is not.
Other issues
- Multiple methods which do not return a value to determine success but failing execution should be arranged in the Exception Handler. E.g.
DeleteSubKey (Registry) returns Void while Bool should be the right return type
- Zero based indexing requires adapting ever samples and working time, like person number 1 in an array is array element 0.
Classes having the same name but different namespaces ("ambiguous reference")
- Visual Studio replaces tabs by spaces a.o. when copying or moving code
Apart from that it is the time I lose (compared to VO) because:
- a : or { / } is misplaced and all program lines in the editor turn red (I usually remove my last edited method completely to a text-editor and step by step insert it again. Caused mainly because you can't edit 1 entity in .Net.
- having to work with escape characters because C# assigns all kind of different and useless meanings to special characters (like filenames needing a @ or double )
- switch statement: every single switch requires a separate break statement (which makes you wonder why they created this statement, a series of if statements is less work
- I have documented all the error messages which caused me more than 10 minutes search before I found the cause, often because the error text is cryptic at best. First you have to copy the error, then strip the unnecessary header and detailinfo VS adds to it, before being able to find the cause. Here's a small selection:
CS0120: An object reference is required for the nonstatic field, method, or property 'foo'
Event Click can only be bound to properties of delegate type RoutedEventHandler
Inconsistent Accessibility: Parameter type is less accessible than method
The modifier 'public' is not valid for this item
Error CS1503 Argument 1: cannot convert from 'string' to 'char'
Error CS8070 Control cannot fall out of switch from final case label
Error CS0079 The event 'ToggleButton.Checked' can only appear on the left hand side of += or -=
Error CS0201 Only assignment, call, increment, decrement, await, and new object expressions can be used as a statement
Error CS0123 No overload for '....' matches delegate 'RoutedEventHandler'
Error CS1010 Newline in constant
I especially documented the cause because often I still don't recognize the cause the next time I get this error. That does happen in VO as well, but far less.
This is what I can think of quickly, of course there's much more.
Dick
Well you asked for it, here we go B)
These are a few samples but on working with C# I am almost always held up because something is not available or not working as I expect. Sure, part of it is because I have worked much longer with VO than with C#. But everything together I hardly have the feeling that a lot is present in C#/.Net. Also of course, my Photo program would probably have been difficult to create in VO, although maybe FabTools would help a lot already. And I do realize that for future projects, I must work in X#/.Net. So even if find working in VO more comfortable in nearly all respects, I will be working in .Net languages more and more the next few years.
Here's a selection of what I missed in C# or had to search quite some time for before finding a solution:
Left
Right
Occurs
Crypt
ApplicationExec(ExecWhileEvent)
I know that in some cases there is even a 1 line solution but the sole fact that people ask it and multiple solutions are offered, often multi line and not really readable later is a huge disadvantage.
Example: If anyone would ask for VO: I need the number of times a substring occurs in a string he would get one simple and understandable reply: Occurs.
But in C# you get many solution, none of which are clear to understand at a glance, e.g. the only 1 line suggestion I found:
Regex.Matches(input, "value").Count
That means that I often have to spend time searching the internet (while in VO/X# I can find a solution in the help usually quickly, even if it's a function I hadn't used before, and then when I read my code later, Occurs is understandable and Regex.Matches(input, "value").Count is not.
Other issues
- Multiple methods which do not return a value to determine success but failing execution should be arranged in the Exception Handler. E.g.
DeleteSubKey (Registry) returns Void while Bool should be the right return type
- Zero based indexing requires adapting ever samples and working time, like person number 1 in an array is array element 0.
Classes having the same name but different namespaces ("ambiguous reference")
- Visual Studio replaces tabs by spaces a.o. when copying or moving code
Apart from that it is the time I lose (compared to VO) because:
- a : or { / } is misplaced and all program lines in the editor turn red (I usually remove my last edited method completely to a text-editor and step by step insert it again. Caused mainly because you can't edit 1 entity in .Net.
- having to work with escape characters because C# assigns all kind of different and useless meanings to special characters (like filenames needing a @ or double )
- switch statement: every single switch requires a separate break statement (which makes you wonder why they created this statement, a series of if statements is less work
- I have documented all the error messages which caused me more than 10 minutes search before I found the cause, often because the error text is cryptic at best. First you have to copy the error, then strip the unnecessary header and detailinfo VS adds to it, before being able to find the cause. Here's a small selection:
CS0120: An object reference is required for the nonstatic field, method, or property 'foo'
Event Click can only be bound to properties of delegate type RoutedEventHandler
Inconsistent Accessibility: Parameter type is less accessible than method
The modifier 'public' is not valid for this item
Error CS1503 Argument 1: cannot convert from 'string' to 'char'
Error CS8070 Control cannot fall out of switch from final case label
Error CS0079 The event 'ToggleButton.Checked' can only appear on the left hand side of += or -=
Error CS0201 Only assignment, call, increment, decrement, await, and new object expressions can be used as a statement
Error CS0123 No overload for '....' matches delegate 'RoutedEventHandler'
Error CS1010 Newline in constant
I especially documented the cause because often I still don't recognize the cause the next time I get this error. That does happen in VO as well, but far less.
This is what I can think of quickly, of course there's much more.
Dick
X# or C#?
Hi Dick,
please keep in mind that Xbase and C# have completely different target groups: C# is an all-purpose language where you can do nearly everything, whereas Xbase (Clipper, VO, VFP, ...) are targeted to database application developers and hence have a large fundus of all-purpose functions.
If you look at VB.NET instead of C# you will see that they there is already a runtime library that has many functions/methods that C# is missing (the same is true even if you compare VBScript and C# Script).
Xbase is much nearer to Pascal than other languages (and Pascal was developed for educational purposes), whereas C# comes from C (there are some C programmers that see it as challenge to put as many functionality as possible in the minimun possible code lines, creating unreadable code full of side effects.
Wolfgang
please keep in mind that Xbase and C# have completely different target groups: C# is an all-purpose language where you can do nearly everything, whereas Xbase (Clipper, VO, VFP, ...) are targeted to database application developers and hence have a large fundus of all-purpose functions.
If you look at VB.NET instead of C# you will see that they there is already a runtime library that has many functions/methods that C# is missing (the same is true even if you compare VBScript and C# Script).
Xbase is much nearer to Pascal than other languages (and Pascal was developed for educational purposes), whereas C# comes from C (there are some C programmers that see it as challenge to put as many functionality as possible in the minimun possible code lines, creating unreadable code full of side effects.
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
X# or C#?
Dick,
You mention a lot of topics. Some I recognize and acknowledge, others have nothing to do with C# vs VO but with the tooling (VS IDE vs VO IDE) .
There is one topic that strongly disagree on:
I have often seen code that looks like this:
Does this look familiar ?
NOBODY is checking the return values of DbUseArea(), DbGoTop() and DbSkip().
And fortunately this mostly runs without a problem.
But in case that there IS a problem, when would you detect it:
- If the DbUseArea() fails
- Then the DbGoTop() will also fail
- and then Eof will return TRUE ? Or not ?
- FieldGet() will fail
- DbSkip() will fail
The original point of failure is the DbUseArea(), bit since most people are ignoring its return value it is very difficult to diagnose the problem.
They will see a loop that is not entered even though they "know" that there are records. Or the FieldGet() fails.
Robert
PS : EoF() will return TRUE when the current area does not have an open table, so the code will not enter the loop.
You mention a lot of topics. Some I recognize and acknowledge, others have nothing to do with C# vs VO but with the tooling (VS IDE vs VO IDE) .
There is one topic that strongly disagree on:
I understand why you find this problematic. Setting up an error handler easily adds a few lines of code that distract from the real programming logic. However many years of support have taught me that most people simply do not check for return values of method/function calls.DeleteSubKey (Registry) returns Void while Bool should be the right return type
I have often seen code that looks like this:
Code: Select all
DbUseArea(...)
DbGoTop()...
DO WHILE ! Eof()
.. FieldGet(..)
DbSkip(1)
ENDDO
NOBODY is checking the return values of DbUseArea(), DbGoTop() and DbSkip().
And fortunately this mostly runs without a problem.
But in case that there IS a problem, when would you detect it:
- If the DbUseArea() fails
- Then the DbGoTop() will also fail
- and then Eof will return TRUE ? Or not ?
- FieldGet() will fail
- DbSkip() will fail
The original point of failure is the DbUseArea(), bit since most people are ignoring its return value it is very difficult to diagnose the problem.
They will see a loop that is not entered even though they "know" that there are records. Or the FieldGet() fails.
Robert
PS : EoF() will return TRUE when the current area does not have an open table, so the code will not enter the loop.
XSharp Development Team
The Netherlands
robert@xsharp.eu
The Netherlands
robert@xsharp.eu
X# or C#?
Hello Wolfgang,
Dick
I do, and that was the whole purpose of my posting: that it may sound logical to work in the bradly used C# but that a lot is missing so X# is the more logical choice. Some of the drawbacks (VS/.Net) also apply to X# but there are a few advantages in VS/.Net as well. In fact, if I would be able to edit and identify (the change dates etc) of single entities I would probably find the disadvantages and advantages about equal.wriedmann wrote:please keep in mind that Xbase and C# have completely different target groups: C# is an all-purpose language where you can do nearly everything, whereas Xbase (Clipper, VO, VFP, ...) are targeted to database application developers and hence have a large fundus of all-purpose functions.
Indeed. And that is also the drawback of the widely available solutions for common problems. Even with a lot of upvotes in Stackoverflow a solution can be worse than another. I always search for the one with the minimum amount of code provided I still understand what is being done. The extra advantage of X# is that when I find a solution here for a problem I usually think, ok that must be good because it is written by someone I know (in quite some cases even personally).(there are some C programmers that see it as challenge to put as many functionality as possible in the minimum possible code lines, creating unreadable code full of side effects.
Dick
X# or C#?
Hello Robert,
Never seen it like that. The better solution probably should have been a more detailed error as return value (instead of Void) but I now see the disadvantages of a boolean as return value. Thanks for that!
Dick
That is a very interesting observation. I have had more of these "issues" but indeed, if you can get more information than a simple true/false which may even be misleading, in the error handler than it is easier to react accordingly.robert wrote:Dick,
There is one topic that strongly disagree on:
DeleteSubKey (Registry) returns Void while Bool should be the right return type
Never seen it like that. The better solution probably should have been a more detailed error as return value (instead of Void) but I now see the disadvantages of a boolean as return value. Thanks for that!
Dick
X# or C#?
Dick,
Registry.DeleteSubkey gives you several different exceptions depending on the cause of the problem:
InvalidOperationException: The subkey has child subkeys
ArgumentException: The subkey parameter does not specify a valid registry key
ArgumentNullException: subkey is null
SecurityException: The user does not have the permissions required to delete the key.
ObjectDisposedException: The RegistryKey being manipulated is closed (closed keys cannot be accessed).
UnauthorizedAccessException: The user does not have the necessary registry rights.
I think this is very helpful
Robert
Registry.DeleteSubkey gives you several different exceptions depending on the cause of the problem:
InvalidOperationException: The subkey has child subkeys
ArgumentException: The subkey parameter does not specify a valid registry key
ArgumentNullException: subkey is null
SecurityException: The user does not have the permissions required to delete the key.
ObjectDisposedException: The RegistryKey being manipulated is closed (closed keys cannot be accessed).
UnauthorizedAccessException: The user does not have the necessary registry rights.
I think this is very helpful
Robert
XSharp Development Team
The Netherlands
robert@xsharp.eu
The Netherlands
robert@xsharp.eu
X# or C#?
Hello Robert,
Dick
I totally agree. But at the same time: would have been much more elegant if that message were returned as a string instead of having a void method and a necessary error handler. That is IMO one of many flaws in the design of .Net.Registry.DeleteSubkey gives you several different exceptions depending on the cause of the problem:
I think this is very helpful
Dick