Anyways, on the to topic at hand; "C". I hate "C", I've always hated "C". I hate "C", "C+", C++" and any other derivation of "C" including my current nemesis "C#" (Pronounced C-sharp).
You see, I've been programming on and off for nearly 25 years. I started out on a Timex Sinclair, writing Sinclair basic. I've written dozens of applications that are in use in businesses including my own for years. Basic is a crappy language, I'll give you that, but I have yet to run into an argument that will convince me I need to write in a lower level language like "C". When I say lower level, I mean closer to the machine. Basic is highly interpretive, the machine has to work really hard to use it.
I've been told by dozens of people that I should teach programming, computers or computer history. If I could spend 16 weeks spinning yarns about Bill Gates, Steve Jobs and the rest of the HomeBrew era computer hoodlums, I'd love it. Teaching doesn't pay enough.
Anyways.
Computers really work on a series of one's and zero's. Everything you do eventually becomes one's and zero's. When you write in Basic, Fortran, "C", or whatever, the computer has to compile that down to something "it" understands. Some languages are easier to compile than others. Basic languages need an interpreter to run, or what is called a "runtime". Without the Basic "runtime", the program bombs. The interpreter converts the language to something the computer understands. When you compile a "C" type program, it's turned into something the computer understands already, no need for interpretation. I take issue with this today. To me, requiring the "VB.net" runtime, or requiring the ".net framework" are the same friggin thing. You need a library eternal to your program.
Programmers like to crab about Basic being procedural, lines execute one after another, unless interrupted and re-routed. Well, so are other languages. Basic didn't have the market cornered on procedural programming. In fact, most business applications were procedural, written in COBOL.
"C" languages are considered "Object Oriented", and when you use them, you are doing "Object Oriented Programming", or OOP. Object languages reflect the real world much better than Basic languages did. Lower level Basic languages like "Visual Basic .net", (pronounced "dot-net) are OOP for the most part. Here's an example of what I'm talking about.
A telephone is an "object" we can all agree on that. This object (the phone) has things called "properties", it can be black, red, white, big, small, plastic, ceramic or whatever. These are the properties of the phone. It also has "methods", things it can do. It can dial, it can answer, it can take a message. Finally, it has "events", things that happen. It rings, it lights up and so on. The core of object programming is just that; Properties, Methods and Events.
Let's consider making a P&J sandwich for instance. This was my first formal "program" I had to write in college (community college). Not one line of code. My teacher wanted us to describe how to make a P&J.
Well, most people said "get the peanut butter, get the jelly, put out some bread, yada yada..". I, on the other hand was FILLED with questions, and my teacher loved me for it. Where the the peanut butter come from?, same with the jelly. Was it in the fridge?, the closet?, a cabinet? How do you "get" it anyways?. Do you grasp it?, what if the door was closed?, what if you looked in the fridge and it wasn't there?. I was thinking OBJECT, but being asked to write PROCEDURAL.
This is the basis of traditional old-school programming. Present a problem, determine what the preferred result is, draw a path to get there, think through every possible scenario that may get in our way, follow it step by step and deal with those issues along the way.
OOP says Present a solution, build, borrow or inherit tools to handle whatever may happen on the way to the solution, and let er' rip.
The procedural way to a P&J may be "go to the closet", "open the door", "look inside", and so on...
Well, the OOP approach is different, OOP says "Get the peanut butter", which fires off an event called "get the peanut butter", which in turn fires off events called "Is it in the fridge" and "is it in the closet" and "is it in the cabinet".
Each event reports back if it found it. If "closet" and "fridge" both find it, maybe a "Crunchy versus creamy" method is called, or a "is this one more full than the other" may be called.
You see, *I* don't *care* how the peanut butter is gotten, all *I* care about is getting it. Conversely, if my wife wants a fluffernutter, does she have to go through the whole process?, of course not, she can use the same "objects" that I did. Those objects are dedicated to the ferreting out of peanut butter wherever it may be.
The traditional "first" program for 99% of the programming population is called the "Hello World" program. Here are a couple of examples:
Basic:
10 PRINT "Hello World"
20 GOTO 10
Simple. Line 10 prints "Hello World", line 20 tells the computer to go to line 10, and do whatever it says to do. This is also whats called an "endless loop". Kinda like "Pete and repeat were sitting on a fence". It never ends. Nor, do you have any control over where it prints it. What if you wanted it to go to the printer?
Now, the computer processes the lines in order, starting with 10. There is no magic to "10", it could be 1, 2, 15, 99, or 1,8907. As long as the next line number is bigger. It's a procedure - one after another until it's done.
Here's the same thing in "C":
#include iostream.h
main()
{
cout << "Hello World" << endl;
return 0;
}
Not quite as simple; It starts with an "include", which tells the computer I need to do something using input and output, so prepare anything I need to do that.
The IOSTREAM.H handles how to write stuff out (Input/Output). In the Basic example, the computer assumed the screen, unless told otherwise. In this case, we tell it the screen.
The second line "main()" is what's called the "entry point", or the start of the program. The "{" (braces) tell the computer that this is a program, self contained, a beginning and an end. Inside those braces, you may call all sorts of other "programs" if you wanted to.
the "cout << "Hello World" << endl;" says; "Console output (the screen), the words "Hello World", and add a carraige return (end line - endl).
The "return 0;" says; "we're done, and we're not giving any thing back".
Same stuff, except this one ends properly.
Now, in "C#":
using System;See????? A little more readable, a little more understandable, but still convoluted.
class HelloWorld
{
public static int Main(String[] args)
{
Console.WriteLine("Hello, World!");
return 0;
}
}
Now, Visual Basic .net:
'Hello World in Visual Basic .NET (VB.NET)
Imports System.Console
Class HelloWorld
Public Shared Sub Main()
WriteLine("Hello, world!")
End Sub
End Class
Very similar, but no stupid ";" or braces. The last two examples introduce whats called a "class". A class is nothing more than a self contained program. When you "include" something, you are really saying "I want to use the classes that belong to whatever". This way, you don't have to reinvent the wheel.
This is what frustrates me. As a Basic Programmer, 80% of what I want to do is accounted for in the runtime library, and it's assumed that I want to use them. as a "C" programmer, I need to write every stinking thing very specifically. Basic is sloppy, "C" is clean. I'm sloppy.
Take a car builder. If I was a basic car builder, I would say give me a body, make it red, give me some wheels and an engine, an interior and lets drive. Sure, I could modify those things if I wanted to, but for the most part I'm ok with what's provided for me. A tweak here, a twaek there and I'm done. Sure, there are the Farrari and Roll's guys out there, but that's a small universe.
With "C" products, I either have to find the engine, or build it myself. I need to find tires, or build a tire factory, I need to tell the system the exact treads, or find a tread that fits my needs. It's just not as simple. Yes, there is a need for mission critical applications, there are huge systems that need that level of specificness, but for day to day business, VB apps work just fine.
OK, so I didn't make any point at all other than "C" is a pain in the ass to me. That's what's nice about Blogs. I can talk to myself.....
"Do what you do me Frustrated!"...........
No comments:
Post a Comment