Lambda the Ultimate

"I think the real topic of the article is how practice is different from theory, and how crusty old practitioners like the author know better than mandarin professor-theorists up in their ivory towers."

Even more bizarre, it's about how "amateurs working alone" like the author know better than "professionals and academics".

Was the article against OOP or against C++?

I gave up reading when I got to the statement, "most programming is done by individuals".

Whatever the mapping between a problem domain and a design, it's always a mapping and always requires some ingenuity.

One of the biggest ways in which OOP has been oversold is the notion that OOP mappings are somehow more natural or intuitive than other mappings. That depends entirely on what intuitions you have acquired!

If all you know and practice is OOP, your intuitions will most likely be OOP intuitions and OOP solutions will feel correspondingly more intuitive and less ingenious. One of the advantages of trying out different models is that if one perseveres with them one can begin to acquire new intuitions.

For instance, although I still program in an OOP style most of the time, since I started dabbling more frequently in Haskell there have been more and more occasions when I've found myself wishing I could write a nice reduce foo n . map bar to transform some data set - it seems so much more natural to do it that way (and Google agrees!).

Complaints that this approach is somehow more complicated or difficult to understand seem totally nonsensical to me...

I mostly agree with you. I also spend nearly 100% of my time in the OOP world and on many occasions I do find that the odd functional concept would make my program easier to read and require far less time and typing. However, I would like to reiterate my view that OOP is the closest programming approach to real problems most of the time.

My belief stems from the propensity of people to see systems as a collection of things with certain properties that interact in certain ways, rather than a bunch of functions called in a sertain sequence on an input. True, you can acquire the skill to see things this way with practice but the catch with OO is that one requires minimal training to grasp the idea of objects as they are so close to real life conceptually. Grasping the idea of functional programming isn't more difficult at a basic stage (i.e. functions as first class citizens, polymorphism etc), but the intuition stops abruptly when you try to get people to design a solution to a complex problem (e.g. an online bookshop). With OO, a person is likely to think "Well, I have a bunch of Books that have Authors, which will be purchased by Customers who have creditCardNumbers)", whereas what does a normal human begin think when you ask them to produce a functional solution?

Perhaps I have fallen into the trap of being one of those who can no longer think in a non-OO way. I do not discount this as a possibility. The OO way is a nice comfort zone and with practice showing that it does the job, it might be hard to escape. Please feel free to recommend books/resources that demonstrate how "real" software is designed in other methodologies, particularly FP. Then we'll be able to see how close those concepts are to the average problem at hand.

What you've just described sounds more like a relational/first-order logic model than anything specifically OO, e.g. Author(person,book) etc. You can encode this into a functional language easily enough (e.g. as a set of tuples, or as a boolean function to indicate set inclusion). In fact, if you take "object" as meaning just a thing with a bunch of attributes, then you can easily model that as a key and a bunch of relations. For me, it's the inheritance aspects of OO which are distinguishing features. But you can encode those into a functional/relational language too.

Are you asserting that OOP is suitable for more than GUIs, or that OOP is suitable for most real-life problems?

If the former, you're attacking a strawman. The article stated that OOP is often a useful paradigm, just not enough to justify excluding other alternatives. It's aimed at those people who claim that OOP is great as a one-size-fits-all paradigm.

If you're making the latter, stronger claim, you're going to have to justify it.

Note that I disagree with many points of the article, which is written from a rather mainstream perspective. I'm fairly certain that many people on LtU will agree that in order to defend OOP, you have to defend the need for subclass polymorphism and dynamic dispatch specifically.

Data abstraction and encapsulation are entirely independent of OOP, the typical mainstream class facility is just one way of implementing them.

In my experience, "OO" programs with shallow class hierarchies are usually only making use of the class facility for abstraction and encapsulation. Programs with deep class hierarchies are often unnecessarily complex and inefficient.

Can you provide examples of real world problems where deep class hierarchies are a useful way of representing things?

Note that I disagree with many points of the article, which is written from a rather mainstream perspective. I'm fairly certain that many people on LtU will agree that in order to defend OOP, you have to defend the need for subclass polymorphism and dynamic dispatch specifically.

Are classes necessary for OOP? Isn't the existence of other approachs like prototypes, "lambda-objects" (e.g. E language), structural subtyping, etc. an evidence that they aren't necessary? IMO classes are the wrong tool to solve a fuzzy problem.

But I assume that they are something implied by most OOP advocates.

Rather than try to define "what is essentially OOP" (definitions vary depending on who you ask), I was trying to exclude commonly misattributed features that are definitely not in any way unique to OO languages.

Retrofitting a formalism to a framework for dealing with "things that have properties and can do stuff to each other" was never going to produce something as clean as, say, ML. It does, however, map better on to real problems.

There are some formalisms that can be applied to OO that are clean and deal with things that have properties and can do stuff to each other. Bart Jacobs' papers on coalgebraic specification of classes comes to mind (e.g. The Coalgebraic Class Specification Language CCSL, Coalgebras in Specification and Verification for Object-Oriented Languages, Objects and classes, co-algebraically).

OO language designers usually ignore formalisms and just use ad-hoc solutions, instead going the FPL way: start with a basic calculus (e.g. sigma calculus, opulus) and extend it with some theoretically proven features (e.g. type-classes, functors, uniqueness). A formal treatment of the features available in OO languages like Java, Eiffel or Smalltalk is available at The Theory of Classification (this is the latest column, earlier columns introduced the basic formal ideas used in this one).

IMHO such approachs are as clean as ML. The problem isn't in inexisting formalism, but on clueless language designers.

If OOP so closely matched the real problem domain, then it would be easy. The fact that "after 10 years, people still don't get OOP" is not necessarily an indication of programmer quality (at least, not to as great an extent as many say). Rather, I think it points to a mismatch between OOP's stated advantages and its real-world use.

I think OOP is very useful when you have a designer that is good at mapping the real-world to OOP solutions (and further knowing where OOP is going to get in the way, for both large and small problems).

I wonder if this is a programmer issue. The strengths of the languages that most people use is that they are, for the most part, multi-paradigm. Also for the most part, there are only two paradigms supported (OOP and procedural). Multi-paradigm is good, because one size does not fit all. But it's bad because it discourages people from learning OOP properly.

I often wonder if OOP would be more successful if programmers were forced to spend a year solving problems in languages like Smalltalk, Eiffel and Erlang; the idea being that your C++ would look a lot less like C when you were done.

Another good reason not to do education using whatever language happens to be popular today, and I definitely recommend CTM and Oz for the same reason you're suggesting Smalltalk, Eiffel, and Erlang. Working familiarity with many different concepts leads to better implementations in whatever language is ultimately used.

In contrast a logic programmer is like a full-sighted man and can see and work on any aspect of the system.

The logical/relational paradigm is established and dominant in database technology. It will be at least another 10 years before the same occurs for software development.

Robert Kowalski has published an online book How to be Artificially Intelligent – the Logical Way . In particular Chapter 10 Logic and Objects discusses the relationship of logic programming to OOP.

I started reading the online form of Robert Kowalski's book and also looked at the short article about the Wason Selection Test. I find the following excerpt mildly amusing as well as instructive:

The negation of the concept "the number is 3", however, has no natural positive representation. Worse than that, as we will see later, if we are given as input an observation that "the number is 7", it is difficult to derive the conclusion that "the number is not 3". This is because we could equally well derive that "the number is not 1", "the number is not 2", etc. It is only because we are asked to test a rule referring to the number 3, that we are able to make the mental leap from "7" to "not 3".

Isn't the mapping of OOP to real-world objects a little overrated? Consider design patterns, which are by definition supposed to be commonly seen in OOP. What exactly are say, visitor objects in the real world? Are they any less abstract than corresponding solutions in other paradigms? Ditto for controller objects in MVC.

Sure, it's easy to identify the concrete objects early on, but orchestrating them together in a solution is not at all intuitive and it requires thinking just as abstract as in any other paradigm, if not more so since you chose to see everything early on as only objects and nothing but.

The major advantage of OOP is that it allows to map real-life problems to a design and then an implementation.

No, you're talking about OOAD (Object Oriented Analysis and Design).

I would argue that historically, OOAD is indeed a strength of OOP. One of the reasons why OOP became as popular as it did is that it came with an analysis and design methodology such that the solution space (i.e. the language you're implementing in) and the design space (i.e. what your design methodology created) were extremely close. Interestingly, it's also the tight integration of OOAD and OOP which has led to the over-hype by tools vendors.

OOAD doesn't reflect "real life problems" any better or worse than any other big-M Methodology. What it does do, though, is that it breaks a problem down into schedulable entities. Even if it doesn't model the problem very well, it does model the solution in a way that managers can hand out work assignments. "You write this object and you write this object." That is a strength, of sorts.

You're talking about having a restricted enough language to force programmers to use the same approach for every problem. In this case, you're also confusing OOP with data abstraction and encapsulation, because a popular "OO" language (Java) happens to use the same mechanism for both while being crippled enough that it doesn't really support anything else.

Using a restricted language may be necessary when you have teams of bad or lazy programmers, but when you're using the same approach for every problem, it'll also very often be the wrong tool for the job.

There are far too few programmers who are good at using different kinds of methods of abstraction, but those programmers are likely to be far more productive given the chance to use powerful tools than the lazy ones that require crippled languages in order to produce maintainable code.

I do agree with you (and disagree with the author of the article) that the traditional C/C++ procedural approach is usually a bad idea for anything non-trivial, but there are far more alternatives than OOP vs. procedural.

But the state of programming is never going to improve if people think that teaching programmers only one way to approach problems is a good idea. You'll only end up with bad programmers. That shouldn't be the goal. Something like this should be.

Or, indeed, this.

I am talking about two things:

1) OOP being really useful.
2) it's better for a project if discipline is enforced rather than suggested.

I agree that good programmers will be far more productive when given powerful tools. For example, I prefer C++ because I like templates, and I am much more productive with templates rather than with Java.

But how often is it guarranteed that the same good programmer will always be available to maintain a project? In the real world, a programmer being too good is usually a problem: the others can't follow him, and he can't be replaced.

As for 'far more alternatives' to OOP/procedural, would you like to provide some links? I only know about one other real alternative: functional programming.

For what other professions is it true to say that in the real world, an <x> being too good is usually a problem: the others can't follow him, and he can't be replaced?

I've heard that this is a problem with musicianship, where someone with too much talent can unbalance a band and is likely to be leave for better offerings quickly.

Personally, I prefer to call programmers like the ones described as "too clever" rather than "too good". There are plenty of good programmers who realize that code which may be a clever solution to a tactical problem can easily create strategic problems that are worse. The keys are whether your "clever solution" obscures or illuminates design intent, and whether the programmer views coding as a solo performance or an orchestral collaboration.

I think this is a property of really good programmers: that their solutions make it easier for others to proceed, because they clarify the domain model and provide pertinent abstractions for general use.

The advanced language features that are often argued against on strategic grounds are often the features that you need to do this: they support library writers and creators of new frameworks, and may not be really suited for ad hoc use in everyday code (the scripting layer at the top of the stack). The trouble is, if you don't allow anyone access to those features, you force everyone to muddle along without the benefits that a tastefully-chosen set of macros or decorators or custom attributes or what-have-you could provide.

A really good bass player does nifty things that nobody notices directly - the odd passing note, the off-the-beat accent here or there - that provide the underpinnings of a band's whole groove. Does that have anything to do with programming? I guess it can if you want it to. ;)

Logic/Declarative is more widely used than acknowledged. But in terms of real world, the Relational model is perhaps the most pervasive. (and no, the relational model is not the same thing as either OO or Procedural - which fall under the imperative programming umbrella).

I don't think logic/declarative/relational are alternatives to imperative programming. Would you care to mention an example of an algorithm that can be expressed with those 'paradigms'?

Well, declarative type programming is used in most of the spreadsheet programs in the world. And relational databases contain a lot of the data of the world.

But I guess, the bigger question is what do you mean by algorithm? And does that automatically assume a procedural aspect? An algorithm can either be looked at as "a step-by-step procedure for solving a problem or accomplishing some end especially by a computer", which means that it's a self fulfilling prophecy that the procedural is the only method that is capable of producing a "procedure".

Or you can look at an algorithm, not in terms of how it accomplishes it's goals but rather as a timeless transformation of some input to some output. In that sense, algorithms can be expressed in non-procedural terms, functional, relational, or any other numbers of logic/maths.

Functional programming is nothing more than imperative without assignments. In other words, the programmer is not allowed to change the state of a variable, because the change might create bugs. FP does not trust the programmer. Other than that, it is a procedure-oriented paradigm: a function is a computation step amongst other computation steps. Since FP has steps, it is procedural, i.e. the flow of computations is coded by the programmer. Of course FP has many other properties that are not directly related to the main concept; for example, pattern matching, closures etc that exist in other non FP environments. The main concept of functional programming can be easily applied to any other imperative language; for example, try coding in C++ without assignments, without classes and every parameter as const. It's the same thing.

The declarative thing is not programming at all. All that it is about is declaring things. In spreadsheets, you don't do programming, you simply declare the formulas to be used and the range to be applied to. The actual program has been there for you, in the form of built-in functions. It is only when you make a new function that you make some sort of programming. But that is not declarative, it is procedural, because it involves logic and assignments (hidden from the user, though). Take the SUM function, for example: it iterates over a range of cells, adding the contents to a variable. That's procedural programming: it is a loop over a range, an addition and an assignment. Although the user doesn't deal with that in a spreadsheet.

The relational model is an information organization model and not a programming paradigm. It does not contain logic, nor does it allow for doing algorithms. It describes the organization of data.

the programmer is not allowed to change the state of a variable, because the change might create bugs.

The declarative thing is not programming at all. All that it is about is declaring things.

The relational model is an information organization model and not a programming paradigm.

Heck, lisp gets by with the far simpler concept of manipulating lists, and tuples are a step above that.

? I have a hard time seeing this, since Lisp explicitly builds its lists up out of 2-tuples.

Anyhow, tuples are quite powerful in their own right. :-)

I think you confuse a constraint of FP (no side effects) with the goal of FP

But without that constraint, it would not be possible to have FP. There are imperative programming languages where functions are first class citizens.

Still, you'd be amazed how much stuff can get done with RDBMS

Would you care to provide some examples?

But without that constraint, it would not be possible to have FP. There are imperative programming languages where functions are first class citizens.

And you can do FP in imperative languages (just like you can OOP in practically any PL). Or as the old addage goes, you can write Fortran in any language.


Without delving too far in some of the possibilities, let's just refer to the FP FAQ:

Functional programming is a style of programming that emphasizes the evaluation of expressions, rather than execution of commands. The expressions in these language are formed by using functions to combine basic values. A functional language is a language that supports and encourages programming in a functional style.

Or if you prefer the more homespun sayings of Larry Wall:

We know from experience that computer languages differ not so much in what they make possible, but in what they make easy

Anyhow, you'll find a lot of ideas from FP have crept into more imperative languages as well as vice versa.

Would you care to provide some examples?

SELECT SUM(StorageSpace), ClientID FROM Archive GROUP BY ClientID

But seriously, are you questioning whether the relational model exists in the real world? Whether it is useful in the real world? Or whether it is a programming language?


If it's one of the first two, you need to get out more. If it's the third, then give me the reason why it is not considered a programming language?


Also, for reference we have discussed spreadsheets as languages in the past on LtU: here and here. Most telling was the statement that:

Design of a programming language is a Human-Computer Interaction (HCI) problem

Too many assume that the PL of their discipline is the only thing that exists. Indeed, there are a multitude of Programming Languages that exist for communicating with a computer. And more optimistically, there has to be more and better ways than assembly or the slate of procedural or OO languages that are currently at our disposal. (Unless of course you believe that faith based usage of computers is here to stay. Of course, I always find it ironic that the only thing that computers can't check is the programmers - the rest of the world constantly has their work overseen by automation).

It is a rather common language in academy and uses logic. Search for "prolog tutorial" to see some algorithms. Other languages based on logic are: Mercury and Oz.

But how often is it guarranteed that the same good programmer will always be available to maintain a project? In the real world, a programmer being too good is usually a problem: the others can't follow him, and he can't be replaced.

This is only a problem if managers value more tools/processes/languages/paradigms than people. In the end of the day software is written by good people (as Brooks noted decades ago) not by bad programmers with buzzword compliant tools.

Well, it is not: maybe a good programmer decides that he wants to work on something else; maybe a good programmer gets ill, or even dies in a car accident. Maybe a good programmer is smug and not co-operative enough; maybe a project stalls because it takes too long for all the other (average) programmers to catch up.

For me, software is written by people following established procedures. From my experience, it is much more important for a company to be able to quickly implement, maintain and evolve a project, rather than code a perfect solution that no one but the original programmer knows how to handle. It is no coincidence that very advanced designs and tools are considered as a risk by managers.

You seem to be under the impression that "good" programmers write unmaintainable code. That they use their fancy skills to willfully obfuscate their code. Maybe some do. Perhaps it's a useful strategy for ensuring "lock-in" and a job for life! I don't think that's really the case though. "Good" programmers create useful abstractions that make the code easier to understand and maintain. If they're creating bizarre, contorted, unfathomable tangles then they're either not a "good" programmer, or likely trying to workaround some restrictive limitation in the language they were given (like only being able to form abstractions through class hierarchies).

I am not talking about unmaintanable code, but about code that is very clever, and therefore difficult to be understood by the majority of the other programmers.

But this is another discussion, and I am going offtopic.

is that "bad" or "average" programmers using crippled tools and languages produce "useable, understandable, maintainable" code.

I've not seen this in practice. (I consider myself an average programmer. I write crap code in PERL, C, C++ equally well.

In my experience, (forced-useage OR crippled-language) + (average programmer) code is just as hard to read, sometimes harder than great-programmer code.

I've known a couple of really good programmers and much of their code has been easier to understand than most other code (sometimes my own!).

In terms of object oriented design & development I keep coming back to what the books say.

"how to make your company succeed with OO"
in the first chapter will tell you OO is easy & intuitive.

Later it tells you the programmers will have a major drop in productivity lasting from months to years.

Also later it tells you to hire several decades-experienced gurus for each project. This kind of puts the lie to the 'intuitivity' theory.

1. I'd say it's often somewhat useful. Abstraction and encapsulation are really useful, but they're not specific to OOP.

2. Discipline can be enforced by means other than language choice, such as requiring all inter-component interfaces to be documented and accepted by the project lead. Rigorously defined programs can be written in multi-paradigm languages (consider that Ada is a multi-paradigm language).

As for alternatives, I'm not just talking about named paradigms, but various features and techniques that may or may not be part of any given language categorized as "functional", "OO", "concurrent" or anything else. You mention one - C++ templates.

The combination of closures and mutable state is powerful, as it allows you to trivially build several other abstractions (laziness, many forms of "OO") even if the language doesn't have them.

First-class continuations are extremely powerful, also particularly in the presence of mutable state, although they're probably not something that should be used directly in most programs; but they can be used to construct control flow abstractions used to write the program.

Indeed, one of the most powerful programming techniques, regardless of specifics, is building your own abstraction methods to write your program with.

There's also a lot more to OOP than is possible in C++ or Java. Consider BETA or CLOS, which are neither similar to one another or C++/Java.

OOP is nothing more than procedural programming organized in a different way. What OOP says, essentially, is to bind code together with data. The real problem with procedural programming is that it does not enforce organization of code. Disciplined programmers, or strict procedures may alleviate the problem; otherwise, spaghetti code can be easily done.

After all these years of programming and thinking about programming languages, all I can say is that there is only one programming paradigm: the Turing machine. In other words, when we make a program, we arrange instructions to be executed one after the other. OOP, FP, procedural, etc are all disguises of the Turing model, and they exist in order to solve specific problems. For example, OOP solves the big project organization problem (that's why studies show success in big projects). FP solves the problem of undesired state change. But all these are simply models for laying instructions one after the other. There has never been any really different paradigm that puts the programmer one step closer to making bug-free programs.

In the process of evolution of programming languages, there have been successes in several areas, including OOP. Java solved many C++ problems, like the lack of standard libraries for many usual tasks, the header file problems, the write-once-run-everywhere thing etc. But the successes of Java were wrongly contributed to OOP: Java is good, not because it is object-oriented, but it solves many other problems in a beautiful way. Imagine a C++ with a garbage collector, bytecode and a library to include gui/dbs/etc! it would seriously kick Java's butt! So it is not OOP that it's good, but the other properties of it. OOP has been overestimated, to the point that today's frameworks are seriously complicated. I think the original article wanted to give emphasis to that, but it went to the other edge, even declaring 'copy-and-paste' as a good technique for software re-use.

Do you have any real world experience in non-mainstream programming languages?

Er, why do you ask?

After all these years of programming and thinking about programming languages, all I can say is that there is only one programming paradigm: the Turing machine.

After all these years of programming and thinking about programming languages, all I can say is that there is only one programming paradigm: the Lambda Calculus.

After all these years of programming and thinking about programming languages, all I can say is that there is only one programming paradigm: the Turing machine.

After all these years of programming and thinking about programming languages, all I can say is that there is only one programming paradigm: the Lambda Calculus.

Regarding proc vs. fun: why, it's obvious, procedural means following the procedures while functional means performing some function. It's red tape vs. something useful, really :)

You mean neither of you ever written any interactive application?

Sure, they all have type World → World!

If yes, I would much appreciate some pointers.

I'm not really into interactive programming myself. Clean uses explicit environment passing (World -> World) and you essentially get a different world after receiving each event. The type system makes sure that you use the World single-threadedly (you can't copy the World).

See Comparing Proofs about I/O in Three Programming Paradigms (2001) by Andrew Butterfield and Glenn Strong for an comparison between this way of handling I/O, the monadic approach (Haskell) and the imperative, side-effect approach (C).

[...] although the project was in OOP, the OOP style was violated many times from the developers: it was easier for them to do something quick and dirty in C procedural style, but that could not be changed easily.

Forgive me if this sounds a bit rude, but it sounds to me like you don't do enough code reviews in your shop, or they're not good enough. Your development process is supposed to catch this sort of thing, surely?

I thought you might ask for a definition of "normal"! ;-)

I see where you are going with types. However, this is starting to look like OO, since (and I might send shockwaves through LtU here, but bear with me) to Joe Sixpack, they are not that different a notion.

However, the decisive issue that gets people to choose the "OO" model is not the ease of programming but the ease of design. Few people think of relations when they see Books and Customers. Inheritance is a simple and useful tool which for bolting on extensions without too much headache. I realise that it is not what it should be used for, but from where I sit, this is the sad reality.

So, to draw the line under my mutterings: I agree wholeheartedly that OO is not the most elegant approach to programming, but refuse to concede that currently there are methodologies out there "on the market" which are more accessble to the programming masses.

BTW, thanks a lot for the "Concepts, Techniques, and Models of Computer Programming" link -- it's a little cheaper on Amazon and looks quite interesting.

...then you'd really love the Tablizer, the bane of many a newsgroup. (wasted many an hour reading and arguing with the dude). :-)

I was also immediately struck by the cut/paste comment.

By the way, speaking of types, does anyone know what the current sate of the art is in type theoretical analysis of OOP. I recall Cook's thesis work years ago and issues about contravariance of function types making them unsuitable for modeling polymorphism, subclassing, etc. I've always thought that the single object dispatch approach in C++ and Java made it difficult to see functions as having some kind of first class status. Contrast that with the generic functions approach in CLOS. Aside from the theory, the superficial view of objects as types does help in modeling applications and also enables tool vendors to build refactoring IDEs and so forth, that are essential in large programming efforts.

In the beginning was the cons.

In my experience as a professional and hobbyist programmer, OOP works well for large, coarse objects.[...]And it's not so much encapsulation or inheritance or classes as much as being able to send an arbitrary message to a "thing" and have it respond.

I was thinking of designing a language like that, but using some Turing-incomplete language (such as Epigram) instead of Haskell as a base. What an opportunity to clash dependent types with interactive logic types! If only I were smart enough to do that :-)

You might like to learn Erlang. I think you'd love it.

But OOP - as in "classes are the only abstractions you need/should use" - is constraining and counterproductive.

My arguments were more against modern mainstream OOP proponents than in agreement the article, which made a few correct observations for the wrong reasons.

Given that the article that started this thread reminds me of the cheesy computer hobbyist magazines from the 80's,

No surprise--according to the bioblip at the bottom, that's where the author got his start.

But we don't code the algorithm ourselves, we just select one of the predefined ways and supply it with data. That's not programming.

The spreadsheet programmer neither codes nor selects the algorithms that are used to evaluate the spreadsheet program, and that's the point.

I fail to see how not coding or not selecting the algorithm is programming.

If we have a set of input data, and a set of outputs, and a description of how to produce the outputs from the inputs, then what we have is arguably a program.

By this definition, a spreadsheet is a program. However, it is not a procedural program, because the procedures that are followed to transform the inputs into the outputs are not specified in the program itself.

Neither is it correct to argue that, because some procedure must be followed to perform the computation specified by the spreadsheet, the spreadsheet is really a procedural program in disguise. That is because we cannot say exclusively what procedural program it really is: any of a number of procedural programs might realize the specification, and it is the task of the spreadsheet engine to determine a suitably efficient strategy. This is also true of query optimization in relational databases, of course.

Finally, one might object that real programs often do more than simply translate a set of inputs into a set of outputs: they interact with the outside world in various ways. But so do spreadsheets, which automatically update their state in response to user input (changes to cell values). It is perfectly possible to implement a state machine in a spreadsheet, with the user providing inputs that cause state transitions (the user must provide the previous state as part of the input, as spreadsheet programs are referentially transparent).

Do you fabricate your own chips too? After all, your programs all get translated down to machine code eventually -- which is just a sequence of predefined "ways" which you supply with data. All programming must come down to selecting from predefined operations at some point. Even electronic circuits designers must select their operations from the set that physics allows. Anything else would be magic.

Let's see it from a practical viewpoint: what one can really achieve with Spreadsheets, other than calculations?

Let's see it from a practical viewpoint: what one can really achieve with Spreadsheets, other than calculations?

Let's take one more step back: What can one really acheive with Computers, other than calculations?

(Actually, I promised myself I wouldn't post in this thread. Whoops.)

Let's take one more step back: What can one really acheive with Computers, other than calculations?

Unlike with (automatic) Turing machines, with Computers one can achieve more than calculations (if we define calculations as calculations of values of functions).

(Actually, I promised myself I wouldn't post in this thread. Whoops.)

Me too, but I never can withstand a chance to proclaim superiority of computers over a-TM :-)

Programming a computer to do only what a Turing machine can do is still programming...

Programming a computer to do only what a Turing machine can do is still programming...

In response to your prevous comment that a TM can simulate an interactive process: imagine a process with more than one interaction channel (say, a real-time mutliplayer game server, connected to other processes/TMs that represent clients). The TM will accept a pair of the game state and an event, and calculate the next state of the game. The problem is, who will call the TM? Client TMs obviously cannot do that. It looks like we need some demon who will run all the TMs, passing outputs of one as a part of input to another, keeping in mind their last states and connections to each other. Again, this demon cannot be a TM itself (as no (deterministic) TM can run several potentially blocking TMs in parallel without being blocked itself).

I have trouble explaining my point, so I will look for some papers...

Meanwhile, here is an example from real-life: try to program a web server on one thread (deterministic TM) without select(2).

Slight crossing of wires - I just wanted to point out to our other interlocutor that the fact that computers aren't just TMs doesn't mean that programming something that is just a TM (or even not quite a TM) isn't real programming.

Well, I wouldn't call that "emphasis"-- not anymore than in the phrase "ATM machine" the word "machine" is emphasized...

Still, google for "object oriented programming", and the first hit you get is the Object-Oriented Programming Concepts part of Sun's Java Tutorial. The first section thereof ("What Is an Object?") gives you the party line:

Software objects are modeled after real-world objects in that they too have state and behavior.

You just said that's what OOP gives you!

No I didn't. I said that it strikes me like it's designed primarily to provide domain modeling capabilities, not program organization. Essentially I'm being skeptical about mainstream OO languages in the following way: it strikes me that their constructs are designed with domain modeling in mind, not for program organization, and that there might be a better and/or more straightforward approach to the latter, that they're missing.

Smalltalk, Lisp, ...

I'm not aware of Smalltalk and Lisp having much of the way of a module system... especially not if you compare them with ML. (I ought to take a look perhaps at Scheme48's module system, and definitely at Alice ML's...)

People who don't "get" OOP generally don't "get" programming. That's a gross generalization and needs to be broken down actually. There are two variants of "not getting OOP":

* the person is genuinely clueless

* the person is not following a methodology or set of procedures that has been established by an "OOP guru"[1]

I think that you are referring to the former one. The latter one is a common reason cited by managers for the failure of OO projects. There is a sort of "general cluelessness" that pervades the corporate programming world that people sort of try to sweep under the rug with a lot of blather about how OOP (or something else) is going to revolutionize the industry. By general cluelessness I mean a profound and glaring lack of ability to specifically identify the problem to be solved and map it into a formalisation so that it can be processed by computer. This is step number one in all programming: identifying specifically the problem (the difference between the current state and the result you want) and figuring out how a computer might be used to solve it. If you lack this capability then you lack the capability to program. This lack of capability of programming in the general sense is often misinterpreted as a lack of capability to do OOP precisely because OOP has been so successful with the lack-of-ability-to-program crowd: OOP tool vendors have targeted the corporate development market in a big way in the last ten, fifteen years or so.

[1] By OOP guru I mean the kind of person who writes thick tomes about implementing Rational Unified Process for managers; I don't mean Alan Kay, Guido van Rossum, or someone like that who is the real deal. :)

I guess the article isn't that good, and perhaps I shouldn't have posted about it. But at least this thread gets some attention while threads about interesting papers with new results didn't get the attention they deserved...

My criticism was intended entirely for the article, not for your editorial discretion. Sorry if it appeared otherwise.

At any rate, your observation is rather astute--an article that is essentially flamebait attracts more attention than numerous examples of real scholarship (assuming attention is measured in number of talkbalks). I suppose that's just human nature... the urge to shoot at fish in barrels is frequently irresistable.

I think this phenomenon is more immediate than that: it can take a really long time (and non-zero work) to read some of the papers here fully, whereas anyone who has heard of a class can argue about OOP.

Where the playing field is level, many will play.

I find that it sometimes takes me so long to digest some of the papers mentioned that by the time I have something interesting to say, the live threads have moved on.

Perhaps if we all developed the habit of reviving old threads after we read the paper, we might have more focused discussions. ;-)

Good idea!

Oh, wait, I think you meant the threads about real papers. Sorry.

(P.S.: Lately i've been looking for something away from OO, maybe away from FP too, something to mix them up somehow? I am insufficiently smart to formalize my thinking. Maybe driven by the 'eval problem'... I think the solutions to the 'eval' problem we've seen of late are nice and all, but they smack too much of a physical representation rather than a logical one to me; Scala's solution has so much ASCII here, there, everywhere that it is painful. I'd rather have that be the microcode in a sense, and be working in some higher level ("any problem solved by introducing abstraction") logical view that shows things all together. Even though Chris didn't like Tablizer, for some strange reason when I noodle, er, google around for alternatives I end up there sometimes. Maybe it is like how some of the things LaRouche says make sense to me, in the small, but when I see the big picture they inhabit I think I need to scream and run.)

([on edit adding] P.P.S.: Recently I've been wondering about RPC vs. not and it does sound like the old saw all over again. Why is it that we are so attracted to the shiny idea of keeping state and functionality bundled together? What are the key points we have to remember / drill into ourselves that knock us on the head so we remember that there are even better reasons not to marry them?)

We are?

Well, some folks are. And others as mentioned before. There are enough people who are clearly smarter than I on either side of the debate, from what I can see, that I guess the only conclusion I have is "it depends".

But the argument is that OOP is "better" in "theory" than in "practice," not that OOP is better than alternative concepts. It's really not hard to see how someone could arrive at that conclusion based upon experience with the C++s and Javas of the world. Nor is it hard to see how someone could disagree based upon experience with the Smalltalks and the Common Lisps of the world. I haven't seen a lot of dismissal of the article based upon the claim that "OOP is better," but rather precisely on the basis that the author doesn't engage in the kind of science that you're asking for.

but rather precisely on the basis that the author doesn't engage in the kind of science that you're asking for.

Nobody is doing such science, and THAT is the problem. All we have are endless fights based on anecdotes. The author rightfully asked for better science, or at least public examples of OO being better that are subject to open-source-like scrutiny.

The experiences of using C++, C# and Java are vastly different than using Smalltalk, LISP and python. I think OOP cannot be justily defended or blamed because different experiences result from using OOP in language specific ways.

CLU, for example, is considered OOP by some (myself included), but it did not provide inheritance and methods were bound to types only. This is an extreme example, but my point is that OOP experience is mostly described from language specific point of view.

It is harder to talk about specifics of OOP concepts as practiced by many practicing programmers who churn out production code.

I suspect even the most ardent OOP defenders would in practice "resort" to procedural way of programming when necessary.

LISP gives you both ways. For me, langauges that force you to declare a class for the "main" procedure are absurd.