Talk:Low-level programming language

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Software (assessed as Low-importance).

Examples

This page could use some examples. Thehotelambush 16:09, 30 July 2007 (UTC)[reply]

Example - a function that calculates the nth Fibonacci number.

First, in C [3rd generation]:

unsigned int fib(unsigned int n)
{
    if (n <= 0)
        return 0;
    else if (n <= 2)
        return 1;
    else {
        int a,b,c;
        a = 1;
        b = 1;
        while (1) {
            c = a + b;
            if (n <= 3) return c;
            a = b;
            b = c;
            n--;
        }
    }
}

The same function, but converted to x86 assembly language, specifically MASM, using the __cdecl calling convention [2nd generation]:

fib:
    mov edx, [esp+8]
    cmp edx, 0
    ja @f
    mov eax, 0
    ret
    
    @@:
    cmp edx, 2
    ja @f
    mov eax, 1
    ret
    
    @@:
    push ebx
    mov ebx, 1
    mov ecx, 1
    
    @@:
        lea eax, [ebx+ecx]
        cmp edx, 3
        jbe @f
        mov ebx, ecx
        mov ecx, eax
        dec edx
    jmp @b
    
    @@:
    pop ebx
    ret

Note:

@f refers to the closest following @@: label.

@b refers to the closest preceding @@: label.

I deliberately did not use proc.

And here is the final x86 machine code [1st generation]:

8B542408 83FA0077 06B80000 0000C383
FA027706 B8010000 00C353BB 01000000
B9010000 008D0419 83FA0376 078BD98B
C84AEBF1 5BC3

For comparison purposes, here is a disassembly listing:

00401000                    fib:
00401000 8B542408               mov     edx,[esp+8]
00401004 83FA00                 cmp     edx,0
00401007 7706                   ja      loc_0040100F
00401009 B800000000             mov     eax,0
0040100E C3                     ret
0040100F                    loc_0040100F:
0040100F 83FA02                 cmp     edx,2
00401012 7706                   ja      loc_0040101A
00401014 B801000000             mov     eax,1
00401019 C3                     ret
0040101A                    loc_0040101A:
0040101A 53                     push    ebx
0040101B BB01000000             mov     ebx,1
00401020 B901000000             mov     ecx,1
00401025                    loc_00401025:
00401025 8D0419                 lea     eax,[ecx+ebx]
00401028 83FA03                 cmp     edx,3
0040102B 7607                   jbe     loc_00401034
0040102D 8BD9                   mov     ebx,ecx
0040102F 8BC8                   mov     ecx,eax
00401031 4A                     dec     edx
00401032 EBF1                   jmp     loc_00401025
00401034                    loc_00401034:
00401034 5B                     pop     ebx
00401035 C3                     ret

Alksentrs (talk) 23:57, 16 February 2008 (UTC)[reply]

By the way, the Fibonacci sequence breaks at precisely F₄₇.

unsigned int fib(unsigned int n): -1323752223

unsigned long long int fib(unsigned int n): 18446744072385799393

actual F₄₇: 2971215073

Just thought I'd let you know. 174.28.41.236 (talk) 18:24, 2 January 2014 (UTC)[reply]

Absolute terms

I've always known low-level and high-level programming languages to be absolute terms. The former refers to programming languages that provide no abstraction from the instructions that the processor implements, this is binary code (maybe written in hexadecimal), and assembler language, which is a mnemonic for the binary code and is assembled. The latter refers to programming languages that can be used independently of the processor because there is a software layer that abstracts that detail (something an assembler does not do), as a compiler or an interpreter.

The crisp and absolute difference between low-level programming languages and high-level programming languages, for what I knew, is that the code is done for a specific hardware (or group of them) as may be the x86 group of processors, or it is done for a software (or group of them) as is the group of C compilers.

Unfortunately I haven't been able to find references as this is more a terminological matter than a informatics matter, that's why I've required the citation (as there may be one). All that I got by now is this a definition in the webopedia[1].

Kind regards. —Preceding unsigned comment added by Trylks (talk • contribs) 23:26, 19 February 2008 (UTC)[reply]

Removed two-year old citation tag

There are no controversial statements of fact in this article, so no citations are needed. Nor is the Utah State Office of Education reference needed. "a low level language is one that does not need a compiler or interpreter to run" is a simple statement of fact. "Mars is a planet" does not need an "according to..." reference. The article may be a stub, but what's there is an example of content which does not need references, besides the one instance with the citation tag. And sometimes, especially in the long-winded Wikipedia, a term can be explained perfectly well with a stub. J M Rice (talk) 13:37, 11 October 2008 (UTC)[reply]

Old citation

It's rediculous to require a citation for the statement that programmers rarely code in machine code. That's like requiring a citation to state that Elvis is dead.

"Rediculous" or not, it's Wikipedia policy.Diego (talk) 10:26, 27 October 2008 (UTC)[reply]

Elvis died?Stevebroshar (talk) 09:55, 10 August 2025 (UTC)[reply]

Low-level programming in high-level languages - needs edit, possible removal

I have moved the C example code out of this section and provided a point by point comparison between it and the assembly language example, to emphasise the difference between high level abstraction and low level architecture specifics. The C example served absolutely no purpose in this section - it is absolutely not an example of low-level programming in a high level language.

I do not think this section is very useful as currently written. It makes no mention of the most pertinent mechanism (inline assembler) and I think causes confustion by mostly refering to systems programming. Systems programming is not by definition low-level programming. UNIX (and UNIX-like) operating systems are written in C but almost all of that code is completely portable. Porting such an operating system to a specific architecture mostly means simply specifying values for operating system constants and in some places choosing implementations which will operate most efficiently on a particular architecture (over implementations which would function poorly but would work). Even those parts which are achitecture-specific are mostly high-level C code written with an awareness of the architecture rather than code which directly manipulates that architecture in a low-level way. Actual low-level programming is a very small part of operating system design. As it stands, this section is as vague in its worning and uncertain in its purpose.

I think this also applies to the "relative meaning" section, which seems equally ill informed. The beginning of the article gives a clear definition of "low level". This is computer-science jargon, where words and phrases which might be ambiguous in general language have specific meanings. Whoever wrote that doesn't realise that C is still considered a high level language. The emergence of more abstract languages hasn't changed that basic fact.

I am going to make the following changes to this section:

Add mention of inline assembler and other techniques for low-level hardware control by high level programmes.
Remove mention of Forth (off topic).
Remove the paragraph which is entirely devoted to systems programming in C, does not contribute to the definition of Low-level programming languages and is off topic.
Remove the small bullet list of other types of programmig languages. It is not relevant to this section, very limited and entirely redundant given the automatically-generated category-relevant lists at the bottom of the page.

Itsbruce (talk) 17:39, 25 August 2014 (UTC)[reply]

I am not sure by now, how well low and high are defined. Seems to me that there needs to be a name for something above assembler, but that still allows for low-level coding at the register level, and other machine specific abilities. PL/360, for example, allows operations on specific machine registers. As well as I know, BLISS and PL/S also allow specification at the hardware level. PL/M does similarly for the 8080 and 8086. I believe some C compilers allow writing interrupt routines, with, for example, proper interrupt enable and disable. While C is still a high-level language, one can cast an integer constant to a pointer, and read or write from specific hardware addresses. On machines with memory-mapped I/O, one can do I/O operations directly. Those are things one normally is not able to do in a high-level language, yet C allows for them. Gah4 (talk) 13:04, 11 July 2019 (UTC)[reply]

ESPOL is another high-level language that supports hardware-specific operations - including, with POLISH, what amounts to inline assembler. Guy Harris (talk) 22:28, 11 October 2023 (UTC)[reply]

more examples

Seems to me that languages like PL/360 and PL/M should be described here. They are designed to look like higher-level languages, but operate more like an assembler. In PL/360, variables with names like R1 and R2 represent actual processor registers. Even more, the translation is more direct than for high level languages. In PL/360, for example, R1:=R1+R1+R1; will result in R1 holding four times its previous value, LR R1,R1; AR R1,R1; AR R1,R1, as the modified value is used for the last AR. Gah4 (talk) 18:57, 29 June 2018 (UTC)[reply]

C as a low-level language

There is no mentioning of C being used as a low-level language. C could be used as a high-level language, but the modern day go-to low-level programming language is pretty much C.

People publishing books about "low-level programming" with C in the title.
Columbia University offering course in Low-level programming with C

Based on my observation, the only people who potentially disagree about C being low level are hardware developers. However if this article only takes their point of view, then it is basically NPOV. --Voidvector (talk) 07:54, 27 December 2019 (UTC)[reply]

No idea about the WP:NPOV, but I do agree that C is commonly used as a low-level language. One common example is assigning addresses (often of memory-mapped I/O devices) to pointers, and then dereferencing them. While the standard is meant to be used as a high-level language, that doesn't mean that people do it. Gah4 (talk) 00:32, 31 December 2019 (UTC)[reply]

C is often used to control low-level machine details, however that statement does not imply that C is a low-level programming language. For instance, many languages uncontroversially considered high-level (e.g. Haskell, Java) can also perform low-level operations if suitable abstractions are provided. As evidence, House is an operating system written in Haksell. I argue the correct way to think about C is as a high-level language with implementations that often provide out-of-the-box support for low-level operations. I suggest that this article can be improved by mentioning very high-level languages so as to distinguish C from languages like Java and Haskell. — Preceding unsigned comment added by 65.60.139.183 (talk) 14:00, 27 March 2020 (UTC)[reply]

C is not just a low-level language, it is a primitive language with lowest-common-denominator facilities like pointers dressed up with defines. This is actually non-semantic, giving it the feeling of non-semantic low-level coding.

However, the lack of semantics is also lack of hardware semantics as well. This leads to comments like: Alan Perlis (first recipient of the ACM Turing Award for computing): “A programming language is low level when its programs require attention to the irrelevant. While, yes, this definition applies to C, it does not capture what people desire in a low-level language.”

This is what the hardware people are getting at.

Because of the primitive features of C is can't be considered a high-level language. It is a coding language dressed in structured syntax. It is the compromises (some of which are needed for system programming, but many that are just bad compromises) that makes C not a high-level language. Ian.joyner (talk) 02:14, 20 September 2024 (UTC)[reply]

This leads to comments like: Alan Perlis (first recipient of the ACM Turing Award for computing): “A programming language is low level when its programs require attention to the irrelevant. While, yes, this definition applies to C, it does not capture what people desire in a low-level language.” The text in quotes is not a quote from Alan Perlis. It is a combination of a quote from Alan Perlis, "A programming language is low level when its programs require attention to the irrelevant.", followed by a reply from David Chisnall, "While, yes, this definition applies to C, it does not capture what people desire in a low-level language." Perlis' quote comes from his Epigrams in Programming, and Chisnall's response from his ACM Queue article, |"C Is Not a Low-level Language". Some of what Chisnall is saying there may apply to other programming languages with a sequential view of the world.

Perhaps you should have also pointed to what I suspect may be your own criticisms of C++, including criticisms of C that also apply to C++ (which also include complaints about C in areas other than what you describe above, such as syntactic complaints about #defines and the assignment operator). Guy Harris (talk) 08:53, 20 September 2024 (UTC)[reply]

I think there's an important difference between claim #1: C supports low-level programming and 2) C is a low-level language. But my point of view does depend on what one means when they say a language: is-a something. To me and to I'm sure some, it means the language is categorized such that it is one thing and not another. But, I think to some it's more of a tag; meaning that the language has the capability to do something. Thing is, since people don't usually discuss this subtly I think it best to avoid the is-a claim. We all agree that C supports low-level programming. We don't all agree that C is a low-level language ... at least in part bc we don't agree what that statement means. ... I'll go down the rabbit hole of is-a claims to make my point. C++ is a low-level language bc you can do all the stuff with C++ that you can do with C. I used Ada on a real-time embedded system. That makes Ada a low-level language. I can construct very high-level (highly abstracted) logic in C. That makes C high-level. I can do the same with assembly. So, it's also high-level. At the end of the day, both high and low level are useless terms. Always have been. How about we just say: there's assembly which is a PITA to work with and there are higher level languages that make programming way easier than via assembly. Stevebroshar (talk) 10:14, 10 August 2025 (UTC)[reply]

Yes, the concept is poorly defined.

We'll ignore raw machine code as a language; it seems useful only if either 1) you're trying to write an assembler for a machine that doesn't have an assembler or even a cross-assembler on another platform, 2) you're looking for a challenge or just enjoy something that's more difficult than it needs to be, or 3) you're doing something sufficiently weird that assembler won't do it.

Assembler language is definitely "low-level" in that it lacks a bunch of capabilities that programmers - even system programmers - have generally gotten used to (perhaps unless you're writing in HLASM and its accompanying control-flow macros, in which case you get some of those capabilities) and tied to a specific instruction set (unless you're writing in MACRO-32 for Alpha, Itanium, or x86-64).

There are some languages described as "high-level assembler" languages. I am not sure, from that page, what renders them assembler languages. The article claims that "High-level assemblers typically provide instructions that directly assemble one-to-one into low-level machine code as in any assembler", but some of the languages mentioned there also let you write expressions rather than "load/add/add/divide/store" or "push/push/add/push/add/push/divide/pop" sequences. They may not provide data structures, but in the 1960s FORTRAN and ALGOL 60 didn't provide them, either, but they didn't provide arrays, just as FORTRAN and ALGOL 60 did. What some of them provided were features such as direct references to specific registers as variables (PL360), or what amounts to inline "real" assembler (ESPOL and, I think, NEWP). I'd say that allowing arbitrary expressions that don't map directly to individual instructions rules out calling the language an "assembler language". Perhaps "machine-specific language" or something such as that, if it has features that are tied to a particular instruction set.

C - and C++ - have no standard way to drop to assembly code. About the most that it does is let you cast an integer value to a pointer for code that manipulates specific memory addresses or I/O addresses, but, as C18 says about that, "An integer may be converted to any pointer type. Except as previously specified [meaning a constant value of 0 -> null pointer], the result is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation.", so you'd better know what you're doing. The extended C - and, I think, C++ - provided by gcc and clang, with inline assembler via asm - lets you drop to raw assembler code, but, unlike the inline assembler in ESPOL (POLISH, as in "Polish notation", as the two lines of Burroughs Large Systems that ESPOL targeted both having stack machine instruction sets), it supports multiple targets, so you can use #if to choose different assembler code on different platforms. I would NOT call C or C++ machine-specific languages; you can write machine-specific code, but you're usually not obliged to, even in OS kernel code. (It might be nicer if you had to explicity declare, in the language, that you're doing so in order to be allowed to do so.)

So, yeah, low-level and high-level programing, OK, but low-level and high-level language, there's a big gray zone. You can write a parser in (pick your imperative programming language) or you can write in (pick your parser-generation language); in that context, the parser-generation language (YACC, Lemon, etc.) is higher-level than the imperative language (C, C++, Pascal, Ada, Rust, etc.) Guy Harris (talk) 01:10, 13 August 2025 (UTC)[reply]

Very popular, little development

This article gets a lot of traffic and is especially underdeveloped. I am just remarking on this; I have no ideas for organizing editing of this topic. Bluerasberry (talk) 23:15, 12 June 2022 (UTC)[reply]

Many people like/want to talk about the concepts of high and low level languages -- which I think explains why there's alot of traffic here. But the concepts have little value so there's no good way to develop these articles. It's idle chatter. Stevebroshar (talk) 10:19, 10 August 2025 (UTC)[reply]

Only one source present in majority of the article

The entire of the introduction section and portions of the Machine Code section is almost entirely copied from this source, with little changes made. Bxshan 09:04, 3 April 2023 (UTC)[reply]

Wiki Education assignment: Introduction to Digital Humanities Spring 2024

This article was the subject of a Wiki Education Foundation-supported course assignment, between 15 January 2024 and 10 May 2024. Further details are available on the course page. Student editor(s): Phoenixpinpoint (article contribs).

— Assignment last updated by Phoenixpinpoint (talk) 21:20, 21 April 2024 (UTC)[reply]

Very poor wiki page

It is hard to know where to begin on this page. It was posted to disagree with my assertion that languages using structured syntax (high-level syntax) do not define high-level programming languages.

This article is based on the wrong assumption and thinking that only machine language or assembler is low level.

Reference 1 goes to some African University page with an article only covering machine code and assembler (although there is a little confusion in it, it is never clarified).

The Fibonacci examples are irrelevant. They don't help with the definition.

The C example is only about syntactic appearance. C is absolutely not just a low-level language but primitive language with pointers (exposing memory which high-level languages should not, by definition) and macros (actually from Burroughs ALGOL).

If the function of a language is to handle platform and machine details, it is a low-level language. High-level languages do not touch those details - they concentrate on the abstract conceptual level, not on the physical implementation level.

There is a clear distinction between low-level and high-level programming. This article fails to get it.

The comments on the Burroughs languages of ALGOL and ESPOL (replaced long ago by NEWP) are inaccurate. These languages go back to 1961, not late 1960s. C did not come out until 1974. ALGOL and ESPOL (NEWP) run on machines that have no assembler. They do everything an assembler might cover. Since they do that they are low-level system languages.

They also do not rely on any inline assembler code (there is no assembler). Ian.joyner (talk) 08:16, 10 July 2024 (UTC)[reply]

There definitely needs to be something between assembler and C. And inline assembler isn't really a low level language, but a mix of two languages. I never programmed BLISS, but looking at the page, that could be one. Personally, I always liked PL/360, which is pretty much a S/360 assembler with PL/I syntax. One way to see the difference is with R1 := R1 + R1 + R1; which multiplies R1 by four. No real HLL would do that! It compiles as LR R1,R1; AR R1,R1; AR R1,R1. Well, for one R0 through R15 are names the registers, not general variables. Gah4 (talk) 17:44, 10 July 2024 (UTC)[reply]

If the function of a language is to handle platform and machine details, it is a low-level language. High-level languages do not touch those details - they concentrate on the abstract conceptual level, not on the physical implementation level. C's function is not to handle platform and machine details. It allows doing it, as does C++, but, at this point, the vast majority of C code is probably machine-independent, and much of that is platform-independent as well - even the majority of kernel-mode code written in C is probably machine-independent. Guy Harris (talk) 22:00, 3 August 2024 (UTC)[reply]

A lot of C code isn't as portable as it should be. Often it assumes specific sizes for types, or specific endianness. Some won't realize that until they try porting it. Gah4 (talk) 19:41, 20 September 2024 (UTC)[reply]

If that code is reading from or writing to files, or sending or receiving network packets, or dissecting raw file or network packet contents, it can be easy to write code that "works on [your] PC", i.e. that assumes little-endianness. It might be harder to do so in languages that don't let you just cast a pointer to a blob of memory to a pointer to an integral or structure data type and access the value through that pointer, as those languages may force you to, for example, extract a 4-octet integral value an octet at a time and combine them into an integral value, which means you have to do that differently for big-endian and little-endian values in the file or over the network, and the result will be correct on machines of any byte order. (Fun fact: newer versions of both GCC and Clang/LLVM detect that idiom and generate loads, or loads and byte-swap instructions, if that works on the target processor.)

I suspect that's the main source of endianness issues, at least, so C and languages derived from it (e.g., C++) may be at fault for making it too easy to cheat. (Note that this issue involves I/O, which I suspect is a rock on which many computing abstractions have crashed.)

I'm not sure what the causes of assuming specific sizes for types are, but having data types that are just "this holds an integer", without specifying the range of the integers it can hold, may not help. That one may not be unique to the C family of languages; it can be a property of languages that purportedly "concentrate on the abstract conceptual level" but have bits of the "physical implementation level", such as the word size of the processor, poke through. (For example, Pascal allows the programmer to express a range, but doesn't require it; the default range is implementation-defined.) Bignums FTW! Guy Harris (talk) 20:39, 20 September 2024 (UTC)[reply]

Network byte order being big-endian makes it a little harder to accidentally get it right, with little-endian processors. But yes in the case of many file formats. This goes back at least to Fortran 66, though. Fortran 66 A format I/O stores characters left (low address) justified. While the standard doesn't allow for comparison, or even assignment, of such data, program often did, and do, it. Java has fixed sizes for data types, and you aren't supposed to be able to tell which byte order the underlying processor uses. You can still put bytes together, though, and write them out in the wrong order. Gah4 (talk) 00:35, 24 September 2024 (UTC)[reply]

Putting bytes together (shifting and ORing) is for reading a value that's in a specified byte order and putting it into a native byte order value; pulling them apart (shifting and masking) is for writing it out in a specified byte order. By "rite them out in the wrong order" do you mean you assemble the bytes when reading and then just dump them out in whatever byte order that happens to be in, rather than disassembling them and writing them in the intended order?

Also, for Java, I've seen some stuff on the web that indicates that the multi-byte-numeric-value methods of `DataInputStream` read big-endian values, and the multi-byte-numeric-value methods of `DataOutputStream` appear to be documented to write big-endian values, which might further suggest that the readers read big-endian values. I don't know if you can use that for networking I/O (or, at least, TCP socket I/O), or whether there's anything for use with packet-oriented rather than stream-oriented protocols. I also don't know if they have anything to handle little-endian data. Guy Harris (talk) 05:50, 24 September 2024 (UTC)[reply]

I can concert to machine code without a compiler?

WRT "Low-level languages are directly converted to machine code with or without a compiler or interpreter—second-generation programming languages depending on programming language."

What? I can convert it to machine code without a compiler? And interpreter never converts to machine code. And what does 'directly' imply? What is the phrase after the dash? This seems like over-edited text that now is just nonsense. Stevebroshar (talk) 11:16, 10 August 2025 (UTC)[reply]

I presume you removed that nonsense ("with or without" renders that close to content-free). If so, thank you for purging it. If not, thank whoever else removed it for purging it. Guy Harris (talk) 00:05, 13 August 2025 (UTC)[reply]

Very quickly

WRT "A program written in a low-level language can be made to run very quickly, with a small memory footprint"

First, don't use 'very' in a WP article. Ever. It's a useless word here. Just report the facts. No judgements.

Second: this is a commonly held idea among uninformed developers. Yes, you can optimize assembly code in ways that are not possible in a higher level language. But, in practice performance (running quickly at the UX level) rarely depends on this kind of low-level optimization. As written, it sounds like you have to use a low-level language to have highly-performant, low-footprint code ... which is not true. Stevebroshar (talk) 11:23, 10 August 2025 (UTC)[reply]

What does it mean to say that C is not architecture-independent?

@Stevebroshar: Is that referring to cases in which behavior is specified by the C standard as "undefined" (e.g., the behavior on integer overflow) or "implementation-defined" (e.g., what happens to the high-order bit when a signed integer is shifted right)?

Ada, for example, handles the latter case by only providing, in the Interface package, shift operations for unsigned integer types. (It also provides sized signed and unsigned integer types for various sizes - "if supported by the target architecture", so that package is not architecture-independent.)

I'm not sure how the former case is handled in Ada - integer and floating-point types have a Machine_Overflows attribute that indicates whether the machine catches overflows (or divide-by-zero) and raises an exception, but, from a look at ISO/IEC 8652:2023, it's not clear whether the specification requires that Machine_Overflows be true for any types, or merely requires that the implementation provide that attribute so the code can query whether it's true or false for any particular type. Guy Harris (talk) 21:04, 12 August 2025 (UTC)[reply]

Proposal to remove C from this page.

Just to keep it short, there is no justification to consider C a low level language, and the first sentence in the article conflicts with the idea that C *is* a low level language:

A low-level programming language is a programming language that provides little or no abstraction from a computer's instruction set architecture, memory or underlying physical hardware;

C is entirely abstracted from computer architecture, it is in most cases abstracted from memory and physical hardware by the host OS. On an Operating System, C has no greater access to hardware than Python.

I appreciate it is common now to consider C a low level language, but it simply meets none of the requirements to be one. Gt0101 (talk) 03:46, 3 January 2026 (UTC)[reply]

Request consensus for removing C from this page.

This page describes (correctly in my view) that a low-level language is a programming language that provides little to no abstraction from machine architecture.

C is entirely abstracted from machine architecture, and therefore should not be included here.

I appreciate it is common now to refer to C as a low level language, but by definition (at least the definition in the first sentence of this article), it is not. Gt0101 (talk) 05:04, 8 January 2026 (UTC)[reply]

Oppose removal of C. Support adding clarification (e.g. cited opinion, historicity).

There is no citation for the header definition of "low-level programming language". In fact, section on C has a better cited statement on high vs level than header.

C is effectively the go-to low-level language today. For example:

In books: https://www.amazon.com/Low-Level-Programming-Assembly-Execution-Architecture/dp/1484224027
In Youtube: https://www.youtube.com/shorts/WHjqV4O_JUs

--Voidvector (talk) 06:43, 8 January 2026 (UTC)[reply]

If we are not to use the definition "little to no abstraction over machine architecture", what would be the proposed replacement definition? Are you suggesting that "little to no abstraction over machine architecture" should not be the Wikipedia definition of low-level language?

My point is really that I think most people do accept the Wikipedia definition, but the C section contradicts it. Gt0101 (talk) 06:49, 8 January 2026 (UTC)[reply]

That statement is uncited, I support its removal.

If I were to take a stab at editing it, I would just change the close-ended definition (what it cannot have) to open-ended one (what it must have):

A low-level programming language is a programming language that provides access to a computer's instruction set architecture, memory or underlying physical hardware with little or no abstraction.

--Voidvector (talk) 07:05, 8 January 2026 (UTC)[reply]

I agree with your definition, though it still excludes C, no? C doesn't allow access to machine instructions other than through embedded assembly language, but MicroPython can include assembly language, so I don't think that is qualification enough to consider either a low-level language.

Also embedded assembly language in C is not part of the C specification, it's optional and compiler defined.

Really the core of my point is that C doesn't meet the definition of a low-level language in Wikipedia's current article, nor does it meet your edited definition.

I guess I'm circling around the question, if C is a low-level language, what actually is the definition of low-level language? Gt0101 (talk) 07:11, 8 January 2026 (UTC)[reply]

You can access registers and do inline assembly in C. So it kind of qualifies. That would also include Rust and D, but I personally am fine with their inclusion. I see high-low is a spectrum or continuum. --Voidvector (talk) 07:26, 8 January 2026 (UTC)[reply]

Strictly speaking you can't do inline assembly in C, it's not part of the spec, it's optional. It's included in MicroPython though, and it's seems a stretch to call that a low level language on that basis.

I don't think allowing embedded assembly can qualify a language as low-level, as it include basically any 3GL with a library.

I feel that it is a real stretch to the point of breaking to consider any language that allows inline assembly language to be a low level language. Gt0101 (talk) 07:31, 8 January 2026 (UTC)[reply]

You can access registers and do inline assembly in C. You can choose to add register to the definition of a variable. C does not guarantee that this will cause the variable to be put in a register, nor does it guarantee that something not declared as register will not be placed in a register. Even with a compiler that doesn't automatically put variables in registers, there's no way to get it to put the variable in a particular register; for some particular compiler you might know which register variables get put in which registers based on, for example, the order in which they're declared, but that's it. There may be extensions to C, in some compilers, to allow putting a variable in a particular register, but that's in some C compiler provider's extended C, not in standard C.

And, as noted, inline assembly is also an extension, not a part of standard C.

So I don't see C counting as a low-level language based on those non-standard extensions. Guy Harris (talk) 23:42, 8 January 2026 (UTC)[reply]

For me, if we agree that low level languages offer little to no abstraction over machine architecture, then C is not low level, because it is entirely abstracted from machine architecture.

I believe C23 deprecates the register keyword anyway. Gt0101 (talk) 23:55, 8 January 2026 (UTC)[reply]

This discussion is analogous to the sandwich discussion of whether hot dogs and open sandwiches are sandwiches, which is an example of prescriptive linguistics vs descriptive linguistics. --Voidvector (talk) 02:40, 9 January 2026 (UTC)[reply]

whether hot dogs and open sandwiches are sandwiches Which is the sandwich here? C, or low-level language(s), or both?

If it's C, then presumably the "prescriptive" approach is "C is what's defined by the ISO C specification" and the "descriptive" approach is "anything that, when people are writing code in it, they say they're 'writing C code'".

If it's low-level language(s), then presumably the "prescriptive" approach is "a programming language that provides little or no abstraction from a computer's instruction set architecture" and the "descriptive" approach is "anything that people call 'low-level'".

If you take the "prescriptive" approach to both, C isn't a low-level language. If you take the "descriptive" approach, any language in which somebody does "low-level programming" is a low-level language, including not only C but, for example, Ada.

If you take the "prescriptive" approach to C and you take the "descriptive" approach to "low-level language", the problem is that people who do low-level programming in C probably aren't using strict C - they might be using asm in some places, for example - so there's a mismatch in what "C" means.

If you take the "descriptive" approach to C and the "prescriptive" approach to "low-level language", section 5.1.2.3 "Program execution" of C99 (which is what I have open in my PDF viewer right now), and the equivalent sections in other versions of the C standard, refers to an "abstract machine", so to what extent does that "abstract machine" provide an abstraction from the instruction architectures for which there are C compilers? Guy Harris (talk) 06:23, 9 January 2026 (UTC)[reply]

This is just laughable. This page says that C, a 3rd level language, is low level. Now please click on 3rd level language and you get "A third-generation programming language (3GL) is a high-level computer programming language". Anybody laughing? The fact is that C is not as abstract as say Prolog, but certainly not low level. So say middle level. Yesterday, all my dreams... (talk) 23:48, 9 January 2026 (UTC)[reply]

Maybe if I add some sources:

**Bryant, R. & O’Hallaron, D.** (2016). *Computer Systems: A Programmer’s Perspective* (3rd ed.). Pearson.

The authors refer to C as a “high‑level language” when contrasting it with assembly and machine code.

**Sebesta, R.** (2016). *Concepts of Programming Languages* (11th ed.). Pearson.

Sebesta classifies C as a “high‑level, imperative, procedural language”.

**Louden, K.** (2011). *Programming Languages: Principles and Practice* (3rd ed.). Cengage Learning.

Louden places C in the category of “high‑level imperative languages”.

I think we probably all agree on the definition of low-level language as in the first sentence of the article "a programming language that provides little or no abstraction from a computer's instruction set architecture".

If we *do* agree on that, then what case is there to make that C is low-level? We all know that C is portable and not in any sense associated to any machine architecture, and I struggle to understand why C could ever be considered a low-level language, what definition of "low level language" would we be using would include C? Gt0101 (talk) 09:53, 10 January 2026 (UTC)[reply]

References are always good of course but note that it is 100% certain that C is 3rd level. Also 100% certain that 3rd level languages are not low level. That is it. Yesterday, all my dreams... (talk) 18:26, 10 January 2026 (UTC)[reply]

This page starts out talking about machine language and assembler language and then jumps straight to C, without stopping at, say, PL360 or ESPOL/NEWP or PL/S or PL-11 or even BLISS. At least some of those seem closer to the machine for which they're targeted than C - which was, at most, only a programming language intended specifically for the PDP-11 for a relatively short time, if ever.^[1]

And even Ada, which I suspect few would call a "low-level programming language", has, in the 1995 standard, provisions for an implementation-specified mechanism "Machine Code Insertions" - something C99, C11, C18, and C23 have only in the "J.5 Common extensions" section (it doesn't reserve asm as a keyword).

BTW, "third-level" above should be "third-generation", as in third-generation programming language, with first-generation programming languages being machine code and second-generation programming languages being assembly languages. Guy Harris (talk) 21:09, 10 January 2026 (UTC)[reply]

We are in 100% agreement, C is a 3GL and 3GLs are not low level languages. Gt0101 (talk) 01:15, 11 January 2026 (UTC)[reply]

@Guy Harris: C, or low-level language(s), or both? Yes, both.

For what is C:

Absolute prescriptivist would argue only the spec is C.
Absolute descriptivist would argue any implementation (including unpopular implementations) and usages (including misuses) are also C.

For what is low-level language:

Absolute prescriptivist would argue only definition by some authority is low-level language.
Absolute descriptivist would argue any usages of "low-level language". This would include social media usages.

Here's the deal:

Wikipedia is not a dictionary (from WP:DICT)
Wikipedia aims to describe disputes, but not engage in them (from WP:NPOV)

So there is nothing wrong with having a definition that excludes C (especially if phrased in an open-ended manner). However, given there are people that refer to C as low-level, C should be mentioned and I do not support its removal. The C section could be rephrased to indicate its inclusion is not universal. --Voidvector (talk) 21:51, 10 January 2026 (UTC)[reply]

People who refer to C as a low-level language, or people who speak of doing low-level programming in C?

If the former, OK, but the mention of C should note that it is not a language "that provides little or no abstraction from a computer's instruction set architecture, memory or underlying physical hardware; commands or functions in the language are structurally similar to a processor's instructions", and definitely should be rephrased to indicate that it is not universally considered to be a "low-level programming language".

For that matter, the article should also say something such as

A programming language that provides little or no abstraction from a computer's instruction set architecture, memory or underlying physical hardware; commands or functions in the language are structurally similar to a processor's instructions is a low-level programming language.^[vague] These languages provide the programmer with full control over program memory and the underlying machine code instructions. Because of the low level of abstraction (hence the term "low-level") between the language and machine language, low-level languages are sometimes described as being "close to the hardware".

Some languages that provide an abstraction from a computer's instruction set architecture may also be consider low-level programming languages.

possibly with a qualifier in the second paragraph indicating what makes people consider them "low-level".

And all of this is going to need references, including references for people calling C a low-level programming language. If they do so meaning "it's used for low-level programming, with extensions", then the page should probably separately discuss "low-level languages that don't offer an abstraction from the instruction set" and "languages that offer features for low-level programming". Guy Harris (talk) 22:13, 10 January 2026 (UTC)[reply]

For me, the page is about low-level programming languages, not low-level programming. If people want to describe their programming in C as "low level" that is up to them, but for a page about programming languages themselves, there is no case that I can see that C is low level. Gt0101 (talk) 01:17, 11 January 2026 (UTC)[reply]

C is effectively the go-to low-level language today. For example:
In books: https://www.amazon.com/Low-Level-Programming-Assembly-Execution-Architecture/dp/1484224027

In Youtube: https://www.youtube.com/shorts/WHjqV4O_JUs

The cited book, at least when I use the search feature in Apple Books, contains no instances of the phrase "low-level programming language" and one instance of the phrase "low-level language", at the beginning of chapter 8 "Basics":

In this chapter we are going to start exploring another language called C. It is a low-level language with quite minimal abstractions over assembly. At the same time it is expressive enough so we could illustrate some very general concepts and ideas applicable to all programming languages (such as type system or polymorphism).

"Minimal" is undefined here. The author continues:

C provides almost no abstraction over memory, so the memory management task is the programmer’s responsibility. Unlike in higher-level languages, such as C# or Java, the programmer must allocate and free the reserved memory himself, instead of relying on an automated system of garbage collection.

so at least one of the author's criteria for a high-level language may be "automatic memory management". He continues:

C is a portable language, so if you write correctly, your code can often be executed on other architectures after a simple recompilation. The reason is that the model of computation in C is practically the same old von Neumann model, which makes it close to the programming models of most processors.

and further states later that

The C abstract machine has a von Neumann architecture. It is done on purpose, because C is a language that should be as close to the hardware as possible. The variables are stored in the linear memory and each of them has a starting address.

I think there are Harvard-architecture processors for which there exist implementations of C. Section 6.3.2.3 "Pointers" of C99 does not speak of being able to convert between pointers to functions and pointers to anything else (the standard speaks of "functions or objects" in several places, at least suggesting that they're not the same sort of thing), so that's not "von Neumann architecture".

C does appear to allow order comparison of arbitrary pointers, so C objects presumably are required to exist in some shared address space ("address space" is a term used in the standard), so maybe that's the von Neumann-ish aspect of the abstract machine. However, "linear memory" is a stretch; you can define a total order on pointers in a segmented address space where an address is a segment number plus a segment offset. Pointer subtraction is only defined if either both pointers are pointers to elements of the same array or one of them is a pointer just past the end of the array, so, as long as arrays are always contained entirely in one segment, subtraction just takes the difference between the segment offsets.

(And pointer addition to a pointer to an array element/array subscripting, if the result goes past the end of the array, produces a pointer the result of the dereferencing of which is undefined, which can include "produces an array bounds exceeded error", or the fabled nasal demons, or....)

At one point, the author says "According to von Neumann principles, the program execution is sequential." That's typically the case for most languages, except when they have constructs that explicitly allow parallel execution.

So "low-level" in the sense of "no automatic memory management" and "objects live in a containing address space", but not in the sense of "a programming language that provides little or no abstraction from a computer's instruction set architecture, memory or underlying physical hardware" or "commands or functions in the language are structurally similar to a processor's instructions". The C abstract machine has no instruction set or memory layout.

I.e., there appear to be at least two definitions of a low-level language here.

One post on hackernews has a comment that suggests a third definition is in play - "Zig, like C, C++, Ada, and Rust -- but very much unlike Go -- is a low-level programming language, i.e. one that gives you virtually full control over implementation details such as function dispatch and memory management." Ada is more strict about array indexing ([https://www.adaic.org/resources/add_content/standards/05rm/html/RM-4-1-1.html Ada '95: "For the evaluation of an indexed_component, the prefix and the expressions are evaluated in an arbitrary order. The value of each expression is converted to the corresponding index type. A check is made that each index value belongs to the corresponding index range of the array or entry family denoted by the prefix. Constraint_Error is raised if this check fails."), but it doesn't automatically manage all dynamically-allocated memory, although it does appear to be less of a free-for-all than C.

So this article should perhaps not be written as if there is a single definition of what a "low-level programming language" is. It may have to deal with different levels. All definitions it deals with would need a reference - a reference that can, for example, reasonably be believed not to have been generated by somebody who read this article and then wrote on a web site that "A low-level programming language is a programming language that provides little or no abstraction from a computer's instruction set architecture, memory or underlying physical hardware" (no citogenesis, please).

If we're going to treat any language that's been called a "low-level programming language" as being one, either we need to make an attempt to indicate which definition of "low-level programming language" applies, or turn this article into "List of programming languages that have been called low-level" and make it one big bulleted list.

(I didn't check out the video because I don't have the time or energy to listen to a video and disturb the people around me while I do it, and because I couldn't just pop up a transcript to read in either Safari or Chrome; I tend to avoid videos if possible - just feed me the words and let me read them at my speed. All I want to do is read the text to see, or infer, what his definition of "low-level programming language" is.) Guy Harris (talk) 08:15, 11 January 2026 (UTC)[reply]

I suppose for me, I'm going with the definition of "abstracted from machine architecture". If someone wants to write in a book that C is low-level, I'd like to see them actually define what "low-level" means.

For me, maybe I'm being dismissive (not of you, but of people who talk about programming languages in general), but the "List of programming languages that have been called low-level" would simply be wrong. There are just too many people who call languages "low level" without any sort of justification. I've seen Java of all languages be called low-level.

I guess we need to decide if the definition at the top of the article is something we can agree on. i.e.

A low-level programming language is a programming language that provides little or no abstraction from a computer's instruction set architecture, memory or underlying physical hardware; commands or functions in the language are structurally similar to a processor's instructions.

For me, I agree with this definition except for the vagueness of "underlying physical hardware".

If we can indeed agree on this, then I cannot see the justification for including C on this page.

I accept plenty of languages get called "low level" like Java, Rust, Go etc., but to save time, I just consider the person wrong. Gt0101 (talk) 08:42, 11 January 2026 (UTC)[reply]

I suppose for me, I'm going with the definition of "abstracted from machine architecture". I suspect there are many definitions from which to choose. At this point, my personal choice is "none of the above; with multiple different choices of criteria, it's not a useful term, and it sometimes appears to be used to praise or denigrate a language rather than to convey information".

If someone wants to write in a book that C is low-level, I'd like to see them actually define what "low-level" means. At this point, I'd agree, but replace "C" with "a given programming language".

the "List of programming languages that have been called low-level" would simply be wrong Sorry, I forgot to add the <snark></snark> tags. :-) The point was that if we just include every language that somebody has called "low-level", without an explanation of why they did so, the page wouldn't serve any purpose other than collecting the names of all languages that somebody has called "low-level", and I'm not sure that's a useful purpose.

There are just too many people who call languages "low level" without any sort of justification. I've seen Java of all languages be called low-level. Yup.

I guess we need to decide if the definition at the top of the article is something we can agree on. One question is whether (with the vagueness removed somehow) it is matched by anything other than raw machine language and assembly language. If not, maybe we can just make this page a redirect to Assembly language and be done with it. PL360 looks a lot closer to the machine than C is, so maybe it would count as well.

And there are "languages that are used to write low-level code", which is another matter. Those languages may, either in their specification or in extensions, provide various mechanisms useful for getting "close to the machine" when necessary (e.g., Ada reserves a package for the equivalent of asm, and allows specification of a structure's precise layout in memory), but they aren't necessary always "close to the machine" (it has been ages since I've written any C code - in userland or kernel code - where I had any reason to care which registers were used in the code; I just left it to the compiler to Do The Right Thing). Guy Harris (talk) 09:27, 11 January 2026 (UTC)[reply]

I don't know enough (or anything) about PL360 other than what I just scanned now. It seems to me that it is not entirely abstracted from S/360 architecture, is it? It has high level constructs though. For me, if it's not abstracted from machine architecture, it's not high level, but that's based on very little knowledge of PL360. Gt0101 (talk) 09:32, 11 January 2026 (UTC)[reply]

You need to make a formal "request to close" for this somewhere. Please ask on help desk. You have 3 people in strong agreement and one opposing. Time to move on.

Yesterday, all my dreams... (talk) 09:30, 11 January 2026 (UTC)[reply]

I am new to Wikipedia editing, I don't know how much consensus is *enough* consensus. I can see I have a reasonable amount of agreement, but I don't want to overstep and just do the editing. Gt0101 (talk) 09:34, 11 January 2026 (UTC)[reply]

I can't speak for the 3 people to whom you're referring, but what I agree on is 1) C doesn't fit the definition for a "low-level programming language" given in the lead of this article and 2) there appears to be at least one other definition of "low-level programming language" that would include C (there may be additional ones that exclude it as well). Guy Harris (talk) 09:58, 11 January 2026 (UTC)[reply]

It's number 2 that I don't really understand. If C fits a definition of "low-level programming language", what actually is that definition? I've never been able to extract an answer from anybody for this, on Reddit etc. it really just seems to boil down to "scary pointers" and malloc/free.

I am not being facetious when I say this, if C meets a definition of "low level language", I just don't know what the definition would be that didn't include most 3GLs. Gt0101 (talk) 10:10, 11 January 2026 (UTC)[reply]

The Hacker News post I mentioned said "Zig, like C, C++, Ada, and Rust -- but very much unlike Go -- is a low-level programming language, i.e. one that gives you virtually full control over implementation details such as function dispatch and memory management." That's somewhat like "malloc/free" plus function dispatch (I'm not familiar enough with Go to know what they're referring to there). Another one might be "does array bounds checking (as opposed to "doesn't forbid bounds checking, but most implementations don't do it when they can and don't offer a compiler option to turn it on, and doing it for all arrays would require stuffing, at minimum, length information into pointers into a one-dimensional array, and might involve full-blown dope vectors for multi-dimensional arrays"). Guy Harris (talk) 11:00, 11 January 2026 (UTC)[reply]

Comment: Kernighan and Ritchie Chapter 0, page 1, second paragraph: "C is a relatively "low level" programming language."^[2] — Preceding unsigned comment added by Adakiko (talk • contribs) 09:38, 11 January 2026 (UTC)[reply]

"Relatively" is the key word here. It's probably lower-level than, say Go or that language that I've been mentioning a lot or C++ in its full shining STL glory (I haven't looked at Rust in enough detail to decide where it sits on the scale of levels), but it looks significantly higher than PL360. Again, the more I've looked the less I see a case for any given definition of "low-level programming language" being the one true definition. Guy Harris (talk) 09:53, 11 January 2026 (UTC)[reply]

What about the question: "Is Toyota X an epensive car?" The fact is that high/low is not a 2 valued item, but a fuzzy item like expensive. But C is not in the 100% low level class, hence the term relatively. Yesterday, all my dreams... (talk) 09:55, 11 January 2026 (UTC)[reply]

I feel like we are trying too much to resolve ambiguity in real life, which is unnecessary as an encyclopedia editor.

Let me ask some meta the questions:

Why are we even trying to figure out the boundary of low-level vs high-level?
Is the division a hard boundary? Or is it a spectrum/continuum?
If the division has a hard boundary, is whole system a dichotomy (high vs low) or trichotomy (high vs mid vs low)?

If you ask LLMs about "what is a low-level programming language?", both ChatGPT and Google Gemini would tell you C/C++ are mid-level languages.

IMO, we do not need to resolve these questions, simply cite sources and state the source's positions, make note of the popular and less popular positions. --Voidvector (talk) 09:57, 11 January 2026 (UTC)[reply]

Though if you pester Copilot for the strict definition, it'll tell you C is a high level language. Gt0101 (talk) 10:02, 11 January 2026 (UTC)[reply]

As per my comment about "references" for the definition in the lead of this article that sound suspiciously as if somebody read this article and then parroted it, both human and artificial intelligences might be choosing some of the things they've read and replaying something based on that. (My trust in Google AI summaries has dropped drastically over time; I'm glad it posts references, but it can sure get insistent about things that Just Ain't So, and all too often punts to "X and Y are two things that aren't directly connected blah blah blah" in response to a simple "X" "Y" query looking for a page that mentions both. So I'm not sure I'd treat an LLM as an expert any more than I'd trust some random website I've never heard of as an expert. Guy Harris (talk) 10:29, 11 January 2026 (UTC)[reply]

LLM summaries are like a roulette game. Not reliable. Please take a look at WP:RSN on this right now. Yesterday, all my dreams... (talk) 10:32, 11 January 2026 (UTC)[reply]

Is the division a hard boundary? I'm seeing no evidence for it being one, and plenty of evidence for it not being one, given that, for C and at least some other languages, "opinions differ".

Or is it a spectrum/continuum? Or maybe not a continuum in the mathematical sense, and thus not necessarily a continuum in the measurement sense; maybe each language is at a point in a multi-dimensional space with Boolean or integral coefficients.

I.e., maybe languages should be characterized based on what characteristics they have. Individual characteristics ("language commands or functions in the language are structurally similar to a processor's instructions", "language doesn't do automatic memory management for all allocations", "language lets you drop into assembler code", etc.) may be designated as "low-level" (or "high-level", e.g. if you invert the preceding ones), but there may be language with a mix (e.g., C is a hard "no" on the first, a hard "yes" on the second, and a "several implementations support extensions to do it, and GCC's extension may be common to some of them" on the third).

IMO, we do not need to resolve these questions, simply cite sources and state the source's positions, make note of the popular and less popular positions. Sounds good, as long as we handle multiple definitions and indicate which languages apply to which definitions. Guy Harris (talk) 10:47, 11 January 2026 (UTC)[reply]

Only in the 1978 version though, the statement was removed in later revisions and replaced with "C is not a ‘very high level’ language". Gt0101 (talk) 10:01, 11 January 2026 (UTC)[reply]

Please add the exact latest edition post 1978 that says that. That should settle it. Yesterday, all my dreams... (talk) 10:26, 11 January 2026 (UTC)[reply]

Goodbye. I have nothing more to say here in this circular discussion. Goodbye. Yesterday, all my dreams... (talk) 11:22, 11 January 2026 (UTC)[reply]

References

^ S. C. Johnson; D. M. Ritchie. "Portability of C Programs and the UNIX System" (PDF). C was developed for the PDP-11 on the UNIX system in 1972. Portability was not an explicit goal in its design, even though limitations in the underlying machine model assumed by the predecessors of C made us well aware that not all machines were the same. Less than a year later, C was also running on the Honeywell 6000 system at Murray Hill. Shortly thereafter, it was made available on the IBM 370 series machines as well. (the 310 in the PDF was a typo from OCRing)
^ Kernighan, Brian W.; Ritchie, Dennis M. (1978). The C Programming Language. Prentice-Hall. ISBN 0-13-110163-3.

[1] S. C. Johnson; D. M. Ritchie. "Portability of C Programs and the UNIX System" (PDF). C was developed for the PDP-11 on the UNIX system in 1972. Portability was not an explicit goal in its design, even though limitations in the underlying machine model assumed by the predecessors of C made us well aware that not all machines were the same. Less than a year later, C was also running on the Honeywell 6000 system at Murray Hill. Shortly thereafter, it was made available on the IBM 370 series machines as well. (the 310 in the PDF was a typo from OCRing)

[2] Kernighan, Brian W.; Ritchie, Dennis M. (1978). The C Programming Language. Prentice-Hall. ISBN 0-13-110163-3.

[1]

[2]