Concept Programming

descubes writes "A recent article asked about improvements in programming. Concept programming is a very simple idea to improve programming: program code should reflect application-domain concepts. What is amazing is not the idea itself, but how often we don't apply it, and how much existing tools and techniques can get in the way without us even realizing it. To be able to represent all concepts equally well, we need tools that don't force a particular, restricted vocabulary on us. The Mozart project is a Free Software project to implement concept-programming development tools. It includes the Coda universal intermediate language, the Melody persistent program representation, the Moka Java-to-Java extensible compiler, and a fairly advanced front-end for a new programming language called XL. In the long run, Mozart can give the Free Software community a foundation for something as powerful as Charles Simonyi's Intentional Programming."

Comments

Uh...

[eggstasy]

Isnt this the whole philosophy behind OO programming? ISTR my OO teacher saying something like "every class should reflect a real-world concept"... but hey, it's been a while. I could be wrong.

Re:Uh...

[sporty]

Problem is, in OOP, everything is an object, or a thing.

In AOP (aspect object programming) everything is a verb and a matter of flow. I.e. after doing one thing, you do another. Of if this action is taken, this must be taken. Sorta trigger driven.

In concept, everything seems to be more verb/adjective like. I.e. you wouldn't create a Max object or a Drive object or a Smell object in OOP. You'd create things that have a max() method, or a drive() or smell() method. You'd create the concept of smell() and prolly return something that describes the result of finding the max(), or driving() or smelling().

Re:Uh...

[KieranElby]

True, but not every concept is easily represented as an object.

The 'Concept Programming vs. Objects' page explains how concept programming relates to OOP.

Re:Uh...

[aminorex]

Yeah, you mean meta-object protocol

Not very well-explained nor convincing

[GusherJizmac]

The examples on the site of where Concept Programming results in a better solution, are quite contrived and not very convincing. They make Concept Programming out to be nothing more than a glorified bowl of syntax sugar (hold the types), and that's not always a good thing.

The first example discusses the concept of "Maximum", and shows how you would implement that concept in Java, followed by the allegedly superior XL way to do it. The Java "class" makes no sense, and really would not be the way to go about it. YOu would never want to model the concept of Maximum in that way, but if you did, you would use the already-existing Comparable interface and creating a static method called "Max" of some class that takes a list of comparable objects.

Furthermore, in C, you can model it exactly as they have, since C allows multiple arguments.

The next example was discussing takinga derivative and how you can translate some incorrect Java syntax that takes a derivative into the Java equivalent. Why not write a method to do this? What is to be gained by using a non-standard syntax? It makes it harder to write (you have to learn something in addition to Java), and harder to read (same reason).

As for the XL language, and the notion of Concept Programming, it just wasn't explained well at all, and left me saying "what's the big deal? What does this buy me? Where is a real example?" Not every program (dare I say not many programs) are based around mathematical equations and operations. Most involve executing some logic based on input and spitting out output. Modelling that as math seems really counterintuitive (and not in-line with the "concept" of your domain).

Ultimately, seems like some typical academic wank-fest that someone can use to get their Ph.D., but not very applicable in the real world.

Re:Not very well-explained nor convincing

[descubes]

The examples on the site of where Concept Programming results in a better solution, are quite contrived and not very convincing. They make Concept Programming out to be nothing more than a glorified bowl of syntax sugar (hold the types), and that's not always a good thing.

You missed the point of the examples. They are not about syntactic sugar in the XL or Java++ implementations, but rather in the semantic limitations that non-extensible methodologies or tools impose on us. You prove the point further with your examples, by sticking to reference models even if they don't work very well.

The first example discusses the concept of "Maximum", and shows how you would implement that concept in Java, followed by the allegedly superior XL way to do it. The Java "class" makes no sense, and really would not be the way to go about it. YOu would never want to model the concept of Maximum in that way, but if you did, you would use the already-existing Comparable interface and creating a static method called "Max" of some class that takes a list of comparable objects.

In order to implement the concept, you have added a lot of noise in the implementation, which includes not only the Comparable interface, but the need to use methods rather than operators. Your method needs to take a List of objects, so you have added noise at the call site as well. None of this code is actually useful in representing the original concept, it is some artificial complexity to stick to the OO model at any cost.

Furthermore, in C, you can model it exactly as they have, since C allows multiple arguments.

But the C vararg interface is not object-oriented, so this doesn't invalidate the point. As an additional note, it is not type safe either, So you need to add more noise to pass the type information, again both in the implementation (ever looked at the code for printf) and at the call sites (beauties like "a=%s b=%d")

The next example was discussing takinga derivative and how you can translate some incorrect Java syntax that takes a derivative into the Java equivalent. Why not write a method to do this? What is to be gained by using a non-standard syntax? It makes it harder to write (you have to learn something in addition to Java), and harder to read (same reason).

As another poster noted, this is a meta-operation, which transforms a concept into code. You can't write a method that does that, unless your method is part of the compiler. Please show me how you would code this in Java.

Ultimately, seems like some typical academic wank-fest that someone can use to get their Ph.D., but not very applicable in the real world.

Isn't that exactly what they said about OO when it first came out? BTW, I don't have a PhD.

Is it useful? If you ever wrote a perl script that scans your source code, or ever used some preprocessor, or something like that, then you have hit the limits of your tools, and concept programming tools would have helped you. On the other hand, if you never did, then you are not a Real Programmer (TM)... I can literally list hundreds of examples of such additional "build tools" in common Open Source projects.

Re:Good idea - no need for new tool gimmickry

[descubes]

Yes, Lisp can do a lot of this, because it has meta-programming (reflective) capabilities built-in. What Lisp or Forth lacks is:

- A way to adapt the syntax. In Lisp, you write (+ 1 2), not 1 + 2. So if you have the semantic ability to represent concepts, you don't have the syntactic ability.

- A distinction between the program environment and the meta-program environment. When you create a lambda, its "namespace" is the current program. In Mozart, it needs not be.

Shark Sandwich

[ENOENT]

So, how will introducing the concept of "concepts" make it any easier to write code? I have no concept of how the concept of concepts will help me to conceptualize programming concepts. A class might be a concept, a function might be a concept, windshield degradation on your racing simulation might be a concept... It appears that that "concept programming" is just a fancy way of talking about waving your hands in the air.

From the REALLY LIMITED amount of information about "concept programming" on the linked site, it appears that the author REALLY REALLY wants to use higher-order functions (a la Scheme or Haskell), but he just doesn't know it.

Re:Good idea - no need for new tool gimmickry

[aminorex]

> What Lisp or Forth lacks is: Apparently you aren't aware of the reader. This is one of many implementations of infix syntax support for any Common LISP.