9 replies to this topic

[TARAMAN]

Hi Guys,
Im a beginner programmer trying to get my head around why programming languages are the way they are. I was hoping someone could read my short essay below (based on research) and tell me if my summation is correct. Im taking C++ as the example, but I guess it applies to any programming language. Here goes:


I think its a miss-conception by new programmers to think that elements of a programming language are there to help them. Elements of a programming languages don't necessarily exist to make it easy for programmers to program. They exist because the machines needs to be able to tell apart and orgnaize types of data. INTs and Floating Points was invented because the computers needed to tell apart these type of data for certain reasons. We need lots of tyes of data types to build things. These datatypes reflect how the OS work at a fairly low level.

So when trying to understand something like an INT in C++, the mistake is to think "how is this language element supposed to help me". It is more useful to think "how is this language element helping the machine. What would happen without INTs? "

The answer to why INTs exist as I understand it, is that the OS needs a way of telling apart different datatypes for its own internal organisation. The exact reason is not vital to know, but to have an idea takes a lot of mystery out of why things are they way they are.

The fact that the elements that make up these programming languages so closely reflects the requirements of the machine, does not say much for the maturity of programming languages. I would imagine an advanced programming languages would hide these nuts and bolts and have an interface that relates more to the ends than the means. Object Orientated programming rich data types (for example you can have a instance of "customer") are a good example of a data types that reflects the end use of a program and hides the requirements of the machine

That's my essay! Id love to know if im on the right track here with my understanding. It really would take a lot of the mystery out of programming for me. Should I stop thinking in term of "why was this language element built for me" and instead think "why was it built for the machine and how can I use it".

I have a life long problem where I find it hard to remember things unless I understand them at a fundamental level!
Thanks for your help community. Rob

[RhetoricalRuvim]

Different variable types are processed differently. In C++ it might not make much of a difference, but if you think lower level, such as assembly language, it does make difference in how you process numbers and strings and other things. In C++, you could either define an integer or define a floating point variable, but to, for example, multiply it by two you just have to type "a *= 2;"; at a lower level, such as assembly, you use different methods of processing for different variable types. For an integer you use instructions such as MUL, IMUL, or other regular instructions, based on what you want to do; but if you're working with floating point numbers you use FPU instructions, which are especially made for floating point variables. But the basic concept of programming languages is about the same. Programming languages have function calls, branches, and other things that they share in common. Some programming languages might have been designed to make programming easier, but usually for a specific type of task (such as for the web, for regular programs, or for other types of tasks). So I think the thing about the languages being for the machine is true, although they are meant to be human-readable (and writable, too), however there are different levels of programming languages, with the top levels being for the task of the program (leaving the compiler the job to convert that into code more familiar to the machine) and the lower levels being for the machine.

[WingedPanther]

I would say you don't have a very good understanding of why languages work the way they do. First, your comments are clearly influenced by the languages you've worked with. Lisp, for example, handles data types quite differently, as does Ruby. You also haven't addressed storage of the binary representations of data or their interpretation. 110110101 has a very different meaning as a signed int, an unsigned int, or a float. By using pointers, you can actually interpret a memory address as any of those.

Additionally, it is not true that languages are not designed to make programming easier on the programmers. If you look at .NET languages, for example, there are huge libraries specifically for making a programmer's life easier.

[RhetoricalRuvim]

Yeah, I guess I forgot about those other things.

[RhetoricalRuvim]

By the way, does the programming language depend on the compiler (I know assembly language does, but I am pretty sure Ruby or Perl don't)?

[WingedPanther]

Originally, the C++ compiler was just a preprocessor that converted C++ code into C code, which was then converted into assembly, then machine language.

The language determines how the compiler works, not the other way around.

[TARAMAN]

Thanks for your reply guys!

@RhetoricalRuvim: Great info. Hmm. You know on reflection I think my question i'snt something that will bother application programmers in the future as programmer language become more abstract. MUL's and floating points will just be the domain of compiler/library programmers.

@WingedPanther: I was just taking C++ as an example to quickly communicate what I mean by language element and data. I would have taken any language and rule set really. Sure I know there are libraries etc but im not speaking at that level. Libraries are to programs what car parts are to cars. Im speaking as an engineer more than a mechanic.

Let me take a super simple example using <html>. To create a html document we encase the document in <html></html>. Most codes know "how" to code a html page... but they don't know "why"? I mean why not just have one <html> tag! Now we both know the answer to this question - so lets not waste time answering it. But we can say that the structure of <html> tags reflect workings of the program/machine.

Im certainly not saying modern programming language were not created to make things easier. That's exactly why they were created right. My point is merely that for lower level programming an understand of the requirements of the machine&compiler shed light on some of the curiosities of the language elements.

Thanks both of you! Karma bubbles

[WingedPanther]

I've actually read The Design and Evolution of C++. Having read it, there is an INCREDIBLE amount of work that went into slowly growing C++ that was specifically about balancing various conflicting desires, wishes, etc. All of these things were a balancing act between making things easier for the programmers, the compiler creators, the library builders, etc. Making things easier on the hardware was generally NOT a concern, other than making it easier to create code that runs efficiently.

[TARAMAN]

That sounds really interesting! Id take the history of science over fiction any day. Theres usually more twist and turns! Ive just finished reading Electric Universe by David Bodanis, a history of Electricity (an easy informative and hilarious read)... so maybe ill take a look at your book next if not soon.

[SweetSixteen <3]

C and C++ are often considered "hybrid" languages because they are between assembly (low-level) and high-level languages. Languages that are easier to program in have more abstraction layers. Each layer adds overhead to the program's execution so there's a direct relation between how "easy" a language is and how your programs perform.

People used to work directly with machine code. You knew the hexadecimal opcodes and their parameter lists, and you calculated addresses manually. Then when computers got a little more capable, someone came up with the ASSEMBLER, a program that allowed one to write programs in semi-human-readable text (assembly language) that would assemble directly into machine code. Then came the MACRO ASSEMBLER which is still an assembler but provided some control flow structures. Then the early high-level languages started to arise like C, BASIC, COBOL, FORTRAN, and ADA. These are easier for humans to understand and write but since the compiler has no way to know exactly what you want to accomplish, the amount of assembly code generated is much greater than if you wrote it yourself. More code of course means slower execution. There was a rule back in the day that was something like this: 80% of your code will be executed 20% of the time, while the other 20% of your code will be executed 80% of the time. The 80% that won't be seen much can afford to run slower, so write it in a language that will save you time. Then write the time-critical 20% in assembly.

Computers kept getting faster and faster. Eventually high-level languages became the norm because the performance gains of assembly were only seen in very special cases like the graphics/physics code for high-performance games and certain math and scientific applications. So then somebody noticed that processors were getting fat and lazy (LOL, I had to say that) because they spent most of their lives waiting for hard drives to deliver requested disk sectors, so he made a language that made his life easier while putting the CPU back to work.

Here's another way of putting it:
- In assembly, you must keep track of the entire memory space. You know where everything is so you find it quick, but you need good memory yourself to remember what's where and not go crazy.
- In C++, you ask the low-level library functions to reserve a chunk of memory for you and don't care where it's at. Now you can keep track of more stuff more easily, but the CPU has to do more work.
- In Visual Basic, you work with high-level objects and you don't ever hear the word "memory". The VB runtime library (likely written in C/C++) handles all of the details for you. Now you're getting more comfortable communicating with the computer, but only because you have VB's runtime and the base language's runtime helping you translate, and since both processes happen in real time it takes longer for everything to happen.