4 ms·

I don't think the adage needs revising. We just need to remember that it applies to programming language users, not programming language writers. The whole idea

I don't think the adage needs revising. We just need to remember that it applies to programming language users, not programming language writers. The whole idea is that the writers of your programming language should be doing most of the optimizing for you by making sure the language's primitives are already well-optimized for common tasks.

sreque 10y ago
This fallacy props up surprisingly often. We should not treat programming language writers as a separate class of people from programming language users. We often have the same needs and require the same solutions. My Master's adviser joked that every company ends up implementing their very own ad hoc, poorly designed programming languages to meet their specific needs. After working in the industry for almost a decade I've seen the truth of this joke. A lot of the problem comes from the kind of thinking that would say "this adage applies to programming language writers, not users."
kickscondor 10y ago
Sure, I think what a programmer is building may allow for ignorance of performance - a microservice may be so short-lived and its memory usage so small that it all fits into 32k anyway. No point optimizing. But think about mobile developers. You aim to paint 60 times per second. If Swift doesn't give you any tools for ensuring a specific memory layout - I imagine it does, by having some kind of contiguous array of structs - then how do you optimize those heavily trodden pathways of your app that could really use keeping a certain array within that 32k? This applies to WebGL developers, too. It seems like I've seen code where folks were using arrays of integers to achieve data locality - using a kind of serialization almost to pack and unpack from this array - alas I can't seem to recall where I saw that.

4 ms·

I don't think the adage needs revising. We just need to remember that it applies to programming language users, not programming language writers. The whole idea

by rcthompson 10y ago

sreque 10y ago
This fallacy props up surprisingly often. We should not treat programming language writers as a separate class of people from programming language users. We often have the same needs and require the same solutions. My Master's adviser joked that every company ends up implementing their very own ad hoc, poorly designed programming languages to meet their specific needs. After working in the industry for almost a decade I've seen the truth of this joke. A lot of the problem comes from the kind of thinking that would say "this adage applies to programming language writers, not users."
kickscondor 10y ago
Sure, I think what a programmer is building may allow for ignorance of performance - a microservice may be so short-lived and its memory usage so small that it all fits into 32k anyway. No point optimizing. But think about mobile developers. You aim to paint 60 times per second. If Swift doesn't give you any tools for ensuring a specific memory layout - I imagine it does, by having some kind of contiguous array of structs - then how do you optimize those heavily trodden pathways of your app that could really use keeping a certain array within that 32k? This applies to WebGL developers, too. It seems like I've seen code where folks were using arrays of integers to achieve data locality - using a kind of serialization almost to pack and unpack from this array - alas I can't seem to recall where I saw that.