3 ms·

I come from an EE background, so I learned C and studied various aspects of computer hardware and computer architecture to some relative level of detail before

by austinz 13y ago

I come from an EE background, so I learned C and studied various aspects of computer hardware and computer architecture to some relative level of detail before doing any sort of algorithms or software design. Sometimes I wonder what sort of software engineer I'd be if I had gone the other way - studied CS to start off and then descended down the stack later on. Would I be better? Worse? How would I think about problems, and what mental models would I go for first?

erichocean 13y ago
I've wondered the same, but in the reverse direction: by the time I started programming, I had read—not kidding—thousands of papers on computer science, and read hundreds of books. I just had no interest in coding. (Or math for that matter, though ironically, I also read math books.) Anyway, I've always wondered if I'm a better or worse CTO for having taken that route. I do know I code much less than my peers, even though (it seems to me) I get much better results with far less coding effort.
- erichocean 13y ago
  I'm not sure why, but this comment stuck with me and I kept thinking about it. Here's an example of where I think learning CS, then programming, helped. I had written my own JavaScript application framework, called Blossom[0], and I wanted "real physics". I took a look at the various 2D physics ports that had been made to JavaScript, and they all had pretty bad performance. Also, I knew from my work as a filmmaker that "real physics" is actually a pain in the ass, because what you actually want is directable physics that feel real. (Stick with me, I'm getting there...) So, I took a step back and determined that what I wanted was to be able to use tween curves like normal, but have the actual path that was taken depend on the velocity and/or acceleration of the movement when the user released their finger, yet be "directed" according to the tween curve. That required doing math, specifically, getting first and second derivatives from your tween curves. Yuck. Except, CS to the rescue, there are these things called Dual numbers[1], and when you use them, you get automatic differentiation[2] for free, without having to rewrite your code. So I wrote a Dual number implementation for JavaScript, grabbed a JS parser and rewrote the tween functions at load time (i.e. with code, automatically) to use the Dual numbers so that I could extract the velocity and acceleration. I then took the original curve based on the user's movement, blended it with the tween derivatives, and the resulting animations were actually really great. The whole thing was efficient enough to get real time performance on an iPad 3 in mobile Safari, entirely in JavaScript. And the total time from start of work to the physics-based Dual-number tween animations in Blossom? Two days, and about 2K LOC. If I hadn't know about Dual numbers, there's no way I'd have gotten there just by sitting down and programming, and who knows how long it took the FB team to do the dynamics for FB Home, or the Apple team to add UI Dynamics to iOS 7. My guess is that it took longer than two days... [0] https://github.com/erichocean/blossom https://github.com/erichocean/blossom [1] http://en.wikipedia.org/wiki/Dual_number http://en.wikipedia.org/wiki/Dual_number [2] http://en.wikipedia.org/wiki/Automatic_differentiation http://en.wikipedia.org/wiki/Automatic_differentiation
userbinator 13y ago
In my experience those who start bottom-up tend to have a lot more practical sense of how computers work, and thus write simpler, more efficient code than those who went in the other direction; the latter tend to overuse abstraction and create elaborate architectures that result in writing far more code and generating more complexity than is really needed.

by austinz 13y ago

erichocean 13y ago

I've wondered the same, but in the reverse direction: by the time I started programming, I had read—not kidding—thousands of papers on computer science, and read hundreds of books. I just had no interest in coding. (Or math for that matter, though ironically, I also read math books.) Anyway, I've always wondered if I'm a better or worse CTO for having taken that route. I do know I code much less than my peers, even though (it seems to me) I get much better results with far less coding effort.

erichocean 13y ago
I'm not sure why, but this comment stuck with me and I kept thinking about it. Here's an example of where I think learning CS, then programming, helped. I had written my own JavaScript application framework, called Blossom[0], and I wanted "real physics". I took a look at the various 2D physics ports that had been made to JavaScript, and they all had pretty bad performance. Also, I knew from my work as a filmmaker that "real physics" is actually a pain in the ass, because what you actually want is directable physics that feel real. (Stick with me, I'm getting there...) So, I took a step back and determined that what I wanted was to be able to use tween curves like normal, but have the actual path that was taken depend on the velocity and/or acceleration of the movement when the user released their finger, yet be "directed" according to the tween curve. That required doing math, specifically, getting first and second derivatives from your tween curves. Yuck. Except, CS to the rescue, there are these things called Dual numbers[1], and when you use them, you get automatic differentiation[2] for free, without having to rewrite your code. So I wrote a Dual number implementation for JavaScript, grabbed a JS parser and rewrote the tween functions at load time (i.e. with code, automatically) to use the Dual numbers so that I could extract the velocity and acceleration. I then took the original curve based on the user's movement, blended it with the tween derivatives, and the resulting animations were actually really great. The whole thing was efficient enough to get real time performance on an iPad 3 in mobile Safari, entirely in JavaScript. And the total time from start of work to the physics-based Dual-number tween animations in Blossom? Two days, and about 2K LOC. If I hadn't know about Dual numbers, there's no way I'd have gotten there just by sitting down and programming, and who knows how long it took the FB team to do the dynamics for FB Home, or the Apple team to add UI Dynamics to iOS 7. My guess is that it took longer than two days... [0] https://github.com/erichocean/blossom https://github.com/erichocean/blossom [1] http://en.wikipedia.org/wiki/Dual_number http://en.wikipedia.org/wiki/Dual_number [2] http://en.wikipedia.org/wiki/Automatic_differentiation http://en.wikipedia.org/wiki/Automatic_differentiation

userbinator 13y ago

In my experience those who start bottom-up tend to have a lot more practical sense of how computers work, and thus write simpler, more efficient code than those who went in the other direction; the latter tend to overuse abstraction and create elaborate architectures that result in writing far more code and generating more complexity than is really needed.