Author Topic: classes and getting too big  (Read 7462 times)

0 Members and 1 Guest are viewing this topic.

kryton9

  • Guest
classes and getting too big
« on: August 21, 2011, 11:53:17 PM »
Charles, after watching both videos of John Carmacks talk at quakecon2011 as linked in the thinBasic forums. I was trying to figure out how he restricted his c++, to almost Java like features.
Then I thought well, maybe I should just use Java, but then there is a nice engine already in Java... so I have been going around in circles and doing lots of pc gaming in the meantime just relaxing and thinking.

About classes becoming too big, yes that is something I see all the time. It doesn't help I don't think making bigger classes from smaller ones. At least it doesn't make it easier to use. Here is something I was looking at last night in the Java API. http://download.oracle.com/docs/cd/E17802_01/j2se/javase/technologies/desktop/java3d/forDevelopers/J3D_1_3_API/j3dapi/javax/vecmath/package-tree.html

It get overwhelming quickly. I saw that also when I was playing with the console class and sql class even. I think perhaps going procedural and not object oriented for the main framework might be the way to go and use classes for actual objects sitting in the framework.  So for example, my game engine would be procedural, but my entities let's say for a game would be objects. That is what I am thinking about while playing re-evaluating the whole where to go OOP and not.
« Last Edit: August 21, 2011, 11:55:19 PM by kryton9 »

Charles Pegge

  • Guest
Re: classes and getting too big
« Reply #1 on: August 22, 2011, 01:47:14 PM »
Hi Kent,

Looking at some of my own code, it seems inescapable that there will be a few procedures that are very long and linear like a factory production line. I've seen it in Opengl scene-building and the compiler itself. The linear structure is then supported by many minor procedure calls. It's like a pine tree.

Staying with classes will give you the advantage of keeping many of the variables shareable among all the procedures of the class but out of global namespace.

Without classes you have to use a large number of globals or UDTs and pointers, which perhaps characterises most C coding styles.

This still leaves us with the problem of dealing with huge code libraries, which is why I think manuals are insufficient and some form of smart code searching and cross-referencing utility is essential for speeding up development.

Charles

kryton9

  • Guest
Re: classes and getting too big
« Reply #2 on: August 22, 2011, 07:15:31 PM »
Things have just gotten too complex. I don't know how John Carmack can program for xbox, pc and playstation 3. What I nightmare that must be!

I was hoping Android would bring back the old fun days to programming again, but it doesn't. It is so irrational, it is humorous.
You must program for android in java via an emulator. But you can't run java programs in android.
Android and Google's main strategy with Chromium, it is all in the cloud... well you can't run java applets in any browser with an android device.
Oh and remember o3d, google's 3d for the browser... you got it, it won't run on android.

I am almost tempted to buy something like this and just develop on it, but I am sure there are probably gottcha's in that too.
http://www.arm.com/products/tools/development-boards/index.php

JRS

  • Guest
Re: classes and getting too big
« Reply #3 on: August 22, 2011, 09:44:10 PM »
Nokia had the right idea with the N900 portable computer running Linux with a custom Gtk front end. (Maemo 5) I had ScriptBasic running in the emulator but gave up on the effort when Nokia dumped the open source initiative for MS Mobile 7.



Code: [Select]
FOR x = 1 TO 5
  PRINT x,"\n"
NEXT x

more ...
« Last Edit: August 23, 2011, 05:55:10 PM by JRS »

Charles Pegge

  • Guest
Re: classes and getting too big
« Reply #4 on: August 23, 2011, 01:03:12 AM »

It seems none of these devices are open-architecture. A combination of security and commercial interests is probably responsible for this situation. We are restricted to using only the official portals they provide.

But things may improve as PC electronics continues to shrink and consume less power, competing with these proprietary architectures for the middle ground between phones and full-PCs.



Charles

Charles Pegge

  • Guest
Re: classes and getting too big
« Reply #5 on: August 23, 2011, 01:28:09 AM »

Quote
I was hoping Android would bring back the old fun days to programming again

I miss kitchen table electronics. It is where I started. But small scale devices are very much alive today. & You have the convenience of programming them through the USB port. I would love to program these tiny devices in Oxygen. Some of them at the lower end would only be large enough for about 10 lines of Basic :)

http://www.microchip.com/

Charles

efgee

  • Guest
Re: classes and getting too big
« Reply #6 on: August 23, 2011, 10:59:33 AM »
Charles,
there are open source projects out there and one of them is OpenPandora but the problem with them is that the hardware is always years behind and the cost is actually too high; it's not their fault, it's just what you get in small production quantities.


One dev board I have is mbed and it's pretty neat because you don't need a special programmer or hardware interface.
It has a usb connection and it presents itself to the pc as an "external drive".
This way you just copy your binary onto it, reboot it and you are good to go because the micro-controller will load the newest binary on that "external drive" (if needed).
You can even leave the source code on this "external drive" or older binaries which is pretty cool (so they don't get buried somewhere else...).
They also have a online compiler, just copy and paste you program and get it compiled...
« Last Edit: August 23, 2011, 11:44:26 AM by efgee »

efgee

  • Guest
Re: classes and getting too big
« Reply #7 on: August 23, 2011, 11:33:49 AM »
JRS,
I owned a N900 from Nokia for a few weeks but gave it back to Fry's because I hated the video output. The N900 has 800x480 resolution and the video output converted it to 640x480, and with that circles became ellipses... how stupid!

efgee

  • Guest
Re: classes and getting too big
« Reply #8 on: August 23, 2011, 11:43:07 AM »
kryton9,
Because of your post I took the time and watched the presentation and the Q&A (jumped over games related stuff because I was only interested in hardware and software).
This guy really seems to know what he is talking about... thanks.

Anyway, what I got out of it was that John Carmack did not say he dislikes oop (because it's too big or so), but he said that 95% of code should have hard restrictions to limit programmers to essentially the Java subset of C++ because even if the programmer writes all his new code in this "sudo functional style"... unless something is made impossible it will still creep into the code base.

Here a list of things he dislikes a lot (could be that I missed some stuff; feel free to add...) :

1.) unchecked arrays
2.) uninitialized pointers
3.) "use after free" (suppose he means reusing vars because they "should" be freed by now...)
4.) pre-def format specifiers
5.) operator overloading
6.) null pointer

Really hope Oxygen is able to capitalize from this information...

He also talked about using static code analysis a lot (MS Analyze and Lint/pcLint) because its invaluable. Sure if you have this amount of source code you need something in place to find all the gotchas.

Thanks again for the link.

kryton9

  • Guest
Re: classes and getting too big
« Reply #9 on: August 23, 2011, 04:35:08 PM »
Thanks for the link for mbed. There are so many devices out there that you don't see in main stream tech sites.

Also as Charles mentioned it is just a matter of time before we can use a real OS on small cheap devices.
Right now there are some devices, but they are expensive for the power.

I like the tegra 2 chipset so far in the tablet. It runs cool, there is no heat in my tablet even after hours of playing games on it
and the screen is really really nice.

Charles Pegge

  • Guest
Re: classes and getting too big
« Reply #10 on: August 26, 2011, 07:46:25 AM »
Quote
Here a list of things he dislikes a lot (could be that I missed some stuff; feel free to add...) :

1.) unchecked arrays
2.) uninitialized pointers
3.) "use after free" (suppose he means reusing vars because they "should" be freed by now...)
4.) pre-def format specifiers
5.) operator overloading
6.) null pointer

Really hope Oxygen is able to capitalize from this information...

Oxygen has very few restrictions so all of these sins are possible :)

I think the next big step in programming might be to separate the programmer from the source code, preventing direct access and to treat all the collection source files like a database.

With a Data-oriented IDE, it would be much easier to get information about similar code which already exists and be able to derive new functions from it.

Detailed pre-compile checks can be done before new code is committed to source.

In many cases run-time checks could also be done in isolation with temporary  diagnostics  before the code is committed.

Charles

« Last Edit: August 26, 2011, 07:51:10 AM by Charles Pegge »

efgee

  • Guest
Re: classes and getting too big
« Reply #11 on: August 26, 2011, 11:39:30 AM »
Oxygen has very few restrictions so all of these sins are possible :)

That's what I feared.
Personally I prefer languages that confine me in an healthy way...

I think the next big step in programming might be to separate the programmer from the source code, preventing direct access and to treat all the collection source files like a database.

With a Data-oriented IDE, it would be much easier to get information about similar code which already exists and be able to derive new functions from it.

Detailed pre-compile checks can be done before new code is committed to source.

In many cases run-time checks could also be done in isolation with temporary  diagnostics  before the code is committed.

I see a man with a vision... go for it  ;D

Charles Pegge

  • Guest
Re: classes and getting too big
« Reply #12 on: August 26, 2011, 01:53:14 PM »

Restricting the language would only prevent a particular set of errors. Design errors and run-time errors are far greater in number than things which can be caught at compile time.

I see the main problem lies in the sheer vastness of code libraries with thousands of procedures and tens of thousands of equates. Building an application using manuals alone is extremely laborious and error prone. Programmers get tired then make more mistakes.

Taking code that already works then extending or modifying it is much the easiest way to go. You don't have to have a complete knowledge of the system to do this. I believe this is how things are done in Biology :)

Charles

kryton9

  • Guest
Re: classes and getting too big
« Reply #13 on: August 31, 2011, 04:14:45 PM »
I see the design appeal of a small core and everything else being libraries... but as I see in c++ all the time. All the libraries have a different style and as Charles mentioned those darn equates that everyone makes.
Perhaps once oxygen is fleshed out to version 1.0, then this small core library design can still go on in oxygen and another language can fork off of it where everything is added to the core, no libraries needed type of language. No massive equates, just a nice small set of data types. The compiler can remove core commands that are not used when compiling to make the exe small.

Charles Pegge

  • Guest
Re: classes and getting too big
« Reply #14 on: August 31, 2011, 11:21:47 PM »

There is a search tool I'm working on which I hope will make code-hunting a lot easier. It can be used together with any IDE to locate pieces of code over many directories and hundreds of files interactively.

You will find it in the latest Oxygen in-progress version in /tools/search/

Press F1 to display simple instructions

Charles

Here is an independent exe version. You can enter any directory\filespec in the list on the left panel.