Warning

 

Close

Confirm Action

Are you sure you wish to do this?

Confirm Cancel
Member Login

Site Notices
11/20/2019 5:07:11 PM
Posted: 10/27/2006 8:05:55 PM EST
[Last Edit: 10/27/2006 8:06:34 PM EST by Zaphod]
It's been a LONG time since I programmed a computer. TurboPascal 3.0, in fact.

I look at modern programs, especially big ones like operating systems, spreadsheet programs, word processors, and things like Statistica and Mathematica, and I simply sit in abject wonder.

How the hell are such programs written? What is the design concept? How is it put together? How is it tested, compiled, and launched with so many programmers working on it?

Seriously. It seems to be an almost impossible task. Can someone walk us through the process and maybe some of the techniques?

Thanks.
Link Posted: 10/27/2006 8:09:02 PM EST
Object oriented.

Component based.

Dynanmic loading during runtime.

Establish fundamental product principles.

Maintain a tight infrastructure team.

Build around it.

Spend big bucks.
Link Posted: 10/27/2006 8:10:16 PM EST
I've wondered about Photoshop MANY times.
Link Posted: 10/27/2006 8:11:58 PM EST
[Last Edit: 10/27/2006 8:12:37 PM EST by Zaphod]

Originally Posted By MissouriBob:
Object oriented.

Component based.

Dynanmic loading during runtime.

Establish fundamental product principles.

Maintain a tight infrastructure team.

Build around it.

Spend big bucks.



Perhaps I should have stipulated that the answers be in ENGLISH.

WTF does all that mean?
Link Posted: 10/27/2006 8:19:55 PM EST

TurboPascal is what I learned on in college. Since then I've mainly written Matlab code, very short programs with definite purpose.

I'm curious enough to watch this thread...
Link Posted: 10/27/2006 8:19:57 PM EST
Think about it this way....

Compartmentalize the various logic functions...have teams take on the task of writing the code for individual functions, then bundle the components and debug.

In the most simple way, break apart the program into discrete operations...develop them seperately and combine the parts at the end.

The stuff I do is fairly basic bit register stuff, and TDM....but as things get more complicated it helps to split it up into clearly seperated components.
Link Posted: 10/27/2006 8:20:31 PM EST
I just want to know how the first GUI operating systems were made. "OK, we'll write in this code and it'll look like this, when used through this viewer... which we haven't made yet.. shit."
Link Posted: 10/27/2006 8:25:40 PM EST

Originally Posted By leelaw:
I just want to know how the first GUI operating systems were made. "OK, we'll write in this code and it'll look like this, when used through this viewer... which we haven't made yet.. shit."


An OS is an OS. GUI sits on top of that.

The key for the modern GUI was the ability to write mult-threaded code (do several things concurrently and still keep it coordinated).
Link Posted: 10/27/2006 8:27:59 PM EST

Originally Posted By macro:
but as things get more complicated it helps to split it up into clearly seperated components.


Okay, so let's take Excel as an example.

What are some of these components (or what do you THINK they are)?
Link Posted: 10/27/2006 8:28:31 PM EST
Usually, there's a core piece of code written by a really smart guy that performs the primary operations of the program and then hundreds of little "features" written by not so smart guys to satiate the desires of sales and marketing.

Most very large systems are, at their core, pieces of shit, that work due to the grace of God, not the result of some grand design. After several versions, even the most beautifully designed systems can degrade to the level of spaghetti code out of expediency: because when marketing wants something, they must have it, and they must have it now.

I have worked on systems containing over 1 million lines of C++ code. What starts as beauty ends up as crap, but if it runs and gets the job done, that is all the customer cares about (as he should).

Also, you would be surprised. Some very large systems only have 2-3 full-time guys on them.
Link Posted: 10/27/2006 8:30:44 PM EST
abstraction
generics
100 monkeys pounding on a kbd

Please explain OOD and development in 100 words or less grasshopper.
Link Posted: 10/27/2006 8:32:32 PM EST

Originally Posted By Zaphod:

Originally Posted By macro:
but as things get more complicated it helps to split it up into clearly seperated components.


Okay, so let's take Excel as an example.

What are some of these components (or what do you THINK they are)?


File I/0.
Import/Export.
Calc and re-calc.
Graphing.
Printing.
Editing.
Linking and embedding (OLE).
Scripting.
Macro recording and playback.

Blah blah blah...
Link Posted: 10/27/2006 8:33:43 PM EST

Originally Posted By Sub-MOA:

Please explain OOD and development in 100 words or less grasshopper.



No.

Link Posted: 10/27/2006 8:34:24 PM EST

Originally Posted By MissouriBob:

Originally Posted By leelaw:
I just want to know how the first GUI operating systems were made. "OK, we'll write in this code and it'll look like this, when used through this viewer... which we haven't made yet.. shit."


An OS is an OS. GUI sits on top of that.

The key for the modern GUI was the ability to write mult-threaded code (do several things concurrently and still keep it coordinated).


Its amazing how much is taken for granted today.
The simple concept of a GUI was once groundbreaking.
Really, the development of the mouse as an input device drove modern applications.

Think about the input devices.....keyboard....mouse....and with a few limited exceptions, thats all we have. So much of end user apps were tailored to the mouse since people didnt really know how to type, and more to the point, it takes time.

The 'point and click' concept changed the scope of what an application eeded to do....hence the GUI was developed. Prior to the mouse, all input was command line interface....no geometric navigation. Once you could point and click, graphics were needed to lay out a field on which to place clickable options. Since then very little has changed. The basic concept of how a human interacts with a computer, or more specifically, how a human inputs data, hasnt changed a whole lot.

I am really curious to see what comes next.

Since I am a network guy, quantum computing intrigues me.
The idea of moving data instantaneously could change everything...if it becomes possible to transit distances greater than the fraction of a millimeter that we can today.

The future is an awfully big place it would appear.
Link Posted: 10/27/2006 8:35:23 PM EST
10 PRINT "BITE ME"
20 GOTO 10
Link Posted: 10/27/2006 8:42:58 PM EST

Originally Posted By mattja:

Originally Posted By Zaphod:

Originally Posted By macro:
but as things get more complicated it helps to split it up into clearly seperated components.


Okay, so let's take Excel as an example.

What are some of these components (or what do you THINK they are)?


File I/0.
Import/Export.
Calc and re-calc.
Graphing.
Printing.
Editing.
Linking and embedding (OLE).
Scripting.
Macro recording and playback.

Blah blah blah...


This is essentially what i was getting at....I would have started with the basic mathematical functions, then designed the graphical representation for both the input interface and the output display, then worked on a field of use (the cells, the ability to scale the geometry, etc)

With excel you are really just graphically representing a grid which has no function but to serve a psychological frame for the end user. The program only needs to be able to index the raw data and then order the logical operations the user wished to be performed on the raw data. Once and input mechanism is defined to get the raw data in, another must be implemented to manage the operations to be performed. A graphical apparatus would then manage the display. This gets beyond my area of expertise a bit but it principle I see it working this way. The thing that blows my mind is the idea that multiple teams of people are creating modules of apps independantly and yet at the end of the project, everything is compiled and integrated. That is just a whole lot of coordination.
Link Posted: 10/27/2006 8:43:28 PM EST
Abstraction is the greatest tool we have available to help us understand the world. You never try to grasp something as large as a modern application at once. You divide it into systems and components when you think about it and when you implement it. I maintain a billing and accounting/CRM/ERP system with about 1.1M lines of code of which about 90% of it was written by myself. It was written in a combination of Smalltalk, C, Perl, shell-scripts, Java, LISP, a tiny bit of FORTRAN, and PHP. The backends are a nightmarish combination of flat-files, Berkeley db, dBase, mSQL(converted to MySQL), Informix, Adabas, PostgreSQL, and XML, but I'm in the process of converting as much as I can to InnoDB (no owned by Oracle). About equal parts of it was originally written on DOS, Windows, Linux, SunOS, and AIX, but now all of it will run on Linux or OSX.

Even though I wrote it, when I look at any one nontrivial program typically I still do not understand everything about it. You have simple ideas of what a program does, for example, today I added a feature to the program that exports an XML version of the daily invoices. Then you look at the individual functions the program uses that have a simple, single purpose. You think on the level you need to to solve the problem at hand. The functions act as well documented interfaces so you don't have to understand the entire program or entire system to work on a part of it. This also gives you the chance to delegate the writing and testing of the larger project.

I'm just an old farmer that dropped out of school in eighth grade so I have to use all of the tools I can to get systems working. Over 20 years ago I wrote a textbook on building large-scale systems that was used at several colleges. If you want more of an old guy rambling on, just ask.z
Link Posted: 10/27/2006 8:45:04 PM EST

Originally Posted By macro:

I am really curious to see what comes next.

Since I am a network guy, quantum computing intrigues me.
The idea of moving data instantaneously could change everything...if it becomes possible to transit distances greater than the fraction of a millimeter that we can today.

The future is an awfully big place it would appear.


Read the other about recent developments in quantum security. They can get it up to about 100 miles on premium fiber. Tamper proof and unbreakable.
Link Posted: 10/27/2006 8:48:25 PM EST

Originally Posted By rasanders22:
10 PRINT "BITE ME"
20 GOTO 10



10 PRINT "BITE ME"
15 GOSUB 30
20 GOTO 10
30 INPUT X "DO I WIN - TYPE YES OR NO "
40 IF X=YES THEN GOTO 60
50 IF X-NO THEN GOTO 10
60 END
Link Posted: 10/27/2006 8:56:35 PM EST

Originally Posted By MissouriBob:

Originally Posted By macro:

I am really curious to see what comes next.

Since I am a network guy, quantum computing intrigues me.
The idea of moving data instantaneously could change everything...if it becomes possible to transit distances greater than the fraction of a millimeter that we can today.

The future is an awfully big place it would appear.


Read the other about recent developments in quantum security. They can get it up to about 100 miles on premium fiber. Tamper proof and unbreakable.



One of the coolest things I read about regarding quanta and security was the idea of using a radioactive isotope to generate a private key. On each side of an encrypted tunnel, the KMP would use a given isotope as a catalyst for managing the key. A circuit would be configured in such a way that as the isotope decayed, a counter would take the number of isotopes and run that number against an algorithm to generate a random key. Since both sides of the tunnel would have identical samples of the isotope (split from an original single sample) the isotope count would always be identical on each side of the tunnel. Being that half-life would be unique to the individual sample, it would be next to impossible to recreate the series of calculations used to generate the keys. By constantly re-negotiating the key, it becomes infinitely impossible to hack the tunnel, since the key is never the same for more than a few clock cycles. There was an article in SA several years ago regarding this concept. I havent heard much about it lately, but the concept is fairly cool.
Link Posted: 10/27/2006 9:11:37 PM EST
OOD in 100 words or less

Inheritance. You inherit the characteristics of your parent. You don't have to recreate that.
vehicle -> wheeled vehicle -> motorized vehicle

Polymorphism. Ability to have a type of code react to the same input in a number of different ways.

Encapsulation. One piece of code (object) deals completely with that object's task. Examples: an object about files would be able to read, write, delete, print, copy all within that object.

Combine these concepts.
Link Posted: 10/28/2006 4:06:03 AM EST

Originally Posted By macro:

Originally Posted By rasanders22:
10 PRINT "BITE ME"
20 GOTO 10



10 PRINT "BITE ME"
15 GOSUB 30
20 GOTO 10
30 INPUT X "DO I WIN - TYPE YES OR NO "
40 IF X=YES THEN GOTO 60
50 IF X-NO THEN GOTO 10
60 END


Stack overflow.
Link Posted: 10/28/2006 6:46:42 AM EST
My wife is an SAP programmer - they never start a new project without a tightly written spec. This is discipline that could be adopted by many organizations that write programs.

For my own programming, many moons ago I worked on a simulation with about 2.5 million lines of excutable code - an enormous routine at the time, written for the mighty VAX machine. We started before we knew precisely what needed to be simulated, or how, so the programs (FORTRAN) were written in a modularized manner consisting of call statements to various subroutines that might do a computation or simply return an answer based on a rule of thumb to start. What I learned from that was that it made my own programs for school or work very simple to debug because there were very few long drawn out sequences of code. The danger of doing this on a VAX is causing the machine to page virtual memory too often, but that could be mitigated by careful arrangement of Do Loops and so on.
Link Posted: 10/28/2006 7:03:22 AM EST
[Last Edit: 10/28/2006 7:13:08 AM EST by azsavage]

Originally Posted By Sub-MOA:
abstraction
generics
100 monkeys pounding on a kbd

Please explain OOD and development in 100 words or less grasshopper.


I started life as a software developer years ago and I am currently software architect.

In object oriented programming everything is an object in a similar way that things are objects in the real world. Say for example you have a desk. Your desk has a width, height, drawers, color etc. Each one of these properties can be either what is called atomic meaning that it is in its simplest form (like width for example) and has no other properties. Or it can be another object (like a drawer) which in itself has properties like width, color etc. Just like in the real workd objects in software are composed of other objects untill you are down to the smallest object.

Take Excel for example - you have a "cell object" in Excel that under the hood has properties. It has a color, border, text, format etc.

Big software projects are like construction projects. Software architects design the app like a building architect. Then teams are formed and dependencies worked out. Where in the real worldyou must have a foundation and say plumbing for a building in software you need to have a similar foundation for the application. Then portions of the program are added by the teams (think sub contractors) untill the application is built.

When you build software like this it is much easier for people to develop but it comes at a cost of memory and processor requirements.


Edit - adding more details....

One of the things that is always being looked at is in weighing the balance of performance /project timelines/ budget and functionality. In many cases it is less expensive to buy faster hardware than to spend more money optimizing code for speed. Generally developers cost more than hardware. This one of the reasons your super fast machine from 3 years ago dogs it when you run the latest software.
Link Posted: 10/28/2006 7:06:27 AM EST
[Last Edit: 10/28/2006 7:06:56 AM EST by david_g17]

Originally Posted By rasanders22:
10 PRINT "BITE ME"
20 GOTO 10



http://www.glarkware.com/media/product_main_u_basic.jpg

eta: they always forget the new line character.
Link Posted: 10/28/2006 7:25:42 AM EST
This thread reminds me why I am no longer a CS major.
Link Posted: 10/28/2006 8:14:41 AM EST

Originally Posted By MissouriBob:
OOD in 100 words or less

Inheritance. You inherit the characteristics of your parent. You don't have to recreate that.
vehicle -> wheeled vehicle -> motorized vehicle

Polymorphism. Ability to have a type of code react to the same input in a number of different ways.

Encapsulation. One piece of code (object) deals completely with that object's task. Examples: an object about files would be able to read, write, delete, print, copy all within that object.

Combine these concepts.


Don't ever write a book for newbies.

He doesn't even know what OOP is, let alone those terms.
Link Posted: 10/28/2006 8:59:27 AM EST

Originally Posted By david_g17:

Originally Posted By rasanders22:
10 PRINT "BITE ME"
20 GOTO 10


www.glarkware.com/media/product_main_u_basic.jpg
http://www.glarkware.com/media/product_main_u_basic.jpg

eta: they always forget the new line character.



PRINT spits out a newline automatically, like puts() but unlike printf() in C.

Link Posted: 10/28/2006 9:00:28 AM EST

Originally Posted By ChiefPilot:

Originally Posted By david_g17:

Originally Posted By rasanders22:
10 PRINT "BITE ME"
20 GOTO 10


www.glarkware.com/media/product_main_u_basic.jpg
http://www.glarkware.com/media/product_main_u_basic.jpg

eta: they always forget the new line character.



PRINT spits out a newline automatically, like puts() but unlike printf() in C.



serves me right for learning C
Link Posted: 10/28/2006 9:19:28 AM EST

Originally Posted By macro:

Originally Posted By MissouriBob:

Originally Posted By leelaw:
I just want to know how the first GUI operating systems were made. "OK, we'll write in this code and it'll look like this, when used through this viewer... which we haven't made yet.. shit."


An OS is an OS. GUI sits on top of that.

The key for the modern GUI was the ability to write mult-threaded code (do several things concurrently and still keep it coordinated).

Prior to the mouse, all input was command line interface....

and it was good...

now any monkey can use a computer and post stupid shit on the internet..
Link Posted: 10/28/2006 11:36:18 AM EST

Originally Posted By mattja:

Originally Posted By Zaphod:

Originally Posted By macro:
but as things get more complicated it helps to split it up into clearly seperated components.


Okay, so let's take Excel as an example.

What are some of these components (or what do you THINK they are)?


File I/0.
Import/Export.
Calc and re-calc.
Graphing.
Printing.
Editing.
Linking and embedding (OLE).
Scripting.
Macro recording and playback.

Blah blah blah...

I wrote an OO sparse grid data structure object twelve years ago that is still in use today (not in Excel AFAIK, though). Just keep stacking one rock on top of another and pretty soon you have a big pile.
Link Posted: 10/28/2006 11:41:13 AM EST

Originally Posted By Zaphod:

Originally Posted By MissouriBob:
Object oriented.

Component based.

Dynanmic loading during runtime.

Establish fundamental product principles.

Maintain a tight infrastructure team.

Build around it.

Spend big bucks.



Perhaps I should have stipulated that the answers be in ENGLISH.

WTF does all that mean?


It means that you don't reinvent the wheel.

90% of most apps out there are already written in the form of libraries.

Programming has changed, for the most part, to be a function of "putting the pieces together" rather than starting from scratch.

Which is why Indians are capable of doing most of it.
Link Posted: 10/28/2006 2:07:10 PM EST

Originally Posted By ElCamino:
It means that you don't reinvent the wheel.

90% of most apps out there are already written in the form of libraries.

Programming has changed, for the most part, to be a function of "putting the pieces together" rather than starting from scratch.

Which is why Indians are capable of doing most of it.



Is that a fact?

Is this why (I think it was above) modern applications seem to be a mishmash of C and a bunch of other programming languages?
Link Posted: 10/28/2006 2:25:19 PM EST
[Last Edit: 10/28/2006 5:39:22 PM EST by MissouriBob]

Originally Posted By Fly-Navy:

Originally Posted By MissouriBob:
OOD in 100 words or less

Inheritance. You inherit the characteristics of your parent. You don't have to recreate that.
vehicle -> wheeled vehicle -> motorized vehicle

Polymorphism. Ability to have a type of code react to the same input in a number of different ways.

Encapsulation. One piece of code (object) deals completely with that object's task. Examples: an object about files would be able to read, write, delete, print, copy all within that object.

Combine these concepts.




Don't ever write a book for newbies.

He doesn't even know what OOP is, let alone those terms.



With only 100 words I had to assume people have a dictionary.
Link Posted: 10/28/2006 5:35:22 PM EST

Originally Posted By david_g17:

serves me right for learning C


Well, if you know C, is there any reason to learn anything else? I love C.

Link Posted: 10/28/2006 6:16:31 PM EST
I own a small software company. My current main application has over 11,000 lines of code. The code is consists of about 60 components (or classes). Each class has an average of 9-10 procedures.

Each class is responsible for one aspect of the application. Each procedure is responsible for one aspect of that class.

Some procedures are higher level than others. High level procedures use other procedures to complete a complex task. Lower level procedures do simple things. Examples of low level procedures: open file, close file, read file, write file, parse XML, create a toolwindow, etc. Higher level procedures would do things like: save invoice in CSV format, download an update, popup a color-selction window, etc.

You start with small building blocks (low level procedures) and build your way up. Once you have the building blocks in place, you can do complex things with small amounts of code.
Link Posted: 10/28/2006 7:38:20 PM EST

Originally Posted By Landrace:
You start with small building blocks (low level procedures) and build your way up. Once you have the building blocks in place, you can do complex things with small amounts of code.


This is very true. Unfortunately, today, people are more concerned with low bidder coding from someone in India or China or Russia than with well engineered software. Bloated code is the rule of the day because people have the perception it is cheaper to throw hardware at problems rather than pay a true software engineer.
Link Posted: 10/28/2006 7:47:12 PM EST

Originally Posted By ChiefPilot:

Originally Posted By david_g17:

Originally Posted By rasanders22:
10 PRINT "BITE ME"
20 GOTO 10


www.glarkware.com/media/product_main_u_basic.jpg
http://www.glarkware.com/media/product_main_u_basic.jpg

eta: they always forget the new line character.



PRINT spits out a newline automatically, like puts() but unlike printf() in C.



Unless you append a semi-colon to it. Then it's like printf() without '\n'.
Link Posted: 10/28/2006 7:47:49 PM EST
I have no particular input to this thread, except to comment that there was a super-cute nerdy-cool chick on the plane last night wearing a t-shirt that had a cartoon of a Zombie at a computer that said "Will fix computers ... for BRAINS!!!"
Link Posted: 10/28/2006 7:50:01 PM EST

Originally Posted By ChiefPilot:

Originally Posted By david_g17:

serves me right for learning C


Well, if you know C, is there any reason to learn anything else? I love C.



If you can make a living with C alone, then you should be cool. A lot of embedded work is in C. Although, today is makes sense to at least understand OOP.
Link Posted: 10/28/2006 8:10:38 PM EST

Bloated code is the rule of the day because people have the perception it is cheaper to throw hardware at problems rather than pay a true software engineer.

Of course that only works to a point. I'm still proud of the fact that in less than a week of work I made a daily closing procedure 40,000 times faster for a customer that had a Bangladeshi company write their production scheduling/accounting/CRM system. It was taking almost 56 hours for them to do the close so they could only do payables(print checks), deposits(group the payments) or batch(print) invoices on Monday mornings after letting the system run a close over the weekend. They already had the fastest Intel server you could buy so they couldn't throw hardware at the problem without having to rewrite the system to parallelize it. I got the process down to 5 seconds by building a 4Gbyte cache of the customer history before starting the process. The Bangladeshis had calculated the entire customer balance from scratch for every single item in the history when processing.

Back to the original question of how you build large software. You have to be smart. Those guys were dumb. I quoted $90k to build the system, IBM Global Services quoted almost $2M, PeopleSoft was (IIRC) $14M to get it configured and tested to what they needed, and the Bangladeshi company quoted $40k so my of course customer went with the cheapest quote. The system took almost seven times longer to complete than it was supposed to and cost almost six times as much in bug fixes and constant fixes to bad data as the original work cost. Managers just don't realize the major mistake it is to get a third world country to do programming. If your programmers can't read the spec, they can't produce what you want and they certainly can't ask questions.z
Link Posted: 10/28/2006 8:20:34 PM EST

today is makes sense to at least understand OOP.

I'm not convinced of that. From the programmers I've hired the past ten years (in other words, the guys that were introduced to OOP in school), they would have been much better off spending time to learn how to do the basics rather than having a professor confuse the hell out of them with OOP concepts. I think for Zaphod's original question, understanding that big programs are divided into functions with well defined arguments, the functions have a well defined purpose, and are grouped into separate files is much more helpful than posts like MissouriBob's where he spouts off concepts that I've never seen understood by a programmer under 35. I haven't had a new hire yet that could create a make file and about 90% of them didn't know how to compile a C program so saying they should understand OOP is just asking too much.z
Link Posted: 10/28/2006 8:48:26 PM EST

Originally Posted By Zaphod:

Originally Posted By ElCamino:
It means that you don't reinvent the wheel.

90% of most apps out there are already written in the form of libraries.

Programming has changed, for the most part, to be a function of "putting the pieces together" rather than starting from scratch.

Which is why Indians are capable of doing most of it.



Is that a fact?

Is this why (I think it was above) modern applications seem to be a mishmash of C and a bunch of other programming languages?


It's not only libraries that cause this, really, it's the fact that a lot of the end-user types of applications are built upon other preexisting applications and APIs.

There's tons of semi-custom software out there that relies heavily on Internet Explorer and .NET.

Programming has become a commodity, which is why it can be outsourced. "Quality" isn't important with a commodity, but price and development time is. So a lot of people farm out a lot of programming to various places which produce questionable quality code at a rate of time and money which is acceptable.

The concept has shifted. Computer programming is not the domain of the well-educated and talented anymore - largely it's simply a technical profession. Programmers produce code in the same way that factory workers produce widgets.

That said, there are still very talented people in the field, but programming has grown to the point where frankly there is more of a demand for producing mediocre-but-it-works product than spending the extra money and time to produce really high-quality stuff.
Link Posted: 10/28/2006 8:51:04 PM EST

Originally Posted By zoom:

today is makes sense to at least understand OOP.

I'm not convinced of that. From the programmers I've hired the past ten years (in other words, the guys that were introduced to OOP in school), they would have been much better off spending time to learn how to do the basics rather than having a professor confuse the hell out of them with OOP concepts. I think for Zaphod's original question, understanding that big programs are divided into functions with well defined arguments, the functions have a well defined purpose, and are grouped into separate files is much more helpful than posts like MissouriBob's where he spouts off concepts that I've never seen understood by a programmer under 35. I haven't had a new hire yet that could create a make file and about 90% of them didn't know how to compile a C program so saying they should understand OOP is just asking too much.z


No offense, but if someone was confused by OOP in school they have no business programming a computer.

It's really not that difficult of a concept once you learn it. And if you refuse to learn it, well, I guess HVAC techs are always in demand.
Link Posted: 10/28/2006 8:20:37 PM EST
I'm a software engineer and I look at something like World of Warcraft; it's truly an engineering marvel. Seriously.
Link Posted: 10/29/2006 3:24:47 PM EST

Originally Posted By zoom:

today is makes sense to at least understand OOP.

I'm not convinced of that. From the programmers I've hired the past ten years (in other words, the guys that were introduced to OOP in school), they would have been much better off spending time to learn how to do the basics rather than having a professor confuse the hell out of them with OOP concepts. I think for Zaphod's original question, understanding that big programs are divided into functions with well defined arguments, the functions have a well defined purpose, and are grouped into separate files is much more helpful than posts like MissouriBob's where he spouts off concepts that I've never seen understood by a programmer under 35. I haven't had a new hire yet that could create a make file and about 90% of them didn't know how to compile a C program so saying they should understand OOP is just asking too much.z


Hey, I can write a make file, code in C, and a bunch of other languages. I just wish I was still under 35.

Everyone should start with a really strong operating systems course or two or three. Understand the fundamentals and the rest is just icing on the cake. They can't teach experience in school. You can't offshore business knowledge or the feeling of skin in the game. The global economy is in the process of rebalancing. Eventually (2-5 years) the offshore salary structure will inflate enough they are no longer all that competitive.
Top Top