nephesh

I'm sure productivity skyrocketed /s

> Generics would not make the function signatures shorter. You would have to introduce yet another concept: type inference for the signatures of anonymous functions

Yes, I should have said type inference obviously. I can't think of a decent functional language that doesn't have type inference though.

> No, it will not be less efficient. It's all done within one loop, in-place. You can compose everything inside the body of the loop. A functional language would do the same if it's intelligent.

If it's all done in one loop then it isn't composing. It's writing custom code every time you need to do something.

> You can easily create an infinite data source in Go with the generator pattern:

That's nice, you only need to change all of your code to do so. The functional version doesn't have that problem.

> With a more complex type (I don't see how this would affect one more than the other)

It does because the discussion is about generics. The fact that you're writing out types for one and not the other makes your comparisons a bit disingenuous, though I understand if Go isn't very good at functional programming.

b) Composing various operations. Composing filter + map:

As you keep building them up the imperative style will have more code overhead and less efficiency.

> c) Swapping the container type is just a matter of swapping "_, n := range numbers".

This isn't true since the functional one could easily swap out to use an infinite data source whereas the imperative will be constrained to the arrays you're already using.

Now try it on a more complex type. Then try and compose various operations. Then swap out the container type.

With this standard for "essential" you may as well just drop down into assembly language.

The only added simplicity here is for the compiler writers, not the end users.

Yeah, it basically makes the answer to the original question an emphatic "No".

Not to disagree, but this type of scenario has become much easier to deal with using iframe's and postMessage (https://developer.mozilla.org/en/DOM/window.postMessage). You can basically setup a client script that is embedded as the widget and some javascript inside your iframe to talk between each other. Just thought I'd throw out another option for those that are looking for one.

Yup, I even wrote a framework to convert F# to javascript which allowed me to create a new (really powerful) validation provider for MVC. Sadly I haven't had a real world project that fit it well, so it's kind of gone by the wayside.

It's fairly straight forward to use with MVC, though it's less than ideal. You basically need to have a C# MVC project that referneces your F# projects (these would contain your controllers etc.)

As someone who has been learning Haskell recently I think I can bring up a point that no one else has. Record syntax in Haskell sucks. Most business programming revolves around a form of DDD, where each of your business entities are fairly well defined. Creating records that match these business entities is fairly simple, working with them is not. None of the web frameworks I've seen follow a model based approach where you bind directly to your form representation of a model. I've been trying to figure out a way to do this in Haskell, but it looks like I have to learn Template Haskell and Generics on top of the already steep learning curve of Haskell, for something that would be simple in almost any other language. So far I haven't given up, but I don't see mainstream programmers getting into Haskell until they can describe their processes in a model focused fashion (and no, I don't mean with OOP).