xsharp.eu

Hi guys,

I have just been adding the last few slides to my second 'Power Point' presentation, for Cologne at the end of April. (xBase.Future)

I would like to share the image of this slide with you here in Pearls. For the good reason that it suddenly hit me that although I am solving a definite business problem (common?), the shape and style of the computer code is looking really quite different to much of what I have coded over the last few decades - where 'few' is starting to be 'many'!

It is not just that putting the answer details on a colourful GUI took about half a line (240) of code, but more of the syntax, and what underlying facilities / technologies that are being used.

[And before you ask - YES, I do this stuff each and every day to solve real problems.]

Study the following :-
Yes, it was easier for me to chain four queries together to get the final results set (answer) and most of the code is LINQ based, and we see four anonymous types being used in the coding, as well as the results being passed back from the static method as a List of 'Dynamic' types.

I believe the 'Dynamic' means more or less that it is a place holder and that the type is provided at run time. Some don't like type 'Dynamic' but it works well with such problems.

Oh! should have said, the querying is being done on Entities (from version 6 EF).

I will leave it up to you to count the number of FOR loops used, 'For' and 'Foreach' both count.

It may be helpful for you to know that the 'OrderLine' entity has a Product property and that the Product entity has a Supplier property. So in some ways query 1 is flattening out the properties. We can then use the new 'flat' properties to calculate 'values'.

Obviously, query 3 groups the products by Supplier.

As Nick Friend often says, this stuff becomes second nature when we use it regularly (even easy), AND, we would not now wish to go back and do it the old ways. He or me.

Don't panic, this is slide 35 (P2) of a two slide show presentation (parts 1 and 2).

If you are not coding like this now, then look at your coding future style !

Hope this is of interest to some.

Best regards,
Phil.
Wales, UK.

Phil,

That looks quite different to the code I have been writing recently:
and as you can see we use enums as well:
And yes, this is C# because Roslyn and Antlr are both in C#

Robert

P.S. Notice how nice the Github integration inside VS shows who authored the code and when it was last changed.

Hi Robert,

Very interesting - your C# code, and "ten out of ten" for the Enum use !

Yes, the styles of code are quite different, and that is what was the purpose of my original post.

If I now include a couple of attachments we can study some other, and slightly older, code of mine. These were printed off in August 1973 - from the best 'Chain' printer the University had on its main frame computer, and the best quality paper.

For interests sake, take a look at these images and see what elements we recognise, and are common to your recent C# code :-
Well we can see that we have a 'Block' structure, and Procedures too.

Lets keep looking .............
Yes, plenty of semi colons, Begin/End, For/Step/Do/End, and If/Then/Else/End structures.

Also arrays, just like those many of our Forum readers go on about today.

However, can you see the ' := ' which we used to verbalise as "becomes equal to" as it was an assignment 'action' and not a comparison. Yes, the good old xBase := which our Professor said was a shorthand (icon?) for a left facing arrow a bit like <= (or <-) but I am not sure how many characters we had to play with back then in the early 70's.

Oh!! - sorry ! - the point was that it looks much like a lot of C# / X# code today, if written that way - AND - I have no idea at all what my hand punched card code is doing. Considering that I spent a year writing it before it run fully (only once) and took 3.5 hours of mainframe time, you think I would recognise what it is doing ;-0) But no, no idea at all. So much for readability. I know the problem that I am trying to solve however.

Now then, the LINQ and modern Microsoft code of my 'Suppliers' business solution, looks absolutely nothing like the procedural code of Algol 60, and Fortran 70 was not much different for that matter.

Isn't it time we embraced some of this 'new stuff' before yet another decade has passed us all by ?

WPF has been around for about ten years, and LINQ for a reasonable number of years. Some of us can't remember WinForms, or just!

Lets keep the ' := ' and get rid of all the rest, or at least have it hidden under a surface veneer of the syntax that Microsoft is now providing us with.

Oh! - by the way the one answer the old program provided, was just what we were after. Isn't it strange to think back now, of writing a program for 12 months (hard work) before we ran it on the computer. And as said recently in another post, we had no editors, just re-type the punch cards ;-0)

Amazing we got any results at all - so I don't listen too closely to some of you guys moaning on about the quality of the IDE, and how crap VS is. Wish I had it back then! Or even 100'th. of it.

And by the way, VS can be used even without intellisense, in both X# and XAML editors. I an doing that now.

Finally, before I go, I think I have had enough of writing FOR loops in my time, give me LINQ and its related technologies, any day of the week ;-0) Just don't ask me to count the number of FOR loops in the zillions of cards in my old program.

Hope this interests a few, and gives us something to reflect upon - 'thoughts wise'.

Cheers,
Phil.

Phil Hepburn wrote:Finally, before I go, I think I have had enough of writing FOR loops in my time, give me LINQ and its related technologies

Well, dare i remind you, how easily your last hooray into the lovely one-liner queries let you misestimate the things you thought you counted?
Wouldn't like to be the victim of such things in "real world" situations. So, i think i'll stay old-fashioned

BTW, i don't quite get your urge to evangelize the rest of the world. Most folks here have been "in this business" for quite some time, and IMHO the fact, that they are still here is enough evidence, that they do have a clue of what and why they do things the way they do it (nice sentence, this...).

Progress is a nice thing, but it has to prove that the benefit is "real" - and the calculation of this is not easy.

Karl,

my father always asked 'and where is the advance?'. What he meant was: 'modern' is not always better.

Phil did not fail because of using LINQ, he failed because he did not write a test before coding the solution. He could have taken an assembly or two of his own, count the enums by hand and test against this.

I'm so happy I took new ways of developing software. I would never go back to old bahaviour introduced by this SSA sample. I should have never seen this but read the book of the GOF, published the same year.

The advance of doing it the modern way is for example:
- I never introduced new bugs in well tested code.
- Making classes and methods as short as possible (SRP), I could make my programs more then 100 times faster. It's not because they were short. It was the logic behind becomes clearer so I could identify unneeded things.

So I do all the analyses provided by tools like NDepend and NCover. Not for the complete code yet but for all areas where I work on.

People are happy as long as they do not know what they miss.

my 2 ct's
Frank

BTW: I see the need of refactoring, both on Phil's and Robert's code

Frank

> BTW: I see the need of refactoring, both on Phil's and Robert's code

Yes, I bet you do.
But this code is not finished yet, I am still working on it.
Once it does what it needs to do then I will go in there and refactor as well.

Ask the guys: I am refactoring all the time.
But I am not sure if they always like it...

Robert

Robert,

But this code is not finished yet, I am still working on it.
Once it does what it needs to do then I will go in there and refactor as well.

of course that's the way I do. See the smiley at the end of the message. I wanted to emphasize what I've written before, not criticize your code.

Frank

Hi Frank,

Yes, you are right - any mistake was due to me being human! My mistakes are all my own doing - AND - new syntax and new technologies do not take the 'human' out of the programmer ;-0) Sorry for being human. Sometimes I am proud of my mistakes.

You are also right about the test code - my defence is that I don't know how to do it - yet ;-0((

I keep missing your sessions at conferences. I must learn - talk to me in Cologne please.

Also, in my defence, the misestimate was in my 'development code' I shred with you Pearls guys, once I came to making a final and finished 'blue' screen module my error had been found and rectified. So possibly my 'lander' craft did hit the moon, after all !? 'Man' was that a landing!?

Anyway, I seem to remember late 70's and early 80's where programmers were always desperate to get their hands on the latest version release. Remember summer '87 ? Any good coder would do anything to get and use the very latest and most modern version of their preferred language. And these same guys also very soon learned "off by heart", the new extra commands and facilities in the new versions.

So when did this all change ? When did we all stop moving forward ?

The great thing about X# is that we can often use very different 'aged' technologies either alongside, or even 'hand-in-hand' with each other. So a couple of lines of LINQ code can happily be placed in standard For/Loop based (procedural) code.

We have so many working options and alternatives now in X# that we must not forget to develop our skills and keep on learning. Also much more sample code on the web is MVVM and LINQ based.

Anyway, we have a professional responsibility to our customers to keep 'up to date'. And keep their software solutions up to date. Or is this topic another 'BIG one' for later discussion ?

Best regards to one and all,
Phil.

Okay guys, Frank and Karl for starters,

I have already acknowledged my human side - people traits ! And said sorry ;-0)

However, I need to point out that the code I wrote to find, from the Assemblies, the Enums and their totals, was in fact old style coding, with 'Foreach' loops typed by me, and counts etc..

Now that you have challenged me to do things the LINQ and modern way, we can see a coded solution which looks quite different to my originally posted images.

Thanks to you Karl for making me get to grips with the Extension Method (EM) approach for this problem / solution. Check out the following - and notice that indeed we could have made it a 'one liner' :-
If you have forgotten how the other (original) code looked then here it is below, for comparison's sake :-
Frank, although I have not as yet applied the 'testing' approach, I think you may agree that this more descriptive syntax is less likely to allow me to make my human errors.

I have to say that I owe a "BIG THANKYOU" to Nick Friend for getting me to accept and use the Extension Method approach for LINQ style coding. At times it is not possible to use the more 'flowery' and artistic Microsoft 'query' syntax, stuff that looks familiar to SQL programmers. Its nice to have both available to us.

When EM's are used as in the code shown in the first image, we are really using the Functional Programming approach - where the output from one 'function' is used as input to the next one, and so on down the line, or chain of events. Start to finish, or top to bottom, is really a time direction, or sequence of events.

Because we are effectively doing functional coding, we can have multiple Select clauses represented. I have used three in this one query.

Remember that I am using L2O - LINQ to Objects, meaning the data is already in in-memory objects and collections.

The BIG benefit here is the 'SelectMany' EM, which allows us to 'flatten' the Assembly/Types structure, which then can be further processed and filtered etc..

I hope this interests a few guys who are not scared of those evangelists from Wales. We used to call such guys 'teachers' - in the old days.

Remember, you can now (with X#) mix this sort (style) of code up alongside the older stuff, so we can gradually introduce ourselves to the new technologies. We don't need to do any sort of a re-write but obviously some guys seem to like refactoring their code ;-0)

Also remember, 80% of our code needs clarity and not performance ! Does the 80/20 rule still apply ?

Best regards to one and all,
Phil.

Phil,

thanks for this.
One of the next things to do (for me) is writing the needed set of EM's for the DbServer class. Don't know how difficult this will be.

Long live DBF . I'm sure you disagree.

I see your FOR code does a little bit more than your LINQ code does. Some counting, calculating pertentages. I think it's unfair to compare functions that have different results.

I think the art of programming is like in all crafts: take the right tool. But than we need to learn the tools before we know which to use.

Frank