March 29, 2024, 03:57:53 AM

News:

Own IWBasic 2.x ? -----> Get your free upgrade to 3.x now.........


Learning to use Aurora

Started by Haim, February 23, 2006, 09:34:39 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Ionic Wind Support Team

.NET isn't a language.  It is a collection of runtimes.  And is used by many languages.  C# being the latest bastardization of the C language.  C# for instance doesn't support multiple inheritance, C++ does.  Which one do you think as more of a pure OOP language then?

I'll refer this to the wikipedia defintion of OOP

http://en.wikipedia.org/wiki/Object-oriented_programming

Quote
Class â€ââ,¬Â a class defines the abstract characteristics of a thing, including the thing's characteristics (its attributes or properties) and the things it can do (its behaviors or methods) or features).

In this sentance a 'property' is generalized.  Using the word 'characteristic'.  Truth is there isn't a single accepted definition of how an objects attributes should be defined or used.  Just because I prefer a less bloated approach to Aurora doesn't mean it is not a pure OOP language, if used in that manner.

Then again ANY langauge that allows procedural programming could be said to be not a pure OOP language, which would eliminate everything except scripting and interpreter type languages.  Since all compiled languages need at least one non-oop based subroutine for the system to call upon execution.  Our 'main' subroutine.

Quote
Encapsulation â€ââ,¬Â conceals the exact details of how a particular class works from objects that use its code or send messages to it. So, for example, the Dogs class has a bark() method. The code for the bark() method defines exactly how a bark happens (e.g., by inhaling() and then exhaling(), at a particular pitch and volume). Timmy, Lassie's friend, however, does not need to know exactly how she barks. Encapsulation is achieved by specifying which classes may use the members of an object. The result is that each object exposes to any class a certain interface â€ââ,¬Â those members accessible to that class. For example, an interface can ensure that puppies can only be added to an object of the class Dog by code in that class. Members are often specified as public, protected and private, determining whether they are available to all classes, sub-classes or only the defining class. Some languages go further: Java uses the protected keyword to restrict access also to classes in the same package, C# and VB.NET reserve some members to classes in the same assembly using keywords internal (C#) or Friend (VB.NET), and Eiffel allows one to specify which classes may access any member.

We do have the public, private and protected keywords now.  However again encapsulation just specifies that the exact details of how a particular class method does it's job is not important.  Each OOP langauge is slightly different in this respect. 

My vision for Aurora was not to redefine current definitions of OOP, or to emulate any one particular language.  It is to create a language I can work in fluently without having to continually sidestep the implementation of the core syntax.  C++ requires a lot of sidestepping even if you try and create a pure object based implementation of an application. 

Your vision of an OOP language probably is different than mine, and that is fine.  Have you ever tried Oberon?

Paul.
Ionic Wind Support Team

Parker

September 18, 2006, 09:22:52 PM #26 Last Edit: September 18, 2006, 09:25:09 PM by Parker
Quote.NET isn't a language.  It is a collection of runtimes.  And is used by many languages.

Sorry, I meant the CIL language (which does support multiple inheritance, I have no idea why they leave that out of C#). Object oriented assembly language ::)

QuoteThen again ANY langauge that allows procedural programming could be said to be not a pure OOP language, which would eliminate everything except scripting and interpreter type languages.  Since all compiled languages need at least one non-oop based subroutine for the system to call upon execution.  Our 'main' subroutine.

I've heard this before, I think from someone who likes Java. I've also heard that C++ doesn't really support arrays, but then what is int i[10];? A vulture? ::)

I just meant that just because it's not in C++ why should that mean it's not a part of a pure OOP language? Yes I think it's cleaner, but I'm not going to ask for properties to be incorporated in Aurora if you think it would increase bloat. I was just wondering.

QuoteMy vision for Aurora was not to redefine current definitions of OOP, or to emulate any one particular language.  It is to create a language I can work in fluently without having to continually sidestep the implementation of the core syntax.  C++ requires a lot of sidestepping even if you try and create a pure object based implementation of an application.

C++ is much more feature rich than Aurora or really any other language I know of (though some others do provide different features), and I can see replacing it or giving it a different syntax is a huge task, and besides there's really no point to do that especially with a language with a similar syntax like Aurora. I think Aurora is easier to learn and use, and is very suitable for many tasks, but that C++ has a slight edge with professionals, which is caused by things like templates and operators that can be very confusing.

QuoteYour vision of an OOP language probably is different than mine, and that is fine.  Have you ever tried Oberon?

Certainly, I like Aurora but I also have my own ideas. Not that I can implement them though, with not having much time ;)

Oberon shares a certain resemblance to Pascal, not surprising since they're both by the same guy. But that's not exactly my favorite language.

Ionic Wind Support Team

September 18, 2006, 09:59:01 PM #27 Last Edit: September 18, 2006, 10:00:51 PM by Paul Turley
Quote
I've heard this before, I think from someone who likes Java. I've also heard that C++ doesn't really support arrays, but then what is int i[10];? A vulture? Roll Eyes

Technically that is C syntax ;).

Quote
Yes I think it's cleaner, but I'm not going to ask for properties to be incorporated in Aurora if you think it would increase bloat. I was just wondering.

One feature does not bloat make.  However they do add up over time and before you know it you're dealing with 6MB runtimes, impossibly large environments, and the code produced by users becomes sloppy and larger than it needs to be.  trimming the fat starts with a 'just say no' policy. 

There is a mythology in programming that because drive space, memory, processor speed, double every 18 months that there is no need to worry about the efficiency and size of code. That kind of thinking has brought us to where we are today.  With multi gigabyte operating systems requiring multi GHz PC's just to be able to run notepad.NET  ::)

I am one of the ever decreasing holdouts that still beleive quality of code is more important that the quantity of it.  It is why after a year we are still in the pre-release stages of Aurora.  And why I continually look for ways to improve the speed and size of all of the tools used by Aurora.  It is that kind of thinking that led me to create IBasic, and IBasic Pro.  Bigger is not always better and sometimes you have to cut corners to improve efficiency.  The tagline "Create executables with no runtimes needed" served me well for many years.

You, Parker, represent the new generation of programmers. It is my sincerest hope that you learn from us old guys and not sacrifice quality for the sake of convenience. Don't think that size and speed don't matter because they do, and you can do your part to stop the hemmoraging of bloated code.

10 years ago I could do more with my PC then I can now given the same representative percentage of code size over processor speed.  I could have more apps open at once, was more productive, and despite the fact that win 9x forced daily, sometimes hourly reboots, it was an order of magnitude smaller than the upcoming Vista.  What does the increase in code size and processor speed really give you?  besides nice looking alpha transparent windows, which do nothing at all really.

Quote
C++ has a slight edge with professionals, which is caused by things like templates and operators that can be very confusing.

C++ was a right place, right time language.  C programmers flocked to it and the resultant code base to draw on is staggaring.  The real edge it has with professionals, like myself, is time.  It has been around long enough that there is more reference material available for C++ then any other product in existance.  I still have my orignal VC++, on a dozen or so floppy disks ;)

Paul.
Ionic Wind Support Team

kryton9

September 18, 2006, 10:26:09 PM #28 Last Edit: September 18, 2006, 10:32:30 PM by kryton9
Paul, I don't know if you saw my other post earlier before Parker's about the material I read (reply#23)... but anyways here is what my thinking is at the moment:

1. You have an incredible ability to take the current complicated mess out there in the programming world and make it easier. No doubt about that.
2. You wanted to move passed iBasicPro and bring in OOP aspects that you love. Great, we the iBasic sheep are struggling to follow.

Here is where we diverge. I think since you are so versed in C and C++ you are clinging to it like those of us who are stuck with procedural are clinging to our ways.

With all the reading and testing about OOP in various languages I have been doing the last couple of months, there is a golden and rare opportunity for someone with your skills to develop the next revolution, not just be an inbetween step, but a leap.

From what I have read about OOP, I love it. It makes sense, is the future. By turning your back on certain things you see as bloat, you and the rest of us who could benefit from your skills are missing a golden opportunity. Auto Memory Management just a great idea. Realtime interactive development, a great idea. It is the future, it is just when will it be here.

I really think you should re-evaluate Aurora. Make it fully Object Oriented Programming. Instead of going on and on about what that entails, I would say don't be the next c or c++ but be the next smalltalk, but even better. Compiled, cleaner syntax and full support as you are doing for Aurora, console, windows, 2d, 3d, web.

Your talents are immense and now that you got me to taste OOP, I want to push you as I think Parker is trying to do to embrace what you ask us too, but do it the Turley way.

Parker

I'm just an annoying hindrance, don't take after me ::)

Well, everyone is annoying at some times, but I don't want to be a major influence anymore - I just wanted to get some of the main compiler features that didn't exist in IBasic in, but I'm not going to go petitioning for operator overloading, multiple inheritance, etc because then why don't I just use C++?

I know some people are devoted to certain languages (many [not all, but many] of the people still with IBasic are this way), but I don't like to be that way - I like to use what I think is easiest and best fit for the job at hand. I've tried many different languages, and there are a select few that I like to use. After learning Java and .NET (or C# rather), I've found that I really don't like it when a language hides things from you, which is mainly pointers in these languages.

I have two current projects, not very active since I don't have a lot of time. One is an IDE for Aurora (written in Aurora), the other is a scripting language (written in C++).

Since I'm young and a very fast learner, I don't know what it's like to struggle with OOP concepts and C++, so while I may think that feature X is better and cleaner, to someone else it might just confuse things more. I think if the aim of Aurora is to have an OOP language that is powerful but easy to learn, it should be led more by the users that need help but are willing to learn.

Ionic Wind Support Team

Kryton,
What is happening is your getting caught up in terminology when what you're asking for is already there.

Quote
Each object is capable of receiving messages, processing data, and sending messages to other objects. Each object can be viewed as an independent little machine or actor with a distinct role or responsibility.

They are not talking about messages in the Windows API sense.  A method call is sending the object a 'message' in that respect whether it is done through a virtual function table or COM interface. 

In the windows sense a message is something different, it is a UINT value that is stored in a queue (FIFO) that is read by a function.  'Sending a message' was always a misnomer in GUI docs as far as I am concerned.  You're really storing a message, to be later read by the GetMessage (or PeekMessage) function from that FIFO queue.  Nothing is transmitted in the radio sense ;)  Internally all Windows apps have a loop that calls GetMessage directly and a SELECT statement that calls a function based on the value of that stored message.  Even in Aurora there is a loop, invoked by the WAIT statement that calls GetMessage and then calls DispatchMessage (eventually).  DispatchMessage calls WndProc which has a SELECT statement that calls the OnXXX handler in the CWindow based object that the Windows window is associated with.

Quote
Here is where we diverge. I think since you are so versed in C and C++ you are clinging to it like those of us who are stuck with procedural are clinging to our ways.

Not true.  My first language that I learned was assembly.  Then C, then BASIC, followed by C++.  I have also used, to varying degrees, COBOL, FORTRAN, Pascal, PL/I, Rexx, ARexx, PHP, VB and of course dozens of so called 'scripting languages' which is just another fancy term for 'slow interpreter'.

Aurora contains the best of what I have found in those languages while refusing to submit to generalized ideas.  It may seem a lot like C++ on the surface, only because that type of syntax is commong in many languages.   

When I refer to bloat think about what an internalized 'property' method has to do.

#1 it has to deal with strings.  And account for both ANSI and Unicode.  Let's say you have a variable, named m_bkcolor that represents the background color of an object.  Since we need to deal with Unicode we will need two identical methods, using overloading. 

#2 And then you're forced to use a common base class to all classes since implementing properties on individual classes would be more bloat. 

CObject::Set(string name, int value)
{
...
}

COBject::Get(string name), int
{
...
}

CObject::Set(wstring name, int value)
{
...
}

COBject::Get(wstring name), int
{
...
}

Now we have to have the data structure to support properties.  Lets use hash tables because they are the most efficient, but lists could also be used.

class CObject
{
CIntAssoc m_listProperties;
}

So then we need a way to define properties.  Requring us to add another method the the common base class.

CObject::DefineProperty(string name)
{
...
}

And then a method to return an error when a property doesn't exist.  And the list goes on and on.  When all you really need to do , as an Aurora programmer, is just define two methods and a private variable in your class.  We'll go one step further and say we have a 'validity' check on the object as well.  Otherwise the private variable is rather pointless.



class MyObject
{
private:
     uint m_bkcolor;
     int m_bValid;
public:
     declare GetBKColor(),uint
     {
          return m_bkColor;
     }
     declare SetBKColor(uint clr),uint
     {
           UINT temp = m_bkColor;
           if(m_bValid)
                m_bkColor = clr;
           return temp;   
     }

}


Small, efficient, and follows my methodology of reducing code overhead.   Why require the derivation of a common base class when it is not always needed?  Why add the overhead of literal strings when just a simple method call will do.

If I were to need hundreds of properties that I wanted to access with string names then the CIntAssoc would do nicely.
class MyClass {
    CIntAssoc m_prop;
}

... In some method
m_prop.Add("Left", l);
m_prop.Add("Right", r);
m_prop.Add("Width", w);
m_prop.Add("Color", clr);

and then retrieving

l = m_prop.Lookup("Left");
r = m_prop.Lookup("Right");
...

That is what I am talking about Kryton.  Using what is already there and available instead of trying to add more overhead to the language just because it may or may not be more convenient.

The Associative Array classes CIntAssoc, CStringAssoc, CPointerAssoc all use hash tables making lookups almost instant.

Paul.
Ionic Wind Support Team

Ionic Wind Support Team

I should note that 'private', 'public' and 'protected' are valid keywords in Beta 1, Rev 1.  Sorry about posting code you can't yet run ;)

The associative array classes have been available for a while now though.
Ionic Wind Support Team

Rock Ridge Farm (Larry)

I think 'young' is the operative word. I know I do not learn as fast or as well as I did 40 years ago.
I am still stuck in C structure and syntax - I can do that but other stuff comes very slow.

kryton9

Paul, I see what you are saying. You definitly know more about this stuff than anyone else I know and I appreciate your efforts. I guess I just need to wait for Aurora to be finished, it just seems as it is so functional already, that it is complete and I guess I am getting way ahead of myself and any analysis and comparisons can't truly be made.

Did you get a a chance to watch the Alice video I posted about here? http://www.ionicwind.com/forums/index.php?topic=940.0

When Aurora is complete as you envision it, will we be able to write a program that could allow things programmed as shown in the first video, the one with voice?