Comments

: Imagine abandoning the [b]main()[/b] routine for a new source code structure that allows the programmer to create multiple overloaded entry and exit points for the executable at the system level.:

I'm as "newbie" as they get but, am about to get started in programming. I see you are going back the the "source", seems you've found a limit in the way things currently are. (limits are troublesome) I have had an idea in the past that it was possible the current "ways" may not be so efficient and I would probably wind up trying to create my own.. programs.. os.. etc, seems you have come across a similar conclusion. If you don't mind, can you explain to me with examples as best you can what "multiple overloaded entry and exits points" are? if not, that's ok. but I hope if you succeed that your new source code structure will be the most malliable source code, wich will likely be the one I will use in the future. Also.. have you checked out www.sourceforge.net ? It is a place where many ambitious people get together to create programs and/or OS etc. it's based on open souce software. I don't believe there are any costs, but I haven't tried it yet. Hope for some type of response. thank you.

: : : Imagine abandoning the [b]main()[/b] routine for a new source code structure that allows the programmer to create multiple overloaded entry and exit points for the executable at the system level.: : : : I'm as "newbie" as they get but, am about to get started in programming. I see you are going back the the "source", seems you've found a limit in the way things currently are. (limits are troublesome) I have had an idea in the past that it was possible the current "ways" may not be so efficient and I would probably wind up trying to create my own.. programs.. os.. etc, seems you have come across a similar conclusion. If you don't mind, can you explain to me with examples as best you can what "multiple overloaded entry and exits points" are? if not, that's ok. but I hope if you succeed that your new source code structure will be the most malliable source code, wich will likely be the one I will use in the future. Also.. have you checked out www.sourceforge.net ? It is a place where many ambitious people get together to create programs and/or OS etc. it's based on open souce software. I don't believe there are any costs, but I haven't tried it yet. Hope for some type of response. thank you.: : Okay, I just replied to your other post and e-mail. My aren't we tenacious. That is good! You'll need that persistence and energy when you start marathon coding sessions.

I do not know where to start without the risk of losing you in the stream of things. So, tell me more about what YOU know of programming.Do you know what Object-oriented programming (OOP) is? Are you familiarwith COM?

In response to the interest shown in my new language spec I thought it appropriate to describe my idea in more detail.

I propose a new evolution for the C family of languages, dubbed C-Squared. This new language is an extension of the C++ standard (ignoring the abortion we know as C#). It adapts the conventional Object-Oriented Programming (OOP) paradigm and makes the same more consistent.

The first version of C-Squared will be rather simple. It will not support advanced OOP features such as templates. That will come later. What is important here is to demonstrate the CBOOP concept.

CBOOP is the consistent application of Object oriented design at the component/executable level. Here, C++ loses its main() routine in favor of "public classes" which define components exposed to the system from the binary executable.

Public (CBOOP) classes contain private (OOP) classes which give the component the capacity for shared code structures and higher-level organization (and data abstraction). Source files in CBOOP are the same as we are used to seeing with C++. However, there is no main() routine and cannot be any global variables.

Within the global scope of a CBOOP (c-squared) project, the programmer should be able to define organization (structs, typedefs, functions, public and private classes, enums, unions and so on...). But the programmer cannnot in this scope instance an object.

When reduced to binary format, the public class defines the component prototype that will be instanced on demand. Multiple components may occupy a single Component Executable (CXE) file, sharing other components (also public classes) to interact. Thus, a single executable may have multiple entry points to several components accessing the same core data.

Each component is launched through its constructor. This constructor can be overloaded. At run-time the proper constructor is executed based on execution context. This context gives each component the ability to respond to context at run-time in a way traditional programming cannot effectively acheive.

Remember: With OOP the object marries the data and code into one structure. So, too, the component under CBOOP marries code and data. The programmer defines how this evolving data and code interact, then compiles the source into a CXE file, which the user will transparently use to store code and data.

At first glance this sounds inefficient. Imagine if Word was copied to every .DOC file! THAT WOULD BE UNACCEPTABLE. But this is *NOT* what CBOOP intends. Rather, a CXE file for user data would contain user data and its container code needed to store, authenticate and perhaps render the data to higher-level components. Other "application level" components could access the data in another CXE through the container code. Yet these application level components could store their parameter information internally--eliminating the need for centralized repositories which can be corrupted or compromized.

Now, this is a simple implementation of the CBOOP component that does no justice to the power it allows. But the intended implementation would involve discussion of the OPENOS reference model which is being developed along side CBOOP. This begs the question: How much trouble is CBOOP going to be to put into service?

CBOOP requires, of course, a language. That is, c-squared. Then it requires a compiler for the language (along with the linker and other attending modules). That is the purpose of this thread. Finally it requires a CBOOP Component Loader to load and manage components in current environments--which may act as the basis for a new OS that has been loosely defined in my private papers.

At present, I am working on the code for the compiler. But I am going from scratch. Who wants to use yacc and its relatives to do what a REAL PROGRAMMER can do himself? (Answer: a rational one. But I never claimed sanity.) Work, of course, is slow moving. I am still working on the scanner and lexical analysis units.

Two features I would like to see in this compiler is: hypertext source code files and complete modularization (an object-oriented design). I do not have the time to develop a stripper which will strip HTML tags from my source. THAT IS A NEED I WANT HELP WITH.

Another need is for someone who is good with x86 Assembly. I need a code generation library and interface classes therefor. If others want to develop libraries for SPARC or other instruction sets, feel free to do so. What is needed, however, is a common interface class for these different code generation libraries.

Remember: developing for CBOOP is different. Things have to be really thought through. At present I am working on putting together the money and time to produce a video explaining my concept and needs. But before I make the final plunge to do so I want to find people in the community who want to participate in the adventure.

CBOOP will be released open-source...unless I get offered a large cash reward before work begins. ;->

[b][red]This message was edited by 684867 at 2004-11-1 19:35:33[/red][/b][hr]...Well, So much for programmer's supporting new ideas! Please tell me that the innovation has not left the industry. Are we all so complacent now that we do not explore new ideas?

: ...Well, So much for programmer's supporting new ideas! Please tell : me that the innovation has not left the industry. Are we all so : complacent now that we do not explore new ideas?: To be honest, I had no idea this board existed. Guess I can't use that excuse now. ;-) I'm currently a computer science undergrad at Cambridge (UK), and programming langauge design, compilers and virtual machine are areas I'm interested in. Knowledgable or competent is another matter, mind. Anyway, you've managed to capture my curiosity.

It seems to me that you're saying "we have these different natively compiled files (which may be executables or DLLs, or just a format of your own?) and will provide some kind of standardised, OO-shaped interface to allow connectivity between them". Let me run thorugh some examples of what I think the possibilities are and see if I get the idea.

1) You've written a module that converts a wave file to an MP3. Alone, it provides some mechanism (via a loader?) that allows people to use it out of the box solely for that. I'm implementing something that synthesises some sound and stores it in wave format. I can instantiate your module in my program and use it to convert my wave file to an MP3 using it. Nothing we can't do with a DLL so far, but the nice OO interface of the module being exported is going to make life easier for me.

2) You've written a module that takes a load of text and break it down into sentences. I like this, but I have my text that I want to use stored in HTML documents (sorry, these examples suck...). I inherit from your program, over-riding certain methods so that I can strip out the HTML before invoking the method on the super-module with the text.

The right kind of idea? Interesting, if so. In a way, we kinda went there with UNIX, where we had loads of little programs that we joined together with pipes. E.G. to find the number of lines containing the word monkey in a text file we'd do:-cat textfile | grep monkey | wc -lWhat you suggest almost seems to be an object oriented and more flexible extension of this.

Here's some questions.

1) What's the language going to look like? I suspect C and C++ style syntax, from your posts. But I'm hoping some lessons are learnt from elsewhere too... ;-)

2) Is this language going to be garbage collected? Do we get references rather than pointers (e.g. will there be free pointer arithmetic)? Are we getting bounds checking on arrays (buffers)?

3) Are you going down the native code route, or interpretation (so you win better cross-platform support)?

Warning: time isn't something I have in great supply. But I probably have time enough to bounce some ideas around.

Hope some of this makes sense...it was a long day at the lab today, and my brain is kinda mushy.

I am glad to have captured the curiosity. Here's a little to clarify the matter....

1)What I propose is a new executable format (Component Executable--CXE), which will allow components to exist at the system level much as objects "exist" within a traditional OO executable. This requires a new paradigm by which programming should be approached, a more consistent view of software.

2)The view of software I envision, Component-Based Object-Oriented Programming (CBOOP) is intended to allow developers to write components in any language and to create modules (components) which are interoperable. These are binary objects compiled to a specific machine architecture. (However, there is another level of this project which will allow for interpretation across platforms--worry not faint heart.)

3)CBOOP is a programming paradigm, not a language. However, to implement CBOOP, a first language is necessary. I have dubbed this language C-squared.

4)C-Squared is to be c++ with some added consistency. The aim is to eliminate the inconsistencies in the language first and the inconsistencies of OOP second. There is to be NO GARBAGE COLLECTION. A good programmer cleans his own room after he is done.

5)Bounds checking is an idea. I always do my own...and have for years. I forget from time to time that others do not do this by habit. It is an idea.

6) Pointer math is something to think about. I would like to see this as well. But presently I am focused on other issues (component problems). Thanks for the reminder!

7) Time is not in great supply here either. I work full time, work more after that, then try to make additional cash with my computer on the side. This is a SLOW project. That is why I need help.

: I am glad to have captured the curiosity. Here's a little to clarify : the matter....: : 1)What I propose is a new executable format (Component : Executable--CXE), which will allow components to exist at the system : level much as objects "exist" within a traditional OO executable. : This requires a new paradigm by which programming should be : approached, a more consistent view of software.: To me it sounds like your format is more like a DLL than an executable, for you'd need a loader to decide what to execute. As for a new paradigm, it basically sounds like an extension of an existing one (OOP), but being applied at a larger scale. It seems to me that you're essentially creating a standard for binary compatibility and enabling better code re-use between applications.

: 2)The view of software I envision, Component-Based Object-Oriented : Programming (CBOOP) is intended to allow developers to write : components in any language and to create modules (components) which : are interoperable. You're opening up a whole bundle of fun when you start looking at different languages. Think about how different langauges view OOP, for example. At a lower level, think of calling conventions. I imagine you might need to develop compilers, or certain wrappers for languages that you want to use with this concept.

: These are binary objects compiled to a specific machine architecture. : (However, there is another level of this project which will allow for : interpretation across platforms--worry not faint heart.): From what I can see, a basic interpreter is easier to implement than a native compiler. Implementing a good interpreter that performs well is much harder. That said, you can always emit code to target an existing one.

: 3)CBOOP is a programming paradigm, not a language. However, to : implement CBOOP, a first language is necessary. I have dubbed this : language C-squared.: It's important to keep idea and language apart, for sure.

: 4)C-Squared is to be c++ with some added consistency. The aim is to : eliminate the inconsistencies in the language first and the : inconsistencies of OOP second. What are you thinking of when you refer to the "inconsistencies of OOP"? What is the language going to do with regard to the fact that OOP isn't the right solution for every problem, or is it just going to be aimed at fitting problems that map to OOP well?

: There is to be NO GARBAGE COLLECTION. A good programmer cleans his : own room after he is done.: OK, so tell me what the most common bugs are that come up in C and C++ programs are down to. I'm pretty sure that memory management related issues top the list. Even good programmers make mistakes; it's part of being human. Finding a memory related bug amongst a lot of code is hard, especially in a project where people aren't always greatly familiar with the codebase.

I think that with the computing power available to us today, we can afford GC. With the algorithms we have available to us now (incremental GC, generational GC) it needn't be that costly. In fact, for apps with short run time it can be more efficient because we may not even have to bother freeing memory. It also makes things easier in multi-threaded apps, where multiple threads want an object that they will use at some point in their execution that can be freed when they are all done. Tracking when it's safe to free it can be fun. With GC, we don't have to worry - the GC will look at the stack of each thread as well as statics and free it when it's no longer reachable.

Admittedly, there is fun with ensuring timely destruction, if that's something you want to make available in your language. Destructors (or finalizers, call them what you like) creating another reference to the object can be a real pain too. But those can be worked around.

: 5)Bounds checking is an idea. I always do my own...and have for : years. I forget from time to time that others do not do this by : habit. It is an idea.: : 6) Pointer math is something to think about. I would like to see this : as well. But presently I am focused on other issues (component : problems). Thanks for the reminder!: I was arguing against free pointer math. I think if you:-(a) Force all memory access to be done in an array style notation(b) Do bounds checkingYou'll be enabling people to write much safer code than it's possible to write in C/C++ today.

: 7) Time is not in great supply here either. I work full time, work : more after that, then try to make additional cash with my computer on : the side. This is a SLOW project. That is why I need help.: Certainly it's an interesting project to talk through, and maybe at some point I'll be able to contribute more than just thoughts.

[b][red]This message was edited by 684867 at 2004-11-17 11:14:20[/red][/b][hr]****************************************************************First point:

1)What I propose is a new executable format (Component Executable--CXE), which will allow components to exist at the system level much as objects "exist" within a traditional OO executable. This requires a new paradigm by which programming should be approached, a more consistent view of software.

R: To me it sounds like your format is more like a DLL than an executable, for you'd need a loader to decide what to execute. As for a new paradigm, it basically sounds like an extension of an existing one (OOP), but being applied at a larger scale. It seems to me that you're essentially creating a standard for binary compatibility and enabling better code re-use between applications.

EXACTLY. Here, the CXE is like a merger of DLL and EXE format. OOP is extended and applied at a global level, the component. "better code re-use" is the holy grail of the next generation of software. YOU HAVE HIT THE NAIL SQUARE ON THE HEAD!!!! You have knocked it into the next room. Perfect.

2)The view of software I envision, Component-Based Object- Oriented Programming (CBOOP) is intended to allow developers to write components in any language and to create modules (components) which are interoperable.

R: You're opening up a whole bundle of fun when you start looking at different languages. Think about how different langauges view OOP, for example. At a lower level, think of calling conventions. I imagine you might need to develop compilers, or certain wrappers for languages that you want to use with this concept.

I am trying to keep everything open yet simple. I developed CBOOP as an open standard. C-Squared will implement this. Let others develop languages to the standard. My mind has certain limits.

********************************************************************Third Point: 4)C-Squared is to be c++ with some added consistency. The aim is to eliminate the inconsistencies in the language first and the inconsistencies of OOP second.

R: What are you thinking of when you refer to the "inconsistencies of OOP"? What is the language going to do with regard to the fact that OOP isn't the right solution for every problem, or is it just going to be aimed at fitting problems that map to OOP well?

OOP is inconsistent. OOP applies one paradigm inside the source and another in the object format. Where would OOP not apply?

There is to be NO GARBAGE COLLECTION. A good programmer cleans his own room after he is done.

R: OK, so tell me what the most common bugs are that come up in C and C++ programs are down to. I'm pretty sure that memory management related issues top the list. Even good programmers make mistakes; it's part of being human. Finding a memory related bug amongst a lot of code is hard, especially in a project where people aren't always greatly familiar with the codebase.

Point taken. Memory management is a serious source of bugs. That is true. However, there are times when I have problems giving up control. Perhaps the compiler should allow garbage collection to be turned on or off depending on the programmer's desire (possibly using a directive?). This would allow smaller projects to avoid the overhead, yet permit larger projects to benefit from the safety of GC.

R:I think that with the computing power available to us today, we can afford GC. With the algorithms we have available to us now (incremental GC, generational GC) it needn't be that costly. In fact, for apps with short run time it can be more efficient because we may not even have to bother freeing memory. It also makes things easier in multi-threaded apps, where multiple threads want an object that they will use at some point in their execution that can be freed when they are all done. Tracking when it's safe to free it can be fun. With GC, we don't have to worry - the GC will look at the stack of each thread as well as statics and free it when it's no longer reachable.

Point taken.

Admittedly, there is fun with ensuring timely destruction, if that's something you want to make available in your language. Destructors (or finalizers, call them what you like) creating another reference to the object can be a real pain too. But those can be worked around.

Good point. (Side note: I prefer the term "destructors." It sounds more powerful and sinister. :-)

******************************************************************** Point Six: 6) Pointer math is something to think about. I would like to see this as well. But presently I am focused on other issues (component problems). Thanks for the reminder!

R: I was arguing against free pointer math. I think if you:- (a) Force all memory access to be done in an array style notation (b) Do bounds checking

You'll be enabling people to write much safer code than it's possible to write in C/C++ today.

I disagree. array notation can limit the control and power of the programmer within his code. How can I create objects that alter then call what first appears to be data, but is really code, without a pointer and the abilities of pointers "C" gives us.

Safer code comes from good style and patient, methodical planning.

Memory allocations should be checked and a component should never be allowed outside its declared turf. Bounds checking here will protect the system (that is another level of the project). Internally (OOP) should check bounds within the object. No object should be allowed to effectively rape another object by intruding on its boundaries.

: ****************************************************************: Point Four: : : There is to be NO GARBAGE COLLECTION. A good programmer : cleans his own room after he is done.: : R: OK, so tell me what the most common bugs are that come up in C : and C++ programs are down to. I'm pretty sure that memory : management related issues top the list. Even good programmers : make mistakes; it's part of being human. Finding a memory : related bug amongst a lot of code is hard, especially in a : project where people aren't always greatly familiar with the : codebase.: : Point taken. Memory management is a serious source of bugs. That is : true. However, there are times when I have problems giving up : control. Perhaps the compiler should allow garbage collection to be : turned on or off depending on the programmer's desire (possibly using : a directive?). This would allow smaller projects to avoid the : overhead, yet permit larger projects to benefit from the safety of GC.: I believe that C# allows for both managed and unmanaged code. When you are executing managed code, you get GC, no free pointer arithmetic and so on. When you are executing unmanaged code, memory management is your responsibility. I'm not sure on the details of how it implements this - I guess you'd have to suspend garbage collection while unmanaged code was being executed. Then you get into the fun of doing calls from unmanaged code into managed code. If you want to go down the allow both track (which to me seems a good idea - I'd prefer it to things like JAVAs JNI) then looking at the semantics that C# has may be worth doing.

: *******************************************************************: Point Five:: : R:I think that with the computing power available to us today, we : can afford GC. With the algorithms we have available to us now : (incremental GC, generational GC) it needn't be that costly. In: fact, for apps with short run time it can be more efficient : because we may not even have to bother freeing memory. It also : makes things easier in multi-threaded apps, where multiple : threads want an object that they will use at some point in their : execution that can be freed when they are all done. Tracking : when it's safe to free it can be fun. With GC, we don't have to: worry - the GC will look at the stack of each thread as well as : statics and free it when it's no longer reachable.: : Point taken.: : Admittedly, there is fun with ensuring timely destruction, if : that's something you want to make available in your language. : Destructors (or finalizers, call them what you like) creating : another reference to the object can be a real pain too. But : those can be worked around.: : Good point. (Side note: I prefer the term "destructors." It sounds : more powerful and sinister. :-): I think there may be a subtle difference between finalizers and destructors, in that calling of destructors is a certainty, whereas a finalizer may or may not get called. This certainly matches my experience - Perl's destructors are always called, but in JAVA whether your finalizer gets called is down to the JVM and there are no promises that it will be. See here:-http://portal.acm.org/citation.cfm?id=604153

: ******************************************************************** : Point Six:: 6) Pointer math is something to think about. I would like to : see this as well. But presently I am focused on other : issues (component problems). Thanks for the reminder!: : R: I was arguing against free pointer math. I think if you:-: (a) Force all memory access to be done in an array style : notation: (b) Do bounds checking: : You'll be enabling people to write much safer code than it's : possible to write in C/C++ today.: : I disagree. array notation can limit the control and power of the : programmer within his code. How can I create objects that alter then : call what first appears to be data, but is really code, without a : pointer and the abilities of pointers "C" gives us.: How often do you really need to do this? You need to be doing something fairly low level to need this, like writing a JIT compiler. Also, memory that you want to do things like this with these days needs to be marked as executable, or if it doesn't now will in the near future.

I think one thing that it'd be nice to find a way to do is to be able to acccess an array of a certain native type (e.g. ints) as if they were another native type (e.g. chars). With C you just cast the pointer. That's desirable and useful, but I'm not convinced something safer can't be developed to do the same thing.

As for function pointers, nice idea, but again they can be made safe - e.g. delegates. Mutlicast delegates are also a pretty cool idea.

: Safer code comes from good style and patient, methodical planning.: True, but even good programmers do make mistakes and it's nice if there is something there to catch their buffer overrun error that would otherwise overwrite stuff on the stack and cause all kinds of "fun".

It occurs to me that we'd have avoided this problem greatly if we'd put the stack near the bottom of the virtual memory space and had it growing up, then grown the heap downwards. Not sure if that brings up other problems I haven't thought of, though, which is probably the case.

: Memory allocations should be checked and a component should never be : allowed outside its declared turf. Bounds checking here will protect : the system (that is another level of the project). Internally (OOP) : should check bounds within the object. No object should be allowed to : effectively rape another object by intruding on its boundaries.: Agree. It's also quite efficient to do the checks - the x86 architecture even has a BOUND instruction for doing bounds checking in one cycle!http://www.penguin.cz/~literakl/intel/b.html#BOUND