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 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 (presu
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 s
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 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 red-black tree there.
Right? Well not exactly. When one looks how is this
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::s
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 fix
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 prog
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 fixedness. A haskell
programmer will see a structure as a monad but then does
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 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
> >>
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 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 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
don't
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 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 t
16 matches
Mail list logo