[dba-VS] C#, monads - must read - don't get mad with them while reading :)

[Salakhetdinov Shamil]

 Hi Gustav --

I meant *macro* assembler - it's an assembler with a very power preprocessor, especially IBM 360/370 macro assembler: a long ago one of the things I managed to write using this macro assembler was  a macro "mimicking" PL/I formatted output/print command/statement something like C#'s String.format(...) / Console.Writeline (...) - all in one one macro - while it's preprocessed into assembly language machine  commands calls/subroutine calls it can do very high level parsing of its operands/parameters - that should have been a second order monad I guess :) 

>  Monad should be though of for a more complicated scenarios
They mentioned simple

forach (....)

or

for (int i = 0; ...)

which could be also refactored/streamlined using monads: I'm reading "Monads, part three" ( http://ericlippert.com/2013/02/28/monads-part-three/ ) and I'm planning to continue reading this blogposts series - hope I will have something more to tell on the subject.

I have also a (currently) by-side but challenging project where I have already used LINQ expressions and predicates (https://www.simple-talk.com/dotnet/.net-framework/giving-clarity-to-linq-queries-by-extending-expressions/) and where LINQ expression trees will be also probably used. I cannot say I understand all these techniques in details but at least I have found how to apply them to a real life project one of my customers having been planned to implement for ten+ years for now - and nowadays their "dreams" should come true in a couple of months - thanks to LINQ. LINQ predicates and expression trees - and monads also I guess: without all these modern programming techniques the project would require a lot of custom programming if could have been done at all...

Thank you.

-- Shamil


>Thursday, July  9, 2015 4:46 PM UTC from Gustav Brock <gustav at cactus.dk>:
>
>Hi Shamil
>
>Uh, moving to assembly would be to exaggerate well beyond readability! I never did much in that area except for some small keyboard utilities programmed with Debug(?). I managed to get hold of the original Microsoft Assembly linker/compiler (in the plastic box with the manual) but I never used it.
>
>But, as you do, the author mentioned IEnumerable as a real-life example of a Monad, and that is a good example because how to live without that? So I think - to make sense - Monad should be though of for a more complicated scenarios - not very simple ones as in his tutorial.
>
>/gustav
>
>-----Oprindelig meddelelse-----
>Fra: dba-VS [mailto:dba-vs-bounces at databaseadvisors.com] På vegne af Salakhetdinov Shamil
>Sendt: 8. juli 2015 19:16
>Til: Development in Visual Studio
>Emne: Re: [dba-VS] C#, monads - must read - don't get mad with them while reading :)
>
> Hi Gustav --
>
>Well, then one should better use assembly language, shouldn't they? :) (I have programmed on IBM 360/370 and PDP 11 macro assemblers for more than ten years - I still think IBM 360/370 macro assembler is the best programming language I've ever used - all the system was in my control:) )
>
>Using "bloated" version wouldn't work, I suppose, if the parts of your "bloated" expression would return IEnumerable<T> and would use 
>
>yield return ...
>
>to return enumerable values as soon as they are becoming actual...
>
>So. it's time to get accustomed to use higher level programming concepts? - without them smooth scaling and (automatic) code execution parallelization wouldn't  work.
>
>-- Shamil
<<< skipped >>>
>