In response to thread and email feedback I am revising the programming language specification which will implement CBOOP (Component-based object-oriented programming).

I only regret that many of you emailed your feedback rather than posting it here. The collaborative effort was hindered. But some of you are DAMN good at skewering a man on his oversights.

As a resuld of feedback I will change the language as follows:

1) The language will have two tiers: The first will be a compiler language and the second will be the operational language. The compiler
lanugage will allow the configuration of the compiler within the
source code to activate and deactivate features such as garbage collection, optimization controls, etc.

2) The language will maintain c++ appearances to reduce the learning curve. But it will be based on expressions only! There will be no
statements. Everything will be an infix or prefix expression. (Sorry, I am not going to try to parse infix, prefix AND postfix expressions. If you want it, write it! I AM NOT A MASOCHIST. But the expression- only syntax is a golden idea.)

3) Parse trees will be binary trees using only one object type for its nodes to keep things simple. The expression-only format will make this a lot easier. ...Thanks.

4) Array notation will be the result of a [] group operator. It will be based on pointers, allow those of us who love them to use pointers, while allowing people like the esteemed Johnathan (the only one of you to be brazen enough to post his feedback) to use arrays with bounds checking and more.

5) Operators replace functions. (This is my own new idea which simplifies the language.) There are no function pointers or operator pointers. So, those not comfortable with them can rest easy. However, those of us who love low level code access can create code blocks with the {} group operator which returns a reference to the block that can be linked to an operator and executed.

6) An ASM operator is included to incorporate blocks of assembly.

7) Each code block {} is its own local namespace and can be chained to others.


Further feedback is needeed. I am tired of rewriting the spec. and want to finish this project by Dec 05.


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

Let Penguins rule the earth.
Break some windows today.

: In response to thread and email feedback I am revising the programming
: language specification which will implement CBOOP (Component-based
: object-oriented programming).
:
: I only regret that many of you emailed your feedback rather than
: posting it here. The collaborative effort was hindered. But some of
: you are DAMN good at skewering a man on his oversights.
:
: As a resuld of feedback I will change the language as follows:
:
: 1) The language will have two tiers: The first will be a compiler
: language and the second will be the operational language. The compiler
: lanugage will allow the configuration of the compiler within the
: source code to activate and deactivate features such as garbage
: collection, optimization controls, etc.
:
So basically a bit like C's compiler directives, like #if, #define, #pragma?

: 2) The language will maintain c++ appearances to reduce the learning
: curve. But it will be based on expressions only! There will be no
: statements.
So I'm assuming things like:-
a = b + c;
Are classed as expressions, but soemthing like:-
let a = b + c;
Would be classed as a statement? What about:-
goto somewhere;
Is that a statement?

: Everything will be an infix or prefix expression.
Should expression there read operator?

: (Sorry, I am not going to try to parse infix, prefix AND postfix
: expressions. If you want it, write it! I AM NOT A MASOCHIST. But
: the expression- only syntax is a golden idea.)
:
So no:-
x++;

: 3) Parse trees will be binary trees using only one object type for its
: nodes to keep things simple. The expression-only format will make
: this a lot easier. ...Thanks.
:
That's compiler internals over langauge design, I guess.

: 4) Array notation will be the result of a [] group operator. It will
: be based on pointers, allow those of us who love them to use pointers,
: while allowing people like the esteemed Johnathan (the only one of you
: to be brazen enough to post his feedback) to use arrays with bounds
: checking and more.
:
I think bounds checking that only affects things done directly with array notation doesn't buy us that much. For example, in things like:-
char x[100];
strcpy(x, y);
We are passing a pointer here and not an array of known length, right? How are we going to make bounds checking safety presist accross function calls etc if it's tied to a variable declaration?

: 5) Operators replace functions. (This is my own new idea which
: simplifies the language.)
What will this look like? Are you saying "no global functions"? Methods and functions are distinct, yes, so this is nothing to do with methods? What about static methods?

: There are no function pointers or operator pointers.
No operating overloading I can happily live with. No function pointers...that's not so nice, but I guess OOP provides other routes to polymorphism, e.g. inheritance, interfaces, roles, etc.

: So, those not comfortable with them can rest easy. However, those of
: us who love low level code access can create code blocks with the {}
: group operator which returns a reference to the block that can be
: linked to an operator and executed.
:
Ooh, kinda like closures? Will these blocks be able to take parameters? They'll be able to return things, I assume?

: 6) An ASM operator is included to incorporate blocks of assembly.
:
Boom goes the platform independence. Or at least, now our VM has to include an x86 emmulator.

: 7) Each code block {} is its own local namespace
Would this work (pseudo-code):-
{
int x = 2;
{
int x = 3;
print x; # prints 3
}
print x; # prints 2
}

: and can be chained to others.
:
Can you give me an example of what you mean by this?

: Further feedback is needeed. I am tired of rewriting the spec. and
: want to finish this project by Dec 05.
:
Most of the spec is probably a lot clearer in your mind that mine. Will be curious to see the answers to these questions, anyway.

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

This message was edited by 684867 at 2004-12-7 14:37:9

---

1) The language will have two tiers: The first will be a compiler
language and the second will be the operational language. The
compiler lanugage will allow the configuration of the compiler
within the source code to activate and deactivate features such
as garbage collection, optimization controls, etc.


: So basically a bit like C's compiler directives, like #if,
#define, #pragma?


Actually I want more power than the compiler directives.
But, yeah. It's something like that. I want templates and
other similar features that instruct the compiler to be a
part of the compiler language, not the "algorithmic" language.

*********************************************************************
2a) The language will maintain c++ appearances to reduce the
learning curve. But it will be based on expressions only!
There will be no statements.


: So I'm assuming things like:-
: a = b + c;
: Are classed as expressions, but soemthing like:-
: let a = b + c;
: Would be classed as a statement? What about:-
: goto somewhere;
: Is that a statement?


goto somewhere would be a "statement" if goto were a keyword.
But what if you define goto as an operator and somewhere as
an operand? Same thing, right? But, with goto as an operator
rather than a keyword, the operator could be part of another
expression (and return a value upon evaluation).

MORE POWER!

*********************************************************************
2b) Everything will be an infix or prefix expression.


: Should expression there read operator?


Technically, yes. I was referring to the structure of the
entire expression. I do not think it wise to mix formats.
So, if an expression starts with a prefix operator, the entire
expression should be prefix.
Imagine the complexity and confusion otherwise.


2c)(Sorry, I am not going to try to parse infix, prefix AND postfix
expressions. If you want it, write it! I AM NOT A MASOCHIST. But
the expression- only syntax is a golden idea.)


: So no:-
: x++;


ouch! Good point. This is why feedback is crucial.

*********************************************************************

3) Parse trees will be binary trees using only one object type for
its nodes to keep things simple. The expression-only format
will make this a lot easier. ...Thanks.


: That's compiler internals over langauge design, I guess.


True. The compiler internals are simplified by the
expression-based language design.

*********************************************************************
4) Array notation will be the result of a [] group operator. It
will be based on pointers, allow those of us who love them to
use pointers, while allowing people like the esteemed Johnathan
(the only one of you to be brazen enough to post his feedback)
to use arrays with bounds checking and more.



:I think bounds checking that only affects things done directly
:with array notation doesn't buy us that much. For example,
:in things like:-
: char x[100];
: strcpy(x, y);
: We are passing a pointer here and not an array of known
:length, right? How are we going to make bounds checking
:safety presist accross function calls etc if it's tied to
:a variable declaration?


If the array is treated like an implied class by the
compiler, then a body of managing code will be created to
conduct the array operations. This is a concession similar
to my concession to you on the subject of garbage collection.
I believe the overhead here, too, can be minimized.

Linguistically the array will be an object with [] operators
to conduct indexing operations. If an array
is passed into an operator (function), then the array (object)
pointer (as a type). There the operator will be used from the
common array-object code structure to carry out the indexing and
return the actual value of any referenced element. That object
can check bounds and so on.

Eventually this core array object class may be malleable under
the compiler language.


*********************************************************************
5a) Operators replace functions. (This is my own new idea which
simplifies the language.)


: What will this look like? Are you saying "no global
:functions"? Methods and functions are distinct, yes, so
:this is nothing to do with methods? What about static methods?


I am saying that there will be no "functions" as we know
them. Rather, we will use operators.

x = sin(y);

becomes

x = sin y;

where = and sin are both operators. x,y are operands.

If an operator is a member of a class/component, then the
operator is a method. Otherwise it is a GLOBAL OPERATOR.


5b) There are no function pointers or operator pointers.
So, those not comfortable with them can rest easy. However,
those of us who love low level code access can create code
blocks with the {} group operator which returns a reference
to the block that can be linked to an operator and executed.



: No operating overloading I can happily live with. No function
:pointers...that's not so nice, but I guess OOP provides other
:routes to polymorphism, e.g. inheritance, interfaces, roles, etc.
:Will these blocks be able to take parameters? They'll be able to
:return things, I assume?



Acutally operators may be overloaded.

A block of code will be enclosed with {} OPERATORS. This
means the block will have LHS, CTR and RHS operands. So,
YES, the block can accept parameters of a defined type.

They are nameless blocks assigned arbitrary identifiers
by the compiler for their LHS return to the compiler's
parser. Any data returned is of the same type as LHS.


*********************************************************************
6) An ASM operator is included to incorporate blocks of assembly.


Boom goes the platform independence. Or at least, now our VM has to include an x86 emmulator.


Not so. The code can include assembly for multiple
platforms. Depending on the machine (or virtual machine)
specified to the compiler, the result can be machine
specific or independent.


*********************************************************************
7) Each code block {} is its own local namespace and can be chained to others.



:Would this work (pseudo-code):-
: {
: int x = 2;
: {
: int x = 3;
: print x; # prints 3
: }
: print x; # prints 2
: }


This would work. Except that each expression must be
terminated by the ; delimter.




: Can you give me an example of what you mean by this?


EXAMPLE:

public class somecomponent
<< basecomponent
<< {
private { x new int;
y new int;
z new (char array 255);
};
public {
int operator "+" int;
int operator "-" int;
char operator "<pop<";
};
};

This declares a component "somecomponent" and inherits "basecomponent" which is assumed to be declared elsewhere. Somecomponent is then (or later implemented using the "<<" (link) operator and a {} block. This block defines two scoped member blocks. The first, private, defines two integers and a character array. The second, public, defines two binary and a third unary operator.

If we were to define an operator, we might say:

int operator "+" int;

This declares the operator. But no code is yet defined. Alternatively we could say:

int operator "+" int
<<{
Return LHS+RHS;
};

or

int operator "+" int
<<{
Return LHS+RHS;
}
{
cout << "This is a string passed to the cout object"
<< "through the << insertion operator";

};


note: The semicolon, too, is an operator. Its return value (LHS) is
null. So, since {} as a code block has the syntax

[lhs code reference]{ [code block] } [rhs code reference]

the expression

{ ... }{ ... };

links two blocks then terminates the chain of code with
a null ";" reference.

P.S. Johnathan: Thanks for the feedback.

Everyone else: don't condemned in private (i.e. my work)
what you could condemn in public. Others would enjoy the
humor of your wit just as much as me.

I always appreciate a good lancing.


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

Let Penguins rule the earth.
Break some windows today.

Per your e-mail recently, wherein you demanded that I publicly say what I think of this new idea:

(1) Eliminating statements from the language to create an expression only language is MORONIC! It is done only because you are too lazy to write a REAL compiler.

(2) Garbage elimination is a waste of proc time. Lose it.

(3) Dividing the language into a compiler and algorithmic language may allow you modularity, but it is an over complication of the matter.

(4) CBOOP is too late. Good idea...But it should have been implemented a decade ago. You missed the boat and the industry has moved on. How will you get the initiative to shift the industry in your direction?

(5) Your former partner, D.P., told you to take the money and run.... You do not post that here now. You spend too much time theorizing on this language and compiler. Had you written it years ago, both you and D.P. could have sold out and won. YOUR LOSS!

(6) When are you ever going to post a detailed definition of the new language and CBOOP. If it is to be open-source (and if you are true to your beliefs) then post some real descriptive materials.

P.S. ...And I haven't even started on the real technical problems! Do you want me to move further?

Some interesting points. As GC was one of my suggestions, I guess I should argue this one.

: (2) Garbage elimination is a waste of proc time. Lose it.
:
Your problem is that you only think about computational performance, when the reality is that in many developer environments developer performance is far more significant. Does a few extra miliseconds in execution time cost you much? No, and we're getting more and more powerful processors all the time. Does a few extra days on a project tracking down memory allocatiion bugs and leaks cost you much? Well, I'll bet you it costs a lot more than the extra processing power you needed if you used GC. Furthermore, developers don't get more powerful. Humans are humans. We make mistakes and we'll keep making them.

For *some* applications (e.g. realtime and some embedded stuff) I agree that GC isn't suitable. However, most programmers write web and desktoop apps. Most of the time these don't *need* incredible performance, so even if GC gives a small slow-down it won't be noticable to the end user. And with today's GC algorithms, the slow-down is pretty small.

In addition, having to manage memory is an additional burden on the developer. If you're so fussed about proc cycles, do you write everything in assembly? We stopped writing most things in assembly because it was a pain for developers. We developed a tool called a compiler that could turn a higher level language that was far easier to work with into assembly (or sometimes, directly into machine code). Trading in a few proc cycles to make life much easier for the developer is not a new crazy idea of mine - it's tried and tested. GC is just another step.

When you're developing a programming language and runtime environment, forgetting the people who are going to use it is a fatal mistake. If the intention is to create something that a small group of people who like to manage their own memory will use, fine. If the intention is to create something that developers of everyday applications will want to use instead of things like JAVA, .NET languages, VB, Python, Perl, PHP and so on, GC is the way to go. Oh, by the way, all the languages I named there do GC.

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

This message was edited by 684867 at 2005-1-11 10:26:30

---

Per your objections:

: (1) Eliminating statements from the language to create an expression only language is MORONIC! It is done only because you are too lazy to write a REAL compiler.


K.I.S.S. (Keep It Simple Stupid). Why allow statements and expressions when expressions only allows anything anywhere syntactically? The semantics are the only issue the developer should worry about.

Imagine nesting multiple concepts in a single expression. The expression is a process and should allow more efficient code.



: (2) Garbage elimination is a waste of proc time. Lose it.

Garbage collection is well defended by Johnathan. He proposed it, sold it to me and it is now an optional feature turned on and off by the compiler language.

: (3) Dividing the language into a compiler and algorithmic language may allow you modularity, but it is an over complication of the matter.

To the contrary, division of the language allows the two to grow separately. Therefore, the language should last into the future.

: (4) CBOOP is too late. Good idea...But it should have been implemented a decade ago. You missed the boat and the industry has moved on. How will you get the initiative to shift the industry in your direction?

You are almost correct! It's late but not too late.

: (5) Your former partner, D.P., told you to take the money and run.... You do not post that here now. You spend too much time theorizing on this language and compiler. Had you written it years ago, both you and D.P. could have sold out and won. YOUR LOSS!

This is not on topic. But not everything is based on money. Just most of it.

: (6) When are you ever going to post a detailed definition of the new language and CBOOP. If it is to be open-source (and if you are true to your beliefs) then post some real descriptive materials.

I am working on that! Patience is a virtue.

: P.S. ...And I haven't even started on the real technical problems! Do you want me to move further?

To quote Bush: "Bring it on!" ...And I have the (er, privates) to back that statement up!


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

Let Penguins rule the earth.
Break some windows today.

This message was edited by Alexandrescu at 2005-4-26 9:50:19

---

About the above message:
: (1) Eliminating statements from the language to create an expression only language is MORONIC! It is done only because you are too lazy to write a REAL compiler.

After some two decades in IT and AI, I think eliminating statements is Brillant - Sam, stick to this ideea!

: (2) Garbage elimination is a waste of proc time. Lose it.

You can loose it, but these features has to be embedded into the OS. Bcause Windows lousy manages the memory space and Linux is not very far, then you have eighter to make a new OS too, or you can make a patch - at least Windows needs it [ you may even *get some kisses* if you make sutch a patch ]

: (3) Dividing the language into a compiler and algorithmic language may allow you modularity, but it is an over complication of the matter.

The coyotte hitted the point.

: (4) CBOOP is too late. Good idea...But it should have been implemented a decade ago. You missed the boat and the industry has moved on. How will you get the initiative to shift the industry in your direction?

It is NEVER too late to make things better! As for the industry... I think that the Coyotte didn't hear about Limited GNU licenses - that allows corporate software to be built on a good free library, to be compiled using a real good free compiler and so forth; and this is exactlly the way Sam can achieve his dream [ Good luck with your ideeas, Sam ]

: (5) Your former partner, D.P., told you to take the money and run.... You do not post that here now. You spend too much time theorizing on this language and compiler. Had you written it years ago, both you and D.P. could have sold out and won. YOUR LOSS!

Too boystrous! My mother taught me not to comment such kind of messages when I get angry.

: (6) When are you ever going to post a detailed definition of the new language and CBOOP. If it is to be open-source (and if you are true to your beliefs) then post some real descriptive materials.

I already told something like that to Sam, in a (mutch) more mild way. However Coyotte sems not to understand that Sam tries to get some help to the anlyse phase too.
So, Coyotte, eighter you help Sam, eighter back off because maliciosity leads nowhere!

: P.S. ...And I haven't even started on the real technical problems! Do you want me to move further?

If I'd weare Sam's shoes, I would't want somebody like Coyotte! No offense, Coyotte, but you are not the absolutely trueth and knowledge keeper!! Anyway, at least Sam had an ideea; I wonder where are yours??

: This message was edited by Alexandrescu at 2005-4-26 9:50:19

---

: About the above message:
: : (1) Eliminating statements from the language to create an expression only language is MORONIC! It is done only because you are too lazy to write a REAL compiler.
:
: After some two decades in IT and AI, I think eliminating statements is Brillant - Sam, stick to this ideea!
:
Come on, let's evaluate ideas on their merits rather than how long the person who agrees with them has been doing their thing. I don't really take issue with having an expression based language though.

: : (2) Garbage elimination is a waste of proc time. Lose it.
:
: You can loose it, but these features has to be embedded into the OS.
Huh?

: Bcause Windows lousy manages the memory space and Linux is not very
: far, then you have eighter to make a new OS too, or you can make a
: patch - at least Windows needs it [ you may even *get some kisses* if
: you make sutch a patch ]
:
The VM system of the OS doesn't really matter here. You can do GC on pretty much whatever OS you like. I don't see what your point is here. I mean, all you need to implement your average conservative GC is to be able to walk down the system stack to a certain point, identifying stuff that might be pointers. And that's in your program's memory space anyway, and certainly fine to read from. From then on you're working with your own data structures.

: : (3) Dividing the language into a compiler and algorithmic language may allow you modularity, but it is an over complication of the matter.
:
: The coyotte hitted the point.
:
It's not just modularity you get; meta-programming is a cool thing and many languages in popular use support it at some level (e.g. C, C++, C# etc have #whatever preprocessor directives, including support for macros; Perl has its BEGIN {...} blocks that are evaluated at compile time).

The rest of the post seems to contian more politics than programming language design...

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

Because my English is rather poor, I may of skipped something - in order to cut short my message. I'm awdfull sorry about that.

When I said: "After some two decades in IT and AI, I think eliminating statements is Brillant - Sam, stick to this ideea!" I actually ment that my experience - which can not be bought from some boutique nor quickly gathered from some miraculous book - make me belive Sam is on the right track and all his contenders should think deep. I was not bragging. [ I bet you are "a young wolf" as Romanians use to say ]

When I said that garbage elimination can be skipped, *but these features has to be embedded into the OS*. I was thinking at the compiled applications not at the compiler itself. [ A litle explanation: If GC would work fine, then there is no need for a GC related code within the applications; if the OS handles GC the way Windows does, then any *serious* application has to contain some code that does a little work arround GC; obviously if the OS does not provide GC, then it's the applications which shoull take care about GC entirelly. ]
Otherwise it is absolutely correct what you said [ "The VM system of the OS doesn't really matter here. You can do GC on pretty much whatever OS you like. I don't see what your point is here. I mean, all you need to implement your average conservative GC is to be able to walk down the system stack to a certain point, identifying stuff that might be pointers. And that's in your program's memory space anyway, and certainly fine to read from. From then on you're working with your own data structures." ]

I also said thet the Coyotte hitted the point when he said "Dividing the language into a compiler and algorithmic language may allow you modularity, but it is an over complication of the matter" because since the language is to be developed on two directions, then at some further point everything can go smoothly without the algorithmical part [ Remember that the non algorithmicall languages use expressions; statement seems to be "forgotten" ? ]

: It's not just modularity you get; meta-programming is a cool thing and many languages in popular use support it at some level (e.g. C, C++, C# etc have #whatever preprocessor directives, including support for macros; Perl has its BEGIN {...} blocks that are evaluated at compile time).

Correct! [it is not what I was thinking at, but it is correct.]

You said "The rest of the post seems to contian more politics than programming language design..."

I'd very mutch like to know what "politics" did I write; was it the stuff about Coyotte's atitude? Well... that was not politics; I just emphasised on seamingly long forgotten things; things that I'm sure his parents told him about, but he definitely forgot. And same goes for you! [ Your tone is far too agressive. It is so agressive that makes me think you don't have many friends, do you? ]

P.S. If you really want to see how good I am, then let's "raise" on any, absolutely any topic related to computers! Are you in, or cowerdly out !? [ Sample of question: How to ascribe self awareness to artifficial systems? Answer this within three days and I'll consider you the ultimate ace in the field, tiger! ]

: Because my English is rather poor, I may of skipped something - in order to cut short my message. I'm awdfull sorry about that.
:
Your English seems fine to me - much better than I can speak any other language (I speak a little French, and a very little bit of Spanish).

: When I said: "After some two decades in IT and AI, I think eliminating statements is Brillant - Sam, stick to this ideea!" I actually ment that my experience - which can not be bought from some boutique nor quickly gathered from some miraculous book - make me belive Sam is on the right track and all his contenders should think deep. I was not bragging. [ I bet you are "a young wolf" as Romanians use to say ]
:
Yes, experience is a Good Thing. I guess I just like to see the arguments formed form experience so I can learn from it too (being the young wolf I am ). I'd be interested to hear some of your arguments for expression based languages though.

: When I said that garbage elimination can be skipped, *but these
: features has to be embedded into the OS*. I was thinking at the
: compiled applications not at the compiler itself.
Yes, so was I.

: [ A litle
: explanation: If GC would work fine, then there is no need for a GC
: related code within the applications; if the OS handles GC the way
: Windows does, then any *serious* application has to contain some code
: that does a little work arround GC; obviously if the OS does not
: provide GC, then it's the applications which shoull take care about GC
: entirelly. ]
I guess the OS could provide some kind of support, but all the GC systems I've seen (admittedly, not loads and mostly in VMs) seem to implement it from the ground up, without any help from the OS. So I don't think any GC support *has* to be in the OS at all at the level I'm thinking about. Obviously, when a process ends then the OS should recover all memory related to its memory space - maybe this is the kind of support from the OS you meant? I was talking about the GC that goes on during the execution of the program itself and kinda assuming that any modern OS will recover memory not explicitly freed when the process terminates. But maybe that's not such a valid assumption for some operating systems.

: I also said thet the Coyotte hitted the point when he said "Dividing the language into a compiler and algorithmic language may allow you modularity, but it is an over complication of the matter" because since the language is to be developed on two directions, then at some further point everything can go smoothly without the algorithmical part [ Remember that the non algorithmicall languages use expressions; statement seems to be "forgotten" ? ]
:
OK, that seems to make sense.

: : It's not just modularity you get; meta-programming is a cool thing and many languages in popular use support it at some level (e.g. C, C++, C# etc have #whatever preprocessor directives, including support for macros; Perl has its BEGIN {...} blocks that are evaluated at compile time).
:
: Correct! [it is not what I was thinking at, but it is correct.]
:
: You said "The rest of the post seems to contian more politics than
: programming language design..."
:
: I'd very mutch like to know what "politics" did I write; was it the
: stuff about Coyotte's atitude? Well... that was not politics; I just
: emphasised on seamingly long forgotten things; things that I'm sure
: his parents told him about, but he definitely forgot. And same goes
: for you!
Hmmm....s/politics/stuff not much to do with language design/. Don't think politics was quite the word I was looking for there, sorry.

: [ Your tone is far too agressive.
I'm far from aggressive, as pretty much anyone who knows me well will tell you. What I am up for is a good discussion; I guess I'm a tad argumentative at times. Please don't read anything I write too personally - if I question something you've said it's because I want to know the thinking behind it, or put forward my own idea to see what's wrong with those. Just argue back, I'm quite open to being told I'm wrong.

: It is so agressive that makes me think you don't have many friends, do
: you? ]
:
Quite a few - and many of them have nothing or little to do with computing. Which is good, because I need a break from this stuff from time to time.

: P.S. If you really want to see how good I am, then let's "raise" on
: any, absolutely any topic related to computers! Are you in, or
: cowerdly out !?
I'll remember you're about if I come up with any weird and wonderful questions. Which I do from time to time.

: [ Sample of question: How to ascribe self awareness to artifficial
: systems? Answer this within three days and I'll consider you the
: ultimate ace in the field, tiger! ]
:
At this point, I'll admit to know very little about "AI", but I'd be interested to hear your answer.

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

Both of you come from separate perspectives. Your feedback is very valuable. I am merely "listening" (i.e. reading) and digesting what is posted.

Please continue.

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

Let Penguins rule the earth.
Break some windows today.

For a while I'll be out of town for business & leissure.
After this while I'll submit you a formall description for RBOOP/X-like PL, interpretter & compiler. (I have a genuine ideea about this stuff that you won't find in any book)

I await the posting.

Until then I will focus on my employment situation...or lack thereof.

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

Let Penguins rule the earth.
Break some windows today.

There is no point me to submit the formal description here, since we already work together on CBOOP

I think all the others can do is to wait for our work's results.
================================================
((cons(car X)(cdr X))X)
holds(X,P):-P(X);holds(Y,P),IsA(X,Y).

Any (more) questions? SHOOT!

Will_E_Coyote knows me from years before the internet became popular. He had many good ideas...albeit all of them were pretty nefarious and illicit. But I respect SOME of his opinions, even when he is obnoxious about presenting them.

(P.S. Did the coyote stop posting under this handle? where are you now, my friend? Hiding?)


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

Let Penguins rule the earth.
Break some windows today.

: Will_E_Coyote knows me from years before the internet became popular. He had many good ideas...albeit all of them were pretty nefarious and illicit. But I respect SOME of his opinions, even when he is obnoxious about presenting them.
:
: (P.S. Did the coyote stop posting under this handle? where are you now, my friend? Hiding?)
:
:
: ****************************************
: Excellence Breeds! Go Hard or Go Home.
:
: Let Penguins rule the earth.
: Break some windows today.
:
:
Sorry about that! It might been some kind of cultural clash.
All I can say is that not even my father ever talked to me like Coyotte did to you. Therefore I felt the rage.

I stopped complaining about coyote's mouth when I watched him once burn-up a C64 trying to build a "home entertainment system." Guy is a pain...but he was ahead of his time.


...He is the only person I know who can code in x86 assembly from his head and actually make things work. BUT I AM NOT PAYING TRIBUTE

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

Let Penguins rule the earth.
Break some windows today.

Sam, about your project I already sent some messages in your mailbox. Did you read them ?

Until the day before yesterday you were almost fermly on the good track, therefore I sent you my deepest respects.

In this very moment I feel you are no longer controling the "situation" because I noticed you are conducting your work a little bit disorganized (my 20 years of professional experience tells it), belive me; and I'm trully sorry about that.

For the best results, try to be a little more speciffic, concise. Also try to use some mathematical like notations, because programming as well as conducting any analize *is* mathematics. [ Do do that and I guarantee the greatest results with a minimal effort ].

One more thing: Learn *only* from the best! that means that probably you have to download the "Beta programming language's refference" from
http://www.daimi.au.dk/~beta/Papers/BetaOverview/betaoverview.abstract.html
then select "PDF" and make a good ideea about what real OOP is. You may also consider g-beta language which is an extenssion of Beta. Reviewing your knowledge about LISP's philosophy may also be an asset.

Try some cluster's philosophy as I suggested to you; this may provide support for *classes on the fly* (built at runtime).

Are you somewhat in a hurry? because I smell some deadline around here.

I read my mail daily...usually.

Unfortunately, I was recently spending 12-16 hours a day reconstructing my company's bookkeeping system after losing our sixth bookkeeper.

...Then I found out why the books were out of kilter. My boss (the owner) was keeping the bookkeeper in the dark to conceal the fact that the company was in the red.

As a result of my diligent accounting work I was fired last week, re-hired a couple of days later, then fired again today because I finally got the books closed and balanced (in the red)!

Needless to say, the compiler is on hold...again.

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

Let Penguins rule the earth.
Break some windows today.