Comment Feed for Expert to Expert - Joe Duffy: Perspectives on Concurrent Programming and Parallelism (Going Deep on Channel 9)

Re: Re: Re: Joe Duffy: Perspectives on Concurrent Programming and Parallelism

Benjamin Tomkins — Mon, 23 Feb 2009 18:42:07 GMT

RE: “CIL *is* a representation of whatever you wrote but the translation is one way and the higher level information is lost”

I’m not entirely convinced that the metadata relating to the high level thinking/interpretation is even required to solve this kind of problem? (i.e. mapping serial/sequential code to an equivalent and more parallelized version). In some packages such as Simulink (Mathworks) and BlockBuilder for Simulink (Maplesoft) the model of the algorithm/application is analysed and algebraically simplified into a form that is far more efficient, but equivalent. As, at the low level, the entire application can ultimately be described as a system of equations, why would this abstract principle even require metadata to reform the solution? Only the basic procedural/functional subsets/partitions need be maintained.

In your example of a string of characters, even this can be considered a single value as is commonly used in databases and cryptography (see gmp mp bignum library applications for references). So on the base, all of this can simply be considered one large algebraic problem? Or do you disagree?

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Joe Duffy: Perspectives on Concurrent Programming and Parallelism

Jarle Stabell — Mon, 23 Feb 2009 16:49:06 GMT

Have you really tried "tasting" the syntax (ie worked with it for a couple of weeks)? If not, how can you know you do not like it? ;-)

Even though there are religious wars about syntax, I guess most people would adapt pretty easily to another syntax if they really were convinced there was a substantial benefit in using another language.
If our brains didn't adapt easily to weird syntaxes, we wouldn't have seen all those C-inspired syntaxes and Perl would have remained a sick fantasy inside only one man's brain. :)

Re: Re: Re: Joe Duffy: Perspectives on Concurrent Programming and Parallelism

Allan Lindqvist — Mon, 23 Feb 2009 00:19:02 GMT

sounds great charels :)
as ive said before (though in a far less eloquent manner than you) i truly belive that the concepts, the thinking, is where its at.

learning language x is in a sense a byproduct of learning the concepts behind x imo.. in a way the language is a means to express the concepts.
you can in some cases learn the language without grasping the concepts, but that makes you a lousy programmer :)

looking forward to that anders video and more conceptual goodness :)

Re: Re: Joe Duffy: Perspectives on Concurrent Programming and Parallelism

Charles — Sun, 22 Feb 2009 21:09:24 GMT

"It's as if the name activates a blocking system in the brain."

If an executing conceptual framework inside the brain is not able to understand certain incoming information, then it shouldn't block. :)

The message is simply ignored, asynchronously or sequentially (it doesn't really matter; not in terms of understanding a foreign concept), as expected; the reaction is involuntary, initially. Therefore, the ability for blocking to occur is there, but not highly probable(this is a human brain, after all).

As the language is learned so to is the understanding it realizes, sure. But nothing stops you from investigating a foreign concept directly, bypassing the requirement of mastering any of its associated higher level and formalized expressive abstractions (languages). In fact, this should be the default learning pattern: understand the concepts first (or concurrently, if you can), then language-level expression becomes an exercise in mastering language-specific patterns and syntax. In this sense, a programming language is really just a thin wrapper around a core conceptual framework.

It's rather hard to interpret or express that which you don't understand.

Hypothesis: You can think functionally and formally express side effects in a composable manner without programming in a functional language.

The expression of parallel intentions, for example, can be achieved in an imperative way, implicitly: the functional-ness is abstracted away by the tooling, e.g., Parallel Extensions for .NET, LINQ, Lamdas, TPL, CCR and the runtime (CLR) or in a functional way, explicitly (F#, Haskell, etc). In the latter case there is no indirection overhead, but if you've mastered an imperative toolset, then you should still be able to exploit functional concepts successfully in both a composable and side effectual way in the langauge you already "speak" fluently.

This is exactly what Anders, Joe, et al are thinking with respect to C# evolution and the various parallel .NET libraries in production and incubation.

I think Erik and I are going to pay a visit to Anders soon. Indeed, we'll dig into the thinking behind this thinking as part of a future episode of Expert to Expert. Sound good?

Keep on posting,
C

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Joe Duffy: Perspectives on Concurrent Programming and Parallelism

William Stacey — Sun, 22 Feb 2009 00:16:38 GMT

Specifically, I don't like the " <- ". I don't like loosing the "dot". I don't like lack of explicit statement terminator.

But this is all subjective. Some people love the Mona Lisa, other people see a dude with a wig on.

Re: Re: Re: Re: Re: Joe Duffy: Perspectives on Concurrent Programming and Parallelism

Allan Lindqvist — Sat, 21 Feb 2009 19:31:42 GMT

all im saying is that c# and .net is more general purpose given whats available today. and really, thats all that counts. if may be possible to write xbox games in haskell but as you say, it (along with alot of other things) its not supported. and if its not supported at least to some extent, it might as well be impossible im most buisness scenarios.

we differ in what we mean by general purpose. the examples you give, compileing to native and writing hardware are general purpose in a very formal way, but they are very specific applications and not sovething that you do very often as a regular programmer. what i mean is, given all programers, very few do what you describe.. you see, most programmers dont care if its the "language" or if its "api". if its possible with an api, its possible with the language. i know thats not formally correct, but thats the way people reason..
in that regard, haskell is less general purpose as it has a smaller api. it does have the potential to be more general purpose, but in practice it isnt.

you are right though. i dont know much about haskell. im sorry if you feel ive been putting word in your mouth, that was not my intent.

one thing you dont seem to realize however is that just because someone cant (or has the time) to prove to you that something is difficult, that doesnt mean it isnt difficult. no i dont care enough about winning a discussion at a forum to create a whole app proving some point about c# or haskell. but that doesnt mean that i or stacy or charels are lieing when we say we feel something is unintuative.
thats how we feel, theres nothing you can do about that :)

also, where are these awsome 3dshooters and webapps written in haskell? love to see some links :)

Re: Re: Re: Re: Re: Joe Duffy: Perspectives on Concurrent Programming and Parallelism

Allan Lindqvist — Sat, 21 Feb 2009 19:08:34 GMT

thats exactly the point im trying to make (all though i might not be so good at it)
diffrent tools are good for diffrent things, c# id good at alot of thing while say, haskell is really great for parallelization :)

another point you make that ive also tried to put forth is that the functional thinking is the real gold and that it can be applied across alsmost all languages, purely functional or not

Re: Re: Re: Joe Duffy: Perspectives on Concurrent Programming and Parallelism

Charles — Sat, 21 Feb 2009 04:07:36 GMT

This is why the functional programming model is so appealing from a parallelization point of view: the higher level meaning is not lost, but in plain site and reliably computable (surprise-free, with controlled(controllable) side effects). Determining how to split up code to run in parallel, for example, is explicitly expressed in the higher level thinking (expressed in code), therefore it can be accurately interpreted and recomposed in the compilation process.

C

Re: Re: Joe Duffy: Perspectives on Concurrent Programming and Parallelism

silverfrost — Fri, 20 Feb 2009 16:51:37 GMT

The simple answer is that when you get down to the CIL a lot of the context has been lost. It is true, of course, that the CIL *is* a representation of whatever you wrote but the translation is one way and the higher level information is lost. For example, this post could be read one letter at a time but without assembling the letters into words the content will be lost. It may be possible to get some speedup by examining the CIL, CPUs do that right now on the 'real' machine code by doing out-of-order and speculative execution.

Re: Joe Duffy: Perspectives on Concurrent Programming and Parallelism

Benjamin Tomkins — Fri, 20 Feb 2009 14:40:23 GMT

The one question:

" If all .net languages eventually compile down to CIL, then why not just focus on analysing the CIL code for parallel optimisations and then literally restructure the code on that common level? (rather than finding a common model for all high level paradigms) "

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Joe Duffy: Perspectives on Concurrent Programming and Parallelism

sylvan — Fri, 20 Feb 2009 08:21:28 GMT

Could explain specifically what about that snippet makes it hard to "think" about it? You're just saying kinda vaguely that you can't find yourself "thinking" in it, but I don't understand what specifically is posing a barrier to you.

The way I see it that snippet is, barring syntax, pretty much identical to what you would write in any imperative language to do GUIs. I could accept that you find it harder to use a certain style of programming, e.g. functional vs imperative, but you chose an entirely imperative snippet of Haskell! I don't even see the difference between this and C# other than the extremely superficial (different syntax).

You create objects imperatively.

You set properties (e.g. text) and event handlers (e.g. on command) on those objects.

How is this a different way to think about things than C#? I just don't understand what specifically you have an issue with.

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Joe Duffy: Perspectives on Concurrent Programming and Parallelism

William Stacey — Fri, 20 Feb 2009 01:35:08 GMT

I was careful not to say "ever". I just don't find myself "thinking" in it any time soon. I am not defending c#, nor am I dissing haskell. However, I have seen many times people say they can "think" in c# and it just rolls off the brain. I am in that crowd. I could think in c# after a couple days. This can not be down played as this ability (IMO) makes a language useable and popular more then anything else. If it is not approachable right away, it tends to favor a limited crowd - for right or wrong. I don't believe in absolutes or language realigions as I have used too many of them and seen them come and go (I admit I loved Cobol and RPG back in the day). They have to be very natural and readable. I would rather see more lines for clear intent, then a terse alternative any day. The "dot" in .Net is also lost here from what I can see, and that would be a big deal.

There is also an issue which you pointed out. All these 3rd party libriaries with limited or no support that come and go. That was same reason I finally left my beloved Perl. It turns into a treasure hunt all the time looking for and downloading libraries and extentions and patches and version mismatches, etc. That part could be fixed if MS made it a .net language however. I say, use what you like to write in. The syntax question however is OT to the larger issue of the right Model for concurrency. I think the truth lies somewhere between Erlang, CCR, Linq, and Agents (not Agent Smith) as I think Joe was leading to.

BTW. Anyone *here actually write a non-trivial Windows application written in Haskell and have a URL to sample? Would be interested in looking at it. How about Eric?

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Joe Duffy: Perspectives on Concurrent Programming and Parallelism

sylvan — Thu, 19 Feb 2009 23:53:02 GMT

Uh, I don't see what's so bad about that? This is pretty much what you'd write in any language. Is it just that the syntax is unfamiliar? That's a fairly shallow reason to dismiss something forever.

I really don't see how that sample is in any way more complicated than the equivalent C# code. You create a bunch of widgets, and set event handlers (specified inline here, but they could obviously be named and declared separately if they were larger), what's the problem, surely this is very familiar if you've used any imperative GUI toolkit?

Honestly I thought you were being sarcastic at first, poking fun at Charles by taking something that's very similar to standard imperative programming to illustrate how simple it is, but the rest of the post indicates you're not.

And yes, Haskell is statically typed (that's sort of the point), so auto-completion works fine. There is a mode for Haskell in visual studio, but sadly it's not maintained anymore...

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Joe Duffy: Perspectives on Concurrent Programming and Parallelism

William Stacey — Thu, 19 Feb 2009 23:28:04 GMT

I agree with that Charles. Take this Haskell/GUI sample from wikipedia:
gui :: IO ()
gui = do
f <- frame [ text := "Event Handling" ]
st <- staticText f [ text := "You haven\'t clicked the button yet." ]
b <- button f [ text := "Click me!"
                , on command := set st [ text := "You have clicked the button!" ]
                ]
set f [ layout := column 25 [ widget st, widget b ] ]

Ooo my...I don't see myself ever being comfortable mentally with that and being able to write (or read) my windows apps that way. Not saying it will never happen, but I just don't feel it (and I am pretty open minded). Moreover, would Intellisense be able to work with this?

I am interested to hear more thoughts on linear types and more thoughts on types that could have attributes to dictate concurrency behaviors and useage rights (i.e. read only, read/write, reads for these callers, etc.) with compiler enforcement.

I have to watch this show again. Good show guys.

A random related side: My 4-way 2.66GHz HP is noticiably slower then my 2-way 3GHz HP in the Vista look and feel category. I know there is many factors. But more cores is not really helping the user UI experience more then faster cores in my experience (from the clock on the wall). This is because the "user" things are bound by the UI loop (including the shell). So we can not forget about the "fast" path while reasearching many-core solutions. Hardware and software vendors still need to push each core and not think adding cores is the ultimate solution to the problem.

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Joe Duffy: Perspectives on Concurrent Programming and Parallelism

sylvan — Thu, 19 Feb 2009 22:52:44 GMT

I think we should give people more credit. Most people probably didn't understand basic algebra before they were taught it either. I really don't think Haskell is that big of a deal compared to something like OOP with all the nuances it has. It's just that it doesn't share too much with OOP so it's not as easy to learn as "yet another OOP language", but if you think in terms of the overall effort to go from zero to OOP or zero to Haskell, I'd probably expect Haskell to win.

I was a TA at university teaching Haskell, and people seemed to have a much harder time picking up Java than Haskell if they didn't already know any programming at all (and initially, people who hadn't programmed at all did better than people who had - they just had less baggage - but after a few weeks the experienced students did start to find ways of reusing existing knowledge).

It's a challenge yes, but like I said earlier it's mostly marketing. You need to convince people to make the effort, and help them once they're convinced. But I don't really see it as that big of a problem.

Re: Re: Re: Re: Re: Re: Re: Re: Re: Joe Duffy: Perspectives on Concurrent Programming and Parallelism

Charles — Thu, 19 Feb 2009 22:00:45 GMT

Indeed. What I meant was Haskell (thinking in the Haskell way, more so than the syntax of the Haskell language) won't scale in the sense that gp programmers won't be able, en masse, to make the concpetual switch in a reasonable amount of time. For some gp developers, the shift in thinking is just too high of a bar (and in some cases, unnecessary). How many gp developers out there understand what a monad is? Most developers (by most I mean greater than 50%) do not think monadically, not explicitly, anyway. Most gp developers (at least on our platform) are also not functional thinkers (functional in the functional programming sense).

This is a hard problem that requires changes in several layers of the software stack, including thinking. Someday, perhaps we'll have a new language, let's call it Nirvana (remember that SPJ brief interview? Note where "Nirvana" lives on the Useful vs Safe (where safe-ness is measured in how side-effectual the language is -> unsafe = very side-effectual, safe = not side effectual...) graph), that can be all things to all scenarios (probably by virtue of its native support for EDSLs and it's highly generic runtime). Who knows.

C

Re: Re: Re: Re: Re: Re: Re: Re: Joe Duffy: Perspectives on Concurrent Programming and Parallelism

sylvan — Thu, 19 Feb 2009 21:09:27 GMT

Okay, I guess I my recollection confused that with the statement later where you said that it "doesn't scale" (49:40). Mea culpa. Anyway, that's unsupported too. At the end of the day you could always choose to write 100% of your code in the IO monad at which point you're no worse (or better) off than an "effects-everywhere" language like C#.

Re: Re: Re: Re: Re: Re: Re: Joe Duffy: Perspectives on Concurrent Programming and Parallelism

Charles — Thu, 19 Feb 2009 20:59:32 GMT

I asked Erik "Is Haskell really general purpose?". He then responded as one would expect a high priest of the lamda calculus to respond :)

I didn't say "Haskell is not general purpose." There is a difference between asking a question and stating a position.

I think you're right about a language that supports EDSLs. That's something we talked about in conversation with Anders at JAOO 2008.
C

Re: Re: Re: Re: Re: Re: Joe Duffy: Perspectives on Concurrent Programming and Parallelism

sylvan — Thu, 19 Feb 2009 20:51:52 GMT

Pretty sure you said explicitly that it wasn't general purpose in the video, at which point Eric protested wildly.

Haskell was designed from the start to be general purpose, it even says so in the original documents from the early meetings. It was never intended to be some sort of domain-specific language. Indeed people are doing everything from designing hardware, to writing operating systems, to file systems, to 3D shooters, and web applications in it.

One thing that should be pointed out here, is that the need for multiple languages is reduced if your main language is good at supporting EDSLs (Embedded Domain Specific Language). Haskell (and e.g. F#) does this via monads, other languages do it via e.g. macros, and it's very common to deal with half a dozen of them in any given app (in fact, doing IO itself can be seen as an EDSL, but things like STM, Parsers, non-determinism, dealing with XML, etc. are common too). That doesn't mean you will never need another language, just that it's less common. For example, Haskell people still generally use SQL, even though there are Database EDSLs in Haskell (similar to LINQ-to-SQL).

Re: Re: Re: Re: Re: Joe Duffy: Perspectives on Concurrent Programming and Parallelism

Charles — Thu, 19 Feb 2009 20:37:10 GMT

To be clear, I never said that Haskell is not general purpose. I did imply that it is NOT as general purpose as C#. And I think I'm right here. C# is designed to support a huge number of scenarios. Haskell was not designed to. I don't think even the Haskell creators would say that Haskell is as general purpose in nature as something like C#. But this is all moot. The issue is whether or not C# should become a one-size-fits-all GPL or if .NET is used the way it was intended from the very beginning: use the right tool for the job. As long as the tool is supported (CLI compliant), then it will work in the .NET world.

I mean, would it make sense to write entire applications in a DSL like Maestro? Of course not. You would build the parts of the system that are not parallelizable (they don't need to be.....) in the tool you are comfortable with (C#) and use other tools (like Maestro, for example, or F#) to solve specific problems (like breaking a complex data computation into pieces and running them in parallel).

I love this type of discourse and I do not claim that my opinions are any more than my opinions (and they can change based on conversational data).

Keep on posting,
C

Re: Re: Re: Re: Joe Duffy: Perspectives on Concurrent Programming and Parallelism

sylvan — Thu, 19 Feb 2009 19:41:36 GMT

I didn't ask Eric or Joe because they didn't make the claims you did.

Re: the compilation issue, I was talking about the whole compilation not just the compilation to IL - C# is jitted, so you can't compile it off line and statically link it to any random .o file you have. Bartok could do that, but in general that's a no go so far. This makes Haskell a lot easier to use in a lot of scenarios. For example, embedded software, or just general applications really (no need to distribute the .Net framework).

"Writing hardware" doesn't mean "writing to hardware", it means writing actual hardware - i.e. desigining hardware circuits. See Lava for one Haskell library doing this, or VHDL and Verilog for domain specific languages for it.

Haskell has a Data.Dynamic, which allows you to deal with dynamic data similar to how C# 4.0 does: it gives you a static type of "Dynamic" for values which have no known static type. It doesn't have any syntactic sugar for it like C# 4.0 does, but it doesn't need it to the same extent - see Parsec for an example of parser combinators in Haskell, the parser looks like you're just reading dynamic data and spitting out statically type counterparts. So the ability to write EDSLs really removes a lot of the need to deal with dynamic types at runtime. This doesn't work in every single case, clearly, but the point is that EDSLs can be used to deal with dynamic data in a way where the details of actually looking things up is hidden (sort of like how C# 4.0 has that interface you implement for method lookup).

Strictly speaking Haskell can do anything C can do, as it's natively compiled (and even has a C backend on most compilers). You could definitely get it working on the Xbox 360 for example (I've been meaning to try to do that as I have an Xbox 360 devkit at work). It's not supported (i.e. a ready solution supplied by MS), but that's precisely what I'm arguing for so not really relevant - the point is that none of those things you mention pose any real problems for the language. On the flip side, writing an elegant EDSL in C# is practically impossible (this situation is not the same for F# though, which has Monads now).

The point isn't to compare libraries (though you could use them as an example of something). I'm arguing precisely that MS needs to have a pure language with similar support, including libraries. The point is to compare how well the language itself does with a specific problem.

As long as you have a C API to something (e.g. multi-touch API), getting it working in Haskell is probably easier than in C# (the foreign function interface is a lot nicer in Haskell IMO).

Oh and being pure doesn't restrict what optimizations you can make, because you can choose to have local mutable state, or just bail out and do stuff in the IO monad, if you really need those optimizations. You're just forced to specify up front where this happens.

Not being pure does restrict optimizations though, since many optimizations fail in the presence of mutable state. For example, merely writing to a pointer can cause a massive hit if the compiler isn't able to statically prove that none of the other pointers in scope doesn't alias the memory you just wrote too - if it's not able to do that, which in general it won't, then it needs to reload any data read from those pointers since the data held in registers may be stale. This is a simple example, there are lots of others. Take a look at the fusion/flattening transformations in DPH for example, they're absolutely crucial to make nested data parallel computations tractable, and they totally rely on the code being pure.

I've never said Haskell is perfect, I'm saying it's better than C# in a lot of ways, and one important way is concurrency and parallelism. This discussion is being sidetracked from that, though, because I just feel it's important to refute some incorrect statements made by you and Charles claiming, on no evidence, that Haskell somehow isn't general purpose. It is.

If I thought Haskell was perfect I wouldn't be advocating someone create a competitor to it now would I? I'm precisely saying that someone with pull needs to take the good bits from Haskell, and all the lessons learnt, and produce a new purely functional language and then sell it like no language has been sold before. I can give you list of things I feel need to be looked at, if you're really interested (could you?).

I've never claimed that Haskell (nor any language) solves every problem, please don't put words in my mouth. And drop the ad-hominems too. Accusing me of being "religious" when you're the one who's arguing against a language you don't even know is a bit much.

Bringing up popularity is not very convincing, IMO. Popularity is a function of a whole bunch of other things, language merit is a tiny part of it. It's mostly historical accidents (people don't use C because they think language research hasn't improved in the last 40 years - there are other factors that dominate).

Charles, concurrency and parallelism may have been domain specific challenges five years ago. I'd argue that we're already past that point, and it'll only get worse - concurrency and parallelism are general challenges that will need to be adressed in any language claiming to be general purpose. C# is certainly making strides towards that, and I've already said that this is good stuff - certainly better than not doing anything, I just think there should be a "fully backed" MS alternative for those who are ready to accept the challenges of 5-10 years from now today.

Re: Re: Re: Re: Joe Duffy: Perspectives on Concurrent Programming and Parallelism

Charles — Thu, 19 Feb 2009 18:29:58 GMT

C# is a general purpose programming language (very general purpose). Concurrency and parallelism represent specifc domain challenges. I don't think that we should expect developers to compose systems using only one tool. That seems rather strange, no? If you want to write software that calculates non-linear differential equations as part of solving complex problems of fluid dynamics, well, you probably want to use a tool that a) efficiently and effectively enables you to do so without compromising speed and accuracy and b) you want your highly parallelized system to scale out. You don't use a general purpose language confined to a single very large runtime + library environment...

I think the question here (like we discussed in this interview) is:

Does Microsoft create a new general purpose language and runtime that specifically addresses the concurreny problem while providing engineers with high level abstractions that make programming parallel systems easy, effective, safe and scalable?

Haskell is not the panacea as Joe and even Erik have said (and so has Simon Peyton Jones).

In the end, general purpose programmers who have evolved in this imperative, sequential world must learn to think differently, first and foremost. Getting your minds around completely foreign concepts is a great approach to this. I think it's time for a series of conversations and tutorials on Channel 9 based on the theme of Expand Your Mind. First up: Functional Thinking. Stay tuned.

C

Re: Re: Re: Joe Duffy: Perspectives on Concurrent Programming and Parallelism

Allan Lindqvist — Thu, 19 Feb 2009 13:48:18 GMT

sure, though i gotta wonder why you dont choose to ask joe or eric that question..
its not great for anything where the static type of something you need to talk to isnt known.
beeing completly pure also restricts what kind of optimizations you can make. all those guarantees about isolation just does not come for free.
basicaly every arguments that is used against the static:ness of c# is even more applicable to haskell

you can use c#/.net to write
web apps,
ria apps,
desktop apps,
xbox games,
mobile apps and
embedded apps
all without having to write your own runtime and without using obscure 3rd party libraries. is that true for haskell?

its interesting that you ask me to "compare the amount of work required to get it running" because that doesnt seem to be a requirement for you.. just how much work would it be to create a graphically rich, multi touch application in haskell? id image you'd have to re-invent a whole bunch of things already present in c#/.net

"C# can't easily be compiled" not sure what you're talking about.. the c# compiler is included in the framework but surely you must know that
"Can you generate x86 assembly on the fly into a buffer and then jump into it and start executing in C#?" well, c# is jitted so no. but you can generate IL with AssemblyBuilder/Reflection.Emit. however i dont see that as a very general purpose or command thing to do
"Can you use C# to write hardware?" yes? pinvoke/CreateFile?
"How about reactive animation?" from what i understand, that pretty much what depedency properties do

im not saying it doesnt matter what language we use. im saying that language is not the most important thing, the understanding of the concept is. you seem to think that if we all used haskell, everything would just work, and thats not true.
no language will let you escape the need to understand the problem and if you do understand the problem you truly can implement it in almost any language (even assembler). its just a matter of preference what language you actually use.

the debate between static/dynamic has been going on for what? 40-50 years? knowing that i dont understand how anyone can think there is a simple solution that will just work in any situation.. thats just religion..

the cold hard fact is that haskell is a minority langunage. if it was sooo great, sooo easy to learn, soo general purpose, soo free from problems, it would be more widely used. its not, so it isnt. blaming marketing is pretty lame because haskell has been around for ~20 years, and still hasnt become mainstream. thats not just a marketing problem..

im not married to c#. it has problems and can be made better. its not great for everything.
the fact that you cant admit that about haskell just makes you look silly, and worse than that, you're hindering the progress of haskell by not admitting its flaws..

Re: Re: Re: Joe Duffy: Perspectives on Concurrent Programming and Parallelism

silverfrost — Thu, 19 Feb 2009 11:28:21 GMT

Hi sylvan

I wasn't suggesting nothing is done or people do nothing. After all fully parallel applications have been possible for a long time (I have even written some). The problem is not 'can it be done' but 'how do we make it easier'. Your original point was that it would be better to teach people something new rather than (say) relying on C# to provide the necessary concurrency. Sure it would be good to teach programmers a new paradigm that really helps solve the concurrency issues -- I am just sure we have much idea as to what it is.

Re: Joe Duffy: Perspectives on Concurrent Programming and Parallelism

stevo_ — Wed, 18 Feb 2009 23:03:25 GMT

Why not have something new, not .NET, which is based on what was learnt from .NET, so an updated static type system (perhaps one that can better enable a ~dynamic lang), an intermediate language, native interop, GC.. but base it from functional immutability and native / .net interop.

Wasn't .NET a revolution? it seems to have done well, I don't think you need expect developers to give up their investment in .net code, just as .NET was harnessed and interoped with their native 'investments' (plus I bet companys would actually WANT to 'port' their code up for the advances it gives).

oh and get nullability right.. etc

But really, why not? it won't sell?