I have yet to see a compelling case for the use of anonymous methods. Can someone point to one?

I have yet to see a compelling case for the use of anonymous methods. Can someone point to one? 

In many (if not most) cases, they seem to me to reduce readability, and the needed functionality could have been achieved in other ways, ways which I would consider much more readable and maintainable.

Comments

  1. David Heffernan If you had read any books on Delphi, you might have noticed my name in few of them. Perhaps you are too young to remember that I wrote over 700 of the original whitepapers on Delphi when I worked in the Delphi group at Borland.

    ReplyDelete
  2. +Joe Good to hear, but completely unrelated to my point.

    ReplyDelete
  3. Bill Meyer  "Thanks for that perspective. It doesn't alter my observation that the syntax, as it stands, often occludes readability, but it does give me a different appreciation of the values involved.

    Perhaps with anonymous methods, we are in the same state as we were with OOP when it appeared tin TP 5.5: waiting for someone to write clearly and well on the topic."

    People complain that the way C and C++ are defined allows programmers to write code that's "too terse", particularly when they go to the effort of embracing operator overloading so it's easier to read. Some programmers like their code to resemble the mathematical expressions they're trying to implement, while others lament the fact that operator overloading "obscures" the actual functions being called. Well, why bother with a flipping high-level language if you're concerned about all of the logic that's supposedly being obscured? Isn't that the whole idea behind HLLs?

    Lots of people complain that Delphi is "too verbose", and you're certainly not the first person to observe that it "occludes readability". I like C++, but when I try implementing Delphi apps in CPPBuilder I find the C++ is about 30% larger because of all the extra sugar coating you need to add to variable references to make the compiler happy. Blech. It's pretty ironic that a language commonly criticized for it's terseness ends up requiring code expressions 1/3 larger than Delphi's Pascal!

    In the end, Delphi's market has shrunk so much that nobody wants to write books for it. I'm not sure there's anything new in Java 8 that requires any books starting out with "This is a string, this is an integer, this is how you create a class..." But the there are several NEW Java 8 books that do a terrific job elaborating on the role of lambdas, closures, and the new RTL support that all exist because of the focus they've placed on functional programming. I'm not even sure everything that Java 8 supports is in C# yet, but it can be found in some other languages, mostly those built to run on top of Java's JIT platform.

    What I'm trying to say, and I think the others are saying, is there's PLENTY that's been written about functional programming already. Some of it is quite good, in fact. Just stick to books that are focused on "concepts" rather than "recipes" and you'll be fine.

    Functional programming is not a language-dependent thing, although using a language that has syntactic features that help you do it is a very Good Thing.

    Delphi is definitely going in that direction. I just hope they enhance the syntax sooner rather than later, because functional programming is really nice once you get the hang of it. (They need to improve the way the debugger works in that area as well, but that's another story.)

    ReplyDelete

Post a Comment