3 ms·

Fundamentals are algorithm design and complexity analysis, not the accidental complexities of some specific piece of hardware nobody will be using in twenty yea

by derleth 14y ago

Fundamentals are algorithm design and complexity analysis, not the accidental complexities of some specific piece of hardware nobody will be using in twenty years. On the flip side, there will always be teenagers. There will always be people attracted to assembly language for the same reasons I was: A love of complexity and half-formed (and mostly mistaken) ideas about what programming really is.

spec_laconic 14y ago
I completely agree. As I get older, I find the abstractions to be much more interesting; how does one express a lambda in assembly? Functional programming in general? The simplicity of Python and the beauty of Lisp / Scheme / f# keep me going as a programmer. I wonder, as assembly languages become more complex and malformed with the introduction of ARM and all of the headaches of custom architectures, if there won't be more people moving to the higher level, just for sanity's sake.
- gizmo686 14y ago
  Actually, functional programming is very straight forward on a low level. When you define a function, foo, the machine code for that function is at a specific memory location. When the source code says foo(*args), the machine pushes local variables, its current location in the code, and the args to the stack. It then jumps to the memory location stored in foo Once there, the code pops the arguments, does stuff, pushes the return value, and jumps back to where it was called from. Once there, the return values and local variables get pop'ed, and execution continues. Different compilers might use different conventions, but for our purposes this is a good enough model. The way a normal function call would look in assembly might be: mov %eax <returnPoint> ;at assembly time, <returnPoint> is replaced with the memory address of the operation labled returnPoint: push %eax ;save the return point to the stack push %ebx ;push local variables and the arguments ... jmp <foo> ;jump to the memory location labled foo returnPoint: pop ebx ;pop local variables and return values, pop ecx ... The thing to note in this example is that when you run the assembler, <foo> gets replaced with the memory location of the function code. If we want to a functional type thing, we need the address we jump to be able to change at runtime, so instead of having the assembler hard code the memory location to jump to, we need to get that information from a variable. This would look like ... jmp [foo] ... This time, foo is not pointing to a function, but rather to the memory location of a function pointer. This means that if we want to make it so when we call foo(), we run the bar() function, we would simply need to do: mov foo <bar> foo is the memory location of the function pointer, and <bar> is the memory location of the function itself, so now when we dereference foo in the jmp, we will execute bar(). With regard to the ARM architecture, I've done a little bit of work in it, and it isn't more complex than x86.
- tete 14y ago
  Sorry, when I am short, but: https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine
tete 14y ago
> A love of complexity and half-formed (and mostly mistaken) ideas about what programming really is. Couldn't you basically say the same about most system languages (for example C and actually even stuff like Java)?
- derleth 14y ago
  > Couldn't you basically say the same about most system languages (for example C and actually even stuff like Java)? Those languages have more pragmatic use, though.
  - tete 14y ago
    But it's not like Assembly has no pragmatic use. I agree, people often tend to use too low level languages, but there are also good reasons to use Assembly, just like for about any language. In most cases people had a good reason to implement a language and if there are still compilers and interpreters, which maybe even continue to evolve that's a good indication for a using a language. And Assembly... well, when I think about boot loaders, operating system, that 64k ego shooter, implementations of (for example cryptographic) algorithms and how some things are actually easier to do in Assembly, because it is low level then that's enough reason. And if you have fun doing so than it is more than enough reason. I mean if you don't do stuff for fun (and curiosity) in some way, I wouldn't call someone a good scientist. A passionate programmer, no matter what language usually gets stuff done. I mean, here we often talk about things on a kinda philosophical level, but especially when you do some assembly it's just doing stuff and I mean even using a higher, more modern language they usually don't guarantee any of the things that make you better. I often see code that looks like C or Java by just ignoring how a language was designed. I mean we just came to a point where functional programming languages (which actually can be and are pretty simple, when you think about what you need for lambda) and on the other hand loose touch with everything else. Of course, abstraction. That's what it is for. You can forget about it, but that doesn't mean it's good to not know about it. > complexities of some specific piece of hardware nobody will be using in twenty years. Is that so? I mean one is usually still having some kind of interface, because of backward compatibility. And even if it is like that, is it really a problem. Everything changes, what counts is experience, learning from mistakes, ... That's usually very generic and that's the stuff that you spend time on and that will allow you to make stuff quicker.

by derleth 14y ago

spec_laconic 14y ago

I completely agree. As I get older, I find the abstractions to be much more interesting; how does one express a lambda in assembly? Functional programming in general? The simplicity of Python and the beauty of Lisp / Scheme / f# keep me going as a programmer. I wonder, as assembly languages become more complex and malformed with the introduction of ARM and all of the headaches of custom architectures, if there won't be more people moving to the higher level, just for sanity's sake.

gizmo686 14y ago
Actually, functional programming is very straight forward on a low level. When you define a function, foo, the machine code for that function is at a specific memory location. When the source code says foo(*args), the machine pushes local variables, its current location in the code, and the args to the stack. It then jumps to the memory location stored in foo Once there, the code pops the arguments, does stuff, pushes the return value, and jumps back to where it was called from. Once there, the return values and local variables get pop'ed, and execution continues. Different compilers might use different conventions, but for our purposes this is a good enough model. The way a normal function call would look in assembly might be: mov %eax <returnPoint> ;at assembly time, <returnPoint> is replaced with the memory address of the operation labled returnPoint: push %eax ;save the return point to the stack push %ebx ;push local variables and the arguments ... jmp <foo> ;jump to the memory location labled foo returnPoint: pop ebx ;pop local variables and return values, pop ecx ... The thing to note in this example is that when you run the assembler, <foo> gets replaced with the memory location of the function code. If we want to a functional type thing, we need the address we jump to be able to change at runtime, so instead of having the assembler hard code the memory location to jump to, we need to get that information from a variable. This would look like ... jmp [foo] ... This time, foo is not pointing to a function, but rather to the memory location of a function pointer. This means that if we want to make it so when we call foo(), we run the bar() function, we would simply need to do: mov foo <bar> foo is the memory location of the function pointer, and <bar> is the memory location of the function itself, so now when we dereference foo in the jmp, we will execute bar(). With regard to the ARM architecture, I've done a little bit of work in it, and it isn't more complex than x86.
tete 14y ago
Sorry, when I am short, but: https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine

tete 14y ago

> A love of complexity and half-formed (and mostly mistaken) ideas about what programming really is. Couldn't you basically say the same about most system languages (for example C and actually even stuff like Java)?

derleth 14y ago
> Couldn't you basically say the same about most system languages (for example C and actually even stuff like Java)? Those languages have more pragmatic use, though.
- tete 14y ago
  But it's not like Assembly has no pragmatic use. I agree, people often tend to use too low level languages, but there are also good reasons to use Assembly, just like for about any language. In most cases people had a good reason to implement a language and if there are still compilers and interpreters, which maybe even continue to evolve that's a good indication for a using a language. And Assembly... well, when I think about boot loaders, operating system, that 64k ego shooter, implementations of (for example cryptographic) algorithms and how some things are actually easier to do in Assembly, because it is low level then that's enough reason. And if you have fun doing so than it is more than enough reason. I mean if you don't do stuff for fun (and curiosity) in some way, I wouldn't call someone a good scientist. A passionate programmer, no matter what language usually gets stuff done. I mean, here we often talk about things on a kinda philosophical level, but especially when you do some assembly it's just doing stuff and I mean even using a higher, more modern language they usually don't guarantee any of the things that make you better. I often see code that looks like C or Java by just ignoring how a language was designed. I mean we just came to a point where functional programming languages (which actually can be and are pretty simple, when you think about what you need for lambda) and on the other hand loose touch with everything else. Of course, abstraction. That's what it is for. You can forget about it, but that doesn't mean it's good to not know about it. > complexities of some specific piece of hardware nobody will be using in twenty years. Is that so? I mean one is usually still having some kind of interface, because of backward compatibility. And even if it is like that, is it really a problem. Everything changes, what counts is experience, learning from mistakes, ... That's usually very generic and that's the stuff that you spend time on and that will allow you to make stuff quicker.