New Programming Paradigm Spec. Needs Die-Hard Coders

684867

Imagine a truly component-oriented programming paradigm where the binary executable is consistent with the OOP-like structure of the source.

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.

Imagine a new evolution of C programming that is based implemented in an OPEN reference model of software much as networking is based upon the OSI model.

If anyone is interested, I am beginning the compiler and need help with the code. Feedback is welcome

e-mail for details.

****************************************
Excellence Breeds! Go Hard or Go Home.

Let Penguins rule the earth.
Break some windows today.

borgnet

: 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.

684867

:
: : 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 familiar
with COM?

Where do I start?


****************************************
Excellence Breeds! Go Hard or Go Home.

Let Penguins rule the earth.
Break some windows today.

684867

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. ;->



****************************************
Excellence Breeds! Go Hard or Go Home.

Let Penguins rule the earth.
Break some windows today.

684867

[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?

Just checking....




****************************************
Excellence Breeds! Go Hard or Go Home.

Let Penguins rule the earth.
Break some windows today.

Jonathan

Hi,

: ...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 -l
What 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.

Jonathan

###
for(74,117,115,116){$::a.=chr};(($_.='qwertyui')&&
(tr/yuiqwert/her anot/))for($::b);for($::c){$_.=$^X;
/(p.{2}l)/;$_=$1}$::b=~/(..)$/;print("$::a$::b $::c hack$1.");

684867

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.

****************************************
Excellence Breeds! Go Hard or Go Home.

Let Penguins rule the earth.
Break some windows today.

Jonathan

: 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 checking
You'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.

Jonathan


###
for(74,117,115,116){$::a.=chr};(($_.='qwertyui')&&
(tr/yuiqwert/her anot/))for($::b);for($::c){$_.=$^X;
/(p.{2}l)/;$_=$1}$::b=~/(..)$/;print("$::a$::b $::c hack$1.");

684867

[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.

********************************************************************
Second Point:

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?



****************************************
Excellence Breeds! Go Hard or Go Home.

Let Penguins rule the earth.
Break some windows today.

684867

****************************************************************
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.


*******************************************************************
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. :-)

********************************************************************
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.


****************************************
Excellence Breeds! Go Hard or Go Home.

Let Penguins rule the earth.
Break some windows today.

Jonathan

: ****************************************************************
: 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.

Maybe just allow raw pointers in unsafe/unmanaged mode and force delegates/references in managed code?

: 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

I'll reply to your other post sometime soon. :-)

Jonathan

###
for(74,117,115,116){$::a.=chr};(($_.='qwertyui')&&
(tr/yuiqwert/her anot/))for($::b);for($::c){$_.=$^X;
/(p.{2}l)/;$_=$1}$::b=~/(..)$/;print("$::a$::b $::c hack$1.");

684867

[b][red]This message was edited by 684867 at 2004-11-19 10:16:22[/red][/b][hr]
[b][red]This message was edited by 684867 at 2004-11-19 10:2:22[/red][/b][hr]
*********************************************************************
Reply to Point four:

: : 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 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.

*******************************************************************
Rebuttal on Point Four:

C# and Microsoft manage code through an interpreter. They limit the power of the C language (which means nothing is really a native binary anymore, and only MS software runs as fast as the op/sys can--everyone else is slower).

That is bad business. I want to write a language and compiler that allows the low level access C intends and the high-level stability application programmers require. That stability is not in the managed versus unmanaged code thinking of Microsoft. It is in the development of compilers that can be configured to produce code to the developer's specifications and a loader/executor that can safely launch a binary within specified parameters.

Eventually I would like to see coding minimized to the low-level and special needs moments, while most development is conducted through CASE tools. Graphical development environments which allow components to be assembled as lego blocks rather than klocs of code will reduce the probablility of error. ...as will IDE's that are capable of analyzing the code produced low-level and by CASE to identify problems.

Besides C# does not implement its solution with elegance. MS is in this for the money...not quality. That is why I break windows and love penguins, my friend.

*******************************************************************
Reply to Point Five:

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

*******************************************************************
Rebuttal on Point Five:

What is the point of writing a destructor or finalizer if there is no guarantee it will execute as you expect (hope?). That is bad programming. Whoever creates such an abortion should be dragged across the countryside by their entrials--or just mocked as an idiot.

I make enough faux pas in my life. This will not be one of them.
A destructor will execute as the object is released.

********************************************************************
Reply to Point Six(1):
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.
: :
***********************************************************************
Rebuttal to Point Six(1):

I am against the concept of marking memory as executable/non-executable. Memory should be allocated then left tabula rasa for the developer. Remember what I am looking at here is complete system level work. I am creating the paradigm.

To hell with MS standards.

What I do sometimes is create an algorithm that mutates during execution to serve multiple purposes in less memory. This requires some processor cycles but saves the amount of time that the CPU must take to access virtual memory because my code maximizes its memory. I would love to see components under CBOOP do more of this.


***********************************************************************
Reply to Point Six(2):

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.

***********************************************************************
Rebuttal to Point Six(2):

Good Point. But doesn't this negate the idea of strong typing. Usually programmers who perform casting are comfortable with pointers. Those who use arrays are doing so to avoid these issues. what about memory sizes. A char is now arbitrary. I still think of a char as 8 bits. Some now use DBCS, where a char is 16 bits. Translation of an integer (8 or 16 bits?) into a char (8 or 16 bits) may cause more problems than it is worth. But is a new type of power for the coder, thus it is an idea to consider.

Programming should be free and open for creativity.

***********************************************************************
Reply to Point Six(3):

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

Maybe just allow raw pointers in unsafe/unmanaged mode and force delegates/references in managed code?

***********************************************************************
Rebuttal to Point Six(3):

How would you implement this in C syntax? Remember the language must remain consistent unto itself.

***********************************************************************
Reply to Point Six(4):

: 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.

***********************************************************************
Rebuttal to point six (4):

Slammer is the greatest reason your concern is not new to me. I do not want to continue to open these type of doors. If an object is issued memory, then it must have its own address range. An object must not be allowed to rape its neighbor. Nor must a component be allowed to do so. If an array is declared and pointer access is allowed then there is the potential for problems. But a good compiler should analyze the code to estimate its probability.

No matter the case, additional overhead must be avoided at all costs. We want better graphics and power, not useless overhead.

Memory checking (as you point out) will do nicely here.

rattustherat

Hi 684867,
I just read through your posts on CBOOP and it seems pretty interesting. I'm just so sad that I don't know enough to help out. I'm not much of a programmer right now, all i know so far is a bit of C/C++ and I'm now learning Lisp. That's another reason why I'm so interested in doing that project I told you about in the Lisp language because I believe conquering it will help me grow as a programmer. Still I'll be following your debates on CBOOP with great interest because I think I'm learning quite a bit from it :-)

rattustherat

Hi 684867,
I just read through your posts on CBOOP and it seems pretty interesting. I'm just so sad that I don't know enough to help out. I'm not much of a programmer right now, all i know so far is a bit of C/C++ and I'm now learning Lisp. That's another reason why I'm so interested in doing that project I told you about in the Lisp language because I believe conquering it will help me grow as a programmer. Still I'll be following your debates on CBOOP with great interest because I think I'm learning quite a bit from it :-)

Alexandrescu

Found bright young coder who is member of programmersheaven! Very inventive one. [ After all I talked to him and he didn' die - seriously. ]
Talked to him about RBOOP/X and caught his interess.
Sam, please contact him; it's a matter of cultural stuff (He is a Hungarian). His English is rather good - as you will see.

His user name is Gaashius

You can contact him eigther via programmereheaven mail box or at Gaashius@yahoo.co.uk

mblack

I'm glad I am not the only one who doesn't like to compromise on my choise of computer language features. I have been working 25 years using assembly language, C, C++, Delphi and a bit of Java. Funny how there is always something about each of them that I either find very interesting or very annoying. I wish I could just pick and choose the language feature I like and discard the others. I have been looking for a language that provides the "nuts&bolts" capability of C/C++ but with the added protection of Java-like data protection and can be used in an embedded environment as well (deterministic).

Other features I like:

- Multiple return values (tuples) as in "return a,b;"
- Integrated container types (stack, list, queues, etc.)
- Must be easy to read and analyze
- Simple to build compiler / interpreter (for embedded uses)
- Easy to build components

Just an idea, we could set up a website (sourceforge?) to work on this some more.

- Mike