Quote:Original post by ranakor

The reason i'm going for pure functional before F# and not the other way around is that i'm not interested in a transition to functional but in F# itself , i want to try out other paradigms and F# allows me to do it in .net wich is my field. I could go straight for F# but then i'll use it like C# , learning some form of functional language first will force me to work functional and then let me do that too whenever i'll use F#.

Cool. I do that too :)

If you are interested in F# itself then why dont you simply restrict yourself to the functional subset? The imperative mechanisms in the language are clunky and non obvious enough that you will likely not even have to discipline yourself to remain pure. You will prefer it.

The thing is that learning haskell and going to F# you will still end up having to relearn Alot. Time you would have saved by learning the basic concepts of functional languages [which are independent of all functional languages] in your target language itself while also getting used to your target paradigm. That way you get used to the F# way of doing things - which is fairly different from the haskell way.

Quote:Original post by ranakor
Hmmm how diferent would it be? Is it diferent in the logic or mostly syntactically? Also when you say i'd have to relearn a lot do you mean only to get to the F# way/logic or because of the .net framework? Because i'm already pretty proficient in C#/.net fx.

Haskell is a pure functional language, whereas F# is not. Because F# is a mixed paradigm language, the framework and the documentation skip over certain areas of functional programming. For instance, monads are vaguely supported in F#, but not really used. This is fine for a mixed paradigm language, since <whine>monads are haaaaard</whine> and breaking out of them to do things the procedural way is easier. That means, however, that you don't get the beneficial mind expansion of learning how stateful and effectful programming really works in a functional paradigm.

Haskell wasn't the first functional programming language I learned, and I'm not sure if it would have been as easy for me to learn if I hadn't already grokked the basics of FP using ML and Scheme. I think, though, that it was far and away the most useful of the three to learn. Learning Scheme made me better at thinking about code vs. data, though it wasn't a particularly deep lesson. Learning ML made me appreciate functional programming, Learning Haskell made me a better programmer, full stop.

One more thing: F# is an experimental language. Think of it as a .NET version of ML, as well as a proving ground for half-baked cool-sounding theoretical programming language features. This is a good thing if your objective is to play around, but it's not so great if you're just learning FP and are unable to separate the Right Way from the Strange But Cool New Way. I don't think F# would make a good first functional language, though I think it'd make a great (and actually useful) second or third.

A good IDE is nice and all, but it is a good skill to be able to fall back on a text editor and command line tools. With most editors, and a little bit of configuration, you can run whatever command line tools you want from within the editor.

Since you are on Windows, the best text editor for you would probably be Notepad++. I haven't used it as I develop on Linux, but I have heard great things about it. Here is a description of how to use run external tools from within the editor.

With a good text editor and a bit of work, you can have an effective IDE that you can use for whatever languages you want. I use Kate to edit C++, Python, Verilog, Scheme, Ocaml, HTML and LaTeX and can compile/run/view all of them with a single keystroke.

Quote:Original post by ranakor
Hmmm how diferent would it be? Is it diferent in the logic or mostly syntactically? Also when you say i'd have to relearn a lot do you mean only to get to the F# way/logic or because of the .net framework? Because i'm already pretty proficient in C#/.net fx.

I guess i could try to restrict myself & use F# but the issue is i don't know what the functional way is or where functional/imperative blend & where they are clear cut so i risk using a merge of both at times & missing out on "that other way to do things". Note that i posted here because i respect the members's opinion in here but , and i should have specified it before , this is nor specially for games: this is to learn as another everyday useage programming language (i want to be future proof so F# came next on my list now that i'm done learning linq/wpf/wcf to a reasonable level)

edit: Note that i own "Expert F#" from Apress , haven't opened it yet (bought it with a large batch of books a few monthes back) . Did you read that book per chance? If so is it pure functional oriented? Because if so i guess F# while sticking to what the books teaches would do too ... Had forgotten i had that lol.

I have that book :). And the other one Foundations of F#. Yes you will learn functional programming from going through it. In F# if you do not use "<-", ":=", "ref", or "mutable" then you are almost certainly not doing imperative programming. F# also uses immutable collections. This is the other aspect that is different from say C#.

Like Sneftel said Haskell will introduce you to things like higher order polymorphism, a reliance on algebraic types and pattern matching for arranging code and monads since they are a core part of the language (although there is nothing inherently functional oriented about them nor is their real benefit to do with packaging effects and state, what you will learn from them is do with flow, control, composition and domain specialization within a monad - this aspect is introduced in a friendly manner in Expert F#). Although F# also is based around patterns, I have found that most of the things I know from Haskell only really apply in the core (e.g. functional programming and using composition to great effect). The way of thinking about how to organize code and the overlying concepts are different.

My suggestion would be Learn F# till you are comfortable. Expert F# really is an excellent book for that. Then Pick up Haskell to really learn everything at its purest (e.g. going to train with some shaolin monks) and when you want to make something useful (e.g. an environment with loads of libraries) then go back to F# :p. This is the fast track way. Learning haskell from scratch tends to be difficult because there are not many beginner friendly tutorials. Even Yet Another Haskell tutorial is dense for a complete beginner. I have not read this though.

Sneftel - F# is a stable language now in terms of features and is currently going official producterization. Monads are fully supported in F#. However things which require Type constructor polymorphism like Monad Transformers or even Monadic Combinators are not.

Quote:Original post by Daerax
Sneftel - F# is a stable language now in terms of features and is currently going official producterization.

Regardless, it still has plenty of half-baked features left over. "Official producterization" (?) sounds like they don't intend to do any further baking.

Quote:Monads are fully supported in F#. However things which require Type constructor polymorphism like Monad Transformers or even Monadic Combinators are not.

Monads are supported, but that's a lot different than monads being the normal way of performing sequence-structured computation. Monad transformers are more a type system doohickey than an essential functional programming tool, so their absence isn't a big problem, but the status of monads in F# is indicative of its functional impurity. Which is not to say it's a bad language, of course.

Quote:Original post by Sneftel
Regardless, it still has plenty of half-baked features left over. "Official producterization" (?) sounds like they don't intend to do any further baking.

I have this habit of using suffixes inappropriately.

Quote:Monads are supported, but that's a lot different than monads being the normal way of performing sequence-structured computation. Monad transformers are more a type system doohickey than an essential functional programming tool, so their absence isn't a big problem, but the status of monads in F# is indicative of its functional impurity. Which is not to say it's a bad language, of course.

F# is a multiparadigm language. Monadic programming is supported in the same sense that OOP is supported. Sequence structure computation is only a small part of what Monads are useful for, it is an unfortunate by product of having been introduced in a lazy pure language that this aspect gets so much press. Monad Transformers are not part of the type system, although they are only really possible in a richer type system than .NET provides. But you can achieve the same way in an untyped language (and even safely if the typing is done in a staged manner by presenting the library as a dsl when programming in a language which supports strong metaprogramming as I did). But they allow you to do better functional programming in that you can compose different monads and generalize your code better.

Finally monadic computation expressions/sequencing is a major part of the language. It is just done in such a straightforward manner that the user does not know they are using it, though they will recognize it if they were to learn see it in haskell.

Quote:Original post by Daerax
Sequence structure computation is only a small part of what Monads are useful for, it is an unfortunate by product of having been introduced in a lazy pure language that this aspect gets so much press.

It's unfortunate that IO is the only monad most people -- even Haskell programmers -- are familiar with. But sequenced computation is, well, pretty much the entire part of what monads are useful for. That's why one of the three main monad operators is the sequence operator. I probably should draw a more explicit distinction between sequenced computation and effectful computation, though.

Quote:Monadic Transformers are not part of the type system, although they are only really possible in a richer type system than .NET provides. But you can achieve the same way in an untyped language (and even safely if the typing is done in a staged manner by writing the library in a dsl using a language which supports strong metaprogramming as I did). But they allow you to do better functional programming in that you can compose different monads and generalize your code better.

That's what I mean. The power of Haskell's type system is far beyond virtually any other programming language out there, and as a result it can do things like monad transformers (almost) without blinking. In fact, though they are useful, I have a suspicion that their primary initial draw was as a compelling demo of Haskell's typing power. Nevertheless, I think monad transformers, in their current form, still have a lot of growing up to do. Even in Haskell their syntax can be a little atrocious, and writing your own involves seeing error messages that no man should ever see. (Dear God, when I close my eyes I can still see the nested foralls!) From that perspective, transformers are actually nicer in dynamically typed languages, where you don't have to find your way around those dusty little corners. (Disclaimer: that's based on very limited experience with transformers in dynamically typed languages.)

Quote:Original post by Sneftel
It's unfortunate that IO is the only monad most people -- even Haskell programmers -- are familiar with. But sequenced computation is, well, pretty much the entire part of what monads are useful for. That's why one of the three main monad operators is the sequence operator. I probably should draw a more explicit distinction between sequenced computation and effectful computation, though.

The sequence operator is kind of a misnomer it is more a throw away this computation operator, you can write it in terms of the bind and return functions. some monads can be commutative and there sequencing does not matter. Also see my above edit. sequenced computations within monads are a major part of F#. There they are called computation and sequence expressions and are introduced in a friendlier manner.

Quote:That's what I mean. The power of Haskell's type system is far beyond virtually any other programming language out there, and as a result it can do things like monad transformers (almost) without blinking. In fact, though they are useful, I have a suspicion that their primary initial draw was as a compelling demo of Haskell's typing power. Nevertheless, I think monad transformers, in their current form, still have a lot of growing up to do. Even in Haskell their syntax can be a little atrocious, and writing your own involves seeing error messages that no man should ever see. (Dear God, when I close my eyes I can still see the nested foralls!) From that perspective, transformers are actually nicer in dynamically typed languages, where you don't have to find your way around those dusty little corners. (Disclaimer: that's based on very limited experience with transformers in dynamically typed languages.)

But I only had to write the DSL once and now I can use it on all monads, within static type safety, as naturally as if it were built in.

Yeah haskell's type system is matched perhaps only by ML in a production language - if you consider modules from the perspective of type classes - and not as cleanly. But you are right sometimes a type system can be too helpful.

also i think you are right correct the compiler showcase - I think i read about it in one of wadler's papers.