50 ms·

But it does. The same holds for Google and stackoverflow: the majority of developers have trouble with sql.since the introduction of or mappers and plenty of ot

by wokkel 2y ago

But it does. The same holds for Google and stackoverflow: the majority of developers have trouble with sql.since the introduction of or mappers and plenty of other examples. Ask a junior dev about the difference between a stack allocated and a heap allocated object and be amazed.

throwaway314155 2y ago
[flagged]
- fsloth 2y ago
  I'm not sure what type of code you develop but it sure ain't the entirety of the real world. In my corner of the real world we are quite concerned about the difference between stack and heap and profile our applications to pinpoint any opportunities for optimization in e.g. heap allocations. Like, most of the world runs on puny chips, and if the chips are not puny, the workloads are still going to eat up battery and contend with all of the other crap running on the end users device.
  - throwaway314155 2y ago
    sorry if i struck a nerve. i maintain that this is a domain specific skillset and that only specific types of coders really need that knowledge.
- qsort 2y ago
  I read comments like this all the time in all sorts of variants (we don't need math, we don't need CS theory, we don't need regexes, we don't need pointers). What do you people even do? Most of my work is with managed languages, but lower level concerns bubble up multiple times per project; you can't write great Python if you can't write decent C.
  - throwaway314155 2y ago
    i never said we don't need it. just that not everyone should be expected to know it and you don't need it except in particular situations.
hinkley 2y ago
I haven't been able to read any brand of assembly since about 2010, and that was JVM not Intel. I still retained the 10000 foot view, and that mechanical sympathy has definitely helped me with fixing supposedly intractable performance issues with some regularity. Like a lot of things in education, there's an important distinction between learning something to use it, and learning it to appreciate or inform what you do with what we have now. Similarly there are processes we try to deploy 24/7 at work that I think would be better off being done for four weeks twice a year just to knock the cobwebs off of how we perform the job the rest of the year.

by wokkel 2y ago

throwaway314155 2y ago

[flagged]

fsloth 2y ago
I'm not sure what type of code you develop but it sure ain't the entirety of the real world. In my corner of the real world we are quite concerned about the difference between stack and heap and profile our applications to pinpoint any opportunities for optimization in e.g. heap allocations. Like, most of the world runs on puny chips, and if the chips are not puny, the workloads are still going to eat up battery and contend with all of the other crap running on the end users device.
- throwaway314155 2y ago
  sorry if i struck a nerve. i maintain that this is a domain specific skillset and that only specific types of coders really need that knowledge.
qsort 2y ago
I read comments like this all the time in all sorts of variants (we don't need math, we don't need CS theory, we don't need regexes, we don't need pointers). What do you people even do? Most of my work is with managed languages, but lower level concerns bubble up multiple times per project; you can't write great Python if you can't write decent C.
- throwaway314155 2y ago
  i never said we don't need it. just that not everyone should be expected to know it and you don't need it except in particular situations.

hinkley 2y ago

I haven't been able to read any brand of assembly since about 2010, and that was JVM not Intel. I still retained the 10000 foot view, and that mechanical sympathy has definitely helped me with fixing supposedly intractable performance issues with some regularity. Like a lot of things in education, there's an important distinction between learning something to use it, and learning it to appreciate or inform what you do with what we have now. Similarly there are processes we try to deploy 24/7 at work that I think would be better off being done for four weeks twice a year just to knock the cobwebs off of how we perform the job the rest of the year.