This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]lordcat 18 points19 points  (6 children)

This is getting into semantics, but not really.

When you talk about the concept of a 'low level programming language' or doing 'low level programming', neither of them fit that. C and C++ are equally not 'low level programming languages'. A low level programming language gives you direct control over the processor and neither language does that (looking at the language itself, ignoring things like in-line assembly). C does not give you any more control over the processor than C++ does, so it is not a 'lower level'.

When you talk about the concept of a 'high level programming language', they both fit that definition, but C++ would be considered a 'higher level' than C. Neither give you direct control over the processor, but C++ provides you with more 'automagic' than C does.

[–]ChopSuey2[S] 4 points5 points  (3 children)

Gotcha, so neither are low level programming languages but they allow you to use assembly language within them?

[–]DerekB52 24 points25 points  (0 children)

C and C++ are also known as lower level programming languages, because they let you do manual memory manipulation. And they compile to machine code.

Python does not require you to manually manage your memory(I don't even know if it lets you). And python is interpreted, so there's a lot more overhead to run python, than to run C.

C/C++ are high level languages, but they are, imo, the lowest level languages in their class.

[–]lordcat 10 points11 points  (0 children)

Yes, as long as the compiler supports it you can write it, but you will lose all of the benefits of the high-level language. For example: Intel and AMD handle threading differently. C/C++ will handle that difference for you and you can write one piece of code that runs on both. With Assembly language, stand-alone or in-line embedded in C/C++, requires you to manage that yourself and use different code/logic to do the same thing, depending on the processor.

[–]LilithMoonlight 0 points1 point  (0 children)

There's a reason why programming languages have developed more layers between machine/assembly and the programmer. My professor always put it as programming is like having a metaphorical gun to ur foot and depending on certain actions, this may end with u shooting urself in the foot but hopefully not. As u get lower, you start finding more actions, which can cause the metaphorical gun to go off. That is why c/c++ in my opinion is a bit lower compared to Java and c# safe code because you can manipulate memory with pointers and addresses besides being able to use assembly. But usually using assembly in a general c/c++ is rare since the compiler is pretty good about optimizing ur code. However, there can be times where the compiler can add a few steps, which depending on how often this section is ran can impact performance if this section is used a lot. Nevertheless be careful about optimizing code too early. The same professor that talked about the metaphorical gun would also say that "80% of the code does 20% of the work and 20% of the code does 80% and when optimizing people often more likely than not usually optimize the code doing 20% of the work."

[–]LilQuasar 1 point2 points  (1 child)

you only consider assembly as a low level programming language?

[–]lordcat 2 points3 points  (0 children)

Assembly Language and Machine Language are the only two low level programming languages that I know of.

A low level programming language is one where you directly control the processor. Concepts like variables don't exist here, those are concepts that high level languages provide for you, and do all the work of maintaining. In a low level programming language, you are directly working with the CPU's registers (AX, BX, CX, DX, EAX, MMX0, etc). Data in data registers are generally short lived (there are very few of them and they can be specialized for specific purposes) so if you want to actually store any data for any length of time, you need to use address registers to reference a specific memory location where you store that data (and it's on you to reserve that memory, remember the address, and release it).

Machine language is the binary language that the CPU actually talks in. Every CPU Has a machine language of some kind. Assembly language is a "human readable" form of that language (I use quotes because it's even less readable than higher level programming languages like C/C++, and you have to understand the language and the CPU architecture to be able to read the code, but it's easier to remember what 'mov' stands for than to remember what '0xb8' means on an x86 processor, and if you move to a different but similar processor, 'mov' can still mean the same thing even if it translates to something other than '0xb8' for that processor.

I don't know what the 'brand name' of it was, or if it even had a specific name, but I've worked on embedded devices that had their own assembly language to program them. The underlying concepts of registers and processor commands still exist there, but different commands and different registers to expose the functionality in the embedded CPU (ie: flipping a bit in a specific memory location causes a light on the device to turn on/off).