pouët.net

Go to bottom

Better to learn C or ASM first?

category: general [glöplog]
Without knowing your practical level in programming, I would advise :

- learn programming *first*, learn to write algorithms that solve specific issues, learn to process data, write a sorting routine, how to transform vertices in 3D, and so on.
- C could be a good language to learn programming. Knowadays, I think that Python or Java are taught as a first language to IT students. C has an advantage that you will be able to work with blocks of raw memories, hence learn how to split a long into words, into bytes, into bit (well, almost), how to deal with memory addresses...
- if it turns out your target platform needs you to write some pieces of routines in ASM, you might eventually find enough time to lear x86, 68k, Z80 or 6502. I'm actually stuck at this step.

on a side note, coding in Python and even more Java and C++ will bring the question of object oriented programming. When and why shall I use a class (or not) ? That's a reccuring question nowadays, even with young programmers that can't start a new project without creating an object :)
added on the 2017-05-25 09:38:23 by fra fra
Learn FORTRAN.
added on the 2017-05-25 11:00:02 by Natopsi Natopsi
To me, objects and classes make more sense only if they are viewed as a syntax helper macro system for specifying operations together with the data structures they manipulate. Structs "s" and functions "f(s)", tied together syntactically. Stuff that you should be writing anyway, even in assembly or C, but with more rigid structural help from the compiler. If you don't understand how classes map to structs+functions, then isn't it just a load of magical cargo cult mumbo jumbo? Probably it's possible to learn the ideas behind object-orientation as implicit assumptions practiced by the programming culture, but that's not how I learned it.
added on the 2017-05-25 11:11:02 by yzi yzi
A class is a struct with methods.
added on the 2017-05-25 13:11:16 by Adok Adok
Everybody means different things when talking about OOP, but for me, it's about implementation (and information) hiding. Package down things into some abstraction where you can change or improve the insides at will, without the callers caring or even knowing. And no, it's not always the right thing to do.
added on the 2017-05-25 13:12:59 by Sesse Sesse
"Programming is learned by writing programs." - Brian Kernighan
added on the 2017-05-25 15:02:57 by maali maali
1. Learn the very basics of asm: registers, stack, memory access, the most common instructions. Don't bother trying to write anything at this point.

2. Learn C. Enable asm output from your compiler. Every time you have successfully compiled a function, look at the generated asm. Look up all the instructions you don't know yet. Make sure you understand how the asm corresponds to the C code you have written. Try different optimization levels (and other compiler options) to see what difference it makes.

3. Profit: This way, you will develop a much deeper understanding of both languages than if you learned them separately.
added on the 2017-05-25 16:19:28 by Blueberry Blueberry
Better advice:
1. For ASM: only be sure to know all those cool tricks like "lea eax,[eax*2+eax+1234]", just to increase your rep.

2. For higher-level languages: ignore sorting, algorithms and computation complexity - that is for wimps. Start with lambda calculus/functional purity/continuations/contracts/promises etc... and be sure to intimidate everyone on forums that is not familiar with the topic.

3. Profit.
added on the 2017-05-25 18:14:25 by tomkh tomkh
Quote:
Better advice:
1. For ASM: only be sure to know all those cool tricks like "lea eax,[eax*2+eax+1234]", just to increase your rep.

2. For higher-level languages: ignore sorting, algorithms and computation complexity - that is for wimps. Start with lambda calculus/functional purity/continuations/contracts/promises etc... and be sure to intimidate everyone on forums that is not familiar with the topic.

3. Profit.

:D
added on the 2017-05-25 18:23:42 by ferris ferris
there seems to be some kind of pattern.
Quote:
"sorting, algorithms and computation complexity"
vs.
"lambda calculus/functional purity/continuations/contracts/promises"

I know both. But only the former gets me a job.
added on the 2017-05-25 18:58:39 by xTr1m xTr1m
To answer the original question: you just fucking do it (one or the other or both) instead of talking about doing it. Then come back with questions that are not stupid. But as sensenstahl pointed out, there indeed is a pattern here.
added on the 2017-05-26 09:46:25 by Preacher Preacher
Stick to graphics or music! Life is much simpler, although it's unlikely to get you a job.
added on the 2017-05-26 11:22:19 by djh0ffman djh0ffman
Whatever you do, just make sure what you're doing makes you happy...
added on the 2017-05-26 11:37:38 by DanLemon DanLemon
I suggest starting with C64 basic for 6 years, then progress on to AMOS basic. After about 2-3 years you are now ready to start coding 100% assembler for the next 7-8 years. Suddenly you are ready to try your first C program. Out of experience it pays off to code a Lightwave object reader as first project because if you don't have 3D you can't win any compos.

Remember to code C as if it was still assembler with a different syntax. Cast all pointers to byte pointers for maximum control. Now after 1 year start with C++ and code a 3d shooter in DirectX 8. C++ will give you powerful features such as not complaining about declaring variables at top of scope and double slash comments.

True story!
added on the 2017-05-27 13:13:38 by rloaderro rloaderro
Truest story: Putting jumbled English command words into text files is a terrible way to communicate what you actually want a computer to do. It's a fascinating bridging technology and appeals to a certain type of adolescent brain, but actually sucks on all levels.
added on the 2017-05-27 14:48:50 by tomaes tomaes
Quote:
1. For ASM: only be sure to know all those cool tricks like "lea eax,[eax*2+eax+1234]", just to increase your rep.

Interestingly, you can learn a lot of those tricks by looking at compiler output. Compilers are deviously clever sometimes. Just the other day, I was looking at the generated code for a function that had a long list like this:
Code:return x == SOMECONST || x == OTHERCONST || ...

The compiler translated this into a bunch of range checks and some adjustment, and rounded off with:
Code: mov rax, bitmask rsh rax, cl and rax, 1 ret
added on the 2017-05-29 20:14:00 by Blueberry Blueberry
In case you enjoy uncommon/weird assembly snippets, there's a book with 64 x86 assembly "riddles" here. Nice for a quick diversion during lunch break. :)

Not sure the original poster would enjoy this though. :D
added on the 2017-05-30 11:37:43 by Kylearan Kylearan

login

Go to top