If you want art and engineering in programming, think of the way architects bring art to the world's most impressive buildings and bridges. It doesn't count if the bridge falls down.
Similarly, your program can't ignore "memory and runtime".
If you want art and engineering in programming, think of the way architects bring art to the world's most impressive buildings and bridges. It doesn't count if the bridge falls down.
Similarly, your program can't ignore "memory and runtime".
Interestingly, the architects have structural engineers and all sorts of other engineering professionals to help them make sure the building, bridge or whatever will not fall down.
Perhaps that's the problem with software development. We still want the coolest fancy looking bridges that span miles, but we haven't quite figured out how to get the artist-programmers and the engineer-programmers working together.
Pair programming.
Alternatively, I would say that we actually have. I believe that the Artist-programmer is most concerned with the expressiveness of the code, wheras the engineer-programmer is concerned with the efficiency and stability (of course there is overlap/cross-pollination.) The artist-programmers work at the problem domain level, and the engineer-programmers work at the systems/implementation level. Apache/MySQL/Sphinx written by engineer-programmers, Sinatra apps written by artist-programmers.
Maybe best not to look at contemporary architecture as a model.