<p>Fair warning, as you said, we don't really do this anymore - &quot;low level&quot; and &quot;today&quot; contradict each other somewhat.  Higher level languages are just too convenient in producing complex actions from less code.  Even on embedded/lower level environments we still, at the very least, use C.  I'd say C is probably what meets most of your requirements - about as low level as you'll get these days outside of assembly and easy enough to do start doing basic data manipulation quickly if you don't want to dig too deep into the features without too much complexity, having the added bonus of being still somewhat relevant.</p>
<p>Right off the bat, an additional warning to save time/sanity: you've mentioned instruction sets, implying writing in machine language - this wasn't done much anymore even 30-40 years ago.  Assembly is almost a 1-to-1 equivalent to it with a minor abstraction layer and a few convenience features.  Machine language is both too complicated and specific to the processor/family to be even niche useful these days.</p>
<p>To address your goals/reasons:</p>
<ol>
<li><p>(assumed: web bots?) Lower level languages are the opposite of easy.  Try different high level languages for creating bots: javascript, python (in a VM).  If you're looking to see how they work when all you have is the binary/executable, have a look at disassemblers/decompilers (in a VM).  Be prepared to commit to a puzzle - most things aren't designed to be reverse engineered, and some even are designed to thwart the attempt.</p>
</li>
<li><p>Grab/make a golfing language: code golf is a more about the puzzle of the shortest code than producing a working/modern project.  Golfing languages are optimized for the purpose of golfing at a higher level than most general high level languages.  Assembly/C could work, but the number of bytes it takes to do even some simple things would be prohibitive.  Look up &quot;assembly print to console&quot; or even &quot;C print to console&quot; for generic examples, then compare it to an equivalent code golfing language like Jelly or 05AB1E.</p>
</li>
<li><p>We're doing a lot (!) of Arm these days.  For the overall goal of learning and becoming more familiar with today's hardware/engineering technologies, I suggest looking at an Arm target - a Raspberry Pi is a convenient/cost effective way to get a quick host going.</p>
</li>
</ol>
<p>It's not going to be easy any way you cut it, but try debugging programs in Linux ddd, a gdb gui.  Write some simple programs in C with some breakpoints to see how a lower-ish level language and the compiler represent ideas in assembly/machine language - especially when the optimization flags are changed in the compilation.  After that, try some higher level compiled languages - i.e. C++, Rust - and see how different they look under the debugger/disassembly to understand how much complexity a modern compiler handles for us.</p>
<p>If still desired at this point, try your hand at assembly for the experience - &quot;as&quot; is included on the default Pi image as of writing.  Even in 8085/MIPS assembly, we're still dealing with the basic building blocks - loads/stores, registers, etc.  To produce complexity out of the basics, strong organization/strategy will be required to maintain/break down the long segments of code required - the name &quot;BF&quot; can be appropriate here for programs of sufficient length to be useful: they're a magnitude more complicated than the equivalent high level code would be.</p>
<p>That being said, I'd also suggest doing the same thing on Windows/OS X if you can get a hold of the hardware/tools - modern systems/technologies include them as well.</p>
<p>Keep in mind that lower level languages are usually brought out for hardware specific reasons/optimizations in the rare case that a higher level language isn't cutting it.  Often one of the more essential tasks in a project is choosing the tools for the job that yield the correct results, as quickly as possible, using the least resources - lower level languages typically don't fit these goals anymore.</p>

CC BY-SA 4.0
2024-04-14T21:44:21.250Z
I may not have been able to fully articulate myself about code golf.However,as far as I understand from your answer,code golf is necessary for problem analysis.I would rather use the hardware for quantum programming as much as possible in applying binary logic to everyday computers.In other words,I want the bests of the algorithm at the expense of spaghetti code.Which is almost why I'm not interested in OOP-This increases code security,as the emulator will be easy to code every time.I don't care about the performance impact of that either.These're things that improve synthesis capabilities
fkybrd
CC BY-SA 4.0
2024-04-14T21:47:34.640Z
This is necessary for less e-waste.
fkybrd
CC BY-SA 4.0
2024-04-14T15:28:41.500Z
2024-04-14T15:28:41.500Z
user1692597
<p>After reviewing the 8086, 8085, 6502, MIPS, NASM, and MASM instructions, I decided that the instructions were similar. I want to learn a low-level programming language, but it doesn't have to be assembly. There are three reasons why I want to find out.</p>
<ol>
<li>To make it easier to emulate bots in a different way post-compilation.</li>
<li>Doing code golf as a hobby.</li>
<li>Become more familiar with today's engineering technologies.</li>
</ol>
<p>Are there low-level data processing programming languages, esoteric or not, that I don't need to code forever (!) to solve very complex problems like BF? 8085 or MIPS instructions seem to meet my needs at the moment, but I don't have a complete learning plan.</p>

CC BY-SA 4.0
2024-04-06T12:11:20.187Z
Do you want something concrete such as the examples you give, or will something constructed for educational purposes do?
Buffy
CC BY-SA 4.0
2024-04-07T10:33:58.610Z
Rather, there may be concrete examples or similar languages to understand the standards.
fkybrd
CC BY-SA 4.0
2024-04-07T12:44:26.580Z
Sorry, but I don't understand your comment. Clarify?
Buffy
CC BY-SA 4.0
2024-04-07T14:05:51.277Z
In daily life, programming languages that are very close to machine language are not widely used.
fkybrd
<self-learning><language-choice>
Where do I start learning low-level programming?
# Where do I start learning low-level programming?

(Asked by: username_0 on 2024-04-03)

After reviewing the 8086, 8085, 6502, MIPS, NASM, and MASM instructions, I decided that the instructions were similar. I want to learn a low-level programming language, but it doesn't have to be assembly. There are three reasons why I want to find out.

1. To make it easier to emulate bots in a different way post-compilation.
2. Doing code golf as a hobby.
3. Become more familiar with today's engineering technologies.

Are there low-level data processing programming languages, esoteric or not, that I don't need to code forever (!) to solve very complex problems like BF? 8085 or MIPS instructions seem to meet my needs at the moment, but I don't have a complete learning plan.

**Tags:** self-learning, language-choice

> **Comments:**
> **username_1**: Do you want something concrete such as the examples you give, or will something constructed for educational purposes do?  
> **username_0**: Rather, there may be concrete examples or similar languages to understand the standards.  
> **username_1**: Sorry, but I don't understand your comment. Clarify?  
> **username_0**: In daily life, programming languages that are very close to machine language are not widely used.  

---

## 1 answers

### Answer by username_2 on 2024-04-14. Score: 1

Fair warning, as you said, we don't really do this anymore - "low level" and "today" contradict each other somewhat. Higher level languages are just too convenient in producing complex actions from less code. Even on embedded/lower level environments we still, at the very least, use C. I'd say C is probably what meets most of your requirements - about as low level as you'll get these days outside of assembly and easy enough to do start doing basic data manipulation quickly if you don't want to dig too deep into the features without too much complexity, having the added bonus of being still somewhat relevant.

Right off the bat, an additional warning to save time/sanity: you've mentioned instruction sets, implying writing in machine language - this wasn't done much anymore even 30-40 years ago. Assembly is almost a 1-to-1 equivalent to it with a minor abstraction layer and a few convenience features. Machine language is both too complicated and specific to the processor/family to be even niche useful these days.

To address your goals/reasons:

1. (assumed: web bots?) Lower level languages are the opposite of easy. Try different high level languages for creating bots: javascript, python (in a VM). If you're looking to see how they work when all you have is the binary/executable, have a look at disassemblers/decompilers (in a VM). Be prepared to commit to a puzzle - most things aren't designed to be reverse engineered, and some even are designed to thwart the attempt.
2. Grab/make a golfing language: code golf is a more about the puzzle of the shortest code than producing a working/modern project. Golfing languages are optimized for the purpose of golfing at a higher level than most general high level languages. Assembly/C could work, but the number of bytes it takes to do even some simple things would be prohibitive. Look up "assembly print to console" or even "C print to console" for generic examples, then compare it to an equivalent code golfing language like Jelly or 05AB1E.
3. We're doing a lot (!) of Arm these days. For the overall goal of learning and becoming more familiar with today's hardware/engineering technologies, I suggest looking at an Arm target - a Raspberry Pi is a convenient/cost effective way to get a quick host going.

It's not going to be easy any way you cut it, but try debugging programs in Linux ddd, a gdb gui. Write some simple programs in C with some breakpoints to see how a lower-ish level language and the compiler represent ideas in assembly/machine language - especially when the optimization flags are changed in the compilation. After that, try some higher level compiled languages - i.e. C++, Rust - and see how different they look under the debugger/disassembly to understand how much complexity a modern compiler handles for us.

If still desired at this point, try your hand at assembly for the experience - "as" is included on the default Pi image as of writing. Even in 8085/MIPS assembly, we're still dealing with the basic building blocks - loads/stores, registers, etc. To produce complexity out of the basics, strong organization/strategy will be required to maintain/break down the long segments of code required - the name "BF" can be appropriate here for programs of sufficient length to be useful: they're a magnitude more complicated than the equivalent high level code would be.

That being said, I'd also suggest doing the same thing on Windows/OS X if you can get a hold of the hardware/tools - modern systems/technologies include them as well.

Keep in mind that lower level languages are usually brought out for hardware specific reasons/optimizations in the rare case that a higher level language isn't cutting it. Often one of the more essential tasks in a project is choosing the tools for the job that yield the correct results, as quickly as possible, using the least resources - lower level languages typically don't fit these goals anymore.

> **Comments:**
> **username_0**: I may not have been able to fully articulate myself about code golf.However,as far as I understand from your answer,code golf is necessary for problem analysis.I would rather use the hardware for quantum programming as much as possible in applying binary logic to everyday computers.In other words,I want the bests of the algorithm at the expense of spaghetti code.Which is almost why I'm not interested in OOP-This increases code security,as the emulator will be easy to code every time.I don't care about the performance impact of that either.These're things that improve synthesis capabilities  
> **username_0**: This is necessary for less e-waste.  

---

