Has anyone played with these yet?
I’m far more interested in P# because I would love to have a Prolog type back-end for some things.
Lambda calculus makes me feel small and impotent, so F# seems less intriguing, but it’s getting great reviews, and is very easy to see why it would be far less buggy than most other languages.
Charles
Haven’t tried any of these.
What I really like though is lambda expression in C# 3.0
You have the convenience of functionnal languages and yet you use still use OOP.
The problem with functional languages (F# among others) is that I can’t see how you could make a big project using only a functional languages. It seems great for small applications but just impractical when you have to design a huge program (although I’ve only tried Haskell so I can’t talk for every functinnal languages…)
Haven’t tried P# but I like Prolog. It certainly has its uses in several cases.
Regarding large projects in F#; I agree it’s hard to imagine how it would work. We (most of us) are so accustomed to the imperative or procedural mindset that it’s hard to see mapping large tasks as functional relationships.
The catch is, having said that, and then seeing small tasks expressed as functional relationships, and seeing how cleanly this avoids things like race-conditions and glitches in distributed environments, it’s easy to see how it’s highest value will be found in exactly those large distributed systems. I don’t know.
I’ve always liked set-theory solutions in SQL, and pushed newer programmers to seek out those type of solutions over procedural hacking, but never really considered how that would be applied to “normal” programming.
Which is why love prolog, or any unification type approach, because it allows small, sensible assumptions to be used to prove larger abstract goals.
.NET is all about elegance, in my mind, but does not represent a paradigm shift the way OOP did. In fact, Unity itself represents a sort of harbinger of the component driven model that I think will come to rival OOP in acceptance, but is still not the full qualitative shift that things like F#/P# advocate, even if their roots can traced back to age-old LISP and Prolog interpreters.
I am quite certain the imperative programming model will give way to something better in the next few years.
Charles
I don’t see how a component-driven model in any way excludes or replaces OOP? Or did I miss the point?
No, not at all, and I probably did not make my point clearly.
OOP and Component driven development are by no means preclusive and, in fact, one could argue they arise from the same goal; to make code modular, portable and re-usable.
Chronologically speaking though, I would say that savvy component driven development (e.g. Unity) is relatively new (compared to pure OOP), at least from the view point of “what are mainstream programmers doing now”.
For instance, I do not derive from CharacterController and add my own MouseLook functionality; nor do I bother with messy multiple inheritance. I just pin components on an object (CharacterController, Mouselook, etc) until I get the desired final functionality.
Perhaps I’m showing my age to consider this a paradigm shift, and you could argue it’s just a natural and common sense use of objects, but the same was said when OOP came of age, as good procedural C programmers were already organizing their data and functions to be inherently related.
But this all comes back to make my original point more forcefully, I hope.
That Component driven development is just a quantitative addition to OOP which, was itself, an quantitative step beyond global data, sub-routines and true spaghetti code. All healthy advances but they do not represent a qualitative shift in how we get computers to think.
Nevertheless, the majority of programmers are still evolving along this imperative (procedure) line of thinking, which is a paradigm (I think) becoming increasingly stressed by larger, more complex systems serving higher and higher expectations.
It seems, to me, that we (the programming community) are beginning to dawdle around with the fundamental questions we batted around back in the 60s when there was no obvious heir apparent, and it was not decided at that time if a logic, functional or procedural language was best (or if, when).
I think the procedural approach won out because it’s the easiest to understand; i.e. anyone can bake a cake while the average person’s contact with ideas like “epistemology” are limited to “how do you KNOW she’s a witch” Monty Python sketches.
I’m just saying I think we’ve beaten this square peg into all the round holes we can afford, and older languages (mindsets) are going to come back into vogue (e.g. .NET 3.X lambda calculus support and, more to the point, F#).
My attraction to P# is that I want my game objects to infer that if “all men are mortal” and “Charles is a man”, then “Charles is mortal”.
Combine a Natural Language Parser front end with a prolog type back-end, and imagine the converstaions you could have with your NPCs.
Certainly something more engaging than “what ‘orc’” type question mining.
Charles