Tuomas Hietanen

• Immo Landwerth and Andrew Arnott: Inside Immutable Collections

  Apr 11, 2013 at 12:28 PM

  Sounds interesting... As this is very functional approach, I hope there will be also good interfaces to use these with F# (where the default list is already one-way linked list).

  Speaking of that, good posts of tree-traversal: Catamorphisms in F# (Part 1, 2, 3, 4, 5, 6, 7)

   

• What is a database, really?

  Aug 02, 2012 at 1:09 AM

  "Bind is the mother of all operators"...? How about fold (=aggregate)? Can you do bind with aggregate if your accumulator is type of M(v)?

  I'll try to explain here.

• LINQ, Take Two – Realizing the LINQ to Everything Dream

  Jul 31, 2012 at 12:33 AM

  What, now it is here!?

  Thanks! Downloading...

   

• Bart De Smet: Rx v2.0 Release Candidate - Time, Error Handling, Event Subscription

  Jul 16, 2012 at 7:05 AM

  Ok, thanks!  

• Bart De Smet: Rx v2.0 Release Candidate - Time, Error Handling, Event Subscription

  Jul 10, 2012 at 10:08 AM

  So... I'm using Silverlight (and Rx 1.0) and have this kind of code:

  IO<Result> res1 = GetWebserviceRequest();// (or/and FromEventPattern);
  var res2 = res1.MuchLinqHere();
  var res3 = res2.ObserveOnDispatcher();
  var res4 = res3.LessLinqHere();
  var d = res4.Subscribe { ... };
  

  The great thing about Rx is that it is much more efficient than normal events: "MuchLinqHere()" don't cause load to the UI thread. I'm happy with that.

  "LessLinqHere()" will cause load to UI thread as it is executed there, right? So... In this application there is a lot of code. I try to call ObserveOnDispatcher as late as possible.

  It has to be called before the code tries to make a side effect in Linq: e.g. access Application.Current... or UI.

  Now, are you saying in the video that in Rx2.0:

  1. The ObserveOnDispatcher() will happen automatically before "MuchLinqHere()"? Will I lose performance? 
  2. Or will it be called just before Subscribe? (Then will it still throw if there are side effects in Linq?)

• LINQ, Take Two – Realizing the LINQ to Everything Dream

  Jul 06, 2012 at 10:18 AM

  The slideset is very promising so I relly hope the video is somewhere.

   

• The Lambda Calculus, General Term Rewriting and Food Nutrition

  Jun 26, 2012 at 2:57 PM

  Erik: "You can parse HTML with regular expressions..."

  It turns out you can't: http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454 

  How about will Roslyn expose some of C# compiler internal TRs to public?

   

• Keynote - Martin Odersky: Reflection and Compilers

  Apr 25, 2012 at 2:31 PM

  Scala may be the best choice for JVM environment. It gives developers some functional concepts but is quite simple language still (for a Java developer). This was a great presentation. Also challenging audience.

  However, I didn't like the "Cake pattern". It reminds me of the C# partial classes: Try to be object-oriented (classes) but still break two basic design principles of OO:

  1. Single responsibility principle: Composition classes often have many responsibilities.

  2. Open Close Principle: Software entities like classes, modules and functions should be open for extension but closed for modifications. This means that the internal state and design of the entity should not be visible to outside.

• Going Deeper with Project Roslyn: Exposing the C# and VB compiler’s code analysis

  Apr 23, 2012 at 12:16 PM

  Too bad that Visual Basic and C# are overlapping languages. So there is double work with no real gain.

  Hopefully interfaces and API:s are open and well documented, so future (community projects?) could add support for languages like Javascript and F#.

• Lang.NEXT 2012 Expert Panel: Web and Cloud Programming (and more)

  Apr 21, 2012 at 1:46 PM

  Yes interesting...

  Apr 10, 2012 at 5:26 PM

  It's very strange that this panel didn't mentioned F# at all.
  

  I agree. In F# you can write same kind of code inside and outside a monad (="computational expression") where e.g. in C# you have to move from old imperative ("normal") code to LINQ-syntax.

   

See more comments…