John Sheehan: Architecture and Engineering of Microsoft Application Virtualization…

Niiiiiiiiiiiiiiiiiiiice! Thanks guys.
Joe has a point: Haskell only looks complicated. Probably if the language would look more like C/C++, C# or JAVA people would probably use it more and not get scared simply by checking it out. The stuff often is only named in a way that people get scared.
I have already had a similar experience with trying to explain Lambda Expressions in C#. They are not that complicated to get but people are scared when you tell them the term "Lambda Expression(s)". It's as if the name activates a blocking system in the brain.
great, great interview as always.. i dont want to take a break at all
it touches on alot of things ive been burning cycles in my puny brain on..
the pull between more static and more dynamic, both are beeing called "the solution" but they pull in so diffrent directions and c# is in the middle..
i think what anders said at pdc and other times is so very true. there is no one correct model. sometimes we need to be dynamic, sometimes we want o be really static.. there just isnt a single solution, a single model. so should we accept this and try making
using diffrent models easier or should we make it more difficult
i know you dont agree sylvan but i think its better to get 80%-90% there and get high adoption that to get 100% and make 99% of programmers relearn 99% of what they know we cant just ignore the people.. that is unfortunate
banans must be one of the more paralell fruits btw..
its time, not marketing that stopping joe programmer from learning from learning something radically diffrent.. marketing may help convince people to spend that time, but in a lot of cases its just not possible.. if the boss man tells you that he wants the
serverapp back up you cannot tell him/her that you gotta go relearn a large portion of your programming skills first yes i know thats an extreme example but time is always an issue in industrial programming
Adding things to c# will make it more complex, this is true. but when its "too" complex is a subjective thing. when c# does become "too" complex for someone, that person will move to another language (hopefully still .net) if c# becomes more complicated
than haskell for newbies, arent the newbies free to use haskell?
My point is that you already do have a language that is pure from the start, haskell, so why not use that if thats what you prefer.. perhaps the best thing would be to have a haskell compiler for the clr (with its own pure bcl). also, theres
f#, its a lot more pure than c# and its beeing added as first class language, isnt that sort of what your calling out for?
the lines of programming is pretty blurry, sometimes you need some purity and sometimes you really need to be dynamic, c#4, as a true general purpose language (i dont agree with eric that haskell is GP, not in practice anyway), tries to find a middle road.
its not optimal for dynamic programming and its not optimal for pure functional programming, if you want more dynamic/more pure, use a diffrent language
i dont think there can be one language that pleases everyone and trying to force people to do this or that just doesnt work. they have to come willingliy.. i think exposing people to functual constructs through c#4 will entice them to try purer languages like
f# or haskell where its applicable and that cant be bad right?
I'm glad you enjoyed the discussion.
I'm reading over all of your comments, and I see many great points being made.
One that I'd like to deposit for your consideration. Haskell is an ideal language _in certain contexts_. For some people, those contexts are important enough to learn an entirely new language. Highly parallel programs may be one such context, where the safety moving wholesale to Haskell brings is worth the cost of switching. Even if that were true, _most_ .NET developers are not currently salivating for parallelism. In 5 years? Maybe. But not today. So as a broad blanket statement, it is safe to say that the perceived cost of switching to Haskell is far higher than the perceived benefit for the bulk of the development community. This is why an incemental, move-select-parts-of-your-program-over-to-the-safe-world-piecemeal, strategy is so attractive.
In addition to that, I mentioned in the video that Haskell is not a panacea. It has many interesting ideas, but some that I consider to be debatable for the .NET community at large. Algebraic data types mixed with structural pattern matching -- with type classes for polymorphism -- are useful for a certain class of programming, but telling a whole community of object-oriented developers to switch overnight will not only result in religious clashes, but is probably just plain wrong anyway. There is a plethora of shared knowledge (e.g., in patterns -- see GoF), collateral (books, articles, training), and frameworks that Windows developers rely on each day, which are strongly tied to the C++-family of languages. Moreover, I don't believe vanilla Haskell (98) has solved _all_ of the problems associated with composition of separate agents that are performing I/O. The "one top-level I/O loop" style of programming doesn't scale beyond one coarse-grained agent. For that, something more like Occam or Erlang is neeeded, and this is crucial to address in order to enable composition of fine-grain with coarse-grain concurrency.
Food for thought, I hope.
Best Regards,
---joe
haskell might be great for paralellism but like joe said, its not great for everything. c# is really good for a very wide amout of stuff and i think that means more to most general purpose programmers that excelence in a perticular area
As far as new language goes.. well.. yeah a better language is always great, but i think its easy to over state the importance of languages and understate the importance of philosophies and understanding of what one is doing.. alot of these problems really
transcends computing in my view the world is massibly paralell after all.
what i mean is that its prefectly possible to create perfectly pure-no-side-effects applications in any language, its the philosophy thats the core. no language will allways produce perfectly scalabe programs. we must not forget that we, the humans, are the
ones who wants to express something and the language is just a means (all be it, an important one) to do that
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
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
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.
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