You should believe both, they are not mutually exclusive. Concept programming is about representing the concepts of your application domain correctly. It is a very subtle, grayish, and subjective proposition, not at all the kind of black-and-white thing you are talking about.
If the main concept of your domain is based what Lisp-ers call M-exprs (infix notation for math), you should not be forced to use S-exprs (the prefix notation). In the case of Lisp, you can add a macro to use infix notation, so it is more of a strong encouragement, "we know what is best for you, my friend". But the default syntax for that particular application is close to inane. The default semantics is also inappropriate for that domain, by the way, see http://www.ai.mit.edu/docs/articles/good-news/subs ubsection3.2.2.4.html, where a rather experienced Lisper has this to say: This example is bitterly sad: The code is absolutely beautiful, but it adds matrices slowly. Therefore it is excellent prototype code and lousy production code. You know, you cannot write production code as bad as this in C.
Another example: Perl has special notation and semantics for parsing regexps. If you want to parse text, Perl will be better than Lisp: concepts are represented in a more concise way, with tons of implicit semantics like $_ which make a lot of sense in that context. Yet to do general purpose programming, the syntax of Perl is inane at best.
Re:Good idea - no need for new tool gimmickry
on
Concept Programming
·
· Score: 2
Everything in Lisp ultimately becomes machine code once it's gone through all the layers of macroexpansion and compilation.
There is a difference between lowering everything to Lisp code and lowering everything to machine code.
and vectors and hashtables and symbols and clos objects and numbers and all those other primitive lisp types you disregard
I disregard them in that thread because Lisp doesn't use them for code representation, it uses lists. I'm pretty sure that the packages we discussed generate lists, not any of these entities.
Thanks to all of you in the Slashdot community who offered interesting feedback. I've started taking this feedback into account, and updated the web site.
My purpose here is not to expose the details of XL syntax and semantics, which are largely irrelevant. Let me answer your questions once, but if you have further questions, I suggest taking them to the XL mailing list on SourceForge.
How does XL know what to do with the < operator? There are operator definitions. For instance, less-than for integers is declared as:
function CmpLT(integer A, B) return boolean
written A < B
I invite you to look at the real thing in the CVS tree. A pragma connects this declaration to the implementation, which is in this case a built-in operation of the compiler back-end. The same mechanism, but generally without the pragma, is used for programmer-defined types.
The way I keep reading it is... but it obviously doesn't make sense
It turns out that you read it right. You are telling the compiler what an ordered entity is. Why doesn't this make sense? To implement "Maximum", this is exactly what the compiler needs. It allows the compiler to reject incorrect uses of Maximum, for instance. If you ever passed a wrong argument to a C++ template, you will understand why this is useful.
What you really mean is simply "expressive programming" [... which] is not a new idea
"Expressive programming" doesn't carry the important notion that your reference is the application domain. A pointer in C is expressive, but I still have problems with a pointer used where the application concept is not that of "reference"... for instance to return values from a function. This problems comes from the concept mismatch, not from whether the code is expressive or not.
Also, I'm not trying to do something new, but to do something useful. Some people are doing concept programming today, some are using the terms in a different sense. What matters is that there is a lot of code written today where "my" concept programming shows problems. As long as such code exists, I'll keep trying:-)
Reading the web site and looking at the test case code might be a good start...
Re:Not very well-explained nor convincing
on
Concept Programming
·
· Score: 2
The Maximum example goal is to illustrate how not having the right tool leads to having to workaround. Being more verbose is the problem. If you are more verbose by a factor of 4 on something that simple, what about something more complicated?
Concept programming doesn't focus on extensibility. Extensibility is a consequence, not a goal.
Re:Good idea - no need for new tool gimmickry
on
Concept Programming
·
· Score: 2
I am not saying that you can't extend Lisp, nor that you can't do concept programming in Lisp. Heck, I even applied concept programming to assembly not so long ago. You seem to do it intuitively, so much the better for you. I'd go farther and say that, up to now, Lisp is probably the best environment to do concept programming in.
What I am still saying that the fundamental idiom in Lisp remains lists and functions. Show me your code Prolog and music environments. If they don't ultimately generate lists and functions, you will have convinced me. If I can't take the "car" of one of your "Prolog" programs, or if it tells me "Can't do that, that's a Prolog program, not a list", then you have made a giant step towards convincing me.
The discussions with Lispers have convinced me that I really need to have an "XL vs. Lisp" page somewhere, and I will do that. It's hard, because Lisp can do everything, just like assembly. It doesn't mean that it's the right way to do it, though. Don't make the mistake to believe that I didn't know Lisp when I began XL. I did, and Lisp was a major source of inspiration from day one. But I am convinced that it is possible to do better than Lisp. I'd like to invite you to discuss your Prolog implementation and Lisp vs. XL extension mechanisms on the XL mailing list.
Btw. there are a lot of very friendly and competent people which are always interested in language wars^H^H^H^Hcomparisons.
It's not about language comparisons. You can apply concept programming principles in Python. If you decide to call a method "Draw" rather than "Vhhlqkwz", it is because you apply concept programming implicitly: "Draw" is a better program representation of the concept than "Vhhlqkwz", at least for English readers.
Re:Not very well-explained nor convincing
on
Concept Programming
·
· Score: 2
Admittedly, the lack of varargs-alike syntax in Java is a bit annoying, but it's trivial to work around
And then, you totally miss the point. It's not about Java not having varargs, it's about the fact that not having varargs forces you to workaround. The resulting code no longer maps correctly to the application concept. It generally contains a lot of noise.
You only showed a fraction of the total noise with your example. makeList4 looks simple, but how many of these do you need? Do you need makeList27? For floating-point arguments? It gets very verbose by then...
And then, the only reason it is trivial to workaround is because I chose a trivial example to make my point. Take something more complex than maximum, and you have real problems. Compare the Java and Objective-C of the MacOSX frameworks to see what I mean...
Now we are getting to an interesting implementation, at last:-) So let's see what concept programming can help us uncover...
One nit: the implementation probably allows comparison between objects A and B of different type, as long as you can compare them. So this is not exactly the same concept, but it's close enough.
On the use side, nothing to say. The notation is natural. It is also the same as the one I suggested:-)
On the implementation side, I notice that you did not show the first line of the help, which states "built-in function". Why is it a built-in? Can't you write something like that in Python?
Another nit: the use of __cmp__ instead of < is not very convincing. The < concept is mapped in a relatively unnatural way.
A more serious issue: you made __cmp__ a member of the "my_obj" class. This is, I think, the most natural approach in Python. Back to application space, < is not defined based on the type of its left operand. Why does it matter? If you write A < B, you don't expect the left and right to behave differently with respect to types. In your approach, they do. If I write max(A, B), it might work if A has a __cmp__ even if B doesn't.
So the implementation is useful and practical, but concept programming still has some interesting things to teach us about it. All of these comments have interesting applications in terms of long-term maintainnability. This is left as an exercise for the reader
A concept is not something in your code. It is something from the application space. So you don't throw something at a concept. You represent it in the code. And there are many ways to do it.
For instance, the concept of adding A and B can be represented by:
A+B: a built-in operation, the preferred form for C Add(A, B): a function call, the preferred form for C++ except for built-in types (+ A B): a list representation that can be evaluated, the preferred form for Lisp A.Add(B): a method invokation, the preferred form for SmallTalk (written A + B in SmallTalk)
All of these concept representations have subtly different semantics. What does that mean with respect to how well the concept is represented? This is a question that good programmers always ask themselves implicitly, and that concept programming makes explicit.
Re:Good idea - no need for new tool gimmickry
on
Concept Programming
·
· Score: 2
I knew it could be done, but I was not aware that this had been done already. My mistake, I'll fix the web site. And your observation partially invalidates this particular argument.
Lisp might have the technical capabilities to do concept programming. But based on my limited experience, concept programming is not in the Lisp mind set any more than for other languages. Rather than asking themselves how code could represent user concept, Lisp programmers spend their time finding ways to turn application concepts into lists or functions. Just like C programmers spend their time turning concepts into pointers and low-level malloc(). This is backwards in both cases.
The core of my (+ 1 2) argument is that this form is the natural representation of the concept in Lisp. The Lisp users consciously choose mathematical purity over diversity. Saying "everything is a function" or "everything is a list" is mathematically correct. But it is not true from a concept point of view. If you have any doubt, a comment from the package you referred reads essentially: 1+2 is equivalent to (+ 1 2), but much easier to read according to some folks (emphasis mine). This comment was most certainly written because it was expected that there would be a negative reaction to trying to mess with the sacred notational purity of Lisp. The comment really reads like "Eh, I'm not one of them guys who don't know the one and only truth!"
Lisp is both more extensible that C, and much more capable to digest new paradigms, like object-oriented programming. This is no coincidence. I see this is a proof by existence that concept programming can enhance the longevity and adaptability of the code.
Of course, the concept of maximum can only be definited with respect to some partial ordering function.
Good point. The XL Maximum example makes this requirement explicit and verifiable by the compiler. The Perl code you submitted doesn't.
I was using the partial ordering function <, which in Perl orders numbers numerically and orders strings as being equal with 0.
So you are saying "the problem is not in my code, but in the Perl < concept which doesn't match the mathematician's <. Why did you decide to use Perl's < then? By the way, your definition of Perl's < is somewhat incomplete, you could have "use overload" or other operator redefinitions too.
If you have some other partial ordering function you'd like to to define, I can easily replace the calls to < with calls to some user defined less_than function that does whatever you want, and the code will always return a maximal element (x such that for all y, it is not the case that less_than( y , x )).
I don't need a somewhat pedantic definition of what a partial ordering is:-) My question is why Perl forces me to write all this less_than stuff if all I want is to compare two strings?
Of course, you'd rather just say I'm wrong than properly define Maximum or notions of well-defined orderings, so just go ahead and call me wrong because my code didn't do whatever it was you had in mind.
I gave a relatively simple and precise challenge: write a Maximum that resembles a mathematician's understanding of Maximum, using any language. Better yet, I also gave you an example written in XL as a reference. It specifies very precisely "what I have in mind", which includes comparing elements of the same type, in any number, using only <, and rejecting any type for which < doesn't return a boolean.
You proposed some Perl code in response. It is my duty to simply point out that your code fails to behave like the mathematician would expect it to. Not because "Of course, I want to prove you wrong" , but because it accepts nonsensical input (from the mathematician's point of view), such as Maximum(1, "abc").
Incidentally, the difference between $_ and @_ is a matter of syntax, and every programming language, even your beloved XL, has syntax that has to be learned.
But the syntax Perl imposes is not exactly close to what the mathematician would expect. Perl mandates the correct understanding of the difference between $_ and @_, which is totally irrelevant to the mathematician. On the other hand, XL tries very hard to ensure that any element of the syntax, if arbitrary, is also necessary. Try to look at the example and find something that you can remove without changing the definition in a way that matters from the mathematician's point of view... I think the only irrelevant item is "C", the name of the boolean variable used for validation of "ordered". All other symbols might be replaced with some equivalent symbol, but not removed.
If I was nasty, I could also insert a few snide questions her about the deep application concept represented by the subtle difference between $_ and @_ in your code...
You are not implementing the concept I talk about, but a different one, the max of a list. Trying to convince me that this is the right concept because your language makes it easier to manipulate illustrates my point very well: you are not even aware of the "concept cast" that happened there. Blue pill or red pill?
Let me follow your suggestion for a moment. Consider now something like Max(BUFFER_SIZE, CACHE_SIZE), where BUFFER_SIZE and CACHE_SIZE are two implementation-defined constants.
- Why do you need a list? - Why do you need a method call? - Why do you need dynamic dispatch? - Why would I need to box BUFFER_SIZE as an Integer? - Why should anybody have to implement a "LessThan" method wrapper? - Why should I do the computation at runtime, when, as you pointed out, the compiler (but not me) should trivially be able to compute it, for any given platform? - Why should I change my code if CACHE_SIZE happens to be sampleSize, a variable? - Why should I change the form of my code if I compare three entities and not two? - Why should I change the form of my code if the compared entities are not integers but strings?
The answer to all these questions is "Because of Java", not "Because of the application concept". That is the problem.
And now, the more important, higher-order questions: - Is this an unrealistic example, something that nobody would ever need? In other words, is your "Usually" justified? - Do you really think that this problem occurs only with Max, or am I trying to illustrate some general class of problem? Since it is obviously the latter, why try to fix my Maximum implementation? Are you trying to avoid the real issue?
If concept programming really means anything, then you need to sit down and write up a detailed and exact description of what this is
What is the part you don't understand in "Concept programming is the idea that application concepts should be reflected in program code" ? That's much less than 5000 words.
Based on the information on your site, concept programming could be anything at all.
This was the "Is it trivial?" objection in my previous reply. It sounds trivial, and we think we do it. In practice, we don't, that's my Observation #1 above. Anybody can, by looking at the C++ vs. BASIC code, and applying the concept programming one-line definition, identify that C++ has a worse "mapping" of the concept than BASIC for that example. You want a Lisp or Haskell or functional languages example? What about the concept of "addition"? Do you think that writing (+ 1 2) is the correct way to represent the concept that everybody on the planet writes as 1+2 ?
Why can't I just "forget XL for the moment"? Because for some simple examples, XL is the only language where I can express the concept at all. Maximum is a good example. I know of no language which lets you define it "perfectly". Give me any language (and I know a few at least superficially) and write Maximum in that language, and I can probably point out why it doesn't behave enough like the mathematician's concept called "Maximum".
After you have defined concept programming clearly and exactly, then you should write a paper on XL as an example of a language designed for concept programming. Be sure to explain exactly what you mean when you say that XL is "more extensible than Lisp".
I gave a clear and exact definition of what is concept programming. I wrote a web site and 50000 lines of code instead of a paper, precisely showing XL as an example of language designed for concept programming as you suggested. As for the "more extensible than Lisp", I think you could figure it out if you actually spent the time to read and understand the web site. Ask yourself if Lisp could really cover real-time programming or numeric computing? And if not, why not? I know the answers, and I have written them on the web site (or at least I tried to...)
Do NOT mention performance or optimization in this paper AT ALL. XL is a language, and languages do not have performance characteristics. Performance is a property of an implementation.
Based on several years of experience as a compiler developer, I can tell you that you are very wrong. Languages have performance characteristics. One contribution of my XL performance benchmarks is to illustrate why: because a wrong concept can prevent the compiler from doing the right thing. In Java, one "wrong concept" is the stack-based GC JVM design (which can be contrasted to the Taos/Elate virtual machine design, which did not have similar performance drawbacks, at least theoretically). In C and C++, it is the over-use of pointers which causes something called "aliasing". Lisp, Haskell, Scheme, Dylan and Smalltalk share a single performance-impacting "wrong concept", namely their reliance on a single data structure (or a few of them).
Sorry to be pedantic.
You sound more like someone who has been brainwashed by the Lisp school:-) Not being able to think out of the Lisp school is not better, from a concept programming point of view, than not being able to see past pointers and low-level memory management.
And to validate my claim that if you had explored the web site, you could have found answers, I quote this page:
The belief in the superiority, universality and elegance of their preferred view of the world is particularly strong among users of "minority" languages, such as Lisp or Objective-C. A Slashdot comment, for instance, read something like: "People who don't know LISP are bound to reinvent it, badly." This kind of statement may be in reaction to the ignorance most people have of how well designed Lisp actually is. Lisp stood the test of time deservedly.
But no matter how well known the quote is, the objection is easily dismissed. Try and do Prolog-style logic programming in LISP, and you'll end up with a lot of useless effort (compared to using Prolog, of course.) Try and do numeric-intensive programming, and LISP is no good either, not because of its performance, but because mathematicians write 1 + 1 rather than (+ 1 1) Naturally, you could write an expression parser in LISP, but then in C++ and Fortran, you don't have to... Using Lisp for such projects is, in most cases, bigotry.
I don't want to do language evangelism, but I'd be interested in what is wrong with python
Nothing is 'wrong' with Python (or C or Java for that matter). Actually, IMHO, it is a very good language (clean syntax, clean semantics). What is wrong is when you use for what it was not designed for.
Here are a few extreme examples: would you use Python to describe a page (using it like HTML)? Or to do numeric-intensive computing? For real-time embedded applications? To facilitate your coding of a "memcpy()" implementation in a difficult assembly like Itanium? If not, why not? The reasons are probably not the same in each case. Note that for all these examples, I think that XL could perform very well, given the right "plug-ins".
To use a less extreme example from the web site: if a good fraction of your application domain was expressed using the derivative notation, how would you automate the job of turning these application derivatives into code in Python? I'm not saying that you can't, I'm really asking the question. My limited knowledge of Python doesn't indicate that it would do that very well, but I might be wrong. I'm always ready to steal ideas, you see;-)
Concept programming about making sure that the right concepts show up in your code.
So that is obvious? Well, let's see Hello World in C++:
#include
int main() {
cout "Hello World";
}
And now let's see Hello World in Basic:
PRINT "Hello World"
Which one is closer to the "application concept" in that case?
Hence Observation #1: Concept Programming sounds easy and obvious, but we just don't do it.
Now, I can write a "print" in C++ and make it look almost like the BASIC one. So no big deal, right? Well, I can certainly do that for simple stuff, but not for complicated things. You cannot write in C or C++ something that is functionally equivalent to WriteLn in Pascal. In XL you can. You can't write a tasking package that gives you the kind of high-level constructs found in Ada. In XL you can. You cannot have the C preprocessor or compiler compute a symbolic derivative for you. In XL, you can.
So that is Observation #2: For a given tool or language, there are concepts that I can write, others that I can't. They depend on the tool you select.
This brings me to Question #1: Can we write programming tools where you can talk about any concept?
And this is Proof By Implementation #1: XL is a language that is more extensible than even Lisp. I don't know if I can represent any concept, but I can represent using a single language models that up to now were natural only in a few "specialized" languages like Ada, Prolog or Lisp.
Oh, but this adding abstraction, so it must be slow, right? Well, no.
Observation #3: The choice of concepts defines the performance you get.
Observation #4: Higher concepts sometimes enable optimizations that would be impossible without the compiler knowing what it's talking about.
Proof by Implementation #2: By applying these techniques, XL already has demonstrated on a few "toy", but common examples significant performance improvements compared to languages generally considered "fast" like C or C++.
Is that enough to get you interested again?:-)
Re:Not very well-explained nor convincing
on
Concept Programming
·
· Score: 2
I agree that the Java implementation was idiotic at best.
Several comments were along these lines. Now a challenge for all you Java experts who discuss my sanity:-) Please give me a good representation of the "Maximum" concept in Java.
Now that you thought about something, ask yourself:
- How large is it? What fraction of the code is useful code, what fraction is syntactic or semantic glue?
- How difficult is it to use? How much code for the users is irrelevant glue?
- How restricted is it? Does it work for all types? Does it work for "int", or do I need additional "helpers", like boxing/unboxing? Can I add arbitrary classes? What does it mean for my code if I need more than one "less-than"?
- How efficient is it? Did I just create 5 objects, two lists, and invoked seven method calls just to compare two numbers?
- How easy is it to document? Does the structure make sense, compared to the original "Max" idea? Could you explain how it works to your grandmother?
Here are the approaches that I know about:
- Having static functions like Max(int, int). This works for a limited number of arguments and a limited number of types. So it soon becomes very verbose. It is still the best method in many cases.
- Having an interface like Comparable with a method like "Less". This means that I need all sort of ugly boxing, it doesn't work with the natural less-than operator, and it is a bit inflexible, for instance if you want more than one meaning for "less-than".
- Passing lists and comparators around. It is very inefficient, and the caller has to use an unnatural interface.
- A few less interesting solutions, like passing a string, or having a Max class where you accumulate values using one method and produce the result using another.
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 web site:
Obviously, this definition is quite broad in scope. So it begs the question: what is not a concept? Well, by definition, it is either something from the environment that doesn't matter to your program, or it is something that matters to your program but is not from the application environment.
What doesn't matter is a large set of the application domain, but it's a difficult lesson to learn for programmers. For instance, a car racing game program doesn't need to have much code dealing with the behavior of the cigarette lighter. The cigarette lighter is not a concept for that program. This example is trivial. But how simplified can the engine model be? Should tires wear out? Can the windshield be damaged? All these are non-trivial decisions.
What is program-specific includes things like the particular syntax to use. It may also contain elements of the design that are mandated by a particular methodology. These elements can be recognized because they don't translate back. There is no word in the mechanics vocabulary for that semi-colon that terminates statements in C.
Since there really isn't any hard math, evidence and such, the idea is much closer to opinion than fact, and as such won't last very long.
Two hard data points:
- By replacing a "wrong" concept (pointers) with a "better" concept (input/output flags on arguments) for parameter passing, XL shows a 70% improvement over C++ for parameter passing (the detail being, because it avoids the loads and stores, and does everything in registers). This particular fact had been documented previously for languages such as Ada.
- By replacing a "wrong" concept (hierarchy of classes with left-shift operator) with a "better" concept (type-safe, variable argument lists), XL shows a 7x improvement over C++ for text I/O.
Your turn: prove that having the freedom to select the right tool for the job is a bad thing:-)
Re:Not very well-explained nor convincing
on
Concept Programming
·
· Score: 2
Methods in Java are objects, so you are free to pass them to other methods. Since everything is an object, including methods and classes and variables, you can pass a function to a function and have it return a function. This is also trivial in C.
Oh, I'd like to see you try! Since this is so trivial, please give me a definition of a method or function "derive" in either C or Java so that I can write, for any function G, something like:
function F = derive(G);
In C++, you can do it for some special forms of G, using template meta-programming. People have written articles about it. It takes thousands of lines of VERY hairy C++ code. In Lisp, you can do it. In Java or C? I don't think so.
The point of the new "paradigm" to understand how and when to select Python, how and when to select Java, how and when an object oriented design matches the concepts, how and when a function would be better.
Today, we do this implicitly, a bit like experienced programmers used function pointers in C to do some unnamed sort of OO.
What if you make it explicit? Then you realize that any tool or language has built-in limits, but that we learn how to workaround them, and then make it part of our mental model. That is a Bad Thing.
The reason for the Maximum example is that I don't know of a good way to write it in Java. I know of good ways to write it in many other languages. But in Java, all approaches add a lot of useless noise and concepts just to bolt it on one of the few Java paradigms. The same is true in C or C++ as well. That is undesirable.
The same limit exists for more complicated concepts in any non-extensible language. Lisp or Python are somewhat more extensible than C or Java, but you can still hit the ceiling pretty easily. In Lisp or SmallTalk, for instance, it would be doing math-intensive work, because you don't want to write (+ 1 2) when 1+2 is shorter and nicer.
Slashdot Mirror
You should believe both, they are not mutually exclusive. Concept programming is about representing the concepts of your application domain correctly. It is a very subtle, grayish, and subjective proposition, not at all the kind of black-and-white thing you are talking about.
s ubsection3.2.2.4.html, where a rather experienced Lisper has this to say: This example is bitterly sad: The code is absolutely beautiful, but it adds matrices slowly. Therefore it is excellent prototype code and lousy production code. You know, you cannot write production code as bad as this in C.
If the main concept of your domain is based what Lisp-ers call M-exprs (infix notation for math), you should not be forced to use S-exprs (the prefix notation). In the case of Lisp, you can add a macro to use infix notation, so it is more of a strong encouragement, "we know what is best for you, my friend". But the default syntax for that particular application is close to inane. The default semantics is also inappropriate for that domain, by the way, see http://www.ai.mit.edu/docs/articles/good-news/sub
Another example: Perl has special notation and semantics for parsing regexps. If you want to parse text, Perl will be better than Lisp: concepts are represented in a more concise way, with tons of implicit semantics like $_ which make a lot of sense in that context. Yet to do general purpose programming, the syntax of Perl is inane at best.
Everything in Lisp ultimately becomes machine code once it's gone through all the layers of macroexpansion and compilation.
There is a difference between lowering everything to Lisp code and lowering everything to machine code.
and vectors and hashtables and symbols and clos objects and numbers and all those other primitive lisp types you disregard
I disregard them in that thread because Lisp doesn't use them for code representation, it uses lists. I'm pretty sure that the packages we discussed generate lists, not any of these entities.
Thanks to all of you in the Slashdot community who offered interesting feedback. I've started taking this feedback into account, and updated the web site.
My purpose here is not to expose the details of XL syntax and semantics, which are largely irrelevant. Let me answer your questions once, but if you have further questions, I suggest taking them to the XL mailing list on SourceForge.
:-)
How does XL know what to do with the < operator? There are operator definitions. For instance, less-than for integers is declared as:
function CmpLT(integer A, B) return boolean
written A < B
I invite you to look at the real thing in the CVS tree. A pragma connects this declaration to the implementation, which is in this case a built-in operation of the compiler back-end. The same mechanism, but generally without the pragma, is used for programmer-defined types.
The way I keep reading it is... but it obviously doesn't make sense
It turns out that you read it right. You are telling the compiler what an ordered entity is. Why doesn't this make sense? To implement "Maximum", this is exactly what the compiler needs. It allows the compiler to reject incorrect uses of Maximum, for instance. If you ever passed a wrong argument to a C++ template, you will understand why this is useful.
What you really mean is simply "expressive programming" [... which] is not a new idea
"Expressive programming" doesn't carry the important notion that your reference is the application domain. A pointer in C is expressive, but I still have problems with a pointer used where the application concept is not that of "reference"... for instance to return values from a function. This problems comes from the concept mismatch, not from whether the code is expressive or not.
Also, I'm not trying to do something new, but to do something useful. Some people are doing concept programming today, some are using the terms in a different sense. What matters is that there is a lot of code written today where "my" concept programming shows problems. As long as such code exists, I'll keep trying
Reading the web site and looking at the test case code might be a good start...
The Maximum example goal is to illustrate how not having the right tool leads to having to workaround. Being more verbose is the problem. If you are more verbose by a factor of 4 on something that simple, what about something more complicated?
Concept programming doesn't focus on extensibility. Extensibility is a consequence, not a goal.
I am not saying that you can't extend Lisp, nor that you can't do concept programming in Lisp. Heck, I even applied concept programming to assembly not so long ago. You seem to do it intuitively, so much the better for you. I'd go farther and say that, up to now, Lisp is probably the best environment to do concept programming in.
What I am still saying that the fundamental idiom in Lisp remains lists and functions. Show me your code Prolog and music environments. If they don't ultimately generate lists and functions, you will have convinced me. If I can't take the "car" of one of your "Prolog" programs, or if it tells me "Can't do that, that's a Prolog program, not a list", then you have made a giant step towards convincing me.
The discussions with Lispers have convinced me that I really need to have an "XL vs. Lisp" page somewhere, and I will do that. It's hard, because Lisp can do everything, just like assembly. It doesn't mean that it's the right way to do it, though. Don't make the mistake to believe that I didn't know Lisp when I began XL. I did, and Lisp was a major source of inspiration from day one. But I am convinced that it is possible to do better than Lisp. I'd like to invite you to discuss your Prolog implementation and Lisp vs. XL extension mechanisms on the XL mailing list.
The existence of parsers is largely irrelevant. Several Lisp engines have been written in C too. You can write in you C code something like:
eval("(max 1 2 3 4)");
If there is something you don't like in this picture, you might start to "feel" concept programming.
Btw. there are a lot of very friendly and competent people which are always interested in language wars^H^H^H^Hcomparisons.
It's not about language comparisons. You can apply concept programming principles in Python. If you decide to call a method "Draw" rather than "Vhhlqkwz", it is because you apply concept programming implicitly: "Draw" is a better program representation of the concept than "Vhhlqkwz", at least for English readers.
Admittedly, the lack of varargs-alike syntax in Java is a bit annoying, but it's trivial to work around
And then, you totally miss the point. It's not about Java not having varargs, it's about the fact that not having varargs forces you to workaround. The resulting code no longer maps correctly to the application concept. It generally contains a lot of noise.
You only showed a fraction of the total noise with your example. makeList4 looks simple, but how many of these do you need? Do you need makeList27? For floating-point arguments? It gets very verbose by then...
And then, the only reason it is trivial to workaround is because I chose a trivial example to make my point. Take something more complex than maximum, and you have real problems. Compare the Java and Objective-C of the MacOSX frameworks to see what I mean...
Now we are getting to an interesting implementation, at last :-) So let's see what concept programming can help us uncover...
:-)
One nit: the implementation probably allows comparison between objects A and B of different type, as long as you can compare them. So this is not exactly the same concept, but it's close enough.
On the use side, nothing to say. The notation is natural. It is also the same as the one I suggested
On the implementation side, I notice that you did not show the first line of the help, which states "built-in function". Why is it a built-in? Can't you write something like that in Python?
Another nit: the use of __cmp__ instead of < is not very convincing. The < concept is mapped in a relatively unnatural way.
A more serious issue: you made __cmp__ a member of the "my_obj" class. This is, I think, the most natural approach in Python. Back to application space, < is not defined based on the type of its left operand. Why does it matter? If you write A < B, you don't expect the left and right to behave differently with respect to types. In your approach, they do. If I write max(A, B), it might work if A has a __cmp__ even if B doesn't.
So the implementation is useful and practical, but concept programming still has some interesting things to teach us about it. All of these comments have interesting applications in terms of long-term maintainnability. This is left as an exercise for the reader
A concept is not something in your code. It is something from the application space. So you don't throw something at a concept. You represent it in the code. And there are many ways to do it.
For instance, the concept of adding A and B can be represented by:
A+B: a built-in operation, the preferred form for C
Add(A, B): a function call, the preferred form for C++ except for built-in types
(+ A B): a list representation that can be evaluated, the preferred form for Lisp
A.Add(B): a method invokation, the preferred form for SmallTalk (written A + B in SmallTalk)
All of these concept representations have subtly different semantics. What does that mean with respect to how well the concept is represented? This is a question that good programmers always ask themselves implicitly, and that concept programming makes explicit.
I knew it could be done, but I was not aware that this had been done already. My mistake, I'll fix the web site. And your observation partially invalidates this particular argument.
Lisp might have the technical capabilities to do concept programming. But based on my limited experience, concept programming is not in the Lisp mind set any more than for other languages. Rather than asking themselves how code could represent user concept, Lisp programmers spend their time finding ways to turn application concepts into lists or functions. Just like C programmers spend their time turning concepts into pointers and low-level malloc(). This is backwards in both cases.
The core of my (+ 1 2) argument is that this form is the natural representation of the concept in Lisp. The Lisp users consciously choose mathematical purity over diversity. Saying "everything is a function" or "everything is a list" is mathematically correct. But it is not true from a concept point of view. If you have any doubt, a comment from the package you referred reads essentially: 1+2 is equivalent to (+ 1 2), but much easier to read according to some folks (emphasis mine). This comment was most certainly written because it was expected that there would be a negative reaction to trying to mess with the sacred notational purity of Lisp. The comment really reads like "Eh, I'm not one of them guys who don't know the one and only truth!"
Lisp is both more extensible that C, and much more capable to digest new paradigms, like object-oriented programming. This is no coincidence. I see this is a proof by existence that concept programming can enhance the longevity and adaptability of the code.
Of course, the concept of maximum can only be definited with respect to some partial ordering function.
:-) My question is why Perl forces me to write all this less_than stuff if all I want is to compare two strings?
Good point. The XL Maximum example makes this requirement explicit and verifiable by the compiler. The Perl code you submitted doesn't.
I was using the partial ordering function <, which in Perl orders numbers numerically and orders strings as being equal with 0.
So you are saying "the problem is not in my code, but in the Perl < concept which doesn't match the mathematician's <. Why did you decide to use Perl's < then? By the way, your definition of Perl's < is somewhat incomplete, you could have "use overload" or other operator redefinitions too.
If you have some other partial ordering function you'd like to to define, I can easily replace the calls to < with calls to some user defined less_than function that does whatever you want, and the code will always return a maximal element (x such that for all y, it is not the case that less_than( y , x )).
I don't need a somewhat pedantic definition of what a partial ordering is
Of course, you'd rather just say I'm wrong than properly define Maximum or notions of well-defined orderings, so just go ahead and call me wrong because my code didn't do whatever it was you had in mind.
I gave a relatively simple and precise challenge: write a Maximum that resembles a mathematician's understanding of Maximum, using any language. Better yet, I also gave you an example written in XL as a reference. It specifies very precisely "what I have in mind", which includes comparing elements of the same type, in any number, using only <, and rejecting any type for which < doesn't return a boolean.
You proposed some Perl code in response. It is my duty to simply point out that your code fails to behave like the mathematician would expect it to. Not because "Of course, I want to prove you wrong" , but because it accepts nonsensical input (from the mathematician's point of view), such as Maximum(1, "abc").
Incidentally, the difference between $_ and @_ is a matter of syntax, and every programming language, even your beloved XL, has syntax that has to be learned.
But the syntax Perl imposes is not exactly close to what the mathematician would expect. Perl mandates the correct understanding of the difference between $_ and @_, which is totally irrelevant to the mathematician. On the other hand, XL tries very hard to ensure that any element of the syntax, if arbitrary, is also necessary. Try to look at the example and find something that you can remove without changing the definition in a way that matters from the mathematician's point of view... I think the only irrelevant item is "C", the name of the boolean variable used for validation of "ordered". All other symbols might be replaced with some equivalent symbol, but not removed.
The output is:
Yeah! One out of 4! No compiler warning!
Bzzzt, you lose
If I was nasty, I could also insert a few snide questions her about the deep application concept represented by the subtle difference between $_ and @_ in your code...
You are not implementing the concept I talk about, but a different one, the max of a list. Trying to convince me that this is the right concept because your language makes it easier to manipulate illustrates my point very well: you are not even aware of the "concept cast" that happened there. Blue pill or red pill?
Let me follow your suggestion for a moment. Consider now something like Max(BUFFER_SIZE, CACHE_SIZE), where BUFFER_SIZE and CACHE_SIZE are two implementation-defined constants.
- Why do you need a list?
- Why do you need a method call?
- Why do you need dynamic dispatch?
- Why would I need to box BUFFER_SIZE as an Integer?
- Why should anybody have to implement a "LessThan" method wrapper?
- Why should I do the computation at runtime, when, as you pointed out, the compiler (but not me) should trivially be able to compute it, for any given platform?
- Why should I change my code if CACHE_SIZE happens to be sampleSize, a variable?
- Why should I change the form of my code if I compare three entities and not two?
- Why should I change the form of my code if the compared entities are not integers but strings?
The answer to all these questions is "Because of Java", not "Because of the application concept". That is the problem.
And now, the more important, higher-order questions:
- Is this an unrealistic example, something that nobody would ever need? In other words, is your "Usually" justified?
- Do you really think that this problem occurs only with Max, or am I trying to illustrate some general class of problem? Since it is obviously the latter, why try to fix my Maximum implementation? Are you trying to avoid the real issue?
What is the part you don't understand in "Concept programming is the idea that application concepts should be reflected in program code" ? That's much less than 5000 words.
Based on the information on your site, concept programming could be anything at all.
This was the "Is it trivial?" objection in my previous reply. It sounds trivial, and we think we do it. In practice, we don't, that's my Observation #1 above. Anybody can, by looking at the C++ vs. BASIC code, and applying the concept programming one-line definition, identify that C++ has a worse "mapping" of the concept than BASIC for that example. You want a Lisp or Haskell or functional languages example? What about the concept of "addition"? Do you think that writing (+ 1 2) is the correct way to represent the concept that everybody on the planet writes as 1+2 ?
Why can't I just "forget XL for the moment"? Because for some simple examples, XL is the only language where I can express the concept at all. Maximum is a good example. I know of no language which lets you define it "perfectly". Give me any language (and I know a few at least superficially) and write Maximum in that language, and I can probably point out why it doesn't behave enough like the mathematician's concept called "Maximum".
After you have defined concept programming clearly and exactly, then you should write a paper on XL as an example of a language designed for concept programming. Be sure to explain exactly what you mean when you say that XL is "more extensible than Lisp".
I gave a clear and exact definition of what is concept programming. I wrote a web site and 50000 lines of code instead of a paper, precisely showing XL as an example of language designed for concept programming as you suggested. As for the "more extensible than Lisp", I think you could figure it out if you actually spent the time to read and understand the web site. Ask yourself if Lisp could really cover real-time programming or numeric computing? And if not, why not? I know the answers, and I have written them on the web site (or at least I tried to...)
Do NOT mention performance or optimization in this paper AT ALL. XL is a language, and languages do not have performance characteristics. Performance is a property of an implementation.
Based on several years of experience as a compiler developer, I can tell you that you are very wrong. Languages have performance characteristics. One contribution of my XL performance benchmarks is to illustrate why: because a wrong concept can prevent the compiler from doing the right thing. In Java, one "wrong concept" is the stack-based GC JVM design (which can be contrasted to the Taos/Elate virtual machine design, which did not have similar performance drawbacks, at least theoretically). In C and C++, it is the over-use of pointers which causes something called "aliasing". Lisp, Haskell, Scheme, Dylan and Smalltalk share a single performance-impacting "wrong concept", namely their reliance on a single data structure (or a few of them).
Sorry to be pedantic.
You sound more like someone who has been brainwashed by the Lisp school
And to validate my claim that if you had explored the web site, you could have found answers, I quote this page:
I don't want to do language evangelism, but I'd be interested in what is wrong with python
;-)
Nothing is 'wrong' with Python (or C or Java for that matter). Actually, IMHO, it is a very good language (clean syntax, clean semantics). What is wrong is when you use for what it was not designed for.
Here are a few extreme examples: would you use Python to describe a page (using it like HTML)? Or to do numeric-intensive computing? For real-time embedded applications? To facilitate your coding of a "memcpy()" implementation in a difficult assembly like Itanium? If not, why not? The reasons are probably not the same in each case. Note that for all these examples, I think that XL could perform very well, given the right "plug-ins".
To use a less extreme example from the web site: if a good fraction of your application domain was expressed using the derivative notation, how would you automate the job of turning these application derivatives into code in Python? I'm not saying that you can't, I'm really asking the question. My limited knowledge of Python doesn't indicate that it would do that very well, but I might be wrong. I'm always ready to steal ideas, you see
Concept programming about making sure that the right concepts show up in your code.
:-)
So that is obvious? Well, let's see Hello World in C++:
#include
int main() {
cout "Hello World";
}
And now let's see Hello World in Basic:
PRINT "Hello World"
Which one is closer to the "application concept" in that case?
Hence Observation #1: Concept Programming sounds easy and obvious, but we just don't do it.
Now, I can write a "print" in C++ and make it look almost like the BASIC one. So no big deal, right? Well, I can certainly do that for simple stuff, but not for complicated things. You cannot write in C or C++ something that is functionally equivalent to WriteLn in Pascal. In XL you can. You can't write a tasking package that gives you the kind of high-level constructs found in Ada. In XL you can. You cannot have the C preprocessor or compiler compute a symbolic derivative for you. In XL, you can.
So that is Observation #2: For a given tool or language, there are concepts that I can write, others that I can't. They depend on the tool you select.
This brings me to Question #1: Can we write programming tools where you can talk about any concept?
And this is Proof By Implementation #1: XL is a language that is more extensible than even Lisp. I don't know if I can represent any concept, but I can represent using a single language models that up to now were natural only in a few "specialized" languages like Ada, Prolog or Lisp.
Oh, but this adding abstraction, so it must be slow, right? Well, no.
Observation #3: The choice of concepts defines the performance you get.
Observation #4: Higher concepts sometimes enable optimizations that would be impossible without the compiler knowing what it's talking about.
Proof by Implementation #2: By applying these techniques, XL already has demonstrated on a few "toy", but common examples significant performance improvements compared to languages generally considered "fast" like C or C++.
Is that enough to get you interested again?
I agree that the Java implementation was idiotic at best.
:-) Please give me a good representation of the "Maximum" concept in Java.
Several comments were along these lines. Now a challenge for all you Java experts who discuss my sanity
Now that you thought about something, ask yourself:
- How large is it? What fraction of the code is useful code, what fraction is syntactic or semantic glue?
- How difficult is it to use? How much code for the users is irrelevant glue?
- How restricted is it? Does it work for all types? Does it work for "int", or do I need additional "helpers", like boxing/unboxing? Can I add arbitrary classes? What does it mean for my code if I need more than one "less-than"?
- How efficient is it? Did I just create 5 objects, two lists, and invoked seven method calls just to compare two numbers?
- How easy is it to document? Does the structure make sense, compared to the original "Max" idea? Could you explain how it works to your grandmother?
Here are the approaches that I know about:
- Having static functions like Max(int, int). This works for a limited number of arguments and a limited number of types. So it soon becomes very verbose. It is still the best method in many cases.
- Having an interface like Comparable with a method like "Less". This means that I need all sort of ugly boxing, it doesn't work with the natural less-than operator, and it is a bit inflexible, for instance if you want more than one meaning for "less-than".
- Passing lists and comparators around. It is very inefficient, and the caller has to use an unnatural interface.
- A few less interesting solutions, like passing a string, or having a Max class where you accumulate values using one method and produce the result using another.
Please post about any other idea you might have.
IMO, max() should be method of a list or a group and C++ can do that fine with templates.
Are you suggesting that:
x = (new List<int>).Add(1).Add(2).Add(3).Add(4).max()
is a better representation of the concept in your code than:
x = max(1, 2, 3, 4)
?
From the web site:
Since there really isn't any hard math, evidence and such, the idea is much closer to opinion than fact, and as such won't last very long.
:-)
Two hard data points:
- By replacing a "wrong" concept (pointers) with a "better" concept (input/output flags on arguments) for parameter passing, XL shows a 70% improvement over C++ for parameter passing (the detail being, because it avoids the loads and stores, and does everything in registers). This particular fact had been documented previously for languages such as Ada.
- By replacing a "wrong" concept (hierarchy of classes with left-shift operator) with a "better" concept (type-safe, variable argument lists), XL shows a 7x improvement over C++ for text I/O.
Your turn: prove that having the freedom to select the right tool for the job is a bad thing
Methods in Java are objects, so you are free to pass them to other methods. Since everything is an object, including methods and classes and variables, you can pass a function to a function and have it return a function. This is also trivial in C.
Oh, I'd like to see you try! Since this is so trivial, please give me a definition of a method or function "derive" in either C or Java so that I can write, for any function G, something like:
function F = derive(G);
In C++, you can do it for some special forms of G, using template meta-programming. People have written articles about it. It takes thousands of lines of VERY hairy C++ code. In Lisp, you can do it. In Java or C? I don't think so.
The point of the new "paradigm" to understand how and when to select Python, how and when to select Java, how and when an object oriented design matches the concepts, how and when a function would be better.
Today, we do this implicitly, a bit like experienced programmers used function pointers in C to do some unnamed sort of OO.
What if you make it explicit? Then you realize that any tool or language has built-in limits, but that we learn how to workaround them, and then make it part of our mental model. That is a Bad Thing.
The reason for the Maximum example is that I don't know of a good way to write it in Java. I know of good ways to write it in many other languages. But in Java, all approaches add a lot of useless noise and concepts just to bolt it on one of the few Java paradigms. The same is true in C or C++ as well. That is undesirable.
The same limit exists for more complicated concepts in any non-extensible language. Lisp or Python are somewhat more extensible than C or Java, but you can still hit the ceiling pretty easily. In Lisp or SmallTalk, for instance, it would be doing math-intensive work, because you don't want to write (+ 1 2) when 1+2 is shorter and nicer.