On Thu, Jan 03, 2013 at 11:33:53AM -0700, Marcus G. Daniels wrote:
On 1/2/13 1:49 AM, Ondřej Bílka wrote:
A better example is that you have c code where at several places
is code for inserting element into sorted array and using that
array. What should you do. CS course taugth us to use
On Thu, Jan 03, 2013 at 01:07:55AM +0100, Loup Vaillant-David wrote:
On Tue, Jan 01, 2013 at 11:18:29PM +0100, Ondřej Bílka wrote:
On Tue, Jan 01, 2013 at 09:12:07PM +0100, Loup Vaillant-David wrote:
void latin1_to_utf8(std::string s);
Let me guess. They do it to save cycles
On 1/4/13 4:04 AM, Ondrej Bilka wrote:
Profiling will reveal that you spend 5% time in insert and 3% time in
remove. You spend two weeks optimizing your tree and memory allocator
for it.
The call tree, accumulating these costs in different parent contexts,
when correlated to the fact that
I have been looking at Datomic/Datalog which abstracts away the container
entirely and focuses simply on entity, attribute, value + time deltas. In
theory, the underlying container(s) could adjust to optimize for typical,
and possibly changing, usage patterns. Worth a look and some consideration
On Tue, Jan 01, 2013 at 04:57:05PM -0700, Marcus G. Daniels wrote:
On 1/1/13 3:18 PM, Ondřej Bílka wrote:
On opposite end of spectrum you have piece of haskell code where
everything is abstracted and each abstraction is wrong in some way
or another. Main reason of later is functional
On Tue, Jan 01, 2013 at 11:18:29PM +0100, Ondřej Bílka wrote:
On Tue, Jan 01, 2013 at 09:12:07PM +0100, Loup Vaillant-David wrote:
void latin1_to_utf8(std::string s);
Let me guess. They do it to save cycles caused by allocation of new
string.
instead of
std::string
On Mon, Dec 31, 2012 at 04:36:09PM -0700, Marcus G. Daniels wrote:
On 12/31/12 2:58 PM, Paul D. Fernhout wrote:
2. The programmer has a belief or preference that the code is easier
to work with if it isn't abstracted. […]
I have evidence for this poisonous belief. Here is some production
C++
On 1/1/2013 2:12 PM, Loup Vaillant-David wrote:
On Mon, Dec 31, 2012 at 04:36:09PM -0700, Marcus G. Daniels wrote:
On 12/31/12 2:58 PM, Paul D. Fernhout wrote:
2. The programmer has a belief or preference that the code is easier
to work with if it isn't abstracted. […]
I have evidence for this
On Tue, Jan 01, 2013 at 03:02:09PM -0600, BGB wrote:
On 1/1/2013 2:12 PM, Loup Vaillant-David wrote:
On Mon, Dec 31, 2012 at 04:36:09PM -0700, Marcus G. Daniels wrote:
On 12/31/12 2:58 PM, Paul D. Fernhout wrote:
2. The programmer has a belief or preference that the code is easier
to work
On Tue, Jan 01, 2013 at 09:12:07PM +0100, Loup Vaillant-David wrote:
On Mon, Dec 31, 2012 at 04:36:09PM -0700, Marcus G. Daniels wrote:
On 12/31/12 2:58 PM, Paul D. Fernhout wrote:
2. The programmer has a belief or preference that the code is easier
to work with if it isn't abstracted. […]
On 1/1/13 4:29 PM, Loup Vaillant-David wrote:
On Tue, Jan 01, 2013 at 03:02:09PM -0600, BGB wrote:
it is a question maybe of whether the programmer sees the forest or
the trees.
these sorts of things may well have an impact on the types of code a
person writes, and what sorts of things the
On 12/31/12 1:39 PM, Marcus G. Daniels wrote:
Of course, there is rarely the time or incentive structure to do any of
this. Productive programmers are the ones that get results and are fast
at fixing (and creating) bugs. In critical systems, at least, that's
the wrong incentive structure. In
On 12/31/12 2:58 PM, Paul D. Fernhout wrote:
Unless you know what to look for (and even sometimes if you do), it is
hard to tell whether a programmer spending a month or two refactoring
or writing tests is making the system better, or making the system
worse, or maybe just is not doing much at
On 12/31/12 6:36 PM, Marcus G. Daniels wrote:
2. The programmer has a belief or preference that the code is easier to
work with if it isn't abstracted.
It's all right in front of them in the context they want it. Perhaps
they are copying the code from foreign modules they don't maintain and
14 matches
Mail list logo
