←back to thread

We're not innovating, we're just forgetting slower

(www.elektormagazine.com)
139 points obscurette | 4 comments | 04 Jul 25 14:13 UTC | HN request time: 1.422s | source
Show context
raincole ◴[04 Jul 25 16:04 UTC] No.44465682[source]▶
> They can deploy applications to Kubernetes clusters but couldn’t design a simple op-amp circuit

And the ones who can design a op-amp circuit can't manufacture the laminate their circuit is going to be printed on. And the ones who know how to manufacture the laminate probably doesn't know how to refine or synthesize the material from the minerals. And probably none of them knows how to grow and fertilize the crop to feed themselves.

No one knows everything. Collaboration has been how we manage complexity since we were biologically a different species than H. sapiens.

replies(14): >>44465734 #>>44465874 #>>44465898 #>>44465912 #>>44465979 #>>44466012 #>>44466026 #>>44466117 #>>44466133 #>>44466193 #>>44466238 #>>44466369 #>>44466940 #>>44468200 #
jjmarr ◴[04 Jul 25 16:46 UTC] No.44466012[source]▶
I can design a simple op-amp circuit and deploy to a Kubernetes cluster because Canada has a "Computer Engineering" degree that's a hybrid between CS/Electrical Engineering.

It doesn't work in practice. CS graduates from my school are trained on git and Linux command lines. CE teaches none of this and students discover in 3rd year they cannot get an internship because they share all their code as IDE screenshots in Google Docs.

But we do know how the entire process of building a computer works, from quantum physics, semiconductor doping, npn junctions, CMOS logic, logic gates, hardware design languages, assembly, C, and Java.

If only all of this "important" knowledge didn't crowd out basic skills.

replies(2): >>44466148 #>>44466656 #
1. bee_rider ◴[04 Jul 25 17:04 UTC] No.44466148[source]▶
I think designing the EE and computer engineering curriculum is pretty tough. Because:

* the EE’s need to learn matlab or numpy, to use as a tool

* so do the computer engineering students, probably

* the computer engineering students also need to learn low level stuff, because they might reasonably end up writing drivers or embedded code

* separating out what should be in which classes is kind of tricky; keeping in mind that the students don’t necessarily know anything about programming at all, you probably need some kind of “intro to the general idea of programming” class

* realistically when they start the program they don’t know much about what the jobs look like, so it is good if they are able to switch paths, for the first couple years

* realistically a lot of people just want to get a stem degree and then go be a programmer anyway

replies(2): >>44466211 #>>44470588 #
2. WillAdams ◴[04 Jul 25 17:11 UTC] No.44466211[source]▶
Time was that this sort of thing was covered in courses such as:

https://ocw.mit.edu/courses/6-001-structure-and-interpretati...

but they've since switched to Python for reasons:

https://irreal.org/blog/?p=2331

replies(1): >>44468916 #
3. bee_rider ◴[04 Jul 25 23:41 UTC] No.44468916[source]▶
I think you can teach this sort of class, in Python. Just using the basic syntax of Python, which is essentially pseudocode. The main danger, I think, is that it would involve doing lots of things in a non-pythonic way, which could confuse the students if they went on to write Python for real.
4. jjmarr ◴[05 Jul 25 06:42 UTC] No.44470588[source]▶
We do basic C, basic-medium Java, Python for signals analysis, and somewhat advanced design patterns. Tons of UML.

The misses remind me of technical debt vs shiny features. I wrote embedded assembly and did a bunch of labs on them. But due to time constraints and difficulty, I didn't go into much detail on interrupt-based programming. And our OS course focused more on rote memorization of concepts such as locks/mutexes/semaphores/deadlock avoidance algorithms/memory management.

But there's little detail on why I might use Linux syscalls over libc.