User Panel
User Panel
User Panel
|
Posted: 10/27/2006 9:09:02 PM EDT
[#1]
Object oriented.
Component based. Dynanmic loading during runtime. Establish fundamental product principles. Maintain a tight infrastructure team. Build around it. Spend big bucks. |
|
|
|
Posted: 10/27/2006 9:10:16 PM EDT
[#2]
I've wondered about Photoshop MANY times.
|
|
|
|
Posted: 10/27/2006 9:11:58 PM EDT
[#3]
Perhaps I should have stipulated that the answers be in ENGLISH. WTF does all that mean? 
|
|
|
|
|
Posted: 10/27/2006 9:19:55 PM EDT
[#4]
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... |
|
|
|
Posted: 10/27/2006 9:19:57 PM EDT
[#5]
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. |
|
|
|
Posted: 10/27/2006 9:20:31 PM EDT
[#6]
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."
|
|
|
|
Posted: 10/27/2006 9:25:40 PM EDT
[#7]
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). |
|
|
|
|
Posted: 10/27/2006 9:27:59 PM EDT
[#8]
Okay, so let's take Excel as an example. What are some of these components (or what do you THINK they are)? |
|
|
|
|
Posted: 10/27/2006 9:28:31 PM EDT
[#9]
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. |
|
|
|
Posted: 10/27/2006 9:30:44 PM EDT
[#10]
abstraction
generics 100 monkeys pounding on a kbd Please explain OOD and development in 100 words or less grasshopper. |
|
|
|
Posted: 10/27/2006 9:32:32 PM EDT
[#11]
File I/0. Import/Export. Calc and re-calc. Graphing. Printing. Editing. Linking and embedding (OLE). Scripting. Macro recording and playback. Blah blah blah... |
||
|
|
|
Posted: 10/27/2006 9:33:43 PM EDT
[#12]
No. 
|
|
|
|
|
Posted: 10/27/2006 9:34:24 PM EDT
[#13]
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. |
||
|
|
|
Posted: 10/27/2006 9:35:23 PM EDT
[#14]
10 PRINT "BITE ME"
20 GOTO 10 |
|
|
|
Posted: 10/27/2006 9:42:58 PM EDT
[#15]
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. |
|||
|
|
|
Posted: 10/27/2006 9:43:28 PM EDT
[#16]
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 |
|
|
|
Posted: 10/27/2006 9:45:04 PM EDT
[#17]
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. |
|
|
|
|
Posted: 10/27/2006 9:48:25 PM EDT
[#18]
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 |
|
|
|
|
Posted: 10/27/2006 9:56:35 PM EDT
[#19]
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. |
||
|
|
|
Posted: 10/27/2006 10:11:37 PM EDT
[#20]
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. |
|
|
|
Posted: 10/28/2006 5:06:03 AM EDT
[#21]
Stack overflow. |
||
|
|
|
Posted: 10/28/2006 7:46:42 AM EDT
[#22]
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. |
|
|
|
Posted: 10/28/2006 8:03:22 AM EDT
[#23]
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. |
|
|
|
|
Posted: 10/28/2006 8:06:27 AM EDT
[#24]
 http://www.glarkware.com/media/product_main_u_basic.jpg eta: they always forget the new line character. |
|
|
|
|
Posted: 10/28/2006 8:25:42 AM EDT
[#25]
This thread reminds me why I am no longer a CS major.
|
|
|
|
Posted: 10/28/2006 9:14:41 AM EDT
[#26]
Don't ever write a book for newbies. He doesn't even know what OOP is, let alone those terms. |
|
|
|
|
Posted: 10/28/2006 9:59:27 AM EDT
[#27]
PRINT spits out a newline automatically, like puts() but unlike printf() in C. |
||
|
|
|
Posted: 10/28/2006 10:00:28 AM EDT
[#28]
serves me right for learning C
|
|||
|
|
|
Posted: 10/28/2006 10:19:28 AM EDT
[#29]
and it was good... now any monkey can use a computer and post stupid shit on the internet..
|
|||
|
|
|
Posted: 10/28/2006 12:36:18 PM EDT
[#30]
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. |
|||
|
|
|
Posted: 10/28/2006 12:41:13 PM EDT
[#31]
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. |
||
|
|
|
Posted: 10/28/2006 3:07:10 PM EDT
[#32]
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? |
|
|
|
|
Posted: 10/28/2006 3:25:19 PM EDT
[#33]
With only 100 words I had to assume people have a dictionary. |
||
|
|
|
Posted: 10/28/2006 6:35:22 PM EDT
[#34]
Well, if you know C, is there any reason to learn anything else? I love C. |
|
|
|
|
Posted: 10/28/2006 7:16:31 PM EDT
[#35]
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. |
|
|
|
Posted: 10/28/2006 8:38:20 PM EDT
[#36]
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. |
|
|
|
|
Posted: 10/28/2006 8:47:12 PM EDT
[#37]
Unless you append a semi-colon to it. Then it's like printf() without '\n'. |
|||
|
|
|
Posted: 10/28/2006 8:47:49 PM EDT
[#38]
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!!!"
|
|
|
|
Posted: 10/28/2006 8:50:01 PM EDT
[#39]
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. |
||
|
|
|
Posted: 10/28/2006 9:10:38 PM EDT
[#40]
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 |
|
|
|
|
Posted: 10/28/2006 9:20:34 PM EDT
[#41]
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 |
|
|
|
|
Posted: 10/28/2006 9:48:26 PM EDT
[#42]
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. |
||
|
|
|
Posted: 10/28/2006 9:51:04 PM EDT
[#43]
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. |
||
|
|
|
Posted: 10/28/2006 9:20:37 PM EDT
[#44]
I'm a software engineer and I look at something like World of Warcraft; it's truly an engineering marvel. Seriously.
|
|
|
|
Posted: 10/29/2006 4:24:47 PM EDT
[#45]
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. |
||
|
|
Win a FREE Membership!
Sign up for the ARFCOM weekly newsletter and be entered to win a free ARFCOM membership. One new winner* is announced every week!
You will receive an email every Friday morning featuring the latest chatter from the hottest topics, breaking news surrounding legislation, as well as exclusive deals only available to ARFCOM email subscribers.
AR15.COM is the world's largest firearm community and is a gathering place for firearm enthusiasts of all types.
From hunters and military members, to competition shooters and general firearm enthusiasts, we welcome anyone who values and respects the way of the firearm.
Subscribe to our monthly Newsletter to receive firearm news, product discounts from your favorite Industry Partners, and more.
Copyright © 1996-2024 AR15.COM LLC. All Rights Reserved.
Any use of this content without express written consent is prohibited.
AR15.Com reserves the right to overwrite or replace any affiliate, commercial, or monetizable links, posted by users, with our own.
