Mohtalim

Amusing, but it's really not so bad always knowing where something is coming from... Interfaces are probably the closest you come to having first class functions, but even then, the interface itself is sorta class even though it has no data I guess.

Just be glad you don't live in an event driven world. It's a huge pain in the ass to figure out what's going wrong sometimes since there can be many triggers to a particular event and there's no strict execution ordering of threads that are triggered by the event. Ideally, one would not write two interacting threads, but it happens...

Luckily, I live in a Perl world as much as possible.

I don't understand HLL. 00 00 00 is my favorite function!

I think the author's point is sometimes when you eat it, the verb doesn't come from anywhere. You make a home for it to live in.

I and several of my co-workers find it a deeply irritating practice to add a class where none is necessary, just to stuff some functions in it. Any type without some concept of state inside needs to get unbundled with a quickness.

Like one of the commenters said, actions require an object for that action to happen on and every object should have at least exists(). For example, it's a pain to do something like logging when you need to pass around the logging object everywhere; or make the logger object a singleton; or use a logger factory to get the log object to get the log routine. Which of those choices you use though depends on how annoying will it be if you have to change it later. If you don't use the factory, then changing the logger later in a large project might be a pain if you don't design the logger for change. For instance, you could just skip the factory and design the logger to have overridable components which is just pushing the configuration from a factory into the logger itself. If you do use the factory, that's an extra intermediate class you need to create and type every single time you make a log entry. In any case, Java's meant to be a completely explicit language which is part of what makes it relatively easy to debug. Yes, it's a different way of thinking, but you get used to it, and it becomes second nature. Deal with it and move on.

If you say eat, there's gotta be an implicit thing to eat. Java doesn't have an implicit source of data. Perl has $_ and @_ and <> to work with. Maybe Java can add some similar syntactic sugar? Although, you do sorta get this by being able to say obj.comp1().comp2().comp3().comp4() where comp1-4 return an object that becomes the object of the next computation. I guess it might be nice to be able to leave off the obj?

Like what sort of functions? Often, the functions should be put in a class that already exists or an extension of that class.

I think the author wasn't making a point about Java the language itself, but rather people who program in Java and writes Java library. Instead of a simple Horse.fuck(Horse), they have to be complicated and write Breeder.execute(HorseBreedingProgram.impregnate(Horse, Horse)). People take an idea and made a religion out of it for no good reason.

Yeah, you're probably right. He did seem to complain about the language itself by the end some though. Anyways, I'm against unnecessary classes that don't fulfill a design goal and make it a pain to type out what I want to do! People should list out their design goals and class structure decisions that implement them.

I think one of the reasons I like C++ and Python is that I can use whatever paradigm seems natural for the situtation. I've started disliking C, because object methods are just more convenient, readable, etc in some cases. I haven't touched Java in years, but I'd bet I'd be just as annoyed by the lack of stand-alone functions.

On the other hand, its really just syntax. You want a stand-alone function in Java, you just make it a static class function on an otherwise useless class. Annoying, but not crippling. And you can do object-oriented programming in C, but the syntax is so unpleasant that it's generally not worth trying. So maybe a better measure of a language is how often its syntax and other capabilities cause you to chose an otherwise suboptimal solution.

I will say that the patterns he whined about really are useful sometimes. Factories are great when dealing with run-time configurable interprocess-communication. Depending on the library support, function objects can be as easy to use as first-class closures. In C++, boost::function and boost::bind pretty much give you everything you could want, except maybe some of the sloppiness that you'd get in a weakly typed language.

quantus wrote:obj.comp1().comp2().comp3().comp4()

As an aside, I think the Law of Demeter is supposed to prevent you from doing this, though I'll admit to not following it or even understanding it. I think the law says you should just call obj.comp1234() and comp1234() internally calls obj.privatemember.comp234(). And so on. Maybe.