OOP is a high level programming language, but that in itself still requires the programmer to write code at a very low level. Allowing/forcing the programmer to create the fundemental control structures, variables, and functions. This low level control offloads much of the low level design to the programmer, but also creates many oppurtunities for mistakes (through poor design/lapse in overall design/logic error/etc..) I think its within the possiblities with current technologies for the programmer to work almost totally at the higher level and automate out the low level implementation to the machine. With advances in genetic programming, natural language processing, and neural networks, the machine can search/interpet/sort to a level which allows it to create competive low level code which fufills a higher level defined function with fewer errors than if a human being had written it. A concept to code architecture, the programmer designs not just the overall implentation of a program, but also its runtime requirements, and design archtypes. All 3 are required by the machine to efficently parse the high level concepts into effective lower level code. A design archtype is one which is iherently defined and applied through out multiple levels of the code, within which all concepts conform too. Such as refrecence counting for disposable entites, using smart pointers, or an exception handling protocol, etc.. Its also important to define the context of the archtypes if possible, as to spefically tailor and limits it uses to the most applicable cases. Concept to code, as a byproduct will be platform independent and extremly modualar and flxeible. This will allow for larger programs, more robustness, and fewer bugs. But, the technologies are just comming into fruition, and it will take alot of work to get from here to there. -ddn

I think the first step along this kind of route wouldn''t have to be nearly as complex as you suggest. I think the next step might be to merge the benefits of Design Patterns and Visual Programming. For example, you might be able to draw some sort of class diagram, using dropdown menus or whatever to define different kind of relationships between the classes, and the system would spot the need for Visitor patterns or Mediator patterns, and build your classes accordingly. You could specify things such as your ''design archetypes'' and it would also be able to automatically generate appropriate container classes.

I think it would be a long way before things such as genetic programming could do away with the need for low-level code, simply because the genetic method implies that you can accurately specify what the desired outcome will be, and quite often the most accurate way of doing that is pseudocode... which corresponds almost 1-to-1 with high level languages like C++ anyway. Natural language processing techniques will never be good enough, in my opinion... it''s hard enough to get another human to understand technical specifications that are given in ambiguous, redundant ''natural'' language, never mind a computer. Better to use efficient technical languages that relate more directly to the design, rather than the problem, I''d think.

quote: Original post by Kylotan

I think the next step might be to merge the benefits of Design Patterns and Visual Programming. For example, you might be able to draw some sort of class diagram, using dropdown menus or whatever to define different kind of relationships between the classes, and the system would spot the need for Visitor patterns or Mediator patterns, and build your classes accordingly. You could specify things such as your ''design archetypes'' and it would also be able to automatically generate appropriate container classes.

It''s being done already, at least on a limited scale, by folks selling UML tools. You draw out your class diagram, and add in patern labels like ''Singleton'' and they crank out a code skeleton.

It''s crude so far, since the tool can''t understand your design, only try and implement it, but it''s happening.

Take a look at Rational Rose or Togethersoft for some examples.

quote: Original post by Anonymous Poster

It''s being done already, at least on a limited scale, by folks selling UML tools. You draw out your class diagram, and add in patern labels like ''Singleton'' and they crank out a code skeleton.

Gahh, that shit is ugly. I like intentional programming myself:

quote: From http://research.microsoft.com/ip/
Unfortunately, computer software written today in high-level languages bears depressing similarity to a blueprint. When we inspect C++ or Java source code, we easily find many repeated patterns and missing parameterizations. A computer program today is much larger than the problem it solves (namely the "specs"), and that is why a marketing decision that can be expressed in one paragraph can take months to implement. To reach the vision of distilled complexity, the source code should not contain anything except what is only known to the programmer - in other words the programmer''s "intentions".

Some of the prototypes are pretty damn impressive.

MSN

Yes, very ugly. Very rough too. But interesting to watch.

I cruised through the site you quoted and I don''t thik I really understand intentional programming, even after reading the summary.

This is what I got out of it, tell me if I''m close:

The programmer assembles a group of components that make up the syntax he wants, and then writes the program using the assembled syntax pieces.

The idea being that the programmer gets to write the simplest program for the task (expressing his intentions) while the different implementation pieces can be optimized for specific machines or algorithms.

It becomes a two step process then - writing (or acquiring) a library of implementation pieces, and then writing out the program in the complete (simple) syntax.

You could do this with lexx and yacc, for example, with the addition of modularizing the syntax parts.

The only difference between this and a set of re-usable class libraries is that the classes are generally larger and more complicated objects rather than lower-level routines (individual operators).

Did I get that right? It certainly doesn''t seem groundbreaking, so I must be missing something. The idea of programming a tree shape looks just like building a compiler tree.

The low level symbolic method of programming, by using symbolic templates, is just a non-verbal extrapalation of the current programming methodology. What im proposing is a radical departure from the current programming methodlogy. Where the programmer doesn''t touch the low level code at all, but rather trusts/builds a program which uses the current state of the art AI algorithims to handle it. A convergence of AI techonolgoies is making it possible of offload the task of the lower level coding to the machine. In the age of 1+Gigahertz processors and cluster supercomputers, it wont be long before machines become powerful enough and algorithims become sophisicated enough to do this.

Good Luck

-ddn

The program could make itself faster over time too

Hasn''t rose been around for years? a few decades at least? What''s it do? I''ve read a little bit about it, but its not entirely clear to me.

Ever used LabView? Its a grpahical procedural language. Very intoxicating at first, leaves a lot to be desired on seconds.


Magmai Kai Holmlor
- The disgruntled & disillusioned

Rose and similar build UML diagrams of the program usually via a GUI. Then they crank out code skeletons for the diagrams (generally just the header files).

They try to bridge the gap between design and implementation, but they have some shortcomings.

1) In order to use them well, you have to have the design already sketched out - they aren''t too good as design tools.

2) They generally stick with preset standards, which you may or may not like - they are not easy to customize. Some of the code is crude or ugly.

3) The ones I''ve played with focus on the UML diagrams as the end-all for the program. A lot of the work still has to be done filing in the functions and whatnot -they don''t seem to integrate well with that task.

The one good use for them is that they can convert source code to UML, so you can check if what you programmed matches your design fairly easily.


visual languages
--------------
Visual languages are a slightly different subject. I''ve played around with some of the visual languages (prograph, sanscrit, etc) but I haven''t found one that doesn''t turn into spaghetti.

Some UML software allows you to draw diagrams and will convert them to source code. Try www.objecteering.com/us/ personal edition is free.

Edited by - JD on January 11, 2001 6:29:07 PM

I thought those UML programs only created skeletal OOP code that needed all the details filled in?