Matthew Podwysocki - All Comments

Reflective Perspective - Chris Alcock » The Morning Brew #95

Reflective Perspective - Chris Alcock » The Morning Brew #95 — Fri, 16 May 2008 07:21:17 GMT

Pingback from Reflective Perspective - Chris Alcock » The Morning Brew #95

Concurrency with MPI in .NET

Matthew Podwysocki — Thu, 15 May 2008 20:06:43 GMT

In my previous post , I looked at some of the options we have for concurrency programming in .NET applications

re: let Matt = CodeBetter + 1

Matthew.Podwysocki — Thu, 15 May 2008 18:53:53 GMT

Thanks everyone! Glad to be here and I hope that you find some of these things interesting and help you indeed "Code Better"

Matt

re: Thinking in Concurrently in .NET

Matthew.Podwysocki — Thu, 15 May 2008 18:00:59 GMT

@Mike

I agree that in order to solve a lot of the concurrency issues we're facing, we need to get out of the sequential programming mindset and more into the message passing and message oriented architectures. Erlang does that right by thinking about such topics first, whereas most other frameworks bolted these things on. I've briefly looked at RetLang just a little bit, but it does look interesting. The other things such as PureMPI.NET and others tackle it from the MPI angle which I also find interesting, if you're so inclined to look at those scenarios as well. Although a name like Retlang is a little deceiving because it's a framework and not a language :-)

Matt

Concurrency with MPI in .NET

Matthew Podwysocki — Thu, 15 May 2008 17:52:41 GMT

In my previous post , I looked at some of the options we have for concurrency programming in .NET applications

I Love SPEC# « .Net Braindrops

I Love SPEC# « .Net Braindrops — Thu, 15 May 2008 08:15:02 GMT

Pingback from I Love SPEC# « .Net Braindrops

re: Thinking in Concurrently in .NET

Mike Rettig — Thu, 15 May 2008 01:37:50 GMT

IMO, message based concurrency is the answer. There are many open source and commercial solutions for distributed messaging, but there aren't many that attempt to address the complexities of in process concurrency. Retlang is designed specifically for in process, message based concurrency.

Mike Rettig

Retlang Developer

Thinking in Concurrently in .NET

DotNetKicks.com — Tue, 13 May 2008 21:53:12 GMT

You've been kicked (a good thing) - Trackback from DotNetKicks.com

Spec#: should we really wait for it? | The .Net frog

Spec#: should we really wait for it? | The .Net frog — Tue, 13 May 2008 18:10:59 GMT

Pingback from Spec#: should we really wait for it? | The .Net frog

Reflective Perspective - Chris Alcock » The Morning Brew #92

Reflective Perspective - Chris Alcock » The Morning Brew #92 — Tue, 13 May 2008 06:27:15 GMT

Pingback from Reflective Perspective - Chris Alcock » The Morning Brew #92

re: Thinking in Concurrently in .NET

Matthew.Podwysocki — Tue, 13 May 2008 05:25:34 GMT

At some point last year I looked at RetLang and thought it was pretty interesting and of course hadn't checked back with it. Yes, that's another approach as well as the CCR and a few others. I see that the message count has increased by quite a bit since I last saw it.

Matt

re: Thinking in Concurrently in .NET

shawn — Tue, 13 May 2008 04:56:44 GMT

You might also want to take a look at retlang - code.google.com/.../retlang

re: let Matt = CodeBetter + 1

gblock — Mon, 12 May 2008 05:17:14 GMT

Welcome aboard Matt! Good to have you join.

re: Your API Fails, Who is at Fault?

Matthew.Podwysocki — Fri, 09 May 2008 19:34:02 GMT

@Jared

It's debatable whether the Erlang approach is the right now. I think for high concurrency applications, having a watcher try to clean up afterwards is not a bad thing. The way that Erlang differs from many places is that they don't do defensive programming in layers that don't have direct human interaction, instead just letting the underlying system pick up the crash and try to clean up after itself. I can agree that it could be a bit more cryptic when you know darn well where it crashed, but those areas underneath should be able to compensate as well without the extra clutter.

Matt

re: Your API Fails, Who is at Fault?

Jared Parsons — Fri, 09 May 2008 15:46:47 GMT

I don't think the "let in crash" mentality is the correct approach. I prefer "make it crash". The problem with "let in crash" is just that, it's a passive approach to quality. The earlier you discover an unrecoverable error, the easier the bug will be to track down.

I'm perfectly ok with a CrashIfArgumentNull(someArg) approach. Getting a callstack in a bug report with a CrashIfArgumentNull high on the stack makes the investigation trivial. Getting a crash inside a big method is not nearly as easy.