ThoughtWorks as being different from other software organizations.

• Leveraging bright people over Making the most of moderate people
• Flexible career paths over Well-defined roles
• Delivering business value over Leading edge research
• Learning new technologies over Mastering established technologies
• Solving difficult problems over Increasing market share
• Learning from mistakes over Avoidance of taking risks
• Delivery to the client over Quarterly results

Engineer A: "Spec says this must never happen"
Engineer B: "Can we enforce that in the type system?"

exceptions are not errors unless they are handled badly. Exceptions are opportunities for extra computation.

Semantic gap refers to the difference between expressing a problem in its own domain, and expressing it in some programming environment. [..] The programmer's job is to map a problem specified in problem domain semantics into the programming environment semantics. The smaller the semantic gap, the easier the job. The greater the semantic gap, the higher the salary the programmer commands.

Of course, blasting out hundreds of thousands of lines a year is missing the point. If a Wizard is given complete technical control over a project (which is usually the smartest thing to do, but companies are rarely very smart), the Wizard will typically write in one of the super-succinct “folding languages” they’ve developed on campus, usually a Lisp or Haskell derivative.

They call them Folding Languages because they write code that writes code that writes code… Wizards swear by it, and there’s no question that they can produce amazingly compact, fast, clean-looking code. But 90% of the devs out there claim they can’t read it, and whine a lot about it to their bosses. Given that most companies can only afford a few Staff Wizards, the Wizards are usually forced to capitulate and use Java or C++. They’re equally comfortable in any language you throw at them, though, and if you force them to use a verbose language, well, you get what you ask for. It still amazes me that companies are bragging about how many lines of code their Wizards have produced. Potential startups take note: your competitors are usually idiots.

Analytics: "Forward-looking"
Reporting: "Backward-looking"

A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.

-Robert A. Heinlein

T-Shirt idea: Happy lisper, sadly curly brace programmer

On the front: (:-))
On the back : {:-(}

Models are forever ... data is a happy side effect.

-David Laribee

Wadler's anecdote

While it might not be fair, the game industry's practices reflect the capitalistic nature of the business: they can work people harder because there's so many more people out there who want the work.

That being said, EA is gradually realizing that it takes more than warm bodies to ship games and that well-treated high-quality people are better than a barrel of noobs crunching every week.

...Please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list.

Kent M. Pitman

some of the ideas are interesting, but most (if not all) already existed as Mozilla bugs. For example, one thread per tab is https://bugzilla.mozilla.org/show_bug.cgi?id=40848, but process per tab is https://bugzilla.mozilla.org/show_bug.cgi?id=452272.

I will not be surprised when people incorrectly claim that already-existing plans for Mozilla 2 (Firefox 4) are “inspired” by Google Chrome.

There are four necessary conditions for a deadlock to occur, known as the Coffman conditions from their first description in a 1971 article by E. G. Coffman.

1. Mutual exclusion condition: a resource that cannot be used by more than one process at a time
2. Hold and wait condition: processes already holding resources may request new resources
3. No preemption condition: only a process holding a resource may release it
4. Circular wait condition: two or more processes form a circular chain where each process waits for a resource that the next process in the chain holds
   

Deadlock can only occur in systems where all 4 conditions hold true.

1. Find software out there that sells for $20,000 a copy
2. Pick the products that are supporting a handful of million-dollar companies
3. Build the product but only with the core features
4. Get your name out in the industry
5. Present yourself as consultingware -- it won't matter that it's you against big companies
   

What is Data Mining?

Automatically sifts through data to find hidden patterns, discover new insights, and make predictions.

Data Mining can provide valuable results:

• Identify factors more associated with a business problem (Attribute Importance)
• Predict customer behavior (Classification)
• Predict or estimate a value (Regression)
• Find profiles of targeted people or items(Decision Trees)
• Segment a population (Clustering)
• Determine important relationships and "market baskets" within the population (Associations)
• Find fraudulent or "rare events" (Anomaly Detection)

With most web applications today, the number of simultaneous users can greatly exceed the number of connections to the server. This is because connections can be closed during the frequent pauses in the conversation while the user reads the content or completes in a form. Thousands of users can be served with hundreds of connections.

But AJAX based web applications have very different traffic profiles to traditional webapps. While a user is filling out a form, AJAX requests to the server will be asking for for entry validation and completion support. While a user is reading content, AJAX requests may be issued to asynchronously obtain new or updated content. Thus an AJAX application needs a connection to the server almost continuously and it is no longer the case that the number of simultaneous users can greatly exceed the number of simultaneous TCP/IP connections.

If you want thousands of users you need thousands of connections and if you want tens of thousands of users, then you need tens of thousands of simultaneous connections. It is a challenge for java web containers to deal with significant numbers of connections, and you must look at your entire system, from your operating system, to your JVM, as well as your container implementation.

the sometimes dubious responses that various technology and development methods' offer to the overwhelming demand for software production. 

Waterfall: Nevermind backlog, requirements were signed off.

RAD: Build prototypes faster than discarding them.

Offshore outsourcing: Army of cheap developers producing junk.

Onshore outsourcing: Same junk, but with expensive developers.

Agile: Avoid featuritis; outrun pesky business users.

Domain-specific languages: Compress every problem into one-liners.

CMMi: Enough Process means nothing's ever wasted.

Relational Databases: Code? Who cares? Data lives forever.

Model-driven architecture: Jackson Pollack's models into inscrutable code.

Web Services: Terrorize XML until maximum reuse achieved.

FORTH: backward writing IF punctuation time SAVE.

SOA: Iron-fisted governance ensures total calcification.

Intentional programming: Parallelize programming... make programmers of everyone.

Google as IDE: It's been done, probably in Befunge.

Open-source: Bury the world in abandoned code.

Mashups: Parasitize others' apps, then APIs change.

LISP: With enough macros, one uberprogrammer sufficies.

perl: Too busy coding to maintain anyway.

Ruby: Meta-programming: same problems, mysterious solutions.

Ocaml: No, try meta-meta-meta-programming.

Groovy: Faster Java coding, runs like C-64.

Software-as-a-Service: Don't write your own, rent ours.

Cloud Computing: Programmers would go faster without administrators.

Design by Contract works.  Test Driven Development works.  So do Clean Room, code inspections and the use of higher-level languages. 

All of these techniques have been shown to increase quality.  And, if we look closely we can see why: all of them force us to reflect on our code.

That’s the magic, and it’s why unit testing works also.

“AI only needs to be as good as the character’s life expectancy.”

That’s the rule of thumb for the AI programming world.

Oracle's Cameron Purdy Looks at 10 Patterns for Scaling Out

10 - Understanding the Problem
9 - Define the Requirements
8 - Architecture Trumps Technology
7 - Understand the Basics
6 - Visualize the Networks
5 - Visualize the Design
4a - Plan for Overload
4b - Partition for Scalability
3a - Plan for Failure
3b - Replicate for Availability
2 - Tier Where It Makes Sense
1 - Simplify

1. Focus on people—their lives, their work, their dreams.
2. Every millisecond counts.
3. Simplicity is powerful.
4. Engage beginners and attract experts.
5. Dare to innovate.
6. Design for the world.
7. Plan for today's and tomorrow's business.
8. Delight the eye without distracting the mind.
9. Be worthy of people's trust.
10. Add a human touch.

The most common reasons optimization problems can't be solved with Mathematical Programming include:

• Constraints that are non-linear in nature, or that are linearized into an exponential number of linear constraints
• A non-convex solution space that contains many local optima
• Many disjunctions that result in a highly fractional relaxation with poor lower bounds

Level of Implementation of a Pattern

• Invisible: So much a part of language that you don’t notice. (e.g. when class replaced all uses of struct in C++, no more “Encapsulated Class” pattern.)

• Informal: Referred to by name, but must be implemented from scratch for each use.

• Formal: Implement pattern itself within the language; Instantiate/call it for each use; Usually implemented with macros.

• Make object creation as fast as possible. Don't do anything fancy in __init__.


• Use as few layers of abstraction as possible, especially when there is an object created in each layer.


• Push common or expensive operations down the layers of abstaction, especially if it avoids creating objects.


• Avoid using decorators for heavily used functions.


• Don't use wrapper classes if you don't have to.

What Lessons are in PAIP?

1. Use anonymous functions. [p. 20]
2. Create new functions (closures) at run time. [p. 22]
3. Use the most natural notation available to solve a problem. [p. 42]
4. Use the same data for several programs. [p. 43]
5. Be specific. Use abstractions. Be concise. Use the provided tools. Don't be obscure. Be consistent. [p. 49]
6. Use macros (if really necessary). [p. 66]
7. There are 20 or 30 major data types; familiarize yourself with them. [p. 81]
8. Whenever you develop a complex data structure, develop a corresponding consistency checker. [p. 90]
9. To solve a problem, describe it, specify it in algorithmic terms, implement it, test it, debug and analyze it. Expect this to be an iterative process. [p. 110]
10. AI programming is largely exploratory programming; the aim is often to discover more about the problem area. [p. 119]
11. A general problem solver should be able to solve different problems. [p. 132]
12. We must resist the temptation to belive that all thinking follows the computational model. [p. 147]
13. The main object of this book is to cause the reader to say to him or herself "I could have written that". [p. 152]
14. If we left out the prompt, we could write a complete Lisp interpreter using just four symbols. Consider what we would have to do to write a Lisp (or Pascal, or Java) interpreter in Pascal (or Java). [p. 176]
15. Design patterns can be used informally, or can be abstracted into a formal function, macro, or data type (often involving higher-order functions). [p. 177]
16. Use data-driven programming, where pattern/action pairs are stored in a table. [p. 182]
17. Sometimes "more is less": its easier to produce more output than just the right output. [p. 231]
18. Lisp is not inherently less efficient than other high-level languages - Richard Fateman. [p. 265]
19. First develop a working program. Second, instrument it. Third, replace the slow parts. [p. 265]
20. The expert Lisp programmer eventually develops a good "efficiency model". [p. 268]
21. There are four general techniques for speeding up an algorithm: caching, compiling, delaying computation, and indexing. [p. 269]
22. We can write a compiler as a set of macros. [p. 277]
23. Compilation and memoization can yield 100-fold speed-ups. [p. 307]
24. Low-level efficiency concerns can yield 40-fold speed-ups. [p. 315]
25. For efficiency, use declarations, avoid generic functions, avoid complex argument lists, avoid unnecessary consing, use the right data structure. [p. 316]
26. A language that doesn't affect the way you think about programming is not worth knowing - Alan Perlis. [p. 348]
27. Prolog relies on three important ideas: a uniform data base, logic variables, and automatic backtracking. [p. 349]
28. Prolog is similar to Lisp on the main points. [p. 381]
29. Object orientation = Objects + Classes + Inheritance - Peter Wegner [p. 435]
30. Instead of prohibiting global state (as functional programming does), object-oriented programming breaks up the unruly mass of global state and encapsulates it into small, manageable pieces, or objects. [p. 435]
31. Depending on your definition, CLOS is or is not object-oriented. It doesn't support encapsulation. [p. 454]
32. Prolog may not provide exactly the logic you want [p. 465], nor the efficiency you want [p. 472]. Other representation schemes are possible.
33. Rule-based translation is a powerful idea, however sometimes you need more efficiency, and need to give up the simplicity of a rule-based system [p. 509].
34. Translating inputs to a canonical form is often a good strategy [p. 510].
35. An "Expert System" goes beyond a simple logic programming system: it provides reasoning with uncertainty, explanations, and flexible flow of control [p. 531].
36. Certainty factors provide a simple way of dealing with uncertainty, but there is general agreement that probabilities provide a more solid foundation [p. 534].
37. The strategy you use to search for a sequence of good moves can be important [p. 615].
38. You can compare two different strategies for a task by running repeated trials of the two [p. 626].
39. It pays to precycle [p. 633].
40. Memoization can turn an inefficient program into an efficient one [p. 662].
41. It is often easier to deal with preferences among competing interpretations of inputs, rather than trying to strictly rule one interpretation in or out [p 670].
42. Logic programs have a simple way to express grammars [p. 685].
43. Handling quantifiers in natural languiage can be tricky [p. 696].
44. Handling long-distance dependencies in natural language can be tricky [p. 702].
45. Understanding how a Scheme interpreter works can give you a better appreciation of how Lisp works, and thus make you a better programmer [p. 753].
46. The truly amazing, wonderful thing about call/cc is the ability to return to a continuation point more than once. [p. 771].
47. The first Lisp interpreter was a result of a programmer ignoring his boss's advice. [p. 777].
48. Abelson and Sussman (1985) is probably the best introduction to computer science ever written [p. 777].
49. The simplest compiler need not be much more complex than an interpreter [p. 784].
50. An extraordinary feature of ANSI Common Lisp is the facility for handling errors [p. 837].
51. If you can understand how to write and when to use once-only, then you truly understand macros [p. 853].
52. A word to the wise: don't get carried away with macros [p. 855].

SCTP vs TCP vs UDP

The construction and manipulation of ST and IO actions does actually happen in a purely functional way — it’s running them which requires some extra effects. This seems like a minor point, but it really does end up being important.

For example, a function of type (t -> IO s) will compute the same action of type (IO s) when given the same parameter of type t each time.

the pros and cons of lazy evaluation as a default in Haskell:

Pros:

• Enables new forms of modularity, especially separation of generation from selection.
• "Non-strict semantics means that unrestricted beta substitution is OK".
• Recursive values are useful for building combinator libraries (see e.g. Peyton-Jones' own work on financial contracts (http://research.microsoft.com/Users/simonpj/Papers/financial-contracts/contracts-icfp.htm)).

Cons:

• Laziness "makes it much, much harder to reason about performance, especially space".
• Laziness "has a real implementation cost".
• Laziness "can be added to a strict language (although not as easily as you might think)".

Peyton-Jones concludes that laziness is a "hair shirt", but that it "keeps you honest" (by keeping implementors from sneaking in side-effects).

If you want to build a ship, don’t drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea.

To prove the correctness of code, you need to know exactly what correct behavior is for the code, i.e. a complete and unambiguous specification for what the code should do. So tell me dear reader, when was the last time you received an unambiguous fully detailed specification of an application?

If I ever received such a thing, I would simply execute that sucker, because the only unambiguous complete spec for what an application does is code. Even then, you have to ask, how do you prove that the specification does what the customers want?

"I find OOP technically unsound."

"I find OOP philosophically unsound."

"I find OOP methodologically wrong."

"I have yet to see an interesting piece of code that comes from these OO people."

"I think that object orientedness is almost as much of a hoax as artificial intelligence."

All the quotes above are from an interview with Alexander Stepanov[3], the inventor of the STL and elder statesman of generic programming.

-- The C1x Charter* (for the next C standard)

Lightweight Languages are not lightweight in the sense of ease of implementation, but they are called lightweight because of their intention to lighten the workload of the programmer.

Brevity is one element that helps make code beautiful. As Paul Graham says, “Succinctness is power.” In the vocabulary of programming, brevity is a virtue.

Brevity can also mean the elimination of redundancy. Redundancy is defined as the duplication of information.

In order to eliminate redundancy, we follow the DRY principle: Don’t Repeat Yourself. The concept of DRY is the antithesis of copy-and-paste coding.

Simplicity is the next element of beautiful code. We often feel beauty in simple code.

When simpler tools are used to solve a complex problem, complexity is merely shifted to the programmer.

Balance is the final element of beautiful code. So far I have talked about brevity, conservatism, simplicity, and flexibility. No element by itself will ensure a beautiful program.

Actors are computational agents which map each incoming communication to a 3-tuple consisting of:

• a finite set of communications sent to other actors;
• a new behaviour (which will govern the response to the next communication processed); and
• a finite set of new actors created.

A closure is a function that captures the bindings of free variables in its lexical context.

Validation is not designed to handle/support real business logic. Validation is a means to ensure that the data an object (or object graph) contains meets certain standards. It makes no judgment upon how that data fits within the overall business model. Business logic (and rules engines) represent decision-making capabilities. Validation engines don't.

Computers of today may be 1,000 times faster than they were a decade ago, yet the things that matter are slower.

The standard argument people give me in response is 'but they do such more these days it isn't a fair comparison'. Well, they're 10 times slower despite being 1000 times faster, so they must be doing 10,000 times as many things. Clearly the 10,000 times more things they're doing are all in the wrong place.

Exceptions are a tremendous debugging aid because they help answer these three questions:

• What went wrong?
• Where did it go wrong?
• Why did it go wrong?

When exceptions are used effectively, what is answered by the type of exception thrown, where is answered by the exception stack trace, and why is answered by the exception message.

The path to “flow”:

1. Immediate, meaningful, physical feedback
2. Natural, ergonomic control
3. Aesthetic pleasure
4. Capture a wide range of input data
5. Technology should serve simplicity
6. Progressive complexity
7. Activity oriented design

Personally, I prefer to read fromIntegral :: (Num b, Integral a) => a -> b like: 

IF (b is a Num) AND (a is an Integral) THEN (fromIntegral is defined and is a function from a to b)

a workflow engine (or Graph Oriented Programming in general) is about specifying a graph that represents an execution. The nodes can represent wait states.

a rules engine is about specifying a set of rules and then applying an inference algorithm for a given set of facts. So given a set of rules and a set of facts and an inference algorithm, there is one calculation that results from it. It’s a one shot calculation that possibly creates new facts or modifies the input facts. The rules are a form of if-then-else statements and the inference algorithm specifies how these rules will be applied at runtime.

One crucial difference between the workflow/BPM and rules is the fact that rules engines do not support wait states. And that is not necessary either because rules don’t specify any form of execution.

The overlap is to be found in state transitions in workflow/BPM engines. Processes in workflow or BPM can be considered as state machines. Then one state transition can related to one application of facts to a set of rules by a rules engine. For each state transition in a workflow/BPM process, you could think of a set of rules that will calculate the next state from a given state.

So in theory you could model all state transitions of a workflow/BPM process in terms of rules, but the wait states will remain the gaps. Those wait states are not representable in rules or facts.

Optimization

Optimization is generally viewed as the purposeful act of improving something under a set of circumstances. It is also generally viewed as a beneficial and useful process. I take exception to this. Optimization is good only when important choices are final -- and they usually aren't. An optimized system has lost some of its freedom to become something else. Any choice that is optimized for a particular set of conditions will be harder to adapt to other conditions than if it were not as optimized.

Optimization can only take place in one direction at a time (although that may consist of several conditions). If you want a change of direction, you will need to backtrack somewhat and start over. If you want a radically different solution, you may need to backtrack very far, and start all over again. The further you have progressed in one direction, the harder and more costly the change will be, because you may need to progress equally far in another direction before you get a system that is equally "good". This is why software systems are often discarded instead of attempted improved in a different direction. This is why software systems should be discarded instead of improving them in unintended directions.

Optimization means loss of freedom to navigate the solution space. As such, it should not be performed prematurely, and if at all possible, should be done by machine, such that whatever the human being sees is more intent than implementation. Examples of premature optimization include: explicit typing in programming languages, and explicit layout specification in electronic documents, both in office documents and on the WWW.

Unfortunately, designing any kind of system that is intended to be optimized by machine brings the implementation to a much higher level of abstraction, and few people can handle it unless trained not to think in terms of direct manipulation of the objects of the final product.

1. This works well with the physical characteristics of hard-disks. They have incredibly high transfer rates (10’s of Megs/sec) but very slow seek times (~ 200 seeks/sec if 5ms access time). If you are adding say 1k objects to a data-structure which requires 2 updates on average to a file then you’re looking at about 100 updates per second. If on the other-hand you write all of these updates to the end of the file then you’re looking at say 20,000 updates per second!


2. You can’t corrupt old data with interrupted writes. The old data is always still there. The only place that a corruption occur is at the end of the file, in which case you just scan backwards until you find the previous good head of your data-structure.

by Brian Smith <brianlsmith@gmail.com>

ProceduralProgramming. A program execution is regarded as a (partially ordered) sequence of procedure calls manipulating variables.

FunctionalProgramming. A program is regarded as a mathematical function, describing a relation between input and output.

ConstraintProgramming. A program is regarded as a set of equations describing relations between input and output.

ObjectOrientedProgramming. A program execution is regarded as a physical model, simulating the behavior of either a real or imaginary part of the world.

- Workflow tends to be ‘wide’ where Rule Engines tend to be  ‘deep’.

- Workflow is wide as the flow is spread over different people / actors and over time.

- Rule Engines are ‘deep’ as they apply simple rules to solve complex problems, but in general the rules are applied ‘all at once’.

a workflow engine (or Graph Oriented Programming in general) is about specifying a graph that represents an execution. The nodes can represent wait states.

a rules engine is about specifying a set of rules and then applying an inference algorithm for a given set of facts. So given a set of rules and a set of facts and an inference algorithm, there is one calculation that results from it. It’s a one shot calculation that possibly creates new facts or modifies the input facts. The rules are a form of if-then-else statements and the inference algorithm specifies how these rules will be applied at runtime.

One crucial difference between the workflow/BPM and rules is the fact that rules engines do not support wait states. And that is not necessary either because rules don’t specify any form of execution.

The overlap is to be found in state transitions in workflow/BPM engines. Processes in workflow or BPM can be considered as state machines. Then one state transition can related to one application of facts to a set of rules by a rules engine. For each state transition in a workflow/BPM process, you could think of a set of rules that will calculate the next state from a given state.

So in theory you could model all state transitions of a workflow/BPM process in terms of rules, but the wait states will remain the gaps. Those wait states are not representable in rules or facts.

the main features of Agile projects:

• Working Software over Comprehensive documentation
• Customer interaction over Contract negociation
• Responding to change over following a plan
• Individuals and interactions over processes and tools.

No matter what your system does , be it insurance , banking , online travel booking or telecoms, the chances are it does the following things:

• Gets information from users over the web
• Does some business processing on that information
• Saves the information in a database.

At a conservative estimate , about 99% of Enterprise systems would fall into this category.

If so, why do you need an architect , when you can use our ‘one size fits all’ architecture diagram (below)?! Most non-trivial systems, regardless of the language they are written in (be it Java, .Net , or your language of choice) follow the pattern seen in this diagram.

3 Tier Enterprise Diagram

There are 3 Pieces to the Solution:

• Web Browser (for the user / client).
• Web and Application Server - carry out business logic.
• Database Back End - to store data and ensure data integrity.

Within the Application Server (the middle bit above, which as Java Architects is the bit we are interested in), there are a further 3 tiers

• A Presentation tier (or layer), which is mainly about talking to the user (it gets and sends requests to the web browser).
• A Service layer , which is mainly about talking to back end such as databases, legacy systems (such as mainframes) and XML-Web services that we may use.
• A Business layer, the ‘meat’ of the sandwich, where the ‘Value add’ is in terms of business processing and validation.

For each of these layers , your priority in building them are slightly different.

• The Presentation layer is the bit the user sees. You want it to be fast and give a good impression to the client. Underneath, use a standard framework (link: pick your framework here) and then customize the look and feel.
• The Service layer you want to work fast and well (e.g. no data faults), but then then forget about. Unless things go wrong, no user is going to complement you on the quality of database persistence! Use standard libraries for the entire layer.
• Unless your company is a clone or franchise, the business layer in the system is going to be completely different. Aside from the user-interface , concentrate most of your project effort here as this is the core of what system does. We’ve written quite a bit about how to increase the value-add of the business layer (link to O’Reilly Technical Articles)

Most systems until now have been centralised : A bit like the old Soviet Union, everything is centrally planned. The trouble is real-life isn’t like that - it’s a market economy with no central control. There’s a story about a Russian Diplomat posted to New York in the 60’s. On a visit to a bakery he asked - who decides how many loaves are baked in the city? The answer is no-one - each baker individually decides how many to bake based on how many he sold the day before. Somehow (almost) everybody gets fed.

Current OO systems are like the Russian’s view: everything is centrally controlled. Agents are more like New-York (or Dublin) city today - a place full of people (agents) acting in their own self interest. Somehow everything works ok. Economists have a theory that backs this up ; in general a set of people acting in their own self interest gives the best solution at a global level. Or, if you prefer it’s a bit like Ants. Individual Ants are stupid, but together they are clever enough to mark a trail to food and carry it back to the Anthill. It’s called Emergent Behaviour - simple programs combining to give the answers to complex problems.

Here's my recipe for programming success:

• Get interested in programming, and do some because it is fun. Make sure that it keeps being enough fun so that you will be willing to put in ten years.

• Talk to other programmers; read other programs. This is more important than any book or training course.

• Program. The best kind of learning is learning by doing. To put it more technically, "the maximal level of performance for individuals in a given domain is not attained automatically as a function of extended experience, but the level of performance can be increased even by highly experienced individuals as a result of deliberate efforts to improve." (p. 366) and "the most effective learning requires a well-defined task with an appropriate difficulty level for the particular individual, informative feedback, and opportunities for repetition and corrections of errors." (p. 20-21) The book Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life is an interesting reference for this viewpoint.

• If you want, put in four years at a college (or more at a graduate school). This will give you access to some jobs that require credentials, and it will give you a deeper understanding of the field, but if you don't enjoy school, you can (with some dedication) get similar experience on the job. In any case, book learning alone won't be enough. "Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter" says Eric Raymond, author of The New Hacker's Dictionary. One of the best programmers I ever hired had only a High School degree; he's produced a lot of great software, has his own news group, and through stock options is no doubt much richer than I'll ever be.

• Work on projects with other programmers. Be the best programmer on some projects; be the worst on some others. When you're the best, you get to test your abilities to lead a project, and to inspire others with your vision. When you're the worst, you learn what the masters do, and you learn what they don't like to do (because they make you do it for them).

• Work on projects after other programmers. Be involved in understanding a program written by someone else. See what it takes to understand and fix it when the original programmers are not around. Think about how to design your programs to make it easier for those who will maintain it after you.

• Learn at least a half dozen programming languages. Include one language that supports class abstractions (like Java or C++), one that supports functional abstraction (like Lisp or ML), one that supports syntactic abstraction (like Lisp), one that supports declarative specifications (like Prolog or C++ templates), one that supports coroutines (like Icon or Scheme), and one that supports parallelism (like Sisal).

• Remember that there is a "computer" in "computer science". Know how long it takes your computer to execute an instruction, fetch a word from memory (with and without a cache miss), read consecutive words from disk, and seek to a new location on disk. (Answers here.)

• Get involved in a language standardization effort. It could be the ANSI C++ committee, or it could be deciding if your local coding style will have 2 or 4 space indentation levels. Either way, you learn about what other people like in a language, how deeply they feel so, and perhaps even a little about why they feel so.

• Have the good sense to get off the language standardization effort as quickly as possible.

Add Column

Alter Sequence

Create index

Create Sequence

Create Table

Drop Column

Drop Index

Drop Sequence

Drop Table

Insert Data

Modify Column

Rename Column

Rename Table

Custom SQL

When Does Ontological Classification Work Well?

Domain to be Organized

• Small corpus
• Formal categories
• Stable entities
• Restricted entities
• Clear edges

Participants

• Expert catalogers
• Authoritative source of judgment
• Coordinated users
• Expert users

You can also turn that list around. You can say "Here are some characteristics where ontological classification doesn't work well":

Domain

• Large corpus
• No formal categories
• Unstable entities
• Unrestricted entities
• No clear edges

Participants

• Uncoordinated users
• Amateur users
• Naive catalogers
• No Authority

10 tips on writing reusable code

1. Keep the code DRY. Dry means Don't repeat yourself. This is one of the main changes I have tried to bring in. Always try to eradicate duplication and if you find any then move remove the duplication to a relevant place. Sometimes this has lead me to create Static Helper classes or sometimes move it to the class it makes most sense to have it.

2. Make a class/method do just one thing. This is along the lines of the advice of giving the class only one reason to change. This often means creating methods that other methods use but this helps to make the methods/classes simple and less coupled.

3. Write unit tests for your classes AND make it easy to test classes. Writing code that is easy to test is decoupled. If you write code and are thinking about writing a unit test for it then you tend to split up the code into smaller testable chunks.

4. Remove the business logic or main code away from any framework code. Following the rules above will help this. An example I have seen is code that is inside Struts Actions classes, this code is practically impossible to reuse because of all the Struts dependencies that it now linked with.

5. Try to think more abstractly and use Interfaces and Abstract classes. Try to hide dependencies of code behind a more Generic interface/abstract class. The benefit this gives the code is it creates a flexible point in the code where you can then hide future changes behind.

6. Code for extension. Write code that can easily be extended in the future. This is particularly true with the above point. If you write code that uses interfaces then you can extend that interface at a later point.

7. Don't write code that isn't needed. Do the simplest thing possible. Don't waste your time adding methods and classes that might be used in the future. Keep the code simple and focused on what you are trying to deliver. I think I read/heard Josh Bloch say once that "if in doubt, leave it out". Basically who wants to write code that no one (including yourself) is going to use again.

8. Try to reduce coupling. When writing code think about the links and coupling the code is creating, does it need to be linked to those other classes.

9. Be more Modular - make your code more modular, think modular, be modular.

10. Write code like your code is an External API. Imagine the code you are writing is a self contained component.

Abstraction and indirection are very different yet cooperating concepts with two completely different purposes in software development. Abstraction is used to reduce complexity. Indirection is used to reduce coupling or dependence.

By creating a simple set of “rules” to evaluate an interface you can start to improve any existing or future code:

• An abstract interface should not require any configuration to use.
• A user of an abstract interface should not have to go through more than one function call in a chain to “find” any component they need.
• If an abstract interface wraps another interface then it should reduce the number of entry points (functions, fields, methods, whatever) when compared to the interface being wrapped.
• An abstract interface should not have the goal of being replaceable.
• If an abstract interface stands alone (i.e. doesn’t wrap another) then it should have a minimum number of entry points necessary to provide its services to others.

Design principles of X

In 1984, Bob Scheifler and Jim Gettys set out the early principles of X:

• Do not add new functionality unless an implementor cannot complete a real application without it.
• It is as important to decide what a system is not as to decide what it is. Do not serve all the world's needs; rather, make the system extensible so that additional needs can be met in an upwardly compatible fashion.
• The only thing worse than generalizing from one example is generalizing from no examples at all.
• If a problem is not completely understood, it is probably best to provide no solution at all.
• If you can get 90 percent of the desired effect for 10 percent of the work, use the simpler solution. (See also Worse is better.)
• Isolate complexity as much as possible.
• Provide mechanism rather than policy. In particular, place user interface policy in the clients' hands.

The first principle was modified during the design of X11 to: "Do not add new functionality unless you know of some real application that will require it."

Top ten ways to create a real J2EE disaster

• #10 Specifying the mechanism for data access without understanding the granularity of the data model


• #9 Assuming the container will take care of transactions


• #8 Using a stateless architecture


• #7 Designing the application for deployment on a single server and leave scalability and realibility up to the container


• #6 Utilizing popular technologies such as Web Services for component integration and remoting


• #5 Rolling your own frameworks


• #4 Distributing synchronous object graphs across servers


• #3 Designing logic and data flows assuming the application is a single-user system


• #2 Compensating for a lack of knowledge of the application domain by building in systemic flexibility


• #1 Putting off system testing until the application is ready to deploy

People-Related Mistakes	Process-Related Mistakes	Product-Related Mistakes	Technology-Related Mistakes
1. Undermined motivation 2. Weak personnel 3. Uncontrolled problem employees 4. Heroics 5. Adding people to a late project 6. Noisy, crowded offices 7. Friction between developers and customers 8. Unrealistic expectations 9. Lack of effective project sponsorship 10. Lack of stakeholder buy-in 11. Lack of user input 12. Politics placed over substance 13. Wishful thinking	14. Overly optimistic schedules 16. Insufficient risk management 17. Contractor failure Insufficient planning 18. Abandonment of planning under pressure 19. Wasted time during the fuzzy front end 20. Shortchanged upstream activities 21. Inadequate design 22. Shortchanged quality assurance 23. Insufficient management controls 24. Premature or too frequent convergence 25. Omitting necessary tasks from estimates 26. Planning to catch up later 27. Code-like-hell programming	28. Requirements gold-plating 29. Feature creep 30. Developer gold-plating 31. Push me, pull me negotiation 32. Research-oriented development	33. Silver-bullet syndrome 34. Overestimated savings from new tools or methods 35. Switching tools in the middle of a project 36. Lack of automated source-code control

With Interstage Business Process Manager, business users can:

• Model - Design and visualize business process steps with ease using Interstage Business Process Manager’s intuitive graphical process modeler. Reuse ARIS Business Architect process models and Microsoft Visio process maps to leverage existing investments in business process modeling
• Automate - Implement well-defined business processes that improves productivity and efficiency
• Integrate - Leverage existing IT infrastructure. Realize the value of an enterprise-wide shared infrastructure centered around CentraSite, Fujitsu’s SOA repository. Utilize Interstage Business Process Manager's modular, open standards-based architecture to make integration into existing environments easy while guaranteeing interoperability with future investments
• Manage - Track real-time process performance using Interstage Business Process Manager’s customizable Business Activity Monitoring (BAM) dashboards. Gain control over business operations with ARIS Process Performance Manager’s powerful process analytics and reporting capabilities
• Optimize - Identify and eliminate process bottlenecks and maximize resource utilization to improve business process efficiencies.

Some people say that any problem can be solved just by adding an other layer of indirections. Problem with that: Information is invariant under indirection.

Psychologists have identified a state of mind called flow in which we're capable of incredible concentration and productivity. The importance of flow to programming has been recognized for nearly two decades since it was discussed in the classic book about human factors in programming Peopleware: Productive Projects and Teams by Tom DeMarco and Timothy Lister (Dorset House, 1987). The two key facts about flow are that it takes around 15 minutes to get into a state of flow and that even brief interruptions can break you right out of it, requiring another 15-minute immersion to reenter. DeMarco and Lister, like most subsequent authors, concerned themselves mostly with flow-destroying interruptions such as ringing telephones and inopportune visits from the boss. Less frequently considered but probably just as important to programmers are the interruptions caused by our tools. Languages that require, for instance, a lengthy compilation before you can try your latest code can be just as inimical to flow as a noisy phone or a nosy boss. So, one way to look at Lisp is as a language designed to keep you in a state of flow.

Paul Graham (admittedly a biased source) says (emphasis mine),

"It's pretty easy to say what kinds of problems are not interesting: those where instead of solving a few big, clear, problems, you have to solve a lot of nasty little ones....Another is when you have to customize something for an individual client's complex and ill-defined needs. To hackers these kinds of projects are the death of a thousand cuts.

The distinguishing feature of nasty little problems is that you don't learn anything from them. Writing a compiler is interesting because it teaches you what a compiler is. But writing an interface to a buggy piece of software doesn't teach you anything, because the bugs are random. [3] So it's not just fastidiousness that makes good hackers avoid nasty little problems. It's more a question of self-preservation. Working on nasty little problems makes you stupid. Good hackers avoid it for the same reason models avoid cheeseburgers."

The Eight Fallacies of Distributed Computing 

		1.	The network is reliable
		2.	Latency is zero
		3.	Bandwidth is infinite
		4.	The network is secure
		5.	Topology doesn't change
		6.	There is one administrator
		7.	Transport cost is zero
		8.	The network is homogeneous

Erlang processes generally communicate with other Erlang processes in a homogeneous environment (note: Erlang processes are not OS-level processes). But each process doesn't know a lot about other processes. There's no reason they all have to be written in the same language.

Patterns are signs of weakness in programming languages.

The usual way in which we plan today for tomorrow is in yesterday's vocabulary.

Many people do not realise that Excel spreadsheets are functional programs.

AI - The art and science of making computers do interesting things that are not in their nature.

The primary disadvantage of packrat parsing is its storage cost, which is a constant multiple of the total input size rather than being proportional to the nesting depth of the syntactic constructs appearing in the input

Peter Scott made the point at OSCON 2006 that an average, one-hundred line Perl program can accomplish about as much work as an average, thousand line C program, yet developers take the thousand line program much more seriously than the hundred line program as it’s ten times the code.

Patterns are about what to build, not how to build it.

Any system in which two concurrent agents can name the same piece of data must also exhibit the standard problems of concurrency: broken serializability, race conditions, deadlocks, livelocks, lost event notifications, and so on. Concurrency control is simply a requirement if correctness is desired.

Figure 1 - Ten Negative Implications of Preemption

Dr Esponda sees great potential for using negative databases when there is a need to look at the intersection of many sets of data owned by different parties. Two or more banks, for example, might wish to work out which transactions they have in common without revealing the whole contents of their databases. Using negative databases to do this would, according to Dr Esponda, provide a robust back-up to traditional cryptography, which relies on codes that can be broken.

Its about the progression of a Lisp programmer - the newbie realizes that the difference between code and data is trivial. The expert realizes that all code is data. And the true master realizes that all data is code.

Lines of code is a lousy metric

I think that Dijkstra had it right: a line of code is a cost, not an asset. It costs money to write, and then it costs money to maintain. The more lines you have, the more overhead you have when you come to maintain or extend the application.

Libraries and languages are complicit: they affect each other in important ways. In the long run the language that makes libraries easier to write will accumulate more of them, and hence become more powerful.

Trying to retrofit ideas from one paradigm into a language designed for another is generally a bad idea.

The points on the Software Complexity Triangle are Simplicity, Power, and Design:


On this diagram, Simplicity represents the ease of using a system, both for end users as well as for operational support or back-office staff. Power represents the overall capability and depth of functionality of the system. Design represents the expertise of your software development team, particularly the depth and breadth of their technical skills as well as their knowledge of the problem domain in which they are working.

it’s like installing a huge relational database on the internet, where anyone can add tables to the database, and anyone can add data to a table. Tables and data can map to one another if you want, like foreign and primary keys

To faithfully model SQL we must, on some level, faithfully model the relational calculus. And this is where I think the Object Oriented programmers go astray in trying to interface to SQL. In their hurry to make things into objects, they immediately (and without fail) declare the rows to be objects- and thus miss the fact that relational calculus and thus SQL is about relations, not rows.

Another advantage functional programming confers on interacting with a database is immutable data structures- the elements of an instantiated relation/table are immutable, and thus the question of what happens when you change a row of a table is completely avoided, because you can’t change a row of the table except by explicitly inserting them.

Good, Fast, Cheap: Pick any two (you can't have all three)

We solve problems with computers, ultimately we do so with sequences of opcodes passed to the execution unit of our cpus; but the number of concepts we can express in a single sentence in machine code is limited, and the amount of detail we can choose to ignore when it is irrelevant to our solution is minimal. The act of climbing the language stack, (machine code -> symbolic assembly -> macro assembly -> C -> libc -> [java, Scheme, ML, etc]) is an exercise in increasing these two measures

The central problem with the von Neumann model is that it’s hard to reason about. The only way to understand a program written to the von Neumann architecture is to execute it.

those who do not understand Lisp are doomed to reinvent it (poorly)

The perception that monadic IO entails “jumping through hoops” is arguably an artifact of the sheer culture shock between programmers trying to get things done quickly and computer scientists trying to prove formal theories of program calculation.

Basically, what lazy evaluation brings to the table is that data-generating functions can be written abstractly, manipulated implicitly and computed only as actual results are requested.

So what would a language look like if it got rid of all of these non-composable constructs? The answer, basically, is Haskell. The underlying goal of functional language designers is to make everything completely composable. Haskell is the language that has advanced furthest towards this goal.

With macros, closures, and run-time typing, Lisp transcends object-oriented programming.

Type declarations let us say "the value of this parameter can't be just any value - it must be a value which is a member of this particular type"; type-class declarations let us say "the type parameter for instantiating this function can't be just any type - it must be a type which is a member of this type-class."

Curry-Howard isomorphism, which shows that type systems for lambda calculus are isomorphic to inference systems in some logic. The simply-typed lambda calculus has a type system related to simple propositional logic; Haskell, with its type variables, has a type system derived from first order predicate logic.

Abstraction, as they say, is an artifact of the solution domain, which should ultimately bring you closer to the problem domain.

OASIS (the Organization for the Advancement of Structured Information Standards) defines SOA as the following:

A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

(SOA) Service: A mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description

1. Conceptualize the problem mathematically and physically and give a rigorous but perhaps implicit set of equations describing it.
2. Select a numerical algorithm, that is, an explicit arithmetical procedure (which may be approximate) to replace these rigorous mathematical expressions.
3. Do a numerical analysis to estimate the precision of the approximation process by means of an investigation of the role of errors introduced by the procedure (truncation errors) and by the machine (round-off errors).
4. Determine the scale factors so that the mathematical expressions do not assume values that fall outside the fixed range of the computer at any time during the course of the computation.
5. Do the dynamic analysis by drawing a flow diagram.
6. Write the static code and enter it into the machine.

Description of programming from ‘Planning and Coding of Problems for an Electronic Computing Instrument’ by Goldstine and von Neumann, 1947-48. Quoted in ‘John von Neumann and the Origins of Modern Computing’ by William Aspray (MIT Press, 1990).

All users are evil.

Design for users, not programmers.

JavaScript must only be used for interface enhancements.

Clean separation of logic, presentation and interface every time.

Semantics matter.

Standards matter.

Document or die.

Security through obscurity is no security at all.

KISS: Start simple. Enhance later.

Use the team. We’re on your side.

By being pure (no side effects), by being non-strict, and by structuring computation with monads, Haskell forces you to think differently in order to use it effectively.  This is the greatest difference between Haskell and other languages such as, say, Lisp, that allow you to think differently.

A closure is a function that captures the bindings of free variables in its lexical context.

What are the lexically scoped language constructs in Java?

• The meaning of variable names.
• The meaning of method names.
• The meaning of type names.
• The meaning of this.
• The meaning of names defined as statement labels.
• The referent of an unlabelled break statement.
• The referent of an unlabelled continue statement.
• The set of checked exceptions declared or caught.
• The referent of a return statement.
• The definite assignment state of variables.
• The definite unassignment state of variables.
• The reachability state of the code².

Correlation is not the same thing as causation - but it's a darn good hint!

The evaluation context, i.e. call stack, is not about the history of the program execution. It contains a complete record of the remainder of the program execution, the work the program has left to do.

stack inspection is fundamentally about inspecting the future of the computation, not about recording its history

a language only evolves if its designers and advocates can acknowledge problems

Think of a monad as a spacesuite full of nuclear waste in the ocean next to a container of apples. now, you can't put oranges in the space suite or the nucelar waste falls in the ocean, *but* the apples are carried around anyway, and you just take what you need

Validation is not designed to handle/support real business logic. Validation is a means to ensure that the data an object (or object graph) contains meets certain standards. It makes no judgment upon how that data fits within the overall business model. Business logic (and rules engines) represent decision-making capabilities. Validation engines don't.

The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous. We wouldn't tolerate plumbers or accountants that poorly educated. We don't have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and undertrained.

good design often takes second place to deadlines -- and a language that has the appearance of slowing development won't get far, even if it offers a net gain

The interaction between distributed (and therefore concurrent) activities involves two things: data transfer and coordination. Synchronisation to avoid race conditions is just one form of coordination. Systems also need to coordinate activities that don't share data. Message-passing covers all forms of coordination.

The major advantage of STM as a system is that it gives you certain guarantees about composability of already working systems. It's not magical, it doesn't always ensure that things will play nicely together, but it does give you far more guarantees about the correctness of compositions than previous systems have.

Do message passing, ala MPI or Erlang, at the top level, breaking the problem up into big chunks which can then be distributed over a local network or a highly non-uniform ccNUMA architecture. But then each chunk is solved in a microthread+STM approach, allowing for good utilization of local resources and tightly coupled parallel processes.

The only advantage message passing has over STM in the emergent complexity department is that it encourages bigger chunks per thread (due to the relatively high cost of communication)- fewer interacting components means less emergent complexity. But fewer interacting components also means less parallelism, and less performance on future hardware.

Wether it’s Erlang and message passing, Haskell and STM, or some hybrid, it looks like the solution is going to be functional programming plus something else. What really drove the adoption of OO programming was GUIs

The question is asked over on LtU about my transactional memory rant...

why is the under-the-covers complexity of STM bad, when the under-the-covers complexity of garbage collection is good?

There is a glaringly obvious answer to this...

A garbage collector eliminates tons of complexity from the application developer's burden, allowing the app developer to focus more on the true problem domain.

Transactional memory does no such thing. Application developers have to think about shared memory, potential conflicts, how to express them as transactions, and as mental points out: ultimately how to *recover* from a transaction failure.

Scala is what I consider a very pragmatic (to steal a buzzword from the hype generators) approach to software development as it exists today. It satisfies the incompetent assertions of the illegitimate authority (aka management) — “you must use Java (et al.)”, while still allowing a reasonably concise expression and programming paradigm e.g. Scala has pattern matching, case classes, variance annotations, higher-order functions and implicit defs (similar to Haskell type-classes). These features alone dramatically reduce the amount of repititious work that you otherwise do in more mainstream languages by one of those crazy orders of magnitude that would never be believed by a mainstream programmer and so could easily be explained away as nonsense with support from other ill-informed peers (those who know what I mean, know what I mean).

many functional data structures can compactly represent not just their current state, but all of their past states as well--a feature called "Persistence".

Maybe the debate about adding closures to Java isn't really about adding closures to Java. Maybe it's about bringing higher order programming to Java, where the most vocal part of the debate involves complaining about the proposed syntax, or questioning the value making a large language definition even larger..

We know about as much about software quality problems as they knew about the Black Plague in the 1600s. We've seen the victims' agonies and helped burn the corpses. We don't know what causes it; we don't really know if there is only one disease. We just suffer -- and keep pouring our sewage into our water supply.          -- Tom Van Vleck

"Yet by obscuring the true data source these solutions end up throwing away the most compelling feature of relational databases; the ability for the data to be queried."

Microsoft, DLinq .NET Language-Integrated Query for Relational Data, May 2006

Wexelblat's Scheduling Algorithm:

Choose two:

• Good
  
• Fast
  
• Cheap

"If you think good architecture is expensive, try bad architecture."

language features that any new language needs to provide today to "not suck":

1. Object-literal syntax for arrays and hashes
2. Array slicing and other intelligent collection operators
3. Perl 5 compatible regular expression literals
4. Destructuring bind (e.g. x, y = returnTwoValues())
5. Function literals and first-class, non-broken closures
6. Standard OOP with classes, instances, interfaces, polymorphism, etc.
7. Visibility quantifiers (public/private/protected)
8. Iterators and generators
9. List comprehensions
10. Namespaces and packages
11. Cross-platform GUI
12. Operator overloading
13. Keyword and rest parameters
14. First-class parser and AST support
15. Static typing and duck typing
16. Type expressions and statically checkable semantics
17. Solid string and collection libraries
18. Strings and streams act like collections

how to write any computer program in two easy stages:

• Design and implement the programming language which would be best for solving the problem.
• Write the program in the language you’ve just implemented.

Hypothesis 1: Human interface cognitive load is proportional to the number of clicks/keystrokes/gestures.

Hypothesis 2: Human interface cognitive load is inversely proportional to interface latency.

Hypothesis 3: The usability of an interface is inversely geometrically proportional to its cognitive load.

messaging is something that should be built under an object transport layer, not on top of it. Messaging is a more general idiom than object method invocation.

Any sufficiently complicated Lisp or Ruby program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Haskell.

When you type "class Foo" in Java or C++, it does three things:

1. It declares a new type called "Foo".

2. It declares a _set_ of types (i.e. a "class").

3. It declares that the type Foo (and all of its subtypes) is a member
of the set of types Foo.

In Haskell, these three operations are distinct.

1. You declare a new type using "data" or "newtype".

2. You declare a new set of types using "class".

3. You declare that a type is a member of a class using "instance".

You can think of a type as a set of values.  For example, Bool is the
set { False, True }.  A "class", then, is a set of types.

The distinction between "set" and "class" comes from the various set
theories (Goedel-Bernays-von Neumann set theory being the most common)
which try to avoid Russell's Paradox.

Make it correct, make it clear, make it concise, make it fast.  In that order. 

A language is strict if it evaluates the arguments to a function before it evaluates the function. A non-strict language doesn’t.

Monads in functional programming provide a framework for aspect-aware computations to be composed to build higher-level aspect-aware computations. An aspect-aware computation is some basic computation that has been enhanced, augmented, or, more generally, just transformed, to become aware of some generic concern.

Errors such as taking head or tail of the empty list in Haskell are equivalent to the dereferencing of the zero pointer in C/C++ or NullPointerException in Java. These errors occur because the true domain of the function is smaller than the function's type suggests.

The Semantic Web will never work because it depends on businesses working together, on them cooperating.

The big open secret of software development is that good programmers aren't engineers at all -- we're artists, and artists who aren't living on the edge aren't living at all.

Shared memory systems are impossibly difficult to understand and get right, especially when errors occur. It’s bad enough without errors, but with errors it’s virtually impossible. If a program holds a lock and is messing around with shared memory and crashes how the heck can the other processes know what it was doing and fix up the errors?

Transaction memories and pure message passing system suffer from none of these problems.