Designing C# 7 [video]
infoq.com
infoq.com
Where an IDE could be helpful is in refactoring and code generation. If your code does't require much generation due to its simplicity, you might need half-an-IDE. If you can get decent refactoring by having higher-level functions as the default, maybe you end only needing a quarter of an IDE?
That's why I keep bouncing between LightTable and Counterclockwise (nope hate IntelliJ and Cursives, but that is a taste thing). I'm more comfortable with Eclipse than Light Table. I just don't know how much of it I need.
One caveat is debugging. I do fallback on that. I think that might be a sign of me failing to breakdown my code into isolated units. Regardless, I haven't figured out how to do debugging in LightTable.
I don't know how much direct benefit I would get from using F# instead, though. Too much of the stuff I work on is dependent on using not-so-functional-friendly C#-based SDKs or ties into unmanaged code through COM wrappers.
I'm a huge fan of F#. I ported some old racket program to it, and ended up with a shorter, faster program that looked better. But constantly having to struggle with the tooling just makes me want to go back to DrRacket.
Pure object oriented programming tries to force the object metaphor onto every problem disregarding whether it actually fits naturally. Pure functional programming pretends that there is no state which is as wrong as everything is an object.
In my opinion the really sensible thing to do is to be aware of all the available options and choose the right one for the problem at hand.
Smalltalk had lambdas and LINQ like libraries.
Lisp had Flavors and then CLOS.
For those that tend to forget lambda calculus and place FP == Haskell, type classes allow for most of the ground principles of OOP design. There are a few interesting talks from Simon Peyton Jones about it.
TL;DR - Learn functional programming, what are the strengths and flaws of each approach to software architecture and use the best approaches for solving the actual problem.
Lambda expressions and anonymous types are why. C# 3.5 saved you from having to seriously ask that question any more.
So the answer is no. But learning a functional language can help your skill in your existing ones.
IMO the best option is a language that supports both concepts (In the .NET case, let's say, C# OOP with Lambdas, or F# functional with types.)
I found this series quite informative, as an OOP developer: http://fsharpforfunandprofit.com/series/thinking-functionall...
Perhaps an example of a program or language that does this.
I see you talk about Lisp and ML a lot - are you referring to macros(1) to extend the language?
1) http://stackoverflow.com/questions/267862/what-makes-lisp-ma...
I occasionally wish there were ways to get at the compiler features that add "yield return" and "async ... await" to the C# language and use them for your own extensions, but the hacks that make c++ templates turing-complete definitely don't seem to be a desirable way to do it.
As opposed to a dynamic metaprogramming (e.g., expression trees in C#).
Neither "static metaprogramming" nor "dynamic metaprogramming" give many relevant results on google, so perhaps other terms are more commonly used?
As I said in the other reply, it seems intriguing that some features of C#, e.g. extension methods, yield return, async .. await are essentially rewrite rules. Ways to get at the compiler features that add them to the C# language would be interesting, but the concept seems to be made much harder by the complex curly-brace syntax not being designed for that; it's rather the opposite of lisp.
Once you've got proper macros, pretty much all the other language features can easily be implemented on top of them, so it makes much more sense to get the macros first instead of adding features one by one. I could never comprehend why the mainstream language designers are not doing it.
Syntax is not an obstacle for a proper macro system, as demonstrated by Template Haskell, Nemerle, Katahdin, PFront and the other meta-languages not based on S-expressions. The only thing you need is a quasiquotation for both constructing and pattern matching the ASTs, and it's possible to implement it for any syntax.
Also see Honu[1], which effectively brings Racket's syntax-case into a curly-brace language.