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

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

2. 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.

7. Evaluating a Programming Language

8. Typical Arguments Lisp is better than Java because Java doesn’t support tail recursion 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 using the stack– it’s way more efficient My language has a preprocessor and yours doesn’t.

11. Paul Graham 2. 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

13. 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

15. 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

18. 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.

19. That’s All Good Stuff

31. // 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.