View Full Version : Why OOP then and now
I found this video from 1989 and it is really exciting to see a presentation of OOP that is different. You can see how and why it came to be in this very nice presentation. It makes it easier to understand what makes a good OOP language and what doesn't. I think Charles is on this wave length already, Eros got his surf board out and is ready to hop on the wave. Hope this gives you guys some ideas on how to take and bring OOP to thinBasic.
http://video.google.com/videoplay?docid=-2058469682761344178&hl=en
The first video is important to watch as it also relates to what he is doing now a days. And believe me what they are doing is mind blowing. Even if you don't care about OOP, I think everyone will find this demonstration amazing.
Watch fullscreen to get the most out of the videos. Especially the first one as it is from old video tape days and pre-internet.
http://www.youtube.com/watch?v=gGw09RZjQf8
Enjoy and dream big guys!
Charles Pegge
17-05-2009, 22:27
Thanks Kent, Excellent videos!
I can see how this kind of visual programming will work for building forms, web pages and all kinds of graphics but I think the back end stuff will always require some kind of scripting, though this can be made much shorter and easier - attaching small programs to control an object's behaviour.
Anyway, its good aspirational material.
Charles
It is just hard to believe that they are doing that with Javascript in a browser. I liked how he talked about OOP in the first video too. He pointed things out nicely that I never really read in books. Mainly why going all OOP and the benefits of that approach. The benefits down the road are incredible when you see what can be done from almost having a built in debugger, the ability to translate to almost any language, writing lexers easier and of course as he pointed out, catching errors.
I was surprised by the resistance from the audience in the second one. They were seeing incredible things being done in front of their eyes and didn't have the imagination to see it. All the concerns they raised could obviously be addressed with coding in the future, they were missing the big picture of having such a tool at their fingertips. I felt so bad and was impressed how well he composed himself, he was probably thinking inside, what a bunch of weenies... here I am showing you a diamond and all you see is a rock.
Charles Pegge
18-05-2009, 05:10
Hi Kent,
I think it needs proof of concept. If this approach could be used to develop a demanding application - say a games engine or even a file serving system, compiling to machine code. then it could run rings around the development systems on offer today. There's no other way to convince the sceptics.
Charles
I think what they cleverly saw, that is the original SmallTalk team, is that no OS was out there that would allow them to do what they wanted. They didn't see any on the horizon either I would assume and so went about creating their Virtual Machine. This programming language being wrapped in a virtual machine, especially on old hardware I think is the one reason only why it wasn't widely accepted. Obviously SmallTalk was years ahead of any other language.
Then they made the very clever observation in observing computers today. Nearly everyone is able to run a browser, and of course browsers run javascript. Then the creative jump, let's bring the wonders of our language creating skills into this new world.
Future generations of thinBasic based on a kernel written in Oxygen could be something similar, allowing what Lively Kernel can't-- which is compiled code, to serve for running games and hard core apps.
Right now lively kernel being scripted in real time can bring truly interactive web based experiences, but not the stuff we here would be interested in. I think this sort of thing could give thinBasic its own unique market in the future.
That diagram in the first video where he shows how their oop implementation works is really neat. How everything is tables all linked via pointers thus allowing incredible OOP capabilities. I think it is worth studying and seeing how having everything an object has so many benefits that are hard to see otherwise.
Charles Pegge
23-05-2009, 11:33
OOP resolves some of the complexity in a large program, but it's not the final story. In many games and simulations, there is a need for parallel processing - where different classes of objects interact in a variety of ways as individuals. Objects may be attracted or repelled by others. They may explode, or break down into other objects or fuse together, or turn into fossils and become part of the landscape.
Up to a certain level of complexitiy you can process the objects collectively - as in colliding spheres with different sizes, density and elastic collisions. But anything more complex than this - even a collision between more than 2 objects simultaneously - the program structure soon becomes unmanageable.
This task is to make further levels of complexity tolerable.
Charles
jcfuller
23-05-2009, 11:51
Homer has done amazing things with OA32.
http://www.asmcommunity.net/board/index.php?topic=29229.0
James
John Spikowski
23-05-2009, 22:21
Play Station Supercomputer (http://www.wired.com/techbiz/it/news/2007/10/ps3_supercomputer)
A professor in Germany (Helmut Dersh (http://webuser.hs-furtwangen.de/~dersch/)) is using the PS3 as a panorama stitching machine using the parallel processing features of the system.
Thanks for the links guys.
Charles you are right of course, I guess that is why everyone is scampering to be like Erlang, but looking at Erlang code is even worse than looking at C++ code :)
Hi
Just a few thoughts on OOP. It's POO spelled backwards. I guess I'm just an archaic structured programmer. It's hard to change. Some ways I can see the benifits of POO, I mean OOP, other ways it seems to be piles of redundant code created for each object. A thousand objects each have their own code to accomplish a specific procedure. That's a thousand lines of the same code wrapped in a package called a method. That seems excessively redundant. Why not one procedure to accomodate a thousand objects. It's hard to change. I like code to be small, tight and efficient... not redundant. (It's the old 640K barrier back in the old dos days of programming... do more with less memory) It's hard to change. That's why I like thinBasic. At least I like it enough now to invest some time learning to use it. It's a lean, clean, coding machine. (Hey... that sounds like a slogan... ThinBasic, Lean, Clean, Coding Machine) It also seems much less of a hassel to learn than LUA, PERL, RUBY, or PYTHON. I just spent the better part of a month reading about and trying those scripting languages. That was enough to send me right back here to thinBasic. ThinBasic modules already cover most features that require many third party librarys to use with the other scripting languages. Also thinBasic isn't POO, I mean OOP :lol:
Sorry... didn't mean to get on the soap box :oops:
Pipes
Charles Pegge
10-06-2009, 19:22
As with the development and adoption of structured programming some 30 years ago, OOP was developed to make the larger programs better organised and easier to follow. But if the language imposes a particular style of coding that does not fit the task then the result is more complexity and convoluted code (- deserving your term: POO.)
If your program uses many different kinds of data and looks like a database then OOP might provide the best solution. But if it looks more like a spreadsheet then maybe you would be better served by Functional programming techniques.
But for large scale programs, block structures, subs and functions alone are insufficient to keep the code organised so something like OOP is going to remain a necessity. In Biology higher cells keep their DNA very tightly organised in the nucleus, forming chromosomes whenever the cell is about to divide but bacteria being simpler organisms do without these structures.
Petr Schreiber
10-06-2009, 21:11
I appreciated OOP this year for the first time - it is done very well in C# ( first language in which it made sense to me ), but maybe I had just good teachers. Some obscure OOP things like properties to just access one variable are optimized with the compiler, so there is no performance hit you would expect from using method to access variable. Too bad .NET requirement will keep me away from this language for most work.
We used C# for AI algorithms, and OOP fitted there well. I also like the ability to create variable dynamically - that means spawn it from clear water and then remove from memory when no more necessary. We can do this with ThinBasic too, using heap functions.
I think what I like most on C# implementation are the interfaces ( recipe which says what class should satisfy ) and genericity ( use is very close to what I use MACROs for in PowerBASIC )
I think OOP needs lot of discipline too - you can go the wrong path easily, badly designed class can be as hellish as any other thing.
Then of course Charleses Oxygen OOP, also very nice, and clearly showing OOP and performance can go hand in hand. Along with C#, my favourite OOP implementation so far.
Interesting is PowerBASIC COM compatible object model, performance is very good, but it does not allows as many OOP stunts as the two mentioned ( by design ), the interface-class relationship is little bit unusual.
I think languages should always allow to decide for what use OOP ( C# does not, Charleses Oxygen BASIC does ), as it is not necessary in all cases, but in others it can simplify coding a lot.
Petr
Charles Pegge
10-06-2009, 23:22
Structured programming is almost universal across the spectrum of programming languages but there are so many different implementations of OOP - it has not been the panacea to manage complexity that is proponents had hoped for. I think the main issue is to be able to express a programming task clearly with a minimum of workarounds. Some tasks like encryption or parsing are best handled in assembly code - others like page-formatting and web pages require a markup style of programming.
But Basic has proved to be surprisingly flexible considering its humble origins and we have not reached the limits of its elasticity yet. Although Basic is easy to read, it has a complex syntax offering many avenues for extension unlike simpler languages such as Forth which though elegant in concept proves very difficult to handle data types and complex APIs.
I did everything I could to stay away from OOP for too many years. I did use it with HyperTalk, but that was so easy, not like c++ OOP , so I didn't count that as being an OOP programmer. And for most apps a single programmer does, procedural programming is enough. But OOP does allow once you have the classes in place for some powerful flexible ways to work.
I don't like to plan and just jump in and code. I felt at home with goto's and gosubs but then saw the benefits of procedural programming and moved over to that pretty quickly. I think what puts most people off of OOP is c++. It is just not easy to read with all the different meanings that * has or &. Also the naming of the operators is confusing so it makes it harder to learn. Java is much nicer. C# is even more nicer than Java.
I would say .net will be everywhere in another year or so at most. Deciding if one should use it or not will not be an issue. If you read up on .net, it has come into its own finally. To handle all the places code must be usable from intranets, internet, stand alone it just makes sense. It also allows you to use your favorite language style of choice to work with any other programmer and with them using their language of choice. Each year the list of available languages available for .net is growing. I can't believe I have come this far in one year on my opinion of .net, but as Petr pointed out with C#, until you spend time to learn what these new technologies are about, it seems like bloat, but in reality what was bloat in the early days has come to a point of finally bringing the ideals to life.
I don't know if any of the guys checked out how you can use scripting languages in your code and how that could relate to thinBasic, but it seemed like an interesting example to me.
Greetings thinBAsic Users,
It appears I was erroneous concerning my assumption about some aspects of OOP. Here's my quote...
A thousand objects each have their own code to accomplish a specific procedure. That's a thousand lines of the same code wrapped in a package called a method. That seems excessively redundant. Why not one procedure to accomodate a thousand objects.
Progressing in my studies of C++, I came across this tidbit of information concerning methods or rather member functions.
People new to OOP often suppose that objects must be quite large because they contain data members and member functions... Objects contain only data... The compiler creates one copy (only) of member functions seperate from all objects of the same class. All objects of a particular class share this one copy. Each object, of course needs its' own copy of data... (ref How to Program C++, 5th Edition Dietel & Associates Inc. Prentice Hall pg. 487)
This refers to standard C++ OOP. It's the same as structured. A thousand objects use the same code to process the object data. Only the compiler handles the details automatically. Hmmmmmm... There seems to be more going on in the universe than I am aware of. :read:
May all of your thinBasic endeavors be successful,
Pipes :D