3 ms·

Although I appreciate what the article has to say (indeed its true); I think we are having an issue with the reverse with regards to the SMARTS/SKILLS/JOBS sect

by jdefr89 14y ago

Although I appreciate what the article has to say (indeed its true); I think we are having an issue with the reverse with regards to the SMARTS/SKILLS/JOBS sections. Most new computer scientist/engineers these days DON'T KNOW FUNDAMENTALS WELL. You may say people who code in Assembly (or are learning it) are foolish; that couldn't be farther from the truth. Keeping up to date with your low-level computing knowledge forms a base to work on any other abstraction layer up the chain. The core concepts important in older skills will still be important 1000 years down the road. With the older generation fading out I fear we will lose a lot of the fundamental, gritty knowledge that all other programming is based on. You don't see many new-age programmers learning about low-level details like memory, and i/o. Yet, in years to come if we need to make changes and possibly rebuild some things from close to the hardware we may end up in the dark. Without the people who handled a lot of the hardcore stuff, we may potentially lose knowledge when todays younger generation steps up to the plate. So basically my argument is that any serious hacker should be able to conceptualize a fully working machine from the logic gates to the software. Understanding the primitive components of a computer system helps you everywhere else and will most likely never be knowledge that becomes obsolete.

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.
mechanical_fish 14y ago
I'm going to need actual statistics before I'll believe that assembly programmers, hardware hackers, et cetera are any rarer than they once were. My informal observation is that there's more hardware around than ever. Who designed and built these dozens and dozens of Android phones and tablets? Where are all these tiny helicopters and balancing scooters and taco-delivering drones coming from? Yes, the average programmer today knows a lot less about assembly language than the average programmer in 1980. But there were a lot fewer programmers and a lot fewer computers in 1980, and to do anything beyond BASIC on a microcomputer required assembly. Since then the number of programmers has exploded, and it has not done so evenly. I'm sure that today there's a lot more Visual Basic-only programmers in the world than assembly programmers, but that doesn't mean that the population of assembly programmers has shrunk; it just hasn't grown as quickly. I also suspect that, should it become sufficiently important to double the number of trained assembly hackers, we have the means to do so: Raise the bid high enough and, sure, I'll absolutely retrain in an assembly language newer than 6502 and Motorola 68000. ;) (Though, alas, I'm told that however clever I become at optimizing my assembly, the compiler is probably cleverer still, so I guess I should dream of embedded C instead of assembly.)
gizmo686 14y ago
The time you are talking about was when computer science was in its infancy, and was small enough for people to be fluent in all parts of it. This is not unlike early science, when you had the same people make discoveries in pure math, physics, chemistry ... What we have now that the field of computer science is maturing is more specilization. There are still "systems" students, who learn the low level details (one of my friend's class was writing an operating system). In addition to that, you have application developers, who can spend there resources make a more user-friendly product, and likely taking advantage of dozens of other black box systems other programmers created.
tete 14y ago
> You don't see many new-age programmers learning about low-level details like memory, and i/o. Is that true? We learn that in first semester, including everything from flip-flops upward to how and why the parts of a CPU function, not matter what you specialize on (medical cs, software engineering, ...). One doesn't pass the first semester without basic understanding of assembly and microcode. People doing technical cs do something more in-depth I think (well, one should at least guess so) and I am not at a renowned university. 345 in the Top 400 ranking done here earlier this year[1]. [1] http://www.timeshighereducation.co.uk/ http://www.timeshighereducation.co.uk/

by jdefr89 14y ago

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.

mechanical_fish 14y ago

I'm going to need actual statistics before I'll believe that assembly programmers, hardware hackers, et cetera are any rarer than they once were. My informal observation is that there's more hardware around than ever. Who designed and built these dozens and dozens of Android phones and tablets? Where are all these tiny helicopters and balancing scooters and taco-delivering drones coming from? Yes, the average programmer today knows a lot less about assembly language than the average programmer in 1980. But there were a lot fewer programmers and a lot fewer computers in 1980, and to do anything beyond BASIC on a microcomputer required assembly. Since then the number of programmers has exploded, and it has not done so evenly. I'm sure that today there's a lot more Visual Basic-only programmers in the world than assembly programmers, but that doesn't mean that the population of assembly programmers has shrunk; it just hasn't grown as quickly. I also suspect that, should it become sufficiently important to double the number of trained assembly hackers, we have the means to do so: Raise the bid high enough and, sure, I'll absolutely retrain in an assembly language newer than 6502 and Motorola 68000. ;) (Though, alas, I'm told that however clever I become at optimizing my assembly, the compiler is probably cleverer still, so I guess I should dream of embedded C instead of assembly.)

gizmo686 14y ago

The time you are talking about was when computer science was in its infancy, and was small enough for people to be fluent in all parts of it. This is not unlike early science, when you had the same people make discoveries in pure math, physics, chemistry ... What we have now that the field of computer science is maturing is more specilization. There are still "systems" students, who learn the low level details (one of my friend's class was writing an operating system). In addition to that, you have application developers, who can spend there resources make a more user-friendly product, and likely taking advantage of dozens of other black box systems other programmers created.

tete 14y ago

> You don't see many new-age programmers learning about low-level details like memory, and i/o. Is that true? We learn that in first semester, including everything from flip-flops upward to how and why the parts of a CPU function, not matter what you specialize on (medical cs, software engineering, ...). One doesn't pass the first semester without basic understanding of assembly and microcode. People doing technical cs do something more in-depth I think (well, one should at least guess so) and I am not at a renowned university. 345 in the Top 400 ranking done here earlier this year[1]. [1] http://www.timeshighereducation.co.uk/ http://www.timeshighereducation.co.uk/