Ken Arnold
From Wikipedia, the free encyclopedia
- This article discusses a well known programmer/software architect. For other uses of the term, see Ken Arnold (disambiguation).
Ken Arnold (Kenneth Cutts Richard Cabot Arnold, Kenneth C.R.C. Arnold) is a computer programmer well known as one of the developers of the 1980s dungeon-crawling computer game Rogue, contributions to the original Berkeley (BSD) distribution of Unix, books and articles about C/C++ (e.g. his 1980s/1990s Unix Review column "The C Advisor"), and high profile Java work (Jini, JavaSpaces).
Contents |
[edit] Java, Jini, JavaSpaces at Sun Microsystems
Formerly senior engineer at Sun Microsystems Laboratories, Ken is a leading expert in object-oriented design and implementation, C, C++, Java, and distributed computing. He was one of the original architects of the Jini technology, oversaw Jini future development as Jini Technology Community Coordinator/Source Lead, the lead engineer and main implementor of Sun's JavaSpaces technology, and worked with Jim Waldo on the Remote Method Invocation and object serialization team.
[edit] Other Background
Ken was part of the original Hewlett-Packard architectural team designing CORBA, several user interface and UNIX projects at Apollo Computers, a molecular graphics programmer in the Computer Graphics Lab at UC San Francisco, and served as a member of the UNIX Review Software Review Board.ok
[edit] U.C. Berkeley and BSD Unix Contributions
At U.C. Berkeley, Ken was President of the Berkeley Computer Club and of the Computer Science Undergraduates Association, and made many contributions to the 2BSD and 4BSD Berkeley Unix distributions, including:
- Curses (programming library) and Termcap: a hardware-independent library for controlling cursor movement, screen editing, and window creation on ascii display terminals, based on termcap (based on Bill Joy's vi screen control code). Curses was a landmark enabling technology that made it possible for a vast number of new applications to create full screen user interfaces that were not dependent upon particular display terminal brands.
- Rogue (computer game): (co-author with Michael Toy and Glenn Wichman) a full-screen role playing game that presented a then-novel view of the "dungeon" from above (rather than via textual description as in the older Zork and Adventure, and that spawned an entire genre of Roguelike games.
- Note that despite occasional confusion on the topic, it was a different Ken Arnold (a "Ken W. Arnold") who contributed to the game [Ultima].
- Fortune (program): a fortune cookie program. Although Ken's quote-displaying program was not the first in history, as the BSD standard it became by far the most widely used, and Ken's database of quotes was voluminous. It also standardized a plain-text text file format that was philosophically aligned with Unix philosophy and thus became widely used both for other fortune programs as well as non-fortune purposes.
- Other BSD Unix games by Ken Arnold: Cribbage, Hangman, Hunt, Mille Bourne, Monopoly, Robots.
- Ctags: a very early special-purpose hypertext link generator that essentially turned the vi editor into an IDE (Integrated Development Environment). It indexes program objects (such as functions) in a way such that the vi editor (and its clones such as vim) knows how to navigate to an object/function definition starting from any instance of the object's name elsewhere in the source code.
He received his A.B. in Computer Science from U.C. Berkeley in 1985.
[edit] Books and Articles
- JavaSpaces. Principles, Patterns, and Practice; Eric Freeman, Susanne Hupfer, Ken Arnold; ISBN 0-201-30955-6
- The Java Programming Language; 4th Edition; Ken Arnold, James Gosling, David Holmes; ISBN 0-321-34980-6
- The JiniTM Specification, 2nd Edition; Ken Arnold, Jim Waldo and the rest of the Jini technology team. Part of the official Jini Technology Series, published by Addison Wesley.
- A C User's Guide to ANSI C; Ken Arnold, John Peyton.
- "The C Advisor" column in Unix Review (authored by Ken Arnold 198? - 199?)
- "Fear and Loathing on the UNIX Trail -- Confessions of a Berkeley system mole."; Doug Merritt with Ken Arnold and Bob Toxen; Unix Review, Jan 1985
- "Rogue: Where It has Been, Why It Was There, And Why It Shouldn't Have Been There In The First Place"; USENIX Conference Proceedings; Summer 1982; Ken C.R.C. Arnold, Michael C. Toy
[edit] Selected Ken Arnold Quotes
Ken has an irrepressible (and oft-misunderstood) sense of humor.
- "Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, it is evident that every program can be reduced to one instruction that does not work."
- "First you listen to the users; then you ignore them."
- "I think that the terseness of Unix programs is a central feature of the style. When your program's output becomes another's input, it should be easy to pick out the needed bits. And for people it is a human-factors necessity -- important information should not be mixed in with verbosity about internal program behavior. If all displayed information is important, important information is easy to find."
- "Simplicity has real value on its own that makes the system more usable. It's the difference between reading a 100-page manual and reading a 500-page manual. It is more than five times the size." Taste
- "Someday this will no doubt be a vivacious page, brimming with fascinating information, penetrating analysis, and the most succulent links. Until then, this will have to do."
- "Now that we have all this useful information, it would be nice to do something with it. (Actually, it can be emotionally fulfilling just to get the information. This is usually only true, however, if you have the social life of a kumquat.)" Curses
[edit] Ken's Little Red Book
At a previous job, some of us put together a list of how to understand Ken, who enjoys good phraseology well enough to sometimes let easy comprehension slip away.[original research?]
- If it's that complicated, it must be wrong
- KISS. Perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away. (Antoine de Saint-Exupery)
- The two rules of debugging are (1) Don't think, Do! (2) Don't do, Think!
- The trick is knowing when to apply each rule. In general, when thinking hard has you frustrated, you need data, and when the data isn't telling you much, you need to think.
- You're thinking too hard
- When your problem seems complex, try pretending it's a simple problem. You are likely to find this makes it so. The same is true when someone (often Ken himself) suggests something that seems to require hard thinking or a complex answer. They may have been thinking of something much simpler, if you only step back and look at
- What makes you so smart?
- Also "All the smart people don't work here. " If other people have a solution to your problem, why do you think you're smarter than them? And why do you think we should spend your time proving you're smarter than them? We only build things that we can't find that make us valuable to our customers. For everything else, we borrow someone else's smarts, work, and support.
- You can train smarts, but you can't smart trains
- There is a reason why "train" is a verb and "smart" isn't. The longer form of this is: "You can hire smart people and train them, but you can't hire trained people and smart them."
- First you listen to the users, then you ignore them
- You need to listen through what users say to what they ought to have said. They know they have a problem, but why do they have it and what really should be done? If it's hard to adjust the frobnitz, you could do what they ask to make it easier. But it may be better to make frobnitz adjustment less finicky or, better yet, unnecessary.
- That's an implementation detail
- That is not part of the public API, and it might be done many different ways. The more things you can say this about and still satisfy the design goals, the better the design on average.
- That's what we're paid for
- We get paid to do the hard stuff to make the user's life easy.
- Hardware is free
- Compared to writing, debugging, and maintaining some fancily optimized wad of code, it is usually cheaper to require a more capable machine.
- Trust Moore's Law
- Moore's Law (chip power doubles every 18 months) has been a reality for decades. Take it seriously. When you design for the future, don't fight today's limitations.
- All the code you don't write works
- Every line of code you avoid writing is a line of code without bugs. Consider the full cost of owning the code. Write clear code and let the compiler or machine make it faster. Tools that do a lot of your work for you makes your code smaller.
- Any organization with two or more people is dysfunctional
- Successful organizations succeed despite their dysfunctions. After all, by definition they're not competing against functional organizations. The game is to find yourself a place with compatible dysfunctions.
- Programmers are people
- Good programmers are creatively lazy
- Doing things twice is painful, and more than twice is anathema. This is related to a well-known fact of computer science: There are only three numbers, 0, 1, and "many". When you get past 1, you have just discovered that you will need this "many" times. Don't ignore this discovery.
- Why make things simple when they can be complicated?
- This is sarcastic. When Ken says this, duck.
- Design from the outside in
- Write the pseudo-code your users wish they could write. Then make it work with as little change as you can. Design from their viewpoint inwards, rather than from your implementation concerns outwards. If this makes your work harder, that's what we're paid for.
- Ain't nobody here extra
- Why do we hire someone to answer the phones? So other folks don't have to. If you're one of the other folks, remember: That person makes you more effective. And if that wasn't important, we wouldn't have them answer your phones for you, would we? When it's time to ask who makes our success possible, the answer is "everyone".
- Do one thing right.
- Each tool/component should do one job right. That's hard enough. This is the Unix tool philosophy.
- Names matter
- Names are critical building blocks in cognition. The name and the thing become intimately intertwined in the mind. Picking a good name is crucial, and worth investing time in. Not just for products, but for naming components of a design (types, methods, etc.). Until a name is relied upon by others, we can change names fairly easily: That's what a good IDE is for. Or sed, depending.
- Who needs that?
- Systems that let you do everything make doing anything hard. Systems that do only what you need make doing needed things easier. Much easier. We can all imagine someone wanting a feature. The hard question is whether anyone really cares (even if they say they do, first you listen to the users, then you ignore them). [Note: This really is a question, not a way to so "no".]
- "surface area"
- "Surface area" is Ken's term for the amount of stuff you need to know before you can use something. The larger the surface area the more complexity in the usage model. Surface area is increased not only by the number of explicit things, but also by the number of ways things interact. Not surprisingly, less surface area is generally better than more, which is one reason we ask "Who needs that?"
- Accept failure
- Things will fail, especially in distributed systems. Any design that works when nothing goes wrong does not work. Any failure that is too unlikely to happen will. You cannot add failure recovery after the design, at least not done well. You design for failure. "It's not a distributed system unless the failure of a computer you have never heard of can screw you."
- State is hell
- Managing state in a distributed system introduces complexity, especially when dealing with failure, and we have to accept failure. Minimize the role state plays, and how many components own state (as opposed to using state, which is someone else's problem).
- Don't be perfect
- Also, "A decision is a valuable thing." There is no such thing as a perfect design. There are only good designs. Over time, striving for perfect designs becomes decreasingly effective and eventually it's work avoidance. Academics call this "publish or perish".
[edit] See also
- History of computer and video games
- Rogue (computer game)
- Curses (programming library)
- Fortune (program)
- The Art of Unix Programming
