Comments

I think I get what reddit is saying, but I have the advantage of working with haskell many moons ago and therefore the concepts are not new to me. The reason I can sympathise is that even though I can read Erik's homework questions and immediatly know the answers, when I watch through the explaination, I immediately think of what scenario it could apply to. So with the zip function, I couldn't think of a use of converting two lists to a list of tupples, as data is never that precise to make a perfect match. (maybe to many outer joins in SQL dealing with fuzzy logic) So with all that said, I think it could possibly help a subset of us, if Erik could also include some quick examples of application of a function or two to assist in the learning process. I think that is what reddit was alluding to with the small game comment.

 

Maybe it's just me, but I've programmed in so many languages now, that comparing one to another to help learn the new one become information overload and I tune out. By seeing something in it's own right, rather than a reflection of something else, I find it easier to invent new things using it. eg. I wrote recursion in C for my first assignment. Not because I understood what recurrsion was, but that it looked like the simpliest and least amount of code way of solving the problem; and especially as it didn't core dump like my previous attempts.

I'm running WinXP SP3 on a custom build machine SL3 and also get no sound.

 

Changing path for a second to something totally unrelated, how is the message date/time calculated as it isn't time zoned but it's also not far from the actual local time here.

No sound here either. XP SP3 using SL3 and the download has no sound as well on WMP 11.

Why does file access performance suffer the deeper it is in a path? eg. \path\file is quicker than \\share\path\path\path\path\path\file

 

Especially after the first time the file was accessed. Caching anyone?

 

ps. this is also why I don't really like the breadcrumb style history concept. You can't fully break down directory structures.

Brownie: I understand that the above comments appear to only be whinging about having to roll up the sleves and do some work but... (there's always a but) you're missing the point entirely. Actually you're missing two points.

The first is that in regards to WPF and Winforms, it's just the GUI. Why does one need to take three times longer to display an invoice in WFP compared to Winforms? I'm not just talking about the time to press key strokes and work around the IDE, but the time for the IDE load times and application runtine as well. There seems to be the old saying with every new technology the core is worked out (eg. MSBuild over Visual Studio compiling, some apps won't even compile in VS) "What Intel givith, Microsoft takes away".

The second is about productivity, my time as a developer should be spent on bringing the business solution to the computer. Not fussing over the tools. That's where my value is over offshore developers. It's all about getting the system they want to make money for them as quickly as possible. It doesn't matter what language or tool, C++, C# or even assembly, just matters that what they need to get their job done as efficient as possible. As developers we are *only* the enablers of that, not like the medical overlords that the business and everyday folk must come begging to.

Notes: I also agree that declarative nature, the self organising layout and the bindings functionality in WFP is a fantastic idea, just not "productive" IDE experience at the moment. I also think declarative programing is also the future with going back to the true maths and linear data types, but that's another discussion. Shared state and variables, so 1970's...

I would like to add my bit on the productivity comments in the video. From the comments above Scott makes a terrific point about the new tools being great until you find out that there is a show stopper in that they were not designed to do some aspect. I’ve seen that with WPF which is why we haven’t touched it in any serious way. The second point he made about productivity being the amount of work done with the fewest key strokes is totally off base. WPF again is the perfect example for this. It is so different and unfamiliar to WinForms that the less key strokes makes it much worse in productivity as your trying to guess where you need to type next? XAML, C#/VB code, maybe throw some XML or HTML and see if that helps. The boss wants to know why we need to buy Blend to make the invoicing part look good?

 Without getting off topic too much this also shows up in the treatment of certification. The most bizarre example is having being reduced to “hey, just print your certificate on your dot matrix printer. Employers will love that as it’ll save us a tonne of money! (cough, green environment something…)” So you have MCPD? That’s nice. There are so many parts and framework versions in that certification that you will be of no use to us as we need someone more generic/broad range skills. Can you actually just program WinForms?

 But really, if Microsoft wants us to use and take up these new technologies, then it needs to have code generators. Don’t reduce the number of key strokes, make tools that create the code templates which can be modified. An example of this is the Team Test system. Let it record what you want it to do and then have it spit out the code to make it happen. For the comment above about Excel, I actually find the VBA code spitter quite useful. It’s like the mini-intellisense for VBA. Without intellisense in Visual Studio, I’d spend 2/3 of my day crawling the framework doco looking for libraries that I could possibly use, then find out I can’t and then go and buy a third party component. That's an extreme point, but still mostly true due to another subscription upgrade just paid for.

 For that part in the video about old days, don’t forget how many applications got built in DOS Basic with it’s very limit command set… I can tell you some were not simple indeed, but quick in getting them done. Productive? There were fewer key stokes there as well. So by Scott's definition, yes.

First up, great video! (except for the sound clipping) Please keep on chasing them more on this subject. Plus I'm curious about seeing a video on the the testing lab mentioned.

Unlike t.man above, we are more aligned towards Business Intelligence and Line of Business work, so we only need the power this provides in bursts, so the .Net works well enough for us. If anyone is interested in a side thought what I would like in the parallel/concurrency model is more of a hardware/software combination of hardware "turbo" mode and software linear types. The hardware would be great if we could have a large capactior design which could push huge juice for very small amount of time to process the complex calculations and the rest of the time sit cooling down doing nothing but waiting for user input or report printing. The software, while I can see some benefit of the functional world, teams are expense to run where you need the multi-syntax model (eg. t.man's C/C++/MASM or functional/iterative) skills, so we would prefer to stay with .Net but "remove/isolate" "shared state/variables" slowly with linear types. ie. Bring back true maths to software development. Basically the ability to be able to code at times how to do things and other times just declare parrallel without shared state. This is why LINQ is great. We can do some setup code, tell LINQ to filter/process it and pull the result apart to get the desired information is great.

Anyway, keep up the hard questions Charles, as it's good to see the body language of the tool makers in response.

Thanks for that viellevigne, it was very interesting. It leads me to think why we could not have inline Haskell or F#?

Real World Haskell

cdwatkins: I also was thinking about the NULLable type in alternative for the Maybe monad, except that it doesn't contain the exception information for why it failed.

Back to a more line of business view of things, Eric talks a lot about Haskell from the "everything functional" point of view, but where do you draw the line in the sand on what to use in the real ".Net" world; F# or Haskell? Especially as Haskell has the .Net libraries.

I like what Matthew said about all a programmer really wants to do is a put/get and have the syntactic sugar handle the boiler plate coding for the processing of the exception. Even with Haskell (while I've not touched it since for some time) I haven't see how easy it is to process exceptions. It appears that it's designed for a perfect world that doesn't have exceptions. Is that really the case?