I've watched Unboxing X# 2.8, thank you again for this presentation.
This having said, I often get the impression that quite some IT developments have come to a kind of standstill.
For example, end last year I replaced my Pc after nearly 7,5 years. I've never used a Pc that long and the only reason to get a new one was that I thought I was probably close to a system failure due to the number of working hours.
Although the new Pc really has some nice specs, like a i9 and a NVMe M.2 PCIe SSD and more, the best I can say about it is that it gives the impression that some things seem to work a little bit faster. But no real gains in compile- or unzip times like I had on earlier Pc replacements.
Same for language additions. X# is getting all the bells and whistles of C#, thanks to Rosalyn and the highly skilled development team. However, for most changes I wonder if they are really useful. E.g. I learned we can now write:
METHOD MyToString() AS STRING =>SELF:Left()
instead of
METHOD MyToString() AS STRING ; RETURN SELF:Left()
Robert already mentioned that the 2nd method is also 1 liner and only a few characters less code.
When I see this I actually immediately forget it as I would have to lookup what to do again to apply this. Even worse: when I would later coma across someone's code written with => instead of the clear code of the "old fashioned" way, I would most likely wonder what this means. I've seen that more than once in C# as well, code I absolutely don't understand because the programmer used some "clever" new option with @#$%":{} in it and there's no way to even lookup what it means. How do you search for the meaning of a couple of special characters? Searching for the keyword RETURN, in case that is unfamiliar to you, is a lot easier.
What I am afraid of is that a lot of effort is put in adding functionality which doesn't really change the use of the environment and hence a lot of people don't even bother to memorize it. I haven't found much in the last few years in C# nor Visual Studio which was really improving my productivity so I often don't even read the What's New after an update. Even worse, when I did csc /? in C:WindowsMicrosoft.NETFrameworkv4.0.30319, apparently the way to find out which C# version I have, it said 4.8.4084.0, from 11 years back. But further study learned me that it's updated with VS and/or .Net so it should be something like 7.3. Whatever....
I've seen that happening with Windows 10 as well. The last few years, not much of any interest was added to W10. This means that when there actually is, by exception, something interesting, most people don't know about it. I consider Clipboard history (enabling you to select values copied/cut before the last one) as a very useful and tome saving addition. But I've asked quite a few people recently (including a few IT pro's) and nobody knew about. Default it's even turned off! https://support.microsoft.com/en-us/win ... 46ddf338c6 in case you didn't know either
Finally, I am in no way trying to criticize the work and the choices of the development team; Robert once mentioned that quite a few these language additions are easy to implement using Rosalyn. If Microsoft would put more effort in productivity instead of adding more language "features" than the average programmer is able to recall (and hence: use), that would make X# benefit too. I think when I would move to X# the much better checks of the X# compiler versus that of VO would make my code less error prone. But so far I haven't seen one single language element in X# (or C#) from which I thought "I wish I had that in VO". The opposite I have multiple however (more for C# than for X# of course as X# can use most of the VO dialect) ....
Dick
Some thoughts about new X# functionality
Some thoughts about new X# functionality
Hi Dick,
Indeed, Robert mentioned that the => expression on entities was just a very tiny improvement that was extremely easy to implement, so why not? It was not meant to be a very important addition to the language. What is IMO very useful though is local functions (implemented in the latest build), I've been missing them a lot since my days of writing pascal code.
Regarding X# features in general, if you do not need the extra stuff it has over VO, then it is fine of course. But for other people, those are extremely important improvements, helping to write faster, a lot more robust and safe code. Let's bring this the other way around, is there any feature you are missing in VO and you would like to see it implemented in X# or another language?
Indeed, Robert mentioned that the => expression on entities was just a very tiny improvement that was extremely easy to implement, so why not? It was not meant to be a very important addition to the language. What is IMO very useful though is local functions (implemented in the latest build), I've been missing them a lot since my days of writing pascal code.
Regarding X# features in general, if you do not need the extra stuff it has over VO, then it is fine of course. But for other people, those are extremely important improvements, helping to write faster, a lot more robust and safe code. Let's bring this the other way around, is there any feature you are missing in VO and you would like to see it implemented in X# or another language?
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu
Some thoughts about new X# functionality
Hi,
Best regards,
Leonid
What about SWITCH?ic2 wrote:But so far I haven't seen one single language element in X# (or C#) from which I thought "I wish I had that in VO".
Best regards,
Leonid
Best regards,
Leonid
Leonid
Some thoughts about new X# functionality
Hello Leonid,
[center][/center]
The first time I used it (from some borrowed code) it took me a quite a while to find out that Switch simply continues to go through the conditions except when you type break in every line. If I want to have multiple conditions tested, a couple of IF..ENDIF's makes my code flow a lot more readable. The VO DO CASE is also a lot more readable than the Switch statement.
I've seen several explanations of Switch versus Case but I've never seen a use of Switch which is in anyway more usable than DO CASE or IF ENDIF in VO, And the samples are always more code lines.
Dick
[center][/center]
SWITCH is indeed a great sample of something which only has disadvantages compared to DO CASE.leon-ts wrote: What about SWITCH?
The first time I used it (from some borrowed code) it took me a quite a while to find out that Switch simply continues to go through the conditions except when you type break in every line. If I want to have multiple conditions tested, a couple of IF..ENDIF's makes my code flow a lot more readable. The VO DO CASE is also a lot more readable than the Switch statement.
I've seen several explanations of Switch versus Case but I've never seen a use of Switch which is in anyway more usable than DO CASE or IF ENDIF in VO, And the samples are always more code lines.
Dick
Some thoughts about new X# functionality
Hello Chris,
1 I like CodeLens a lot, but this is not working in X#. Is that something which can be implemented? In VO I can of course do a global search on the function name but it often results in more hits than just the places where it is called and it costs a lot more time and effort.
2 In VS I have more info about variables (e.g. VO stops showing content after 64 array elements or a certain string length) while in VS I can see everything and potentially allows me more options to change the process. But much of this doesn't yet work in X#, like Edit and Continue. Or does it? And it's often impossible to evaluate an expression because you have to guess how the expression would look like in C# including the right case.
3 What I also like in VS is that using Step in the Debugger, you can see how much time was elapsed during the execution of a line. This once helped me finding the cause for a major delay which I could eliminate by using a different class (to get EXIF info of a graphic file).. But this works in X#/C#.
I can't remember language elements I could use (but nor present in VO) but when I think of 1 the next few weeks I will post it. A thing which would save me a lot of time, not present in VO nor VS, would be a way to create strings with multiple languages straight from the code. Think of something like this: you are assigning a variable cVar:="This is a test" and you click to get a kind of popup showing you the machine translation of this string in some languages you have chosen to support, and shows some near similar translations which you could choose instead or show when it was already used (and translated earlier). Then you would edit the translations, if needed, and VS would take care of creating the results in a resource or something and take care of accessing the right string during program execution.
I support multiple languages and I use a fairly efficient program to create translations in a database, but a native support would be much better.
I will leave out all the things I wish VS/X#/C# has not which is in VO
Dick
I re-watched that part about Local functions (from 22:50). Unfortunately I fail to see an advantage above a normal VO function, or it must be that you can use the variables of the calling function. Robert already called this tricky and I would certainly never apply that, a.o. because when looking into the function I am sure I would wonder where the variable (i in the presentation) is coming from.Chris wrote:What is IMO very useful though is local functions (implemented in the latest build), I've been missing them a lot since my days of writing pascal code.
That's a very intriguing question! There are certainly a few things missing in VO but some are present in X#/C#/VS, not all:Chris wrote:Let's bring this the other way around, is there any feature you are missing in VO and you would like to see it implemented in X# or another language?
1 I like CodeLens a lot, but this is not working in X#. Is that something which can be implemented? In VO I can of course do a global search on the function name but it often results in more hits than just the places where it is called and it costs a lot more time and effort.
2 In VS I have more info about variables (e.g. VO stops showing content after 64 array elements or a certain string length) while in VS I can see everything and potentially allows me more options to change the process. But much of this doesn't yet work in X#, like Edit and Continue. Or does it? And it's often impossible to evaluate an expression because you have to guess how the expression would look like in C# including the right case.
3 What I also like in VS is that using Step in the Debugger, you can see how much time was elapsed during the execution of a line. This once helped me finding the cause for a major delay which I could eliminate by using a different class (to get EXIF info of a graphic file).. But this works in X#/C#.
I can't remember language elements I could use (but nor present in VO) but when I think of 1 the next few weeks I will post it. A thing which would save me a lot of time, not present in VO nor VS, would be a way to create strings with multiple languages straight from the code. Think of something like this: you are assigning a variable cVar:="This is a test" and you click to get a kind of popup showing you the machine translation of this string in some languages you have chosen to support, and shows some near similar translations which you could choose instead or show when it was already used (and translated earlier). Then you would edit the translations, if needed, and VS would take care of creating the results in a resource or something and take care of accessing the right string during program execution.
I support multiple languages and I use a fairly efficient program to create translations in a database, but a native support would be much better.
I will leave out all the things I wish VS/X#/C# has not which is in VO
Dick
Some thoughts about new X# functionality
Dick,
And the compiler will detect duplicate CASE values (which often happen when copying code).
Robert
SWITCH in X# does NOT need break statements.ic2 wrote:Hello Leonid,
SWITCH is indeed a great sample of something which only has disadvantages compared to DO CASE.
The first time I used it (from some borrowed code) it took me a quite a while to find out that Switch simply continues to go through the conditions except when you type break in every line. If I want to have multiple conditions tested, a couple of IF..ENDIF's makes my code flow a lot more readable. The VO DO CASE is also a lot more readable than the Switch statement.
I've seen several explanations of Switch versus Case but I've never seen a use of Switch which is in anyway more usable than DO CASE or IF ENDIF in VO, And the samples are always more code lines.
And the compiler will detect duplicate CASE values (which often happen when copying code).
Robert
XSharp Development Team
The Netherlands
robert@xsharp.eu
The Netherlands
robert@xsharp.eu
Some thoughts about new X# functionality
Hello Robert,
The 2nd I once knew but I had forgotten it as I haven't had problems with duplicates values ever, but ok, Switch could be an advantage.
Dick
The first I didn't know, it certainly makes more sense than the C# way of doing it.robert wrote:Dick,
SWITCH in X# does NOT need break statements.
And the compiler will detect duplicate CASE values (which often happen when copying code).
The 2nd I once knew but I had forgotten it as I haven't had problems with duplicates values ever, but ok, Switch could be an advantage.
Dick
Some thoughts about new X# functionality
Hello Dick,
If you need to perform certain actions for different values of a variable, then I cannot think of a single reason why IF/CASE statements are more efficient than the SWITCH statement, both for reading the code and for the speed of its execution.
Comparison example IF/CASE/SWITCH:
As you can see from the example, for IF/CASE statements, you need to write more code and repeat the condition each time. This is one of the serious problems in this task, since every time you have to write a complete condition and in this case it is easy to make a mistake. For example, write the wrong variable in the condition or even the whole condition. In addition, during the subsequent verification of such a code, it is necessary to carefully read and check the condition in each line of this group of operators. In this case, in SWITCH you need to specify only the expected value of the variable, which is easier both for reading the code and for executing it. As far as I know, a special code with a jump table is generated for the SWITCH statement, which makes it possible to execute such code faster than if it were a group of IF/CASE statements.
Thus, the SWITCH statement requires less coding, is less error prone, easier and cleaner to read, and executes faster. How does the IF/CASE for this type of task can be better? This is a rhetorical question.
P.S. As far as I know, in VO, the DO CASE statement is transformed into a set of IF/ELSEIF conditions during compilation and, as a result, generates the same code.
Best regards,
Leonid
If you need to perform certain actions for different values of a variable, then I cannot think of a single reason why IF/CASE statements are more efficient than the SWITCH statement, both for reading the code and for the speed of its execution.
Comparison example IF/CASE/SWITCH:
Code: Select all
LOCAL nVal AS INT
// .... some code
DO CASE SWITCH nVal
IF nVal == 1 CASE nVal == 1 CASE 1
// ........................ do something .............................
ELSEIF nVal == 2 CASE nVal == 2 CASE 2
// ........................ do something .............................
ELSEIF nVal == 3 CASE nVal == 3 CASE 3
// ........................ do something .............................
ELSE OTHERWISE OTHERWISE
// ........................ default ..................................
ENDIF END CASE END SWITCH
Thus, the SWITCH statement requires less coding, is less error prone, easier and cleaner to read, and executes faster. How does the IF/CASE for this type of task can be better? This is a rhetorical question.
P.S. As far as I know, in VO, the DO CASE statement is transformed into a set of IF/ELSEIF conditions during compilation and, as a result, generates the same code.
Best regards,
Leonid
Best regards,
Leonid
Leonid
Some thoughts about new X# functionality
Leonid,
Both in VO and in X# the DO CASE statement and the IF ELSEIF statements are compiled into the same construct. Each CASE and each ELSEIF become an ELSE IF . The last ELSE and the OTHERWISE become ELSE
You can see that in our code:
CASE Blocks generate an IF statement:
https://github.com/X-Sharp/XSharpDev/bl ... e.cs#L6361
ELSEIF generates an IF statement too:
https://github.com/X-Sharp/XSharpDev/bl ... e.cs#L6318
Robert
You are right:leon-ts wrote: P.S. As far as I know, in VO, the DO CASE statement is transformed into a set of IF/ELSEIF conditions during compilation and, as a result, generates the same code.
Both in VO and in X# the DO CASE statement and the IF ELSEIF statements are compiled into the same construct. Each CASE and each ELSEIF become an ELSE IF . The last ELSE and the OTHERWISE become ELSE
You can see that in our code:
CASE Blocks generate an IF statement:
https://github.com/X-Sharp/XSharpDev/bl ... e.cs#L6361
ELSEIF generates an IF statement too:
https://github.com/X-Sharp/XSharpDev/bl ... e.cs#L6318
Robert
XSharp Development Team
The Netherlands
robert@xsharp.eu
The Netherlands
robert@xsharp.eu
Some thoughts about new X# functionality
Hello Leonid,
If I check a condition and directly above the condition I read CASE nVal == 2 I think that is a lot easier than when I read CASE 2. What 2? I have to go to the beginning of the statement (which can be very long) to mentally combine nVal and the value in the CASE line. Not to mention the DO...CASE statement where more than 1 condition is tested, this can't be done with Switch. For that reason I'm inclined to use DO CASE everywhere but I may reconsider that.
I want to be able to have as much information in 1 place as possible. Another issue of .Net is that a method no longer needs to have a class written (although fortunately X# does make it possible). Especially when I have a methods of a few classes in 1 .prg, I will have to scroll up until I find the CLASS statement. That's a step backward too. In C# it's even worse because there's no ENDIF, ENDDO etc. You have to click on a ; and hope you have the one closing the statement you are working on
Dick
Thanks for taking the time to explain the difference and advantages of Switch. I understand and appreciate after the explanation that Switch is less error prone, it saves re-typing the condition and I take your word for it that it's faster. But if it's easier and cleaner to read is a matter of taste. I think it's the opposite.leon-ts wrote: Thus, the SWITCH statement requires less coding, is less error prone, easier and cleaner to read, and executes faster. How does the IF/CASE for this type of task can be better? This is a rhetorical question.
If I check a condition and directly above the condition I read CASE nVal == 2 I think that is a lot easier than when I read CASE 2. What 2? I have to go to the beginning of the statement (which can be very long) to mentally combine nVal and the value in the CASE line. Not to mention the DO...CASE statement where more than 1 condition is tested, this can't be done with Switch. For that reason I'm inclined to use DO CASE everywhere but I may reconsider that.
I want to be able to have as much information in 1 place as possible. Another issue of .Net is that a method no longer needs to have a class written (although fortunately X# does make it possible). Especially when I have a methods of a few classes in 1 .prg, I will have to scroll up until I find the CLASS statement. That's a step backward too. In C# it's even worse because there's no ENDIF, ENDDO etc. You have to click on a ; and hope you have the one closing the statement you are working on
Dick