A Brief History of Programming, Part 2
- Nov 2, 2007
- Article is provided courtesy of Prentice Hall Professional
- The State of Open Source 3D
- What Is Mac OS X?
- Snow Leopard: The Underhyped APIs
- Foundation: The Objective-C Standard Library
- Cocoa Tips: Exposing System Services
- Cocoa Tips: Don't Reimplement Standard Functionality
- Localizing Cocoa
- How Core Animation Changed Cocoa Drawing
- Using Distributed Objects in Cocoa
- Inside Modern X11 Programming
- Making JavaScript Fast, Part 2
- Security in Your Pocket: OpenBSD on ARM
- Making JavaScript Fast, Part 1
- The Failure of the GPL
- How Not To Optimize
- A Half-Way Step to Apple’s Source Code: An Interview with David Chisnall
- Advanced Flow Control for Objective-C
- Erica Sadun on the iPhone SDK, OS X, and the Computing Landscape
- From NeXTSTEP to Cocoa: Erik Buck on the Development of Cocoa and Objective-C
- Fun with the Objective-C Runtime
- Marcus Zarra and Matt Long on Core Animation
- Steve Kochan on the Evolution of Objective-C
- The Technology NeXT Gave the World
- Where the Web and the Desktop Meet: An Interview with Lee Barney
- Pandora: An Open Console
- The Future of Wireless Networking
- GNU or Linux?
- Debugging C-Family Languages
- How Small Is Your PC? The Rise of Netbooks and Other Small Form-Factor PCs
- David Chisnall's CPU Feature Wishlist
- The Dynamic Languages Renaissance
- Robert Seacord on the CERT C Secure Coding Standard
- Objective-C for C++ Programmers, Part 3
- Objective-C for C++ Programmers, Part 2
- Objective-C for C++ Programmers, Part 1
- Writing Insecure C, Part 3
- Writing Insecure C, Part 2
- Writing Insecure C, Part 1
- iRex iLiad e-Reader: Linux's Answer to the Kindle?
- How It Works: Filesystems
- How the LLVM Compiler Infrastructure Works
- How It Works: Virtual Memory
- What Is C For?
- The Future of eBooks
- Imagining an Open Network
- Understanding How Xen Approaches Device Drivers
- Examining the Legendary HURD Kernel
- Competition Among Open Source Compilers
- Inside Your OS: What is a Process Scheduler, and How Does it Work?
- Bad UI of the Week: Read This (OK/Cancel)
- The End of the Desktop Era
- The What and Why of Open IM
- A Look at the Modern X Server
- The Future of Digital Media
- The Future of Identity
- Bad UI of the Week: Ask Forgiveness, Not Permission
- Copyright Versus Free Software
- Is Computer Science Dying?
- A Brief History of Programming, Part 2
- A Brief History of Programming, Part 1
- The 700MHz Question: Will the Wireless Spectrum Auction Lead to Innovation or More of the Same?
- Bad UI of the Week: The Menu Bar
- The Dark Corners of x86
- Bad UI of the Week: The Cross-Platform User Interface
- Bad UI of the Week: The Mythical "is Like" Operator
- Bad UI of the Week: Don't Make Me Tell You Twice...
- Bad UI of the Week: Kettles and Washing Machines
- The BBC iPlayer Controversy Explained
- Bad UI of the Week: The Mitten Mouse
- Bad User Interface of the Week: File It Under “Bad”
- Bad User Interface of the Week: The DVD
- A Roundup of Free Operating Systems
- DragonFly BSD: UNIX for Clusters?
- CPU Wars, Part 3: Put Your Left ARM In
- CPU Wars, Part 2: POWER to the People
- CPU Wars, Part 1: When the Chips Are Down
- ZFS Uncovered
- Vector Programming with GCC
- Free Software Versus Open Source Software
- What Programming Languages Should You Know?
- Standardizing UNIX
- Prolog: Logic Programming for Rapid Development
- POSIX Parallel Programming, Part 3: Threads
- POSIX Parallel Programming, Part 2: Message Passing
- POSIX Parallel Programming, Part 1
- The Nokia 770 Revisited
- The Open Source Desktop Myth
- Separating Style and Content: LaTeX and Typesetting
- GNUstep: A Free Software alternative to OpenStep
- Behind the Scenes of Objective-C 2.0
- The Future of CPUs: What's After Multi-Core?
- What Makes a Good Programming Language?
- Emulation: Role-Playing for Computers
- NetBSD: Not Just for Toasters
- POSIX Asynchronous I/O
- Breaking Down GPL Version 3
- The Role of Binary Drivers in a Free OS
- Security Is a UI Problem
- Debunking the Myth of High-level Languages
- A Taste of Erlang, a Dynamic, Asynchronous Message-Passing Language
- Alternatives to LAMP
- BSD Packaging Systems
- DRM: Digital Rights or Digital Restrictions?
- Introducing OpenBSD 3.9
- The Need for Virtualization and Xen
- Making Effective Software TCO Calculations
- 10 Things I Hate About U(NIX) Revisited: Readers Speak
- Comparing Open Source Licenses: GPL vs. BSDL
- BSD: The Other Free UNIX Family
- Measuring the Effectiveness of Application Security Policies
- The Cost of Free Software
- Nokia 770 Internet Tablet Week-long Test Drive
- 10 Things I Hate About (U)NIX
- The Lure of Open Source Software: Why Consider It for Your Business?
- Cocoa Tip of the Day, 1/29/10
Don't ignore old versions of OS X.
- Cocoa Tip of the Day, 1/28/10
Exceptions should be exceptional.
- Cocoa Tip of the Day, 1/27/10
Explore the runtime system.
- Cocoa Tip of the Day, 1/26/10
Copy design patterns from Cocoa.
- Cocoa Tip of the Day, 1/25/10
Profile with Instruments.
- Cocoa Tip of the Day, 1/22/10
Expose system services.
- Cocoa Tip of the Day, 1/21/10
Always read the release notes for new OS X versions.
- Cocoa Tip of the Day, 1/20/10
Broadcast events with notifications.
- Cocoa Tip of the Day, 1/19/10
Port your code with GNUstep.
- Cocoa Tip of the Day, 1/18/10
Use CoreAnimation for caching.
- Cocoa Tip of the Day, 1/15/10
Don't recreate standard features.
- Cocoa Tip of the Day, 1/14/10
Don't forget NSCell.
- Cocoa Tip of the Day, 1/13/10
Plan for code reuse.
- Cocoa Tip of the Day, 1/12/10
Remember the C in Objective-C.
- Cocoa Tip of the Day, 1/11/10
Separate interfaces and implementations.
- Cocoa Tip of the Day, 1/8/10
Think about localisation early.
- Cocoa Tip of the Day, 1/7/10
Read the Human Interface Guidelines.
- Cocoa Tip of the Day, 1/6/10
Don't optimise yet.
- Cocoa Tip of the Day, 1/5/10
Put controllers in nib files.
- Cocoa Tip of the Day, 1/4/10
Don't write code.
- Cocoa Tip of the Day, 1/1/10
Use Distributed Objects for local network communication.
Like this article? We recommend
Art of Computer Programming, The, Volumes 1-3 Boxed Set, 2nd Edition
Editor's Note: Start by reading Part 1 of this series if you haven't already.
Procedures are a way of tidying up program structure, but they are also very similar, conceptually, to mathematical functions. The difference between functions and procedures relates to state.
Beyond Procedures
A mathematical function has no concept of global state, while a procedure does (and can reference global program state as well as its own).
If you add restrictions to procedures—forcing them to behave as functions—you can then use mathematical reasoning to prove that aspects of your program are correct.
This is the foundation for languages such as Ocaml and Haskell. Haskell, for example, is a pure functional language—everything is a function. Haskell has no global state, so the result of a function depends solely on its input, as with a mathematical function.
This has a couple of interesting side effects from the perspective of efficiency. The first is that execution order becomes less important. If you have already computed the arguments to a function, you can compute the result whenever you want.
If you have computed the arguments to two functions, you can run them both in parallel because no global state means no side effects.
You also get the idea of lazy evaluation. If you don’t use the return value of a function, you don’t need to bother computing it.
This has been used to produce some simple programs that run on very large data sets and only bother loading the parts that are accessed. The program is written as though it performs a computation on the whole dataset, but only results that are used are executed, so only data needed to compute them is loaded.
Account Sign In
View your cart