4 ms·

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 rea

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

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