The speaker advocates for Java as an essential language for beginning and intermediate programmers, arguing its inevitability in technological and social contexts. He emphasizes the importance of managed code for productivity and the future of web-based applications, while also highlighting Java’s supportive community and resources. The document discusses various programming language arguments, focusing on developer productivity, community engagement, and the evolving landscape of programming languages.

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.

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

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

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

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

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.

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

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

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

12. 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”

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

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

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

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

17. Changeability Ability to change software on the fly, in a controlled fashion Not so important on desktops Very important in web applications

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

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

21. 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.”

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

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

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

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

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

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

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

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

30. Java Enables Evolution Bad Code Dies Good Code Lives On And is modified And evolves And becomes better

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.

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

33. 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.org http://www.jboss.org etcetera

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