AMD, like Cyrix VIA, and Nextech (I believe was the name) were all clone makers, they made pin compatible processors for PCs. Their primary advantage was their lower cost. the AMD k5, designed to compete with the Pentium, as a Socket 5 processor just like the Pentium. The idea was that as a lower cost alternative their processors could be used in machines instead of Intel's. AMD, specifically, excelled in integer operations, doing them a lot faster than the equivalent Intel Processor. So in some cases the AMD processor was not only cheaper but also a better choice, if it was for use in applications that did a lot of integer arithmetic. Nextech was working on a new processor to compete with the Pentium and the K6; AMD bought the company and relabelled the in-development Nextech chip the K6-2; the K6 and K6-2 are completely different processors, and not in any way the same (they were basically designed by two different companies). The K6-2 supported a set of 3-D extensions (much like MMX)- whether this was Nextech or AMD that implemented it, I don't remember- at the same time it supported MMX, and it's floating point performance no longer sucked ass, and was very nearly comparable to Intel's offering.

Over time, all the other clone vendors died, or were purchases; VIA, to my recollection, bought Cyrix, made a few processors (the VIA Samuel C3 being the only one I distinctly recall) and then killed their processor division entirely, focusing on their motherboards and embedded solutions. AMD became the only competitor to intel that had any “weight”. Also, as their processors became equal to Intels both in performance and price, they started being made using different Pin designs. I believe this was originally because the socket or slot for some Pentium processor was patented so AMD couldn't make a compatible equivalent; at the very least, the Pentium itself was named the Pentium- rather than the 586- in order to prevent other vendors from using the same name.

One interesting thing about the Pentium Processor is that it is the first CISC instruction set processor to be considered SuperScalar. This is because of it's pipeline architecture which allows it to, in many cases, execute two instructions per clock cycle. The Pentium came in two revisions; the earlier versions didn't have things like MMX, and in many cases had the infamous FPU issue (Intel Errata #23). The second generation came in higher clock speeds (90Mhz, 100Mhz,and 133Mhz, as opposed to the 50 and 75Mhz of their original incarnations), as well as any number of improvements, such as a smaller die size and an on-chip APIC. It didn't have MMX, that was the third revision, which came in even higher clock speeds, FSB/Clock:66/166,66/200,66/233,66/266 (mobile only for the last one). the third revision had MMX, a smaller still die size, lower voltage requirements, a 16KB write-back cache (compared to the earlier versions 8KB). The interesting thing about some pentium boards, including those designed for slot CPUs, is that a lot of them actually had two processor slots. Usually the second one was labelled “for testing only” but you could literally plug in another processor and have dual processors. The only downside is that you pretty much required Windows NT to use them (9x doesn't support multiple cores or processors). Heck that wouldn't even work with XP Home, which only supports a single physical processor.

AMD's lower cost offerings impacted Intel's market, so they came up with their own low-cost alternatives. Which isn't too surprising given they'd been doing that for years, with the 386SX and 486SX, The 386SX being a slower variant of the 386DX, whereas the 486SX was a 486DX with it's FPU disabled. Installing the companion “co-processor”, the 487SX was actually installing a 486DX, which then took over all system operations from the SX. In addition, they created lower-cost upgrade capabilities for the 486, since the k5 was almost feature par with the pentium (and better in some ways, with 6 5-stage instruction pipelines rather than 2). To compete with this they created the Pentium “Overdrive” chip, which would be installed in a 486DX board, and take over all operations from the installed 486DX. Naturally, it was on a 486 board so some operations would still be slow, particularly bus transfers and DMA, but it sped up processor intensive tasks, and sped up a lot of tasks because of that. Later, with the K6 and K6-2 eating into their Pentium II Market share, they came up with another lower cost segment, the Pentium Celeron.

sidebar:*technically, the first Intel 6th generation processor was not the Pentium II, but rather the Pentium Pro*

Of important note is that the first Celerons were not Pentium processors, but rather Pentium II processors; it took a generation for Intel to catch on to AMD's low-cost niche tactic and come up with a response in the celeron. The Celeron was typically a slotted processor, at least all that I've seen are. The basic difference is that it has less on-die cache, and no L2 cache (some revisions had 128KB, compare to the Pentium II's standard 512KB). Ironically, the Celeron usually performed much worse than the K6 and K6-2 it was designed to compete with; Not to mention the awkwardness of the slotted processor design. Even so, and particularly through partnerships with retail computer manufacturers, Intel was able to squeeze the Celeron boards into the market. (the “Barbie” and “Hot wheels” machines from mid to late 1998 are a good example of this, since they sported celeron processors). The Celeron Brand lives on, but it is still a lower cost alternative to their other offerings, and is almost never a wise choice for a desktop machine. Many users are woo'd by the higher clock speed, but with so little cache, the clock speed barely compensates.

The 6th generation gave us the above Pentium II's, Celerons and K6-2s; the seventh gave us Pentium 2s…. Wait? P2s? What about Pentium III's and K6-2s? Well, they aren't 7th gen processors, since they are based on the same die as the sixth gen chips (for Intel, this was the Pentium Pro, for AMD, the K6-2).

The Original Pentium III was practically a Pentium 2 with SSE (MMX2) and a higher clock speed. An interesting sidebar is that the P6 chips from intel (pentium Pro, Pentium II, and Pentium III) are only fully utilized by NT versions of windows; since the Microops that the CISC instructions are reduced to are optimized for use with 32-bit code. windows 9x executes a good half of the time in 16-bit mode (for compatibility with older software, mostly) so you don't get the biggest improvement with it.

Intel failed miserably on their first attempts at a consumer-appealing x64 architecture. The Itanium was 64-bit, but it's execution of 32-bit code had to be fully emulated. It found some uses in business and servers, but it's limited ability with 32-bit code abhorred it's adoption in the consumer sector.

AMD created it's own 64-bit processors, but made it so that 64-bit was just another “mode” of the processor. In this way, 32-bit code could be run quite easy with minimal virtualization. Intel followed suite with their own extensions that implemented the same instruction set as AMD, making it compatible.

I'm not nearly as familiar with their history after around the Pentium III/Athlon XP area.

The two are practically the same now. They offer consumers a choice, but at the same time that choice is practically useless. The fact is that we've pretty much hit the architectural limit that different die configurations can give us, and we are not easily able to reduce the process further without invoking the dangers of quantum tunnelling. The best considerations for the future is to add more processor cores, and, even more important, have software that is better able to extort the best power from those cores. My opinion is that the big problem right now is not the hardware, or the software, but rather the programming languages that are dominant in the industry today, largely C/C++. What is needed is the adoption of one of the myriad languages that have built in support for concurrent execution of constructs; for example, some languages are able to compile a simple for iterative construct in a way that it can execute on separate cores. This approach is particularly powerful in a stateless environment, such as a functional language. to that end many functional languages include built-in concurrency support. What makes this particularly interesting is that most programmers think of “concurrency” and immediately think of threads; but threading is only one of the ways that concurrency can be achieved, and it is one of the least powerful, as well. Erlang, for example, takes the approach of sending messages between processes, instead of having different threads. Since Erlang is a functional' language, most of it's constructs are largely stateless; this is as opposed to most imperative languages which are typically state-heavy. It is the abundance of state in our standardized' programming languages that is causing the difficulties we are seeing with concurrency, not the cores or the implementations thereof. Consider for a moment that most of the benchmarking tools being used to compare processors are he written in C/C++. In order to trust the performance results, you have to trust that the code is making the best use of the available hardware. But the fact is that imperative stateful programming abhors concurrency; threads deadlock, and you have data synchronization issues and race conditions to deal with. So, while processor performance benchmarks might state that a Bulldozer is “worse” than another CPU, I move that that result is as much a testament to weaknesses in the program and the stateful imperative programming paradigm at least with regards to it's use with concurrent solutions. This is why I have never put faith in benchmarks; the fact is that any weakness being shown could easily be an oversight or problem with the software being used to test. If a benchmark tool only uses two threads, how can you trust it's result when it runs on 6 cores? And even if it was to use more, you're still placing your trust in how the program was written. And while one could argue that the test will show how a lot of current software and games run on a given system, it doesn't test the actual potential of that system; a properly written game could be written to take advantage of 6 cores and it would scream compared to running that program with fewer cores. At this point, concurrency is the answer to improving system speed, and in order to properly leverage concurrency, we don't just need more cores, but we need software and programming languages that provide built-in support for concurrency constructs. C/C++ simply does not offer this, and while I'm sure a library could be written that does, there are already loads of languages that provide built-in support for concurrency in any number of different ways; either through C# and .NET's addition of parallel constructs in C# 5.0, or the ability of functional languages to make assumptions because the code is primarily stateless and thus easier to make parallelize.

Personally I don't have a preference for either. I used a K6-2 for nearly 5 years, a Pentium 4 for about a year, and am now using Intel Q8200 and a laptop with a Intel T3200 (I think). Maybe my next build wilent l be AMD, I don't know. Either way, I'm not going to base any of my choices on how a given system performed with a piece of software. The heart of the matter is that I never trust software. I don't even trust software I wrote half the time. Software is a loose thread on a sock. If you pull out the thread, the sock is going to fall down regardless of how well formed the ankle is, and you cannot declare “this ankle sucks, because my sock keeps falling down” just as you cannot say “This hardware sucks, because this piece of software says so”.

And now, for something  completely different- a post that actually is about programming. A short overview of anagrams and a breakdown of a common algorithm that is used for discovering them.

Breakdown

An anagram is one word that is another word when you rearrange the letters; for example, “deposit” and “posited” are anagrams of one another; as are “dare” and “dear”. The idea behind the algorithm is that, given a list of words, to find out which words are anagrams of one another. This sounds fairly simple- one could conceivably create a function That determines if two words are anagrams of one another (by looping through the characters, comparing length, etc) and then use that function on every single possible pairing of the words in a dictionary.

This approach is simple-minded, and will take an intractably long time based on the number of words. For example, Linux systems generally have a word dictionary located at /user/share/dict/words not unlike the one you can download here ; in this case, the dictionary contains over 235,923 different words. Simply iterating through every word and comparing it to every other word will take 235,923 squared calls to the aforementioned “isAnagram” function; that’s over 55,659,661,929 separate comparisons! Even if the IsAnagram Function only took a millisecond to execute, that’s still over 55,656,661 seconds, or over two years . Clearly this is not a good solution.

One method that problems like these can be solved is to realize that the best way of going about it is to change the problem into something that will “sort itself out” so to speak. For example, rather then searching through every word and comparing it to every other word to find a match, one would be better off finding out what the words that are anagrams have in common, and how we can use that to our advantage. In the case of anagrams, what they have in common is rather simple; they have the same letters. The question is, how can we leverage this in a way that makes it easier to find groups of words that are anagrams of one another?

If we were able to create a unique value that all anagrams share that can be used to correlate them, we can create a data structure and only iterate through the list of words a single time. This value is the sorted letters of the word.

For example, both posited and deposit, when their letters are sorted create deiopst; in fact, it seems quite logical to conclude that all words that are anagrams of each other will create the same sorted sequence. This makes the entire thing almost crystal clear.

Instead of comparing every word to every other word in a brute-force approach, we can instead use a List indexed by the sorted strings, where each item contains a list of the words found that “sort” to that set of letters. For each word, we sort the letters, and then we look in the dictionary; if there is a existing item for that sorted set, we add it to the list that is already there, otherwise, we add a new one. Rather straightforward.

This is in fact a very old algorithm, conceived as early as the 60′s. The original concept was merely to bring together those words that were anagrams; the list was sorted based on the sorted letter set of each word, meaning that words whose component letters sorted the same would be contiguous in the list.

Here is the implementation of the Program in C#:

Here, I leverage Generics, and also nest Generic Classes within one another; note the Dictionary > type, which creates a Dictionary that indexes lists of Strings via a string; in this instance, it indexes the lists of anagramatic words by the sorted letters of that word (which is merely a string, since a string is by definition a list of letters). On the aforementioned dictionary file it took about half a second to process the entire file and create the output. The results can be found here . The dictionary appears to have a few esoteric terms; also, as can be seen in the source, it ignores all words less then 5 characters in length.

Companies and businesses want to prosper. At the core, being a successful business means that you make a sizable revenue; But, when those start to falter, how do businesses determine the cause? They generally measure something; for a programming firm, this may be lines of code written. For a restaurant, perhaps the time it takes for a customer to be seated, and so forth. And on the surface, it makes sense.

The problem is, it only makes sense, in theory . Why? because both methods are trying to tack a quantitative statement onto something that cannot be measured in this way; additionally, they forget the human factor.

Let’s look at a hypothetical situation; Programmer Joe. Programmer Joe has worked at a Software startup since it’s early days, and enjoys his job. However, one day, the CEO calls them all into the office to discuss declining revenue. Realistically, the revenue is declining because a competitor has just released a product that directly competes with the startup’s flagship software package. However,  management believes that the loose leash they’ve been keeping the programmers on is to blame; so one of the idea men determines that they should implement a management technique known as metrics. In this case- they start with something basic; each programmer’s performance will be judged directly correspondent to the number of lines of code they write.

Programmer Joe continues his work as normal; he notices some of his co-workers checking in code that re-rolls standard library routines, and cuts out excess code like this. One day he’s called into the Project Manager’s office.

“Joe… I don’t know quite how to explain this- maybe you can. Somehow, you’ve managed to accumulate a [i] negative [/i] lines per day metric… any idea how that is possible?”

“Well, I’ve noticed a lot of redundant code being checked in, and trimmed it down. the code still works the same way- it’s just faster; also, I’ve managed to fix half the bugs on the list just by doing that.”

The Project Manager may, in this case, take this particular information to the higher levels. they decide that the metric is flawed- what they need ot measure is lines of code written minus the number of bugs introduced.

A feature request arrives from a client near the end of the day, at 4:30PM. the Project Manager asks if Joe can look over the request and if he can maybe stay late to try to get some of those features implemented. So Joe spends the next three hours creating a prototype for the new feature and once he has the main functionality down he checks the code in and goes home. The next day, Joe continues his work on this new feature. However, he is once again called into the Project Manager’s office.

The Project manager hands Joe a large stack of papers.

“you know what those are, Joe?”

“No…”

“Those are the bug reports filed on code you’ve checked in recently.”

“All the code I’ve been working on recently has been a prototype… I haven’t yet gotten it fully integrated into the rest of the system.”

…

I think you can see where I was going there. basically, the fact is that havign a measuring metric that measures small fiobles in the entire process is doomed to cause hiccups within that process and even bring business to a standstill. In this case, rather then worry about the number of lines of code written or the number of bugs introduced, it might be better to focus on fixing the bugs and adding features; the number of lines of code in a project does not directly correspond to the quality of that project as a whole, and in some cases can even do so inversely.

In a strange coincidence, a local Coffee shop that Programmer Joe visits on his way to work had noticably changed. When Joe used to go though their drive thru to grab his morning coffee and a box of donuts for his colleagues, the staff were friendly and often asked him how things were going. Recently, however, Joe has felt like a piece of scrap metal on an assembly line. Once he got to the pay window, he would often hear audible grumbles of discontent as he simply reached into his pocket for his wallet. His donuts have often been obviously simply thrown in the box with little care, too. Joe couldn’t understand it, since these were the very same people that would serve him before. Eventually, Joe decided to go elsewhere for his morning coffee.

The previous paragraph is not an entire fabrication; in fact, I work at a location that does just this. They time every single drive thru customer’s time at the window, and it’s treated as the single most important measurement of performance in the entire store. I’d even go so far as to say it seems to be used to reflect directly customer satisfaction. However, this simply is not the case. The franchise, in particular, places a recommended limit of 42 seconds for waiting at the window. a reasonable time frame, depending on the volume of customers. However, at my location it has now been decreed that we shall not take longer then 30 seconds or, from what I hear of others, they will be verbally “abused” about it.

In any case, a little backstory is probably in order. Lately it would appear that revenue has been dwindling; there are far fewer customers then I remember coming in, at all times of the day. Additionally, various seemingly pedantic rules have been places on our release of such seemingly trite things as butters and napkins. It’s fair to assume in this case that they obviously want to bring business back up again- and that is certainly something anybody in that position would try to do.

However, with that said, they are going about it wrong. In the Retail and Customer Service industry- where almost all revenue is coming from consumers who purchase your product by coming to your establishment, the all-time, 100% most important thing for business is customer satisfaction. No exceptions. Interestingly enough, since this has started, I’ve gotten dozens of complaints from Customers who visit regularly about the shoddy way they were treated while going through the drive thru at some other time during the day. This certainly is not the fault of the workers at the time; since, as I said, they are essentially being “forced” to try to reduce times to <30 seconds. But when you get customers, the main source of revenue for the store, complaining about something that is the result of a change to the store policy that was introduced to try to increase revenue it is pretty solid evidence that the technique has failed miserably.

The problem here is not that those in charge know, as well as anybody else, that customer satisfaction is the single most important thing to the stores success, but rather in that they have tried to assign a single metric to measure this particular quality. And they do not correspond. I certainly won’t argue that customers prefer fast service— it certainly is on their list of hopes when they enter a drive-thru to be out as fast as possible— but I think what one needs to realize is that having their orders (literally) thrown into their car for the sake of speed of service doesn’t please the customer. They aren’t going to think, “well, golly, they threw the sandwich right into the passenger seat and refused to carry on a quick little bit of small-talk while I waited, but damn, it took only 30 seconds, so I am going to say I am satisfied”. I’m sorry, but this does not happen. As long as a customer is not waiting an exceedingly long time for their purchase, they tend not to notice it. Think of it this way- there is the old adage where you can either have fast service, good service, or right service, but you can only choose two. I put forth that, for many consumers it also holds true that when one of these is omitted, and the other two are done in a way that exceeds their expectations, they are likely to generally be satisfied. For example, if a customer is greeted with courteous fervor, and perhaps a friendly conversation ensues in addition to their order being made perfect, they are less likely to notice that they had to wait in the line for a few minutes. Now, if they had to wait that same amount of time and they were treated brashly, they are more likely to take offense. In fact, the single most important thing to almost all customers is not the time they wait, or even the fact that their order is made perfectly to their specifications, but rather to be treated as people, and not as some mindless consumer whose particular interests and concerns are of no importance. The sad fact is using this particular measurement metric encourages the workers to do the latter.

The thing is, there are even further flaws in the mechanism. First, the device doesn’t even work half the time, so times come out skewed and sometimes two vehicles get counted in the same interval. Additionally, since the time measured is the entire time the customer is at the window, this is not simply a measure of the efficiency of the workers to get the product to the customer but also a test of how quickly the customer can pay for their product. if a customer needs to dig for change for 10 extra seconds after the employees have successfully finished their entire order and simply await payment, why is this 10-seconds attributed to the detraction of the employees? “Because we have no way of knowing” the people who read the recorded times may say. The issue here is that obviously if there is one fact you don’t know about what the measurement indicates then there are certainly more, and in fact it could even be put forth that the measurement is completely meaningless. a Customer could be at the window for 10 seconds and still not be pleased, be it because of the shoddy service received while being squeezed through in a tiny window of time, or because they got their order mixed up with another, or some other error instigated by the fact that inhuman demands are made of people there. On the converse, a person could wait for a entire minute at the window and still be perfectly pleased with their service, so using the measure of window time as some sort of barometer by which to judge the performance of a business is downright ridiculous, and this only multiplies when one considers that such time-based constraints are not placed on those consumers who decide to enter the establishment for their service.

And while the latter example has certainly acquired far more attention for personal reasons, it certainly is no more or less ludicrous then the software companies implementation; performance metrics have been tried in nearly every industry and in every industry they have failed to provide the hoped for results. The key here is that the measure is not strictly of customer satisfaction or even of revenue; but more directly, of the value of the business.

Value is a perception and must be communicated and measured to be perceived as value. Value measurement is the process by which management decides on operational performance measures that will enable them to secure the the owners return on investment. Value measures must be aligned with the business strategy positioning the business. Measurement includes measuring lead factors and lag factors. Lead factors identify performance measures that will proactively provide an indication of whether objectives will be achieved or not. Lead factors allow management to receive warning sign proactively. Lag factors measure how successful management was in terms of creating value. Financial reports are the ultimate lag measures of success. When a business lead measures indicate that the business is performing well but the business lag factors are showing the contradictory then it is time to review the lead measures.

The value measurement process determines the behaviour of the business and aligns the behaviour of human capital with the value expectations of all stakeholders e.g. owners, management, customers, employees and partners. Value should be measured and reported on from every stakeholder’s perspective. A true balanced scorecard will drive performance improvements for all five stakeholder dimensions. This all applies to ANY business, regardless of industry.

Flipping quickly back to software, an excellent overview of the problems present with Performance metrics as used in that industry can be found here: http://discuss.joelonsoftware.com/default.asp?biz.5.304155.19

In my previous entry, I discussed and provided code that would allow for the detection of Triple-Clicks on a window. By extending the provided architecture, it is relatively trivial to allow any number of consecutive clicks; for example, detecting pentuple clicks.

The revisions are pretty easy; in my case, I created a structure to hold what I previous had in a few module-level variables, to keep track of various data about each consecutive “click set” if that is a proper word to use here. Things such as the first click position, the last click position (these will obviously be the same for the “first” consecutive click (which is just a single-click, really) but could be used in later clicks to compare the distance values used, retrieved via GetSystemMetrics() using the SM_DRAGX and SM_DRAGY constants,(or was it SM_XDRAG and SM_YDRAG…) and comparing these values with the difference between each successive click. The ideal solution would be to compare each click position with the first click position, so that the clicking cannot move across the object very far from where the first click took place. The logic is pretty simple, and should be easy to follow. The project can be downloaded from here .This is a tad different then the previous one, and is instead implemented as a sort of  “game”.

There are a few design and User interface considerations when using Multiple clicks in your UI; the most prevalent is probably that unless you tell your users that they can triple-click or quadruple click, they likely will not try it- that is, it isn’t really that intuitive. Additionally, when you do implement this behaviour, remember that, for example, with a triple click, a double click was already fired and handled before that; so don’t make successive clicks do vastly different things. the ideal scenario is to use successive clicks to do the same thing, but change the scope; for example, Word allowed you to click,double-click, and triple click text. the first click sets the position of the cursor, the second click selects the word that the cursor is in, and a triple click selects a paragraph. (In the outlook editor it actually selects the sentence I think, but let’s not split hairs…). In fact, it would make sense to conclude that as an unsaid rule you should only use triple clicks to build on behaviour that the single and double-clicks before them have already done, just as word does. if you make triple-clicks do something esoteric, such as, for example, triple clicking a drawing to save, consider instead opting for a toolbar button or menu item to perform this task, or perhaps a key combination (or both).

When entering the domain of programming, one finds a plethora of programming languages to choose from; and there are more being introduced nearly every day. Each language was designed for a purpose. From Assembly language, designed simply as a way to write machine code easier, to C, designed to be as “close to the machine” as possible without actually becoming a low-level language, and Perl, designed for text processing.

The interesting thing? They don’t have to be used as designed. Perl, while created by Larry Wall to make text processing of reports easier, has been applied in all sorts of problem domains effectively. Visual Basic can be used to write STDCall DLLs. Scripting languages, once relegated to creating silly animations to annoy users visiting web pages, has found use both on the desktop as well as server side web processing.

As the Information Technology industry has aged so too have the techniques used for programming. new techniques are tried all the time. Previously, the widely held winning formula was called “Structured programming” because, rather then using Goto’s or conditional jumps, the language itself contained constructed for “structuring” code, a method that allows the code to be more readable and organized. It also embraced a top-down approach, whereby the “function” is created before the routine that requires it. Original “pioneers” for this strategem are numerous, but the recognized “original breeds” are  Pascal and C. Pascal was created as a teaching tool. by enforcing a number of things widely held asgood programming practice as part of the language, it “conditioned” new programmers to keep these habits when they moved to other languages. As Pascal evolved, however, it was made more useful, and more applicable to the creation of real applications. C, on the other hand, was designed to allow programmers easy access to a wide variety of functions, both of the language as well as the “bare metal”. This “bare metal” approach was facilitated with “naked” functions as well as inline assembly.

The “Structured Programming” concept dominated the academic circles, and was implemented as a standard by programming firms the world over. However- there was a pattern to how it was used, and this pattern, once recognized, was used to develop the “next leap”.

Program source code that was “structured” had it’s many components separated into various modules, and procedures. Each module would often hold the structure definitions and the procedures to handle them. For example, a program designed to graph functions might have a module, perhaps, modFunctions, depending on the naming convention. This module would define the “structure”- or in memory representation – of the various properties of a function- the expression, range, etc. The routines in the module would be used to manipulate draw, set, and retrieve the various items stored in the structure.

Eventually, this was migrated into the structure itself- that is, a structure might be defined to hold both the data relevant to the function as well as pointers to routines that manipulated it. The common convention was that the first parameter to these routines would be a pointer to the structure being acted on.

This type of programming was first implemented in C, and it worked great. essentially, it combined the concepts of Functions, and the data they manipulated, and created a single entity- the resulting structure. Oftentime the only routine required was a function that returned a pointer to the structure, after initializing the various function pointers. this because known as a constructor.

The problem with this technique was simply that there was a lot of work involved with using this technique- initializing pointers and other “bookkeeping” type tasks. the concept, however, was solid. Languages sprung up that implemented this technique internally, and exposed only those parts of the “object” as it became known, that needed to be coded or used. The concept spread like wildfire. Languages that once conformed to the “structured” paradigm were adapted and given object-based features. Pascal variants known as “Object Pascal” which more fully implemented the loosely object-like syntax of Pascal itself, were created. C was extended into C++, implementing nearly all of the Object Oriented concepts, such as inheritance and interfaces, and so forth. BASIC, in the form of Visual Basic, got Object Based, and later, with VB4, loosely object oriented. Entire languages sprung up on the concept that a “purely” object-oriented language would be the best choice. An early language of this form- or more precisely, the first more popular language of this form, was Java.

With Java, everything was an object. a simple console application was comprised of at least one object. at this point, the code that created the objects, – the very “template” from which they were instantiated, were known as “classes”. it was not until a “class” was instantiated that it became an object.

While Java, with it’s pure Object Oriented approach, created clean code as opposed to a structured language, or half-object based language, it also had shortfalls. While Object Oriented Programming was a excellent concept- it couldn’t always be used to apply to everything, and oftentimes a short quick little program was all that was needed. Java was however well suited to internet applications, since it was also a byte-code based interpreted language.

Now that the Object Oriented approach has matured and entire frameworks have been created based on the concept, such as .NET, one cannot help but wonder wether the idea is to make it easier for the programmer or the user. Just because a language makes it easier to program, or a certain conceptual method of creating said program makes it trivial to do something, doesn’t mean that the user’s experience with the application is any better. What if a user requests a feature not implemented by the run-time? Sure, there are “native” method calls in almost all such language, but is this not, in some sense, an admittance of defeat? that the Object Oriented approach is not flawless? Or, perhaps it is less controversial- maybe it is simply a lesser admittance of failure on the part of the Object Oriented design set forth by the creator of the framework.  But the fact remains- the framework does not make implementing the feature easier. Is this not what the framework is for, however?

So the ultimate question is- are we any better, now, with class framework and libraries all around us, then we were when we had basic Input/output and generic function libraries, and were left to fend for ourselves with all sorts of mundane programming tasks that we now take for granted?