Object Oriented Programming

HotShoe

Well-Known Member
Licensed User
Longtime User
I'm from a time (late 70's) when you could depend on there being 32k of memory, and in most business systems 64k with another 64k for use as memory storage and ram drive space. This meant programmers had to write tight, fast, efficient code for CP/M and MP/M systems.

fast forward to now and I find that software houses would rather force the user to buy memory and fast systems because it is much cheaper than paying programmers to write that tight, fast, and efficient code.

I realize that OOP has made life easier in some ways as a programmer, but, and it's a big but, you inherit all of the slop and bugs in the base objects that you use. It's true that I miss procedural programming, but I do see the value of OOP as well.

For Android, I argued long and hard for Google to adopt Xorg's Xwindows for RISC systems instead of Dalvik, but I didn't have the juice to carry enough weight in the early stages of Android. My contention was that by going with xwindows, 100's of thousands of Linux programs were either instantly compatible, or could be easily ported. Also Android would inherit true multi-tasking and multi-user capabilities with proven resource efficiency.

Unfortunately, Google bought the rights to Dalvik and here we are today. My job was to build Kernel modules and shared object libraries for the base Linux system and not Dalvik, so at the time it didn't affect me in the least.

This rant has no real purpose, but I just read through another rant in the Bugs and Wish forum and thought it deserved more generic discussion without bringing B4A into the mix. So, feel free to rant here and/or tell me how backward and stuck in the past I am. :)

--- Jem
 

Beja

Expert
Licensed User
Longtime User
Hi Jim,
I am from your generation if not older.. at one point, in the early days of Windows (without suffix), some programmers said this is a conspiracy by Microsoft to shield programmers from programming and make them construction workers and not civil engineers.. even though it was time consuming and tricky, but I enjoyed the challenge of spaghetti coding. But these days even the construction workers became assemblymen and I bet it wouldn't be long before we become handyman working for MS and the other conspirators. We are living in captivity.
 

NJDude

Expert
Licensed User
Longtime User
... This meant programmers had to write tight, fast, efficient code for CP/M and MP/M systems.

Fast forward to now and I find that software houses would rather force the user to buy memory and fast systems because it is much cheaper than paying programmers to write that tight, fast, and efficient code.
What has also changed is the quality of the programmer, back then a programmer was able to write code by himself, create their own routines or brainstorm and come up with an algorithm and solution, nowadays (like we can also see it here in the forums very often) those "developers" just ask for "Please, write a SIMPLE CODE to do <fill_your_request>", basically, "Please write some code for me so I can just copy paste" instead of researching, and more importantly LEARNING.

...This rant has no real purpose
Of course, you are a chat regular, that's what we do :D.
 

thedesolatesoul

Expert
Licensed User
Longtime User
fast forward to now and I find that software houses would rather force the user to buy memory and fast systems because it is much cheaper than paying programmers to write that tight, fast, and efficient code.
This is not 100% true. Havent the requirements also increased? Images, bitmaps, resolutions, databases becoming larger and larger?
I think having a lot of processing power, the people who wrote tight code (and need to), still do. But sometimes its not worth the effort, when your machines are fast enough to do trivial stuff.

I realize that OOP has made life easier in some ways as a programmer, but, and it's a big but, you inherit all of the slop and bugs in the base objects that you use. It's true that I miss procedural programming, but I do see the value of OOP as well.
The value of OOP is that you fix the bug in the base object and its fixed across all of its instances. It makes unit testing a lot more easier than in procedural programming.

But your point is still valid, people dont write code as tight as they should. Dalvik isnt great at getting rid of objects fast enough (or is it?). In some ways Android is fairly inefficient, but its not so obvious as the guys writing the run-times are writing extremely tight and optimized code.
 

RandomCoder

Well-Known Member
Licensed User
Longtime User
Well I clearly don't have the level of experience as you guys, but I too feel that programming has become quite sloppy due in the most part to having so much memory and speed that it is no longer a prerequistite to write tightly coded routines. I'm a big believer in keeping my functions as small as possible to make the program as readable as I can but also to reuse as much code as possible. Just like TDS stated, using OOP means that applying one fix in a base class is then applies accross all instances without any further wrok being required.
 

Troberg

Well-Known Member
Licensed User
Longtime User
Basically, it boils down to computer power being cheaper than developer hours.

Also, OO (and other models for designing software, as well as frameworks) allow us to build bigger, more complex stuff.

However, an understanding of what's going on "under the hood" is always necessesary if you want to become a good developer.
 

schemer

Active Member
Licensed User
Longtime User
I remember my first computer. A TI994A and I knew I could never ever afford that expansion box, but I sure wanted it. :) Then I moved up to the Commodore 64 and C128 after that. I ran a BBS on both Commodore systems with LT. Kernal SCSI hard drives with "one" incoming connection on a land line. I also had a CMD (Creative Micro Designs) Hard Drive system later and ran it on the BBS. Those were the days....At the time it was amazing what a good team or individual coder could do with 64k of RAM.

LOAD "*",8,1
 

Troberg

Well-Known Member
Licensed User
Longtime User
Frameworks and libraries are probably another reason for sloppy coding. For e.g. including large overhead of functions when only a small one is required. I think that boils down to code management and distribution.

Yes and no. Frameworks and libraries are good when you need to do complicated stuff that you do not want to do yourself. For example, say that you have a program where you need to display data in a map, but the map bit is not the main thing in the program. Well, you don't want to increase the size of the project several times just to write your own map, and increase maintenance cost as well. In that case, it makes perfect sense to use a third party map library.

On the other hand, if you are just too lazy to make some simple file manipulation and string manipulation to read some CSV file, then you need to get your stuff together and start doing it yourself.
 

HotShoe

Well-Known Member
Licensed User
Longtime User
This is not 100% true. Havent the requirements also increased? Images, bitmaps, resolutions, databases becoming larger and larger?
I think having a lot of processing power, the people who wrote tight code (and need to), still do. But sometimes its not worth the effort, when your machines are fast enough to do trivial stuff.

Absolutely, software has become more complex and demanding as well.

The value of OOP is that you fix the bug in the base object and its fixed across all of its instances. It makes unit testing a lot more easier than in procedural programming.

Yes, if you have access to the base object, but this is rarely the case.

I think as NJ stated, both programmers and software houses have become more and more lazy in policing there own products and output.
 

HotShoe

Well-Known Member
Licensed User
Longtime User
Frameworks and libraries are probably another reason for sloppy coding. For e.g. including large overhead of functions when only a small one is required. I think that boils down to code management and distribution.

I agree. I think classes (objects) are much bigger now, encompassing more methods than they did in the early days of OOP. This makes it impossible for the modern smart linkers to take just what is needed and keep program (and memory) size small.

--- Jem
 

thedesolatesoul

Expert
Licensed User
Longtime User
I think as NJ stated, both programmers and software houses have become more and more lazy in policing there own products and output.
This is absolutely true. Due to impossible deadlines or customer requirements. Sometimes due to diluting code quality by fresh and inexperienced programmers and lack of training.
 

Troberg

Well-Known Member
Licensed User
Longtime User
This is absolutely true. Due to impossible deadlines or customer requirements. Sometimes due to diluting code quality by fresh and inexperienced programmers and lack of training.

Or due to architects who work on a cloud free altitude, making abstract constructions with little relevance to reality.
 

KMatle

Expert
Licensed User
Longtime User
Code quality is a thing. I work as a it project manager. Instead of "just developing" code of good quality we start with huge frameworks, solutions which will compile for 1-2 hours, etc. We only use basic arithmetic functions and absolutely no quantum mechanics.

When I talk to them I often ask "... and all of this is made to display just a few lines of text?!?! ... In a textbox? ... Wow..."

Some sort of code-inflation. Like when the first cd's came out. Coming from 1,44 MB discs the developers were asked to "fill" the empty space on it.
 
Top