34
Java: It's better than you think, for reasons you haven't realized you already know. William Grosso Chair, Emerging Technology SIG SDForum

Java And Community Support

Embed Size (px)

DESCRIPTION

A talk given early in 2003 by William Grosso at CSU Sonoma. At the end of 2008, it stands up remarkably well.

Citation preview

Page 1: Java And Community Support

Java: It's better than you think, for reasons you haven't realized

you already know.

William GrossoChair, Emerging Technology SIGSDForum

Page 2: Java And Community Support

In this talk, the speaker will draw upon his past experience as chair of SDForum's Java SIG (www.sdforum.org/sigs/java) and his current role as the chair of SDForum's Emerging Technology SIG (www.sdforum.org/sigs/emerging) to explain why beginning and intermediate programmers should learn Java, why most (practical) software innovations over the next few years will involve programs written in Java, and why programmers using Java-based systems are going to reinvent the internet over the next 5 years.

Page 3: Java And Community Support

About the Speaker

• Masters in Mathematics, U.C. Berkeley• Currently: Vice President of Technical

Services, Hipbone Incorporated• Author

– Java RMI (O’Reilly and Associates)– Java Enterprise Best Practices (O’Reilly and

Associates)– Working on a book about the Globus Project

Page 4: Java And Community Support

More Importantly

• Chaired SDForum’s Java SIG for 3 years

• Current chair of SDForum’s Emerging Technology SIG

http://www.sdforum.org/sigs/java

http://www.sdforum.org/sigs/emerging

Page 5: Java And Community Support

The Point of this Talk

• I want to convince you of two things– That Java, or some language like it, is

inevitable from a technological point of view– That Java itself is inevitable from a social point

of view.

• I want to avoid using the traditional technology or “computer science” based arguments

Page 6: Java And Community Support

DISCLAIMER:Most of this is not Mine

• Shamelessly stealing from Marc Fleury, Dick Gabriel, Paul Graham, Bill Joy, Peter Norvig, Todd Proebsting, Joel Spolsky, and others.

• Follow the URLs and do google searches.

Page 7: Java And Community Support

Evaluating a Programming Language

Page 8: Java And Community Support

Typical Arguments

Lisp is better than Java because Java doesn’t support tailrecursion very well (or Lisp has better macros or …)

C++ is better than Java because it compiles to native code and will always be faster

C++ is better than Java because you can allocate memory usingthe stack– it’s way more efficient

My language has a preprocessor and yours doesn’t.

Page 9: Java And Community Support

Typical Arguments are Boring

• There are lots of “language arguments” that are based on some artifact of the implementation or algorithms

• Usually these boil down to “X is better than Y because I’m used to X”

• Often these reflect a lack of understanding of the programming process– Everyone’s engaged in them, of course

Page 10: Java And Community Support

Arguments Based on Program Speed are Particularly Silly

• Intel has solved this problem already– My home machine has a gig of RAM and a

2GHZ processor– So does yours (or it will soon)

• What’s the difference between 2 milliseconds and 4 milliseconds?

• This generalizes to resource consumption

Page 11: Java And Community Support

Paul Graham2. Speed Comes from Profilers. Language designers, or at least language implementers, like to write compilers that generate fast code. But I don't think this is what makes languages fast for users. Knuth pointed out long ago that speed only matters in a few critical bottlenecks. And anyone who's tried it knows that you can't guess where these bottlenecks are. Profilers are the answer.

Language designers are solving the wrong problem. Users don't need benchmarks to run fast. What they need is a language that can show them what parts of their own programs need to be rewritten. That's where speed comes from in practice. So maybe it would be a net win if language implementers took half the time they would have spent doing compiler optimizations and spent it writing a good profiler instead.

http://www.paulgraham.com/langdes.html

Page 12: Java And Community Support

Counterargument (Norvig)

• “Mainframe Economics”– Google has 15,000 Linux boxes– A factor of two matters here.

• In fact, Google uses:– A custom build of Linux– A carefully defined hardware platform– C++ and “inner loops written in assembly”

Page 13: Java And Community Support

CounterCounterArgument (Graham)

Back in 1995, we knew something that I don't think our competitors understood, and few understand even now: when you're writing software that only has to run our your own servers, you can use any language you want. When you're writing desktop software, there's a strong bias toward writing applications in the same language as the operating system. Ten years ago, writing applications meant writing applications in C.

But with Web-based software, especially when you have the source code of both the language and the operating system, you can use whatever language you want.

If you can use any language, which do you use? We chose Lisp. For one thing, it was obvious that rapid development would be important in this market. We were all starting from scratch, so a company that could get new features done before its competitors would have a big advantage. We knew Lisp was a really good language for writing software quickly, and server-based applications magnify the effect of rapid development, because you can release software the minute it's done. http://lib1.store.vip.sc5.yahoo.com/lib/paulgraham/sec.txt

Page 14: Java And Community Support

Acceptable Technical Arguments

• Memory management (“managed code”)

• Scriptability / The existence of a well-defined interpreted environment

• Changeability– the ability to change program behavior in radical ways without restarting the program or otherwise disrupting existing users.

Page 15: Java And Community Support

Memory Management

I'll go out on a limb here. In my years of experience, I have seen many language and programming fads come and go. But there's only ONE, that's right, ONE language feature I've ever seen that actually improves your productivity significantly. No, it's not object oriented programming; no, it's not intentional programming or assertions or programming by example or CASE or UML or XML or Java. The only thing that improves your programming productivity is using managed code - that is, using a language in which memory management is automatic. Java and .NET languages do this with garbage collection; VB does this with reference counting; I don't care how you do it, just let me concatenate strings without thinking about where the new bigger string will go and I'll be happy.

http://www.joelonsoftware.com/printerFriendly/articles/fog0000000006.html

Page 16: Java And Community Support

Scriptability

• Ability to quickly test pieces of code in an interpreted environment

• Perl, Python, and Lisp have this.

• Almost all startups use at least one of these for “quick and dirty” code

• I prefer Python; your mileage may vary

Page 17: Java And Community Support

Changeability

• Ability to change software on the fly, in a controlled fashion– Not so important on desktops– Very important in web applications

Page 18: Java And Community Support

Graham on Changeability

3. What Do You Need for Server-Based Software? I think a lot of the most exciting new applications that get written in the next twenty years will be Web-based applications, meaning programs that sit on the server and talk to you through a Web browser. And to write these kinds of programs we may need some new things.

One thing we'll need is support for the new way that server-based apps get released. Instead of having one or two big releases a year, like desktop software, server-based apps get released as a series of small changes. You may have as many as five or ten releases a day. And as a rule everyone will always use the latest version.

You know how you can design programs to be debuggable? Well, server-based software likewise has to be designed to be changeable. You have to be able to change it easily, or at least to know what is a small change and what is a momentous one.

Page 19: Java And Community Support

That’s All Good Stuff

Page 20: Java And Community Support

The Biggest Open Problem In Programming Languages

• Increasing Programmer Productivity– Write programs correctly

– Write programs quickly

– Write programs easily

• Why?– Decreases support cost

– Decreases development cost

– Decreases time to market

– Increases satisfaction

http://research.microsoft.com/~toddpro/papers/disruptive.ppt

Page 21: Java And Community Support

What Proebsting Missed

• Individual Programmer Productivity is important– If individual programmers aren’t productive,

then the game is over

• Community Productivity is More Important– Bill Joy– “No matter how big and smart your

company is, there are more smart guys working outside your company.”

Page 22: Java And Community Support

The Big Bold Claim

• In the world of the future, programs will be increasingly be written by communities

• The single best measure of whether a programming language is worth using is: how well does it support communities.– The social aspects of the language dominate the

technological aspects of the language

Page 23: Java And Community Support

Supporting Communities

• New programmers must be able to get up to speed in the language

• Platforms to learn the language on must be cheap and plentiful

• Programmers must be able to use the language on whatever machine they’re using

• Programmers must be able to understand and reuse each other’s code

• Old code must survive in a useful form– And evolve and improve

Page 24: Java And Community Support

Revisiting Language Design

• Paul Graham’s 5 Principles of Language Design

http://www.paulgraham.com/langdes.html

1. Programming Languages Are for People. Programming languages are how people talk to computers. The computer would be just as happy speaking any language that was unambiguous. The reason we have high level languages is because people can't deal with machine language. The point of programming languages is to prevent our poor frail human brains from being overwhelmed by a mass of detail.

Page 25: Java And Community Support

Write Once, Run Anywhere (WORA)

• One of the original claims behind Java

• “Write in Java, and it’ll run on any machine that has a JVM”

Employee: Hey! Microsoft just changed the Windows API again. Damn

that Evil Monopoly (tm). Our app is crashing !!!!!!

Boss: Hey. Chill out. No problem. Netscape and SUN are porting the

app, even as we speak.

Page 26: Java And Community Support

Original WORA Claim is False

• “write once, debug anywhere”• Problems with “native look and feel

applications”– Java apps don’t quite look like Windows apps

• Subtle differences in things like threading implementations often mean you have to performance tune on platforms

• In general, abstractions leak

http://www.joelonsoftware.com/articles/LeakyAbstractions.html

Page 27: Java And Community Support

WORA Almost Succeeded

• You can read anyone's code

• You can figure out what makes sense

• You can take and adapt whatever works for you

• A whole new style of programming

Write Half, Steal the Rest

Page 28: Java And Community Support

WORA Promoted Readability

• Promoted an active culture of borrowing• I’m not claiming I can immediately understand

any piece of Java code on the net– But I can understand the good ones (and easily)

• Regardless of the platform the code started out on

• Interesting test:– Go to jakarta.apache.org, look at a checkin, and try to

figure out what platform the author was working on

– You can’t do it

Page 29: Java And Community Support

WORA Promotes Software Survival

• Java code will survive.– Write today, use next year.– Easy to maintain at a fixed level of

functionality

• C++ code, on the other hand, needs new ifdefs for every platform that comes along.

Page 30: Java And Community Support

Java Enables Evolution

• Bad Code Dies

• Good Code Lives On– And is modified– And evolves– And becomes better

Page 31: Java And Community Support

// Boost compiler configuration selection header file

// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and// distribute this software is granted provided this copyright notice appears// in all copies. This software is provided "as is" without express or implied// warranty, and with no claim as to its suitability for any purpose.

// See http://www.boost.org for most recent version.

// locate which compiler we are using and define// BOOST_COMPILER_CONFIG as needed:

#if defined __GNUC__// GNU C++:# define BOOST_COMPILER_CONFIG "boost/config/compiler/gcc.hpp"

# elif defined __COMO__// Comeau C++# define BOOST_COMPILER_CONFIG "boost/config/compiler/comeau.hpp"

#elif defined __KCC// Kai C++# define BOOST_COMPILER_CONFIG "boost/config/compiler/kai.hpp"

#elif defined __sgi// SGI MIPSpro C++# define BOOST_COMPILER_CONFIG "boost/config/compiler/sgi_mipspro.hpp"

#elif defined __DECCXX// Compaq Tru64 Unix cxx# define BOOST_COMPILER_CONFIG "boost/config/compiler/compaq_cxx.hpp"

#elif defined __ghs// Greenhills C++# define BOOST_COMPILER_CONFIG "boost/config/compiler/greenhills.hpp"

#elif defined __BORLANDC__// Borland# define BOOST_COMPILER_CONFIG "boost/config/compiler/borland.hpp"

#elif defined(__ICL) || defined(__ICC)// Intel# define BOOST_COMPILER_CONFIG "boost/config/compiler/intel.hpp"

#elif defined __MWERKS__// Metrowerks CodeWarrior# define BOOST_COMPILER_CONFIG "boost/config/compiler/metrowerks.hpp"

#elif defined __SUNPRO_CC// Sun Workshop Compiler C++# define BOOST_COMPILER_CONFIG "boost/config/compiler/sunpro_cc.hpp"

#elif defined __HP_aCC// HP aCC# define BOOST_COMPILER_CONFIG "boost/config/compiler/hp_acc.hpp"

#elif defined(__MRC__) || defined(__SC__)// MPW MrCpp or SCpp# define BOOST_COMPILER_CONFIG "boost/config/compiler/mpw.hpp"

#elif defined(__IBMCPP__)// IBM Visual Age# define BOOST_COMPILER_CONFIG "boost/config/compiler/vacpp.hpp"

#elif defined _MSC_VER// Microsoft Visual C++//// Must remain the last #elif since some other vendors (Metrowerks, for// example) also #define _MSC_VER# define BOOST_COMPILER_CONFIG "boost/config/compiler/visualc.hpp"

#elif defined (BOOST_ASSERT_CONFIG)// this must come last - generate an error if we don't// recognise the compiler:# error "Unknown compiler - please configure and report the results to boost.org"

#endif

www.boost.org

This is what highly portable C++ looks like.

Page 32: Java And Community Support

WORA == Community

• Reuse lots of code from different places– Very little need to worry about platform dependencies

– Widespread adoption of coding conventions

– And large-scale libraries

• Java programming articles are useful to anyone. – I program on Windows, using an IDE. I get feedback

from people using Emacs on Linux.

There is no such thing as a C++ programmer.

Page 33: Java And Community Support

More Community Support

• ANT– cross-platform build scripts

• Java Coding Conventions

• The massive, and growing, open source projects out there

http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html

http://ant.apache.org/

http://jakarta.apache.orghttp://www.jboss.orgetcetera

Page 34: Java And Community Support

Conclusions

• Core technical features of a language are important

• Programmer productivity is important– Lisp, Java, Python, C# are all excellent so far

• Libraries are important– Java and (less so) C# standout here

• Community support is the next level– Java is unique here