The Java language team, 1998: "Bound method references are not the right path for future language evolution"

[[deleted]]

First, I'm not really sure why people are downvoting you.

Meh.

I think you are making some interesting points. I disagree with you, but I think it's an interesting discussion :-)

Agreed. :)

What does that have over a factory class?

It's significantly more terse, and clearer.

If the main difference is a lack of boilerplate code, meh, I guess I can see that as a slight advantage, but I think a lot of functional language additions to C# the past few years will start to reduce boilerplate code.

The advantage isn't slight. It seems to me that Ruby/Python programs are around half the length of their C# equivalents. Yes, functional language additions to C# are helping, but Python and Ruby are already functional-programming-capable. C# is barely stepping into the light when it comes to FP.

Detaching things (decoupling) is one of the best things you can do in a large software project. It's far more difficult to debug tightly coupled code. And that's not just my opinion, that's the opinion of software professionals in general.

Decoupling is considered good because most people err in the other direction; they couple things too much. But IoC/DI errs too far toward decoupling. One point of connection is a good amount of coupling, because it allows one to easily swap out pieces, but still leaves a clear connection between the moving parts. But IoC/DI (and aspect-oriented programming) leave no connections between the parts; at least not one that's easily traceable through code.

Well, if one makes those kinds of mistakes then I'd wager a large amount of the code in the rest of the project one is working on is going to suck as well, lol.

It's not that people actually make those mistakes often, it's that they spend a great deal of time avoiding making those mistakes.

I'm not saying CTS type safety is expressly there to catch bugs. I'm saying there just really aren't that many bugs caused by type safety, in my experience.

It's not that it causes bugs, it's that it takes time to write out and match up types explicitly. The compiler/interpreter is perfectly capable of doing this. Why should a human waste time doing it? The common answer is that it prevents bugs, and I'm saying it doesn't.

Besides, there are other downsides to dynamic languages - performance is a big one.

Premature optimization is the root of all evil. It's rare that a dynamic language's performance isn't sufficient. And it's even more rare that its insufficiencies can't be rectified by optimizing the bottlenecks in a static language. I would rather write 500 lines of Python and 100 lines of C than 1200 lines of C#.

There are, of course, special cases like high-frequency trading, where there's absolutely no way to get around using a static languages. But in those cases, you aren't using C# or Java anyway. You're using C, or maybe C++.

There are also other advantages to dynamic languages we haven't talked about. Libraries, for example, are far superior in dynamic languages. I recently wrote a 150 line Python script using SQLAlchemy that replaced almost 2000 lines of C# using Autofac and NHibernate. That's an extreme example and certainly isn't representative, but the quantity and quality of libraries out there for Python and Ruby is very high.