The Old Joel on Software Forum: Part 4 (of 5) - Complicated APIs vs Simplicity

Complicated APIs vs Simplicity

http://www.linuxworld.com/story/44251.htm

So, which do you adopt and why ?

deja vu
Wednesday, March 31, 2004

Rampage Computer Science? What have complicated/flexible designs to do with CS? Whatever...

I agree with the last 2 sentences but the rest is pretty much "Need to write article..."

Nothing restricts you from putting a simpler interface over the flexible one. You can rave all you want about "simplicity" (which is a nice word and sounds so good), but it can bite you later on (when there's this other nice, well-sounding word "flexibility" making rounds).

Over-enthusiasm with certain design patterns is mostly a fresh/bad programmer thing and certainly not restricted to the Java community.

_
Wednesday, March 31, 2004

"Over-enthusiasm with certain design patterns is mostly a fresh/bad programmer thing and certainly not restricted to the Java community."

So since he's complaining about core java api's, are you saying that java is written by fresh/bad programmers?

Certainly his complaints are spot on for the java xml api's. They are a complete pain to work with compared to almost every other language. I'd rather write my xml stuff in c++ simply because it requires less code than java.

RB
Wednesday, March 31, 2004

But, I think the point he's trying to make (albeit in a slightly incendiary way) is that a lot of Java APIs are very complicated, and needlessly so..

The current rage in Java is to overuse design patterns. But, to extend his point, I'd argue that nowhere is it so glorified to have Factories and layer upon layer of abstractions than in Java.. No one has seemingly stopped and thought "hey, look.. 80% of this functionality can be hidden because few need it".

Take EJBs or Swing (some feedback mentions those two). How difficult is it to get a Table up and running in Swing ? Is it necessary ? When someone approaches the language, how many classes/paradigms must they be "forced" to learn to get a job done ?

C# does it better.

deja vu
Wednesday, March 31, 2004

Guess you meant : .NET

Phil
Wednesday, March 31, 2004

"Nothing restricts you from putting a simpler interface over the flexible one. You can rave all you want about "simplicity" (which is a nice word and sounds so good), but it can bite you later on (when there's this other nice, well-sounding word "flexibility" making rounds)."

Completely agreed.

One of the problems I have with java is that there's no simpler interface over the complicated one. Tasks as simple as formatting a Date require the use of a few classes. There is one method to do it, but it's deprecated.

Don't know about C#. However, given the great job Anders did with Delphi, I expect C# should be equally simple and elegant.

Paulo Caetano
Wednesday, March 31, 2004

C# is fantastic!

Some of the libraries are fantastic: GDI+ for graphics, for example.

The big problems of .NET are in some other libraries, which are poor and very very buggy: the WinForms datagrid, for example, is extremely bad.

ADO .NET is a disconnected architecture which introduces a lot of complexity. They could have made it easier while maintaining it's "disconnectedness" :), but they didn't.

ADO .NET is similar with C++ in one aspect: you have lots of possibilities and a lot of freedom. 50% of these result in doing something bad... so you have to be very very careful not to do something bad.

MX
Wednesday, March 31, 2004

... I meant, 50% of the possibilities.

MX
Wednesday, March 31, 2004

Of course, the author completely overlooks one of the strengths of the "Java way of doing things": that PGP library almost certainly conformed to the Java Cryptography Extensions API. True, this API is somewhat complex, but the point is, that library can be used by any other application that knows how to deal with JCE, without rebuilding the application: any application that uses JCE now has the ability to use PGP, even though it was not specifically written to do so. It is this sort of flexibility that is often hard to come by with libraries and applications on other platforms. Sure, it can be done, pretty much everything can dynamically link in .so or .dll files, but it's not nearly as straightforward as it is with Java.

joev
Wednesday, March 31, 2004

> So since he's complaining about core java api's, are you
> saying that java is written by fresh/bad programmers?

I can't tell, I'm coming from C++ mostly =) But if you say a lack of simpler interfaces on top of the flexible ones is found at core API's, well, then I guess Java is written by bad programmers. Or at least programmers whom are not given enough time/feedback.

_
Wednesday, March 31, 2004

Nothing worse than a simple interface when i
need to do something more complex. At least i can
layer above the complex interface. And you know as
well as i that everything is really complex in the end.
Simplicity is a special case. You are fortunate
is you can get away with the simple.

son of parnas
Wednesday, March 31, 2004

This is what I was talking about:

SimpleDateFormat sdf = new SimpleDateFormat( "yyyyMMdd" );
String strDate = "<SOME_DATE>";
java.util.Date dt;

dt = sdf.parse(DataStr);

// blah blah blah

Can someone tell me if/why is the following inferior:

java.util.Date dt = java.util.Date.StrToDate( strDate, "yyyyMMdd" );

<rant>
All I want is to turn a String into a Date. IMHO, having to use one separate class just to handle the parsing/formatting is unnecessary. If you really want to specialize your classes that much, at least hide it from the user of your lib/API. This operation is trivial enough that it should be accomplished with one line of code, and without having to look up the docs on yet another class.
</rant>

I agree that simplicity is deceptive. But I believe one of the signs of a good lib/api is that trivial tasks are no more complex than they should be.

Paulo Caetano
Wednesday, March 31, 2004

I agree. I've long complained that the Java Date system was designed by an overzealous student trying to get a masters in computer science. It's just plain awful to use, but I bet he got a good grade on it.

You thing what you go through there is a horror, try creating a Date class from JNI:

JNIEnv * pEnv = ENV::get();
JVMClass calType( CALENDAR_TYPE );
JVMClass zoneType( TIMEZONE_TYPE );

// get timezone from static instance method
jmethodID method = pEnv->GetStaticMethodID( zoneType, "getTimeZone",
( std::string("(") + STRING_TYPE + ")" + TIMEZONE_TYPE ).c_str() );
if ( !method ) throw JVMException( "Could not find method getTimeZone" );
jobject zoneStr = newString( "GMT+0" );
JVMObject zone( pEnv->CallStaticObjectMethod( zoneType, method, zoneStr ) );
pEnv->DeleteLocalRef( zoneStr );

// get calendar from static instance method
method = pEnv->GetStaticMethodID( calType, "getInstance",
( std::string("(") + TIMEZONE_TYPE + ")" + CALENDAR_TYPE ).c_str() );
if ( !method ) throw JVMException( "Could not find method getInstance" );
JVMObject cal( pEnv->CallStaticObjectMethod( calType, method, ( jobject ) zone ) );

// set date with calendars set function
method = pEnv->GetMethodID( calType, "set", "(IIIIII)V" );
if ( !method ) throw JVMException( "Could not find method set" );
pEnv->CallVoidMethod( cal, method,
date.getYear(), date.getMonth() - 1, date.getDate(),
date.getHour(), date.getMinute(), date.getSecond() );

method = pEnv->GetMethodID( calType, "set", "(II)V" );
if ( !method ) throw JVMException( "Could not find method set" );
jint MILLISECOND = calType.getInt( "MILLISECOND" );
pEnv->CallVoidMethod( cal, method, MILLISECOND, 0 );

// get date out of calendar, thank you SUN!
method = pEnv->GetMethodID( calType, "getTime", ( std::string("()") + DATE_TYPE ).c_str() );
if ( !method ) throw JVMException( "Could not find method getTime" );
JVMObject result( pEnv->CallObjectMethod( cal, method ) );
zone.deleteLocalRef();
cal.deleteLocalRef();
return result;

And that's using helper classes!

Oren Miller
Wednesday, March 31, 2004

>I agree that simplicity is deceptive. But I believe one of the >signs of a good lib/api is that trivial tasks are no more >complex than they should be.

Agreed. I believe in every sort of "convenience" method
rather than parts i always have to figure out how
to put together. But if they only had the one static
str to date, that would be worse, imho.

son of parnas
Wednesday, March 31, 2004

"You thing what you go through there is a horror, try creating a Date class from JNI:"

OK, I'll stop complaining :)

We had to work with JNI once, before SAP had a Java interface. It was one of those rare occasions where I was thankful that my role had become more project coordinator/manager and less developer.

"Agreed. I believe in every sort of "convenience" method rather than parts i always have to figure out how to put together. But if they only had the one static
str to date, that would be worse, imho. "

I believe we're saying the same thing, which is:
1. Flexible api, with simpler interface for trivial tasks. Good.
2. Flexible api, without simpler interface for trivial tasks. Not so good.
3. Simple api, with little or no flexibility. Worse.
4. Complex api, with little or no flexibility. Sounds like something I could develop when I was learning UML :)

OK?

Paulo Caetano
Wednesday, March 31, 2004

Some see problems others see business opportunities. Don't like it? Market a wrapper implemntation that simplifies it for the most common cases. According to this thread you'd be rich in no time flat.

Justin Kolb
Wednesday, March 31, 2004

The design philosophy behind Perl was to make the things that should be easy, easy, while at the same time to make the hard things possible.

This philosophy has trickled its way down to Perl's users, and the end result is quite apparent: look at all of *::Lite and *::Simple modules on CPAN.

An example of a good mix of complexity and simplicity is the libwww-perl (LWP). LWP is a big, complicated distribution spanning dozens of source files, supporting everything from HTTP to NNTP, and sporting *hundreds* of functions/methods—however, Gisile has wrapped the most common combinations into individual methods (e.g., get(), post(), head(), etc.), ensuring that file transfer can be accomplished in only a handful of method calls. And if that's not enough, he also provides LWP::Simple, to do everything with a single function call.

A madman, sitting in the dark, building a house of cards and deception
Wednesday, March 31, 2004

<tongue in cheek />

In reply to Justin, unfortunately, it would be so simple that *everyone* would say "Hey, I can do that myself" and then proceed to do so..

Simple doesn't offer as many competitive advantages as overly complicated and "locked in" :)

deja vu
Wednesday, March 31, 2004

Constructing stuff out of parts is actually nice, but unfortunately the Java way is verbose:
- create interface
- create implementation
- find out where on the HD to store it, or mess around with inner classes

(I hear IntelliJ helps automte this pattern to some extent, btw.)

Another problem is that any class you write will at minimum have 5 lines. (4 for class/method structure, 1 line of useful code.) People are trying to emulate functional programming with these heavy classes, and they're getting benefits, which is why they do it. Functional programming is often about constructing general code out of simple little parts. But functions are not as naturally verbose as Java's objects, for things which functions are most appropriate.

Still, I like Java since it was very successful for shaking up the world away from old philosophies. I'll take it flaws and all. Things have flaws.

Tayssir John Gabbour
Wednesday, March 31, 2004