|
development management |
OOP FP |
NEW Lisp languages |
NEW design patterns miscellaneous | theory |
development | |
| Fred Brooks |
No Silver Bullet: Essence and Accidents of Software Engineering
A classic article from the author of The Mythical Man-Month Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any |
|---|---|
| Steve McConnell | 36 DON'Ts of software development |
| Hacknot | Extreme Deprogramming (in Essays on Software Development) The nature of XP The Skeptical Software Development Manifesto The over-enthusiastic and often uncritical adoption of XP and Agile tenets by many in the software development community is worrying. |
object-oriented programming (OOP) | |
| Steve Yegge | Execution in the Kingdom of Nouns How much of a program should really be objects? Verbs in Javaland are responsible for all the work, but as they are held in contempt by all, no Verb is ever permitted to wander about freely. |
| Jon Rees |
post on E-lang I think comprehensive OO (occasional OO is fine) is a very poor metaphor for the world, a poor tool for problem solving, and an unnatural way to think. Email on OOP C/C++ folks see OO as a liberation from a world that has nothing resembling a first-class functions, while Lisp folks see OO as a prison since it limits their use of functions/objects |
functional programming (FP) | |
| Slava Akhmechet | |
| bhurt-aw | The Functional-Relational Impedance Match Lazy lists are dramatically better than objects for interacting with relational databases. By concentrating on the row level and demoting the relation level to second class citizens, [OOP] totally misses the power and point of relational calculus. |
| Martin Fowler |
Closure
|
| Christopher Diggins |
Typing like a Functional Programmer
|
| MarkCC | Like Lisp and Smalltalk, it shows you a new way to think about programming. |
| Paul's Pontifications | "No Silver Bullet" and Functional Programming The author believes FP really is a "silver bullet". |
languages | |
| Joel Spolsky |
I have never met anyone who can do Scheme, Haskell, and C pointers who can't pick up Java in two days, and create better Java code than people with five years of experience in Java... |
| NEW David Chisnall |
What Programming Languages Should You Know? C (low level), Smalltalk (OOP), Lisp (macros), Erlang (concurrency), Haskell (pure FP), and Prolog (logic) Eventually, someone might create a programming language that is the ideal choice for all uses. (Lisp programmers will argue that this has already happened.) Also, someone on Reddit suggested Forth (stacks). |
| Paul Graham |
We want to write a function that generates accumulators... In...Fortran, C, C++, Java, and Visual Basic—it is not clear whether you can actually solve this problem. |
| Steele & Sussman | |
| Mike Vanier |
Scalable computer programming languages
a review of popular languages for use in large projects, written in 2001, with updates in 2003 and 2006 |
|
|
design patterns | |
| NEW Peter Norvig |
Design Patterns in Dynamic Programming An online slide presentation about buiding design patterns into dynamic languages. |
| NEW Greg Sullivan |
Advanced Programming Language Features for Executable Design Patterns (Click "The GOF Design Patterns in a Dynamic OO Language" in the Projects section.) Language features such as reflection, higher-order functions, multiple dispatch, and predicate types have a positive impact on the implementation of nearly all of the Gang of Four Design Patterns. In some cases, the need for an explicit pattern nearly disappear; ... Other patterns become much simpler; ... Other patterns, ... are a universal programming concept, but could be supported by more sophisticated type systems. |
miscellaneous | |
|
NEW Peter Norvig |
Teach Yourself Programming in Ten Years "the lyf so short, the craft so long to lerne." Even in programming, patience is a virtue. |
| Donald Knuth |
more comments does not mean more readable code |
| ririan project | |
| Too Much Code |
... the messaging model in Erlang prevents many types of timing problems. Functional languages may eliminate the many types of bugs which arise from side effects. The essence of a design should not be concerned with timing or unexpected side effects, so whenever possible this should be solved in the language itself. ... Code in object-oriented languages often includes many unessential objects that are just noise from a high-level view. |
theory | |
| Ray Djajadinata | Y Combinator for Dysfunctional Non-Schemers Very nice introduction to the Y combinator, using examples in JavaScript. I come across these mental landmines like "pass the function as the first argument to itself", and my brain will just explode Actually, it's not the whole function. It's just a reference to it. |
| Guy Steele & Gerald Sussman | The original "Lambda: The Ultimate" articles discussing efficiency issues in implementing programming languages. |
| Jonathan Bartlett | Lazy programming and lazy evaluation Sometimes by delaying an evaluation until just before the value is needed, you can either optimize the speed of a program or restructure a program into a more intelligible form. |
| D. A. Turner | Total Functional Programming (pdf) The author proposes a super-pure functional language that's not even Turing complete, but the only programs that can't be written in it are ones that don't terminate. A special type called "codata" is required for programs that aren't supposed to terminate. The existing model of functional programming ... is compromised ... by the presence of partial functions. We consider a simple discipline of total functional programming designed to exclude the possibility of non-termination. Among other things this requires a type distinction between data, which is finite, and codata, which is potentially infinite. |