Execution in the Kingdom of Nouns

You sir, are a genius!

The Law of Demeter violations! They burn!

Brilliant, Steve! Great post!

I have often dreamt of first-class functions...

This rant is utterly idiotic. The great investment in literary allure is there in order to mask its hollow emptiness.

Why should one class of words be put on a pedestal above another? Gee, I don't know, could it just be because natural languages ALL DO THE SAME?

All natural languages have something called a WORD ORDER, they're either SVO, VSO, blah blah. Now, as it happens, the english language has Subject-Verb-Object word order.

And not just that, but SVO is by far the most predominant of all word orders in linguistics. Naive people think it's because SVO is easier and more natural to the human brain. Gee, imagine that.

So from the EVIDENCE, a naive person might think that SVO is a GOOD THING. But apparently, evidence isn't a concern to the brainless and disaffected.

No, because the brainless and disaffected would rather speak we all in tongues twisted. Apparently dealing it not enough is with the complexity of programming, as well have to learn you an alien word order.

Hey Idiot, Ich spreche nicht Deutsches und ich wünsche nicht zu auch nicht.

Bah, come back when you have a real argument!

"Steve, take out the trash."
"System.gc()"

Is there really any difference?

If I missed the point, well, I had trouble finding it in Noun Verb Story Land.

Good stuff. Thanks for writing it.

Wah! Java isn'tenglish
Wah, Wah, wah.

shoes, I would argue you did not get the point. I do not think the rant was against OOP... the rant was against Java's interpretation of OOP. In their interpretation, actions are turned into verbs unnecessarily. Factories, proxies, and enablers litter the landscape with verbal garbage.

Other languages manage to be object oriented without spiraling down into object fetishism like Java has.

You know, at first I was just going to say "Dude, two words, 'Object Oriented'." But then I read on, and despite being a bit long, your article was funny, and well, was true.

I'm currently reading _Head First Design Patterns_ and while the book is good, the message, the use of patterns ... is disturbing. It's creating similar-yet-different objects all over, and replacing other, perhaps better ways of abstracting out commonality with ... Nouns.

Eeg.

Thanks for the post.

Ben

The point isn't that object orientation is bad, it's a wonderful paradigm for hiding the implementation of a system. Rather, the point is that Java's type system (specifically, lack of first class functions) causes people to create classes solely for the purpose of shepherding functions around. In many cases it's taken to such an absurd extent and the work around can lead to other poor practices.

It's telling that very powerful IDEs are commonly used to develop in Java, C#, etc but is far less commonplace in other languages.

I especially liked the "Fox In Socks" reference:
"TweedleBeetlePuddlePaddleBattle"

:-)

Steve... your writing skills are impressive. However, if classes in java are such a PITA to many people, I have a workaround:

class AllNounsAndVerbsInExistence {
...declare all nouns as vars...
...declare all verbs as functions...
}

pretty cool and just as flat as any other lang where you can have a first-class function, no? :)

have you ever considered writing your own computer language? I think that every CS student in college should create or atleast design their own language.

The magic word is closures. Functions are objects, too. "Verb" is a noun. Contrary to what you wrote, C and C++ do not have first-class functions. You can only mess with pointers to functions. They lack closures, and that's why you have "function objects" in C++, which are closures masqueraded as classes. Thus, C++ allows a verbose form of Higher-Order Programming. If you ask a Java programmer to find the first integer in an array that is in the range of 2 and 7, he will think of a *loop*. If you ask a competent C++ programmer, he will think std::find_if and an in_range class. Of course, it is pretty silly to use classes when you really mean functions (there goes the Command design pattern! Oh, and look for all those lambda/closures proposals to the C++ Standard). Java is a damn limited, and therefore limiting language. But it's OK, because that's its guiding PHILOSOPHY. It's rotten from the core. C++ does much, much better. C++ pales in comparison to, say, Common Lisp. In fact, everything pales in comparison to Common Lisp when it comes to expressivity.

By the way, thinking more about verbs in addition to nouns is something you should seriously ponder. It's a great way to figure out how to take full advantage of CLOS. Generic Function is not just a pretty name.

Well, kind of a brain-dump comment. I should write some articles real soon now.

I can't wait until they make this into a children's holiday special. Rudolph gets lost in the land of Noun Lords and eventually rescues the enslaved Verbs, who then help him save Festivus by demonstrating feats of strength. It's gold, I tell you. Gold!

As for pedantic richard, SVO may be interesting for natural languages, but less so for computer languages. Natural languages are imprecise, hence the necessity of computer languages or mathematical notation.

Re: SVO

Yeah, it's awesome for natural languages, it sucks for computer programs though. Natural language has the tremendous advantage that a human brain is involved in establishing meaning and context for all of the symbols involved. Much of this information is inferred from past knowledge. A computer program cannot do this.

We cannot simply establish a class car and have it automatically populated with all the attributes and abilities normally attributed to the concept of a car.

So, yes, from the evidence, and without giving a moment's thought to the issue, a naive person would conclude that SVO is a good thing for programs.

Within the context of understanding the differences between the concepts and assumptions of natural language and computer languages, one would include that that naive person is an idiot.

ariel: interesting comments all around! Yes, you should write some articles. Post a link!

Naysayers: Ruby has blocks. Blocks are verbs -- each custom-crafted to meet the demands of the situation at hand. The Nice language has them too. So do pretty much all other languages, except for Java. (Modulo ariel's correct observations about those that lack closures, but even then it beats Java's nothing.)

Why doesn't Java just add them? It'd go a long way towards bringing me back into the fold. Hell, I'd stop trying to rewrite my game in some other language, even.

Nice wording!
I think you miss something though. Nouns are more important than verbs. And you know why? Because there can be nouns without verbs, but there cannot be one single verb without a noun. Verbs are just nouns expressing themselves. There is one exception. All nouns need one verb: exist. So, yes, they belong to each other, and should do all things together. I fully agree with you that a world of nouns without verbs is dead and boring, but that does not change the rest of the story.

It's like Java forces you to use the active voice, in that each verb must always have a clear subject. They say it's good style to use the active voice, but taking this to an extreme leads to some odd sentences. Often the subject is just a distraction.

It's hard for me to describe why I'm allergic to Java. I think you may have touched upon some of it.
Thanks

Quite the contrary, Java forces you to associate actions not with their subjects, but most often with their objects.

That's why it can get so weird.

You overlooked the fact that one could use static functions in Java classes similar to free functions in C++ namespaces (a la the Math package). Granted, most Java APIs don't follow this pattern; however, the Java languages doesn't prevent you from programming in this style.

Beautiful

Only one (small) complaint... Whorf.

The artcle strongly reminds me of Benjamin Lee Whorf. If you know of him it would be nice to mention, if not please read Language thought and reality

It was Whorf who pointed out that SVO is not normal but just SAE (Standard Indo European) and that in a language like Hopi you simply say 'flashed' for the English sentence The light flashed. Its the English SVO pattern that causes us to invent a spurious light to flash.

In short, object oriented thinking is essentially the burden of the 'white man'.

Steve, you might be interested in Bertrand Russell's philosophy, especially as he was concerned with using mathematical logic to reconstruct the meaning in everyday language. E.g. An Inquiry Into Meaning And Truth, Introduction to Mathematical Philosophy, Principles Of Mathematics. If you are courageous, some Principia Mathematica can't hurt as well (I hear maths is a hobby of yours). According to Russell, nouns are particulars, while verbs and adjectives represent universals. The interesting thing is that the existence of particulars is not logically necessary, so in order to reconstruct meaning without burdening it with gratuitous assumptions, it is necessary to define particulars as bundles of universals (i.e. as the subject of a proposition). I'm not sure, though, whether that line of thought would make your argument more convincing.

I am puzzled by one particular implication of your noun/verb dichotomy. It seems to me that what you want to do with functions is pass them around (as you can in C with function pointers while in Java, you can define pure functions but not pass them around unwrapped). If functions are verbs, I wonder what could be the meaning of "passing verbs around"? This is definitely not what you usually do with verbs, whether in SVO or Hopi. So does this, or does it not, imply that you plan to treat verbs as nouns? I'd just warn you that some of us are taking verb protection quite seriously ;-)

Disambiguation note: I am not the "richard" of that hilariously delusional rant.

A fun post. Thanks.

As I see it, the root of this problem, is that Java was designed in reaction to the perceived weaknesses of C++, according to the prevailing wisdom of the early 1990's. One of those weaknesses was that many developers were not taking advantage of C++'s OO features. Solution: severely discourage non-OO programming by forcing every function to be owned by a class.

Sometimes I marvel that Gosling et al allowed static functions and variables, but I suppose they had to have somewhere for main() to live.

Ever looked at the Scala programming language? It's kind of like Nice, I think (didn't look too far into Nice after seeing the licensing).

Perhaps with these functional / OO languages on top of the JVM the Nouns and Verbs can learn to live together in peace? ;-)

Really enjoyed reading your blog posts.

In test-driven development, whatever language you might be using, the emphasis is on defining tests which push along the design of the code. Such tests focus on executing a method and making sure it does the right thing. I don't know how widespread tdd is in the Java world in general, but I think here in Calgary it is becoming quite popular.

A quick opinion on the SVO thing (Likely someone already said most of this and I wasn't listening):

In a procedurally (or, partly, functionally) styled program, the assumption is that each statement is "computer, run..." or "language, compute..." or "thread, do..." or some such. OO replaces the computer/interpreter/process with an object. Both sets of ideas result in really good languages.

I don't think the problem is purely in overframeworkerizing. It also lies in languages not having flexible means of describing verbs and subjects/objects. Lisp has a natural means of creating new lingual forms that contain such descriptive material. Other functional languages have awesome support for functions, which buys a lot of shortness and clarity. Flexible OO languages, especially those with closures or close, do well if certain things can be done with classes and objects that can be used as flexible descriptions and modifications of objects and verbs...

On the other hand, bad languages (C# is the language I have in mind) don't give you much or any flexibility in finding new ways to shorten descriptions that are very lengthy at the lowest level inside the language - of objects instantiations and array accesses and so forth. The example "Take a list of numbers and square them" comes to mind. You can just barely get away with it in 4 lines of C#.

The frustrating, textboox example I have in mind is the ORM I'm using, LLBLGen Pro. It takes 25 lines of C# to fetch a table and a details table with 4 predicates, sorted. It would be possible but not very useful to try to shrink it to 10-15 through a utility, but I just don't have the inspiration. (That's probably why Hibernate has it's own query language.)

Anyway. I'm a slave to C# by virture of signing on with a Microsoft Certified Partner, and I share the frustrations in the article.

Andrew,

I just don't like the GPL and given a choice will avoid it.

What if, for instance, I wanted to embed the compiler to allow me to use Nice (or a DSL based on Nice) in my application (commercial)? Unpleasant problems occur... Better to start with something unfettered.

A noted PhD from Sun, read this essay, and had this to say:

"hmm, chuckle :) This guy has too much time on his hands ! he should be doing useful work, or inventing a new language to solve the problems. Its easy to throw stones - harder to actually roll up your sleeves and fix an issue or two, or write/create a whole new language, and then he should be prepared to take the same criticism from his peers the way he's dishing it out for others. Shame - I thought developers were constructive guys and girls looking to make the lives of future software guys and girls easier and more productive, not self enamouring pseudo-intellectual debaters, as an old manager of mine used to say in banking IT - 'do some work' !"

BTW, this was posted successfully, why did you choose not to share this with the public?

Thanks for a wicked post. It always pissed me off to no end that everything in Java is an object of some sort and it just didn't seem very intuitive when I first started using Java (and it still doesn't).

Like they say, tho. If all you have is a hammer, everything starts to look like a nail. I like languages that let you have the choice... proceedural, functional, OO'ed, strong/weak typed, etc etc...

Wow. According to some anonymous guy, some noted (but unnamed) PhD at Sun said something smug and dismissive...

I would highly recommend to try out the Io language. It uses a very simple syntax to provide a very powerful programming model (and among many other things, it offers first class functions). Most of all, it is backed by a tremendous community.

Nice post, and an enjoyable read.

To Richard regarding word order:

In my experience, I'll agree that most sentences are constructed as SVO, but not all. Impersonal constructions such as "No Smoking" don't have this order. Furthermore, not all languages have a strict word order. For example the word order in Russian is flexible, and that is really the argument here - flexibility. A programming language, like a natural language, should allow verb-oriented constructs as well as noun-oriented ones. Like another commenter mentioned, it is as if Java forces you to use the active voice. It makes it more of a pain to abstract processes.

The the Sun exec: Not all writing is intended to change the world. Come to think of it little of it is.

To Java: See Spot Run. i.See(new Spot().Run()); I have no trouble with this. What I do take issue with is trying to abstract out, up and away from where the rubber hits the road. That is this,

VisionContext vc = new VisionContext();
Observer i = ObserverFactory.GetCurrentObserver(vc);
Dog Spot = (Dog)NorthAmericanAnimalFactor.CreateAnimal(vc);
try
{
if (Spot typeof(RunningAnimal))
i.See(Spot.Run());
else
throw new AnimalMotationException("Spot cannot run as it is not capable");
}
catch (ObservationException oex)
{
System.out.printLn(oex.Message);
}

And for some perverse reason the balance of Java programmers I've met do this, frankly I think, so they can feel akin to the existing JavaAPI.

It's no wonder that movements like HTML, XML and Ajax are simple in comparison.

Damn that was an enjoyable piece of some very clever and entertaining writing. From someone firmly entrenched in both JavaLand and EmacsLispLand, and loving both.

I do hope that eventually your suggestion on enhancing Java to support functions is enacted. Java can only be the better for it.

Thanks.

The rest of the commentors conveyed most of the thoughts I had. To add:

Java's constructs enforce better discipline than of C/C++. The modern order requires better stability and security than just speed. U dont want your nuclear missiles to fire or banks to wipe out ur hard earned money (all in bits and bytes) , just because there was an invalid pointer or memory fault.

Programming and in general Comp Sci, is no longer the realm of geeks where programmers play with gibberish bits and funny looking 0x000000BC23 and produce awesome output on the screen. World is far too much dependent on programming and thus programmers need to build better fool-proof systems.

If the programming construct means that I take a bit more effort to express my verbs or the program runs 3 times slower, I'm fine with it than the alternate involving crasing of my nuclear reactors and banks.

There are also quite a few prominent languages that are SOV. Japanese is one example.

Classic reinterpretation of Ben Franklin's classic!

Makes absolute sense for English-speakers.

Julian Morrison said...
"There's two things missing from java. First-class functions (with proper closures) are one. Anonymous blocks, after the manner of Ruby, are the other."

The problem in Java is checked exception handling. Projecting a verb onto a collection of nouns is not all that difficult even if it does mean proliferating "functor" interfaces. But if your verb needs to throw a checked exception, you're stuck with the equally unenviable choices of refactoring the method to throw Exception or wrapping your verb with boilerplate try/catch/wrap-in-unchecked-and-rethrow code.

So to simplify, free functions have a useful place in programming; Java coders are forced to define a class to hold 'free' functions, which in turn makes Java harder to write, read and understand than it ought to be.

Is it possible for a single programming language to encompass the paradigms of free-functions, classes, and 'functional' programming? If so, it would be a very useful tool for expressing computer applications.

The D programming language is getting close to this ability.

That was interesting, and I agree with most that it would be nice if Java had an easier way to pass functions as parameters. But it seems like we are discussing the wrong issue. The whole SVO issue doesn't really seem relevant because OOP isn't about writing sentences, from what I understand it's about modeling software in a way that resembles the real world. Everywhere you look you see nouns. In the real world you never see a verb on its own. Verbs are, as one commenter said, nouns expressing themselves. So all verbs are nouns in action, so in the real world every verb is associated with the noun that is acting out the verb. An OOP language models this by requiring every method (verb) to belong to a class (noun).

In the real world we have procedures (like a cooking recipe, or an assembly instruction book for a bookshelf), but these are nouns not verbs. They contain a list of verbs that are acted out by other nouns. Any noun that can perform the list of verbs in the procedure can accomplish the task the procedure was design to accomplish. If you modeled this in Java, the procedure would be a method on a class and the method would receive an interface that defines all of the verbs that need to be acted out in the procedure. Any class implements that interface can then be passed to the procedure and the procedure tells the implementer when to execute each method.

The problem with OOP is that it isn't really possible to model the real world because it's too complex. If you really modeled the real world in a Java program you would end up with tons of classes for even simple programs. Also implementing some objects would create classes that are too large to manage. Like, for instance, any person can act out millions of verbs so a class that tried to model any human would be millions of lines long. Since that is not manageable the class would be broken into parts, but if you break it into parts then you are no longer modeling the real world.

So, from my perspective, being noun oriented is required by OOP, so the real problem isn't that Java doesn't give high enough regard to nouns, Java is just following what OOP dictates. The real issue is whether OOP is actually an effective way to write programs. I would argue that the fact that static methods exist in Java means that even Sun knows that pure OOP isn't a good way to write a piece of software. So, with that in mind, how about giving Java an easier way to pass functions.

As a dad, my daughter occasionally wants to "make" things that are broken. As a programmer, there are three ways to see that:

Dad.repair(toy)
Toy.getRepair(dad)
repair(dad, toy)

All three make sense in some way. It all depends on the number of toys, the number of dads, and the ways to repair them. It could even be

Repairs.doRepair(dad, toy, Repairs.TRAIN)

I can live with all of those constructs, but it's nice when your programming language is flexible enough to give you the choice. The right tool for every problem, and so on.

However, to me the rant is as much about the Design Pattern Police that seems to rule Javaland. Java itself is flexible enough, even if not everything is possible, but sometimes its inhabitants are... well, pedantic.

There, I've said it.

Well, in C_land where I think you live, you have to do so much actions yourself. While in the better JavaLand where I live, we just let every thing do their own actions; we do not take their own business. For example: while I'm doing video games, I can just send a message to the garbage can to dump itself, that's it, and the garbage will do the dumping action himself. The only thing I have to do is to tell it to... garbage.dump()

See? in JavaLand, everything is responsible for its own action.

By the way, everything in JavaLand is a "living thing" and is called object. The God in JavaLand is called the JVM, a virtual god. hehehe!

Steve,
That is brilliant! Your skills with English are as top notch as your analysis of one of Java's main down sides. It is exactly that noun-centricity that makes Java code so verbose and because of the verbosity so difficult to manage once there are so many nouns involved. After choosing to go to Javaland for an extended trip and then asking myself why I put myself in a tar pit, I again have the privilege of working with "higher level" languages (Perl, Ruby, Python) and feel like I have wings rather than heavy black pitchy shoes.

Complainers: all good programers should be always looking at other languages, just for the sake of stretching out that thing you call a brain. If you are so incensed by Steve's post, to the point that you can't even appreciate his fine usage of English, then it is quite obvious that you haven't been exploring the language landscape. Jump on a train, be it Ruby-express, Python-pacifc, Haskell-contintental, Lisp-overnight, or whatever. But get out of Javaland for a vacation and see what the landspace has to offer you. You might be surprised by the lovely scenery!

It's easier for me to understand a system if it's written in a procedural language like C even without its documentation. But the same system written in Java is very hard for me to grasp without it's Doc and UML. When going to an unfamiliar place, for example, it's easier to follow the instruction that directs you how you can go there (e.g, go straight; at the 3rd street, turn left; cross the first pedestrian and you will see the train station, blah blah...) than finding objects of which state and behavior are unfamiliar to you (e.g, when you see a big blue rectangular building, it's the most famous shop, if it's not blue but is big, it's probably the hospital; neglect those shop and hospital because you must pay attention to the yellow building which is the restaurant. Continue roaming around the city until you see the shop, the hospital, and the restaurant which are beside each other; When you found the right restaurant and it is open, enter and eat some food there, otherwise, go home and cook your own food!).

IMO, if you're gonna use or read programs written in OOP, you have to see its UML first to make it easy to visualise the system. An OOP and a UML put together, noone can put assunder. Happy Wedding!!!

George - nice example, but you could have done Ruby a litte better, and hense, more lisp-like with:

def sum(ary)
ary.inject { |total,i| total+1 }
end

though I don't really like the name 'inject'. 'apply' is better, but I think there is a term closer to "sum", that doesn't mean "mathimatical summation" but more like "apply block to each item with a running result". I can't think of what that word is though...

avi - I think it is worth noting that Groovy does not live under King Java's rule. They both live independently under the JVM/JRE's rule. The JVM came to be in order to enable King Java limitless domain. From that first start, the JRE (aka the Java std lib) came to be implemented in Java, but once complied it is just JVM code that can be taken advantage of by any resident of JVM land without respect to any given ruler.

Tsk, tsk, tsk, you verbs don't know how to work the system. In Java 5, you can use the nouns' own constructs against them and become first-class objects yourselves.

Hint:

public class DoSomething // A verb is a first-class object!
implements Callable<ReturnType>
{
ParamType param;

// Constructor records parameters
// to the verb:
public DoSomething( ParamType _param )
{
param = _param;
}

// The verb's own verb is just a call():
public ReturnType call()
{
// Really do something
return returnTypeInstance;
}
}

And here's how you get used, Mr. Verb:

ExecutorService pool = Executors.newFixedThreadPool(1);

// Create the verb and pass it the required params:
Future<ReturnType> future = pool.submit(new DoSomething( paramTypeInstance ));

// Then call it blandly in a separate step:
ReturnType returnTypeInstance = future.get();

Yucky, yes, and just to become first-class citizens of Javaland like the nouns, you've now stooped to their level. But then, you can't make an omelette without breaking some eggs, can you?

Very well written! A witty story and a very valid point.

Having to make an excessively long series of method calls, instantiating and passing a multitude of objects along the way, indicates bad OO design and bad API design. An API that forces you to jump through hoops like that is a poorly designed API. Yes, decoupling and abstraction are powerful concepts, and design patterns save a lot of time and effort. However, an API that includes too many design patterns, too many layers of abstraction, and too many decoupling stages, is not a well designed API. I don't see this as a Java problem or an OO problem. Bad designs can be accomplished in any programming language. In English, you can construct simple and easy to understand sentences, but you can also construct horrendously long and complicated sentences. I could say something along the lines of: With regards to something, and taking into consideration another thing, but notwithstanding a third thing, the fourth thing, however much fooing a fifth thing, foos a sixth thing with a seventh thing, while being fooed by an eighth thing for the purposes of a ninth thing, which fooifies a tenth thing, thereby disenfooing an eleventh thing. Sentences with structures like these should probably be broken up. Similarly, APIs that require you to write code like the examples of the horseshoe nail fable should probably be redesigned.

Thanks for the very memorable and enjoyable blog post :-)

Very nice article I must admit. Despite this "noun-thing" Java is not a pure object language anyway in a sense Smalltalk is. There are primitive types (nouns still) which are allowed to run naked.

Talking about nouns, some problems really are best modeled as relations between nouns. Having some verbs roaming freely does no good here. These things (pun intended) are what Java is good for and there's no point to complain that you can find a certain case where it's not applicable or something is difficult. For one thing, Java is _designed_ to make certain things difficult/impossible. Despite your specific project, in general, Java serves it's purpose well. Ever wondered why it became so popular in the first place, having strong competing noun/verb languages advocated by companies such as Microsoft and Borland? Certainly not because of dominant market position of Sun Microsystems.

I think this whole argument is quite similar to conversation I had years ago with a Oracle DB administrator. This guy wanted to model everything using his mighty relational database. Not only information. Instead of having some evil "Java nouns" I had proposed to do the thinking outside the database he wanted to do the work with Oracle SQL stored procedures. The guy was very fixated on the idea of having data (nouns) and stored procs (verbs) this way. After a short while it became apparent he did not know anything about the realm of object oriented programming.

To actually have any meaningful conversation the people involved should have visited these countries. If you never travel outside C-land or Perl-land, your knowledge about the alien culture of Javaland comes from some random rants found on ancient websites. Vice versa, of course. People should travel more! Unfortunately it takes some time to visit the countries, but as in real world, people who actually travel around are less likely to express strong negative opinions about other cultures.

Jesse Millikan,

The example "Take a list of numbers and square them" comes to mind. You can just barely get away with it in 4 lines of C#.

It doesn't work like map, but

foreach (int num in numlist) { num *= num; }

would seem to do this just fine.


George,

You're right that the complete absence of polymorphic math functions in c# is wildly broken. This is arguably the most broken non-feature of c#.

If you wanted to, you could implement a library with static functions like Polymorphic.Add(object a, object b), but this would involve performing runtime typechecks and manually downcasting to the appropriate types. Possibly even worse, it wouldn't work with classes that implemented their own operator overloading.

To add a C++ version to George's list of sum functions, implemented of course using the much more general accumulate function:

template <typename T, size_t N>
T sum( T (&a)[N] ) {
return std::accumulate( a, a+n, T() );
}

That one only works for arrays, so I might as well add an overload for container-like types, such as std::tr1::array or std::list :
template <typename C>
typename C::value_type sum( C const &c ) {
return std::accumulate( c.begin(), c.end(), typename C::value_type() );
}

Seriously folks, the problem is not Java or OOP it's this sophmoric fetish for patterns. I've seen programs in which even the simplest action has to be passed off to every possibly applicable pattern: factories and locators and wrappers and ay yi bloody YI!

I'm on a project now to fix a program that was supposed to simplify a 20K line C program that's been running like clockwork for ten years.

So they hired a Java team of recent college grads eager to demonstrate their flair. The result is 500K lines exercising every conceivable pattern and it doesn't work.

How come?!

Well! Rube Goldberg was funny. But there's not anything so interesting as a toaster or a calico cat in this pretentious act of foppish vanity. And if there is a cat or toaster, somewhere in there, we're going to have to wrangle it out of the factories and the factory.factories, unwrap it from its wrappers, all delegated of course, to in the end find two lovely lines of code that could have done the job elegantly at the start.

It's like a Russian doll that fills the room and when you've pulled them all apart you find a little peanut.



I'm

Great rant! I recall that when I started programming Java, it was hard to talk to "normal" people, because suddenly everything MUST be an object for me, but not for them, duh...

Java is simply more 'real-world' by being purely object oriented because real world IS the kingdom of nouns.
First there is the entity [noun] which has attributes and the entity does something [verb].
Nouns DO verbs as in:
Stevey.takeOutGarbage()

All the 'actions' that you listed, are being done by a noun, just like in the real world.

Okay, we're getting way off topic here but:

>> SVO: I hate you.
>> VSO: Kiss my ass.

I know you're joking but actually, there is no object in the second example. VSO would be something like: (V)Kiss (S)you (O)my ass; which isn't valid English. If you inserted an object you could say '(S)You can (V)kiss (O)my ass' which is, of course, back to SVO (the point being that English is an SVO language so nothing else is valid).

Much more interesting things happen in some Australian Aboriginal languages such as Walbiri where word order plays very little role at all (and the relationship between words is marked by word endings from memory).

That said: arguments about VSO vs SVO etc etc have pretty much nothing to do with the article. Fir ibe tgubg there is, afaik, no reason to think that SVO languages are in any way more or less expressive than languages with other word orderings. Grrr. In any case the point wasn't the order in which the Nouns or Verbs appear but the relative frequency of their occurence. Java favours nouns apparently.

And for the record, about 10% of the world's languages are VSO with the rest split about evenly between SVO and SOV. Languages with O before S do exist, but are very, very rare.

In RESTland, there are very few verbs, but the country is verb-centric anyway, because that list of verbs is entirely autonomous. Not all nouns are usable with all verbs, mostly for security reasons, but nouns don't get to define their own verbs.

If you believe Microsoft's docs for C# 3.0 (http://download.microsoft.com/download/9/5/0/9503e33e-fde6-4aed-b5d0-ffe749822f1b/csharp%203.0%20specification.doc), it looks like C# is becoming much more Functional (lambdas, type inferencing, query comprehensions).

Jesse: The new syntax for squaring a list of numbers is list.select(x => x * x);

George: The new C# syntax for summing a list is just list.sum(), although for more generality you could also use fold (like lisp's apply) like so: list.fold((x, y) => x + y);

Never before in my life I had seeing such a great misunderstanding about some sort of thinking, the thinking of design computer software based on intelligent objects, behavior plus state, bound, for better human understanding and maintainability...

And I thought it was just a unimportant, misplaced rant in only one aspect of Java syntax...

My full critic can be found here.

Thanks i dont program in C# so i did not know that.

In any case, Richard has it wrong. Natural languages are about 10% VSO, 45% SVO, and 45% SOV. The other orders (object before subject) are incredibly rare, maybe ten languages altogether out of the total list of 7000 or so.

hi! i like you site! Keep so! look at my home pages:
Tamilsex Women Photos - xnxx - Freeones - Tamilsex com - 89.com

Okay, we're getting way off topic here but:

>> SVO: I hate you.
>> VSO: Kiss my ass.

I know you're joking but actually, there is no object in the second example.



VSO: Give the man his due.

(or, if you don't like the dative noun, and think it VOD, here is VODS, your normal english imperative word order)

VSOD: Give the man his due, dude.

That's still SVO. The imperative form still has a subject -- that subject is an implied YOU. Therefore:

(You) give [the man] {his dues}.

The words in [square brackets] is the direct object. The {curly braces} in this case is the indirect object.

Oh well. :)

Excellent.
Of course you forgot how every Important Noun has a cousin, of a lower strata named Impl in which the true executioner resides.

There is:
model.service.interceptor.ServiceInterceptor
which too lofty to do any execution, instead there shall be model.service.interceptor.ServiceInterceptorImpl as well.

Also, more seriously, I wonder if it is the "architecture" that is being made visible, or something else, less useful.

What a bunch of smarmy crap. Anyone with half a brain can write a smart-ass 'critique' of anything.

So you need to write your functions/methods inside a class file. Oh the pain!

I've been working commercially on enterprise systems using both MS and Java over the past 12 years. I've struck issues with both. However, I have never struck an issue with Java that equates to anything you wrote.

Your article was pure nonsense.

Sorry, Rob.

I started laughing at 'All Java people love "use cases"' and kept on laughing all the way. Very amusing!

"A verb is a noun, and nounal is not."

To those of you who don't understand, a class can be considered a noun, and a method a verb. The method parameters are a 'contract', and there is some validity to integrating the suggested default parameter values instead of having to overload methods, but I think the metaphor utilized herein is widely inapplicable.

"I don't like them, because they don't like things?"

When I read the "Or whatever you were doing" part in the pseudo-code for taking out the trash, I thought, "He didn't have to write that last clause and it would have been funnier/better." But then when you finished off with "...get back to playing video games. Or whatever I was doing." That was great. haha, good job.

Highly amusing, throughly enjoyed it.

I read Fowler's book on Refractoring a few years ago and had issues with it (which brought me on a link from a blog here).

I often wonder the detachment from reality that some languages have, in that eventually a little electron does have to make its way through an ALU to get something done. Some of the later languages appear to require vast hoards of them, rather than a few, to achieve the same effect.

This comment has been removed by the author.

If we take as a premise, anything worth saying is worth saying precisely and as a corollary, anything worth saying is worth repeating, then maybe Java isn't so bad? It is true that under-parameterized n-off's can get a little sloppy, but those are performance bugs waiting to be noticed. Fantastic post - I appreciate you getting people thinking about garbage in all its real and virtual forms.

A programming language isn't made to model the real world as static objects with behavior, but to compute the behavior on objects. The behavior is the incentive for programming.

The object can be a substitute for a physical thing (e.g. a car) or an abstract concept that's part of a process (e.g. money in a transaction). Whatever it is, it has no real interest in and of itself. The goal is the result of an action on this object, not the object itself. We want to know how this object has changed, not what this object is. We already know that.

This article sums up my feelings about JAVA perfectly.
You did a great job!

Didn't notice this noun thing in Java. Did notice that Java code tends to the verbose. Attributed that to long naming conventions. Expected this was a reaction to C's shorter conventions.

COBOL was an early attempt to make a programming language more like English. Calling COBOL verbose is redundant. COBOL invented verbosity.

Whatever language you program, some compiler has to interpret it or translate it using the machine's native language. It might be instructive to understand that just a bit. Machine languages are nearly all entirely populated with verbs. At the bottom, computers only know how to do things. They don't even know how to stop. The closest they can get to stopping is "wait for interrupt", or spin in a loop.

OK, so every machine language instruction carries a verb and one or more nouns to act on. Every analogy eventually breaks down - if one didn't, it wouldn't be an analogy - it'd be the thing you're talking about.

In the translation to machine language, Java, with it's noun-centric view, requires some serious gyrations to become the verb oriented stream that the machine executes. And, typically, some crap that just doesn't need to happen gets added to the mix. This is a semantic impedance mismatch. Some really, really good compilers can overcome this. And some Java compilers do. Does yours?

Consider a language that matches the machine better. Forth. OK, so it's a noun(s) verb order. But that just matches it's stack orientation. Forth programs are quite terse. A Forth interpreter system can be written in 1 KB of machine language. With tiny overhead like that, most of your machine can be devoted to the problem at hand. And, even as an interpreter, these systems often achieve speeds a third the performance of machine language or C. Totally awesome performance for a system that does not include a compiler. Just as Java pushes you to think in Java, Forth pushes you to think in Forth. How do you think?

I certainly enjoyed reading your article. It's nice to hear some good critique. Although I must say I love expressing my ideas in the way Java land inhabitants do, AND I DO. But because of programming in C#, I avoid the major performance downfalls; old Microsoft has provided the CLR which optimizes what I write.

I dream of a land where humans speak to machines in natural language, and they just know what to do. Programmers should invent a platform which unites all languages in one, optimized, multi-layered architecture, in a similar way to what Microsoft has done with .NET.

I could see people like you work on the bottom, optimization levels, and people like me on the higher, more abstract ones, so that we can build large and stable systems, instead of producing arguments on which language or paradigm is best.

Cheers.

E

We might see slightly better closure support in Java 7:

http://www.ibm.com/developerworks/java/library/j-jtp04247.html#3.0

Many have wondered why it has taken so long to see good closure support in Java. I speculate that one of the reasons Java has very few closure-like interfaces is because of checked exceptions:

http://tiedyedfreaks.org/eric/CheckedExceptions.xhtml

After execution of properly written garbage collector, this article would disappear.

No, really. This article could be written only by someone who has no experience with large projects.

If you run a one-man company, just code as you wish. But I would never work voluntarily with someone who's favorite programming practice came out in 60's.

All the actions you adore so much must be taken by somebody / something. No action happens just out of nothing. STEVE takes the trash out, so you call

steve.takeOutTheGarbage();

Now if you have just

takeOutTheGarbage();

and Steve is hard-wired into the action, what happens if Steve dies?

Java is not a toy-language like PHP and it's design counts on the fact, that the garbage can be carried out by anyone able to do it. So you don't even need Steve; you just tell "Anybody able to do so, carry out the garbage":

public interface GarbageCarrier {
public void carry();
}

Now while maintaining the house, you call:

GarbageCarrier somebody;
// Catch someone who would do it for you
somebody = ... //
somebody.carry();

That's it. In the world of enterprise projects with dozens of libraries and where you even don't know in advance, who will ever do something for you (e.g, will it be Hibernate or Toplink?), this approach is not an option, but a necessity. Of course it basically could be written in obsolete procedural way, but I really wish not to co-work on that code.

Excellent post!

Allan Kay says that OOP is really about messaging, and, essentially, the verbs are essentially the first class citizen in oopland. This, luckily enough, brings us to a better, more enlightened land:

POOPLAND

The land of Procedural OOP. People there feel that objects are like a box - they're incredibly useful and easy to manipulate, but they can't work alone. They need messages or verbs to help them out!

To defend my beloved Ruby and to prove a point, let's use her (because programming languages are like cars, and langue is feminine in french) as an example. Everything is an object in Ruby. Everything. Yes, even methods!
> 5.method(:abs).class
Method
But like I said before, classes are boxes, not cars. A box and an engine (verb) is a car!
> box = Car.new
> box.spark
> box.start
> box.run

Now, we have used some messages (or verbs) to make this box interesting! In ruby, everything is an object and everything has some basic methods. This is important, because otherwise you'd just have an empty box with NO way for it to interact!

(Case in point, Java's array primitive. And C's. And, in fact, all primitives. But an array is most like a box.)

The point is, the purpose of OOP is abstraction and encapsulation. It enables you to think of things on a much higher level, where everything is PROCEDURAL (not necessarily. Could be functional).

OOP tries to make things simpler. So *please* don't go using it to make things harder. Objects aren't people - they're things. Verbs, too, can be objects - they're ideas. Every verb is an aciton, and every action has an associated idea with it.