Re: the perfect abstraction level

On Fri, Mar 25, 2011 at 4:00 AM, Matthew Pocock
wrote:
> On 24 March 2011 20:23, Vlad Patryshev wrote:
>>
>> This code also demonstrates a very interesting way of thinking.
>> case Yes => true; case No => false
>
> yeah, it does
>
>>
>> My question actually is: why do people prefer the kind of code that
>> you wrote? Is it more readable, more clear, less (or more) abstract?
>>
>
>
> Code is as much about communicating to people (yourself, future maintainers)
> than it is about communicating to the machine. If all we cared about was
> telling the machine what to do, we'd speak binary at it. Code becomes easier
> to understand if it appears to communicate to us using concepts that we
> already work with.
> So, although in your case Yes and No are isomorphic with, and could be
> substituted by truth values, the code maintains a semantic (ontological?)
> distinction between the domain of discourse and the domain of logic.
> Replacing Yes and No with booleans would retain the formal correctness but
> would require the reader to infer the ontological semantics. Discourse is
> modelled here as natural-language sentences that you agree with (Yes) or
> disagree with (No). This maintains a clear distinction for the reader
> between these things that people are meant to make a value-judgement about
> to undertand and think about, and the components such as 'match' and 'false'
> that are part of the 'host' language.
> Or something like that.

I think the "something" is that Rex wrote 5 chunks of nice readable
"flowchart" (his word), not code, that used conditions Yes/Yes
if/Maybe/No -- I'm pretty sure that "Maybe" is not a boolean value --
and to turn just the one chunk that happened to be of the form Yes =>
true and No => false into a boolean expression would be so so wrong in
every way.

I'm curious now to see the opinions of the pro-early-abstraction camp on a specific scenario.
I'm (hypothetically) building an application for the iPhone, but know that it's also going to be usable on the iPad.
Should I write my layout/UI logic to completely abstract over the screen resolution, handling all my graphics using vector formats and scaling as necessary, or should I first design for the iPhone 4 resolution using bitmaps and absolute layout?
The absolute layout approach is certainly easier to write and test, and I don't have to worry about different DPIs, correct font sizes, etc.  Once it looks right I know I'm done.  But... I then have to redo all the artwork for the iPad, though the iOS platform at least guarantees all resolutions will be integer multiples and provides scaling to help out here.
On the other hand, things get *really* messy if I then port to android with its multitude of resolutions, where it probably would have been easier to start with dynamic layout if I'm not to limit target devices.
Note that this isn't about abstracting functions, or abstracting objects, but about design/architecture principles in general, and I think that this is the kind of thing that the OP had in mind...


So, do I start with a specific solution, or do I begin with abstraction?


On 25 March 2011 11:17, Jim Balter <Jim@balter.name> wrote:

On Fri, Mar 25, 2011 at 4:00 AM, Matthew Pocock
<turingatemyhamster@gmail.com> wrote:
> On 24 March 2011 20:23, Vlad Patryshev <vpatryshev@gmail.com> wrote:
>>
>> This code also demonstrates a very interesting way of thinking.
>> case Yes => true; case No => false
>
> yeah, it does
>
>>
>> My question actually is: why do people prefer the kind of code that
>> you wrote? Is it more readable, more clear, less (or more) abstract?
>>
>
>
> Code is as much about communicating to people (yourself, future maintainers)
> than it is about communicating to the machine. If all we cared about was
> telling the machine what to do, we'd speak binary at it. Code becomes easier
> to understand if it appears to communicate to us using concepts that we
> already work with.
> So, although in your case Yes and No are isomorphic with, and could be
> substituted by truth values, the code maintains a semantic (ontological?)
> distinction between the domain of discourse and the domain of logic.
> Replacing Yes and No with booleans would retain the formal correctness but
> would require the reader to infer the ontological semantics. Discourse is
> modelled here as natural-language sentences that you agree with (Yes) or
> disagree with (No). This maintains a clear distinction for the reader
> between these things that people are meant to make a value-judgement about
> to undertand and think about, and the components such as 'match' and 'false'
> that are part of the 'host' language.
> Or something like that.

I think the "something" is that Rex wrote 5 chunks of nice readable
"flowchart" (his word), not code, that used conditions Yes/Yes
if/Maybe/No -- I'm pretty sure that "Maybe" is not a boolean value --
and to turn just the one chunk that happened to be of the form Yes =>
true and No => false into a boolean expression would be so so wrong in
every way.

the two options you propose are "specific layout" vs "dynamic layout". the dynamic one is more powerful, the specific one is simpler, but as a member of the pro-early-abstraction-camp, i'd choose a whole different option:
i'd write my api in such a way that i simply don't have to care about how the components will be rendered. *that* is abstraction. i can plug in bitmap or vector rendering later as i see fit. that decision cannot be made hypothetically, i'd need hard numbers and estimations for that.

-------- Original-Nachricht --------
> Datum: Fri, 25 Mar 2011 12:38:05 +0000
> Von: Kevin Wright
> An: Jim Balter
> CC: Matthew Pocock , Vlad Patryshev , Rex Kerr , HamsterofDeath , "scala-user@googlegroups.com"
> Betreff: Re: [scala-user] the perfect abstraction level

> I'm curious now to see the opinions of the pro-early-abstraction camp on a
> specific scenario.
>
> I'm (hypothetically) building an application for the iPhone, but know that
> it's also going to be usable on the iPad.
>
> Should I write my layout/UI logic to completely abstract over the screen
> resolution, handling all my graphics using vector formats and scaling as
> necessary, or should I first design for the iPhone 4 resolution using
> bitmaps and absolute layout?
>
> The absolute layout approach is certainly easier to write and test, and I
> don't have to worry about different DPIs, correct font sizes, etc. Once
> it
> looks right I know I'm done. But... I then have to redo all the artwork
> for
> the iPad, though the iOS platform at least guarantees all resolutions will
> be integer multiples and provides scaling to help out here.
>
> On the other hand, things get *really* messy if I then port to android
> with
> its multitude of resolutions, where it probably would have been easier to
> start with dynamic layout if I'm not to limit target devices.
>
> Note that this isn't about abstracting functions, or abstracting objects,
> but about design/architecture principles in general, and I think that this
> is the kind of thing that the OP had in mind...
>
>
> So, do I start with a specific solution, or do I begin with abstraction?
>
>
>
> On 25 March 2011 11:17, Jim Balter wrote:
>
> > On Fri, Mar 25, 2011 at 4:00 AM, Matthew Pocock
> > wrote:
> > > On 24 March 2011 20:23, Vlad Patryshev wrote:
> > >>
> > >> This code also demonstrates a very interesting way of thinking.
> > >> case Yes => true; case No => false
> > >
> > > yeah, it does
> > >
> > >>
> > >> My question actually is: why do people prefer the kind of code that
> > >> you wrote? Is it more readable, more clear, less (or more) abstract?
> > >>
> > >
> > >
> > > Code is as much about communicating to people (yourself, future
> > maintainers)
> > > than it is about communicating to the machine. If all we cared about
> was
> > > telling the machine what to do, we'd speak binary at it. Code becomes
> > easier
> > > to understand if it appears to communicate to us using concepts that
> we
> > > already work with.
> > > So, although in your case Yes and No are isomorphic with, and could be
> > > substituted by truth values, the code maintains a semantic
> (ontological?)
> > > distinction between the domain of discourse and the domain of logic.
> > > Replacing Yes and No with booleans would retain the formal correctness
> > but
> > > would require the reader to infer the ontological semantics. Discourse
> is
> > > modelled here as natural-language sentences that you agree with (Yes)
> or
> > > disagree with (No). This maintains a clear distinction for the reader
> > > between these things that people are meant to make a value-judgement
> > about
> > > to undertand and think about, and the components such as 'match' and
> > 'false'
> > > that are part of the 'host' language.
> > > Or something like that.
> >
> > I think the "something" is that Rex wrote 5 chunks of nice readable
> > "flowchart" (his word), not code, that used conditions Yes/Yes
> > if/Maybe/No -- I'm pretty sure that "Maybe" is not a boolean value --
> > and to turn just the one chunk that happened to be of the form Yes =>
> > true and No => false into a boolean expression would be so so wrong in
> > every way.
> >
> > -- Jim
> >
>
>
>

On Fri, Mar 25, 2011 at 7:17 AM, Jim Balter <Jim@balter.name> wrote:

On Fri, Mar 25, 2011 at 4:00 AM, Matthew Pocock
<turingatemyhamster@gmail.com> wrote:
> This maintains a clear distinction for the reader
> between these things that people are meant to make a value-judgement about
> to undertand and think about, and the components such as 'match' and 'false'
> that are part of the 'host' language.
> Or something like that.

I think the "something" is that Rex wrote 5 chunks of nice readable
"flowchart" (his word), not code, that used conditions Yes/Yes
if/Maybe/No -- I'm pretty sure that "Maybe" is not a boolean value

Exactly.  I was mapping from something which is more rich than a boolean into a boolean.

Matthew is also correct in that you have to make value judgments to move from the first to the second, and I wanted to highlight that.

  --Rex

> -----Original Message-----
> From: scala-user@googlegroups.com [mailto:scala-user@googlegroups.com]
> On Behalf Of Kevin Wright
> Sent: Friday, March 25, 2011 1:38 PM
> To: Jim Balter
> Cc: Matthew Pocock; Vlad Patryshev; Rex Kerr; HamsterofDeath; scala-
> user@googlegroups.com
> Subject: Re: [scala-user] the perfect abstraction level
>
> I'm curious now to see the opinions of the pro-early-abstraction camp
> on a specific scenario.
>
> I'm (hypothetically) building an application for the iPhone, but know
> that it's also going to be usable on the iPad.

I'm curious to hear the opinions about this being 'abstraction'
vs. generalization vs. decoupling.

That is, to my eyes it seems that your question involves architectural
decisions that are mostly not on the line of more abstract / less abstract,
but losely coupled / straight coupled and pluggable/extendable/configurable
vs fully hard coded.

So when designing resp. implementing your system, you could and should
always bare in mind that the UI part of it could once be changed, even
if you now start with a fix iPhone 4 set.

The 'abstraction' in the end is not a property of the whole system, but
of the reusable parts of it resp. the interfaces where the parts exchange.

Abstraction in the sense of e.g. being gracious at the input params can become
such a common style in daily work that you do not think much about it, so
you do not have to meditate over every method if it should abstract over things
or not. With more and more training you are writing in a more and more abstract
style. And so your product becomes automatically more reusable, configurable,
extendable a.s.o.

I think that is what the pro-early-abstraction camp is about:
Do it so it can become more and more second nature.

Again: The decision to write your UI in an absolute or dynamic layout
style is disjunct from the decision to use more and more abstractions
in the system as a whole.

Just my 2ct
Det

On Thu, Mar 24, 2011 at 4:55 PM, HamsterofDeath <h-star@gmx.de> wrote:

Am 24.03.2011 20:38, schrieb Rex Kerr:

Too much abstraction is a distraction--you have to burrow down through the layers of abstraction before you actually get to do anything.  So I don't start very high level.

that one i cannot follow. can you provide an example?

Sure:

"Add up all the account balances, please!"

My job is to add up all of the account balances, which are decimal numbers with two entries after the decimal point, and appear after the first tab character on each line of the file accounts.txt

My job is to add up all the numbers, which are rationals, in the second column of a text file.

My job is to reduce a sequence of elements from an additive abelian group, with elements obtained at one index of an indexed data structure which needs to be condensed from an input data structure obtained with file i/o.

My job is to reduce a sequence of elements of a magma using its operation; the sequence is obtained, when possible, by application of two functions ("file i/o" and "extraction of magma elements") whose domain may not encompass the input.
 

i've seen some attempts to solve more than the problems at hand at a higher level which led to lots of additional complexity at the lower levels, but i've never seen a high level design fail that focused at the actual problem, no matter how far it was abstracted away. there always was a "natural limit". if you have an example, i can show you what i mean.

If someone asks for a sum of account balances and you immediately start thinking that "reduce" is a universally defined operation on a sequence taken from a magma (also called a groupoid; basically just a set M with an injective mapping from M x M -> M), then you're wasting your time.  The properties you rely upon in order to create your sum are perfectly adequately understood at the level of fixed-point math.

But you can't get there starting from the top; you have to work bottom-up to know where to stop with the abstraction--where even though the abstraction _is_ perfectly targeted at your problem, you have only _one_ such problem and it's adequately understood at a less abstract level, so you quit looking for wider generalizations.

And the adding-numbers example is also a case where you need to go in both directions, but just a little.  It's helpful to step up _one_ level and realize that you want to add rationals, and then step down to implementation and realize that the most natural thing to do would be to use doubles, which may have errors; then you have to consider whether they're a sufficiently good approximation.

  --Rex

P.S. I think this also answers Tony's claim that there's no such thing as too much abstraction, unless he's defining abstraction in such a way that you can't have too much of it by definition.  The most common problems are _too little abstraction_ or _faulty attempts at abstraction_, but _too much_ is also possible since it forces you to keep track of distinctions in properties of things that do not affect your problem (e.g. who cares about the distinction between a magma or a monoid when you are always going to be using an abelian group?).

P.P.S. Reducing an empty monoid sequence has a natural interpretation as a fold starting with the identity; magma sequences do not allow this interpretation since they do not have an identity.

Am 25.03.2011 15:08, schrieb Rex Kerr:

EuvJyBTkd [at] mail [dot] gmail [dot] com" type="cite"> On Thu, Mar 24, 2011 at 4:55 PM, HamsterofDeath <h-star [at] gmx [dot] de" rel="nofollow">h-star@gmx.de> wrote:

Am 24.03.2011 20:38, schrieb Rex Kerr:

Too much abstraction is a distraction--you have to burrow down through the layers of abstraction before you actually get to do anything.  So I don't start very high level.

that one i cannot follow. can you provide an example?

Sure:

"Add up all the account balances, please!"

My job is to add up all of the account balances, which are decimal numbers with two entries after the decimal point, and appear after the first tab character on each line of the file accounts.txt

My job is to add up all the numbers, which are rationals, in the second column of a text file.

My job is to reduce a sequence of elements from an additive abelian group, with elements obtained at one index of an indexed data structure which needs to be condensed from an input data structure obtained with file i/o.

My job is to reduce a sequence of elements of a magma using its operation; the sequence is obtained, when possible, by application of two functions ("file i/o" and "extraction of magma elements") whose domain may not encompass the input.

isn't that upside down? the first one is perfectly abstracted ("what-level", no word about how to handle the details) , the next ones are more concrete ("how-level"), the last one is some wtf that just happens to be able to solve the given problem "by accident" while introducing more complexity.
going higher on the abstraction should make things simpler.

EuvJyBTkd [at] mail [dot] gmail [dot] com" type="cite">  

i've seen some attempts to solve more than the problems at hand at a higher level which led to lots of additional complexity at the lower levels, but i've never seen a high level design fail that focused at the actual problem, no matter how far it was abstracted away. there always was a "natural limit". if you have an example, i can show you what i mean.

If someone asks for a sum of account balances and you immediately start thinking that "reduce" is a universally defined operation on a sequence taken from a magma (also called a groupoid; basically just a set M with an injective mapping from M x M -> M), then you're wasting your time.  The properties you rely upon in order to create your sum are perfectly adequately understood at the level of fixed-point math.

But you can't get there starting from the top; you have to work bottom-up to know where to stop with the abstraction--where even though the abstraction _is_ perfectly targeted at your problem, you have only _one_ such problem and it's adequately understood at a less abstract level, so you quit looking for wider generalizations.

And the adding-numbers example is also a case where you need to go in both directions, but just a little.  It's helpful to step up _one_ level and realize that you want to add rationals, and then step down to implementation and realize that the most natural thing to do would be to use doubles, which may have errors; then you have to consider whether they're a sufficiently good approximation.

  --Rex

P.S. I think this also answers Tony's claim that there's no such thing as too much abstraction, unless he's defining abstraction in such a way that you can't have too much of it by definition.  The most common problems are _too little abstraction_ or _faulty attempts at abstraction_, but _too much_ is also possible since it forces you to keep track of distinctions in properties of things that do not affect your problem (e.g. who cares about the distinction between a magma or a monoid when you are always going to be using an abelian group?).

P.P.S. Reducing an empty monoid sequence has a natural interpretation as a fold starting with the identity; magma sequences do not allow this interpretation since they do not have an identity.

On Fri, Mar 25, 2011 at 3:15 PM, HamsterofDeath <h-star@gmx.de> wrote:

Am 25.03.2011 15:08, schrieb Rex Kerr:

On Thu, Mar 24, 2011 at 4:55 PM, HamsterofDeath <h-star@gmx.de> wrote:

Am 24.03.2011 20:38, schrieb Rex Kerr:

"Add up all the account balances, please!"

My job is to add up all of the account balances, which are decimal numbers with two entries after the decimal point, and appear after the first tab character on each line of the file accounts.txt

My job is to add up all the numbers, which are rationals, in the second column of a text file.

My job is to reduce a sequence of elements from an additive abelian group, with elements obtained at one index of an indexed data structure which needs to be condensed from an input data structure obtained with file i/o.

My job is to reduce a sequence of elements of a magma using its operation; the sequence is obtained, when possible, by application of two functions ("file i/o" and "extraction of magma elements") whose domain may not encompass the input.

isn't that upside down? the first one is perfectly abstracted ("what-level", no word about how to handle the details) , the next ones are more concrete ("how-level"), the last one is some wtf that just happens to be able to solve the given problem "by accident" while introducing more complexity.
going higher on the abstraction should make things simpler.

How can you use that as part of your high-level design, though?

Of course, if you don't have a description of your problem, you're going to have trouble solving it.  But even then, abstraction is not always useful:

  "Compute stuff from account balances."
  "Compute stuff from stuff."
  "Do stuff."

It seems to me that you're taking something for granted about the right level of abstraction, but I'm not sure exactly what is being taken for granted.  Maybe if you supply an example it would clarify how it applies to software design / programming?

 --Rex

the "perfect abstraction level" is reached when the following conditions are met from the current viewpoint:
1 (of one). it is known what has to be done, all components are defined.

in your example, both "account balance" and "add up" have to be defined. what hides inside the definition of "account balance" (like: it's a CSV-file) or "add up" (precision and so on) is completely irrelevant for designing the class that handles the adding:

object AccountBalanceAdder {
   def addUp(balances:Traversable[AccountBalance]) = balances.reduce(_ + _)
}

the "how to add up two balances" is hidden inside the method "+". no need to know what exactly a balance is. it's defined and offers a "+"-method, that's all that matters.
the "how to add up n balances" is hidden inside the method "addUp", which is based on "add up 2 balances". no need to know if we're adding natural numbers, doubles, bigdecimals or some alien number thingy.

Am 25.03.2011 20:43, schrieb Rex Kerr:

XWWNdYu9d0aPwsOC5Zxd-vve3i [at] mail [dot] gmail [dot] com" type="cite">

On Fri, Mar 25, 2011 at 3:15 PM, HamsterofDeath <h-star [at] gmx [dot] de" rel="nofollow">h-star@gmx.de> wrote:

Am 25.03.2011 15:08, schrieb Rex Kerr:

On Thu, Mar 24, 2011 at 4:55 PM, HamsterofDeath <h-star [at] gmx [dot] de" target="_blank" rel="nofollow">h-star@gmx.de> wrote:

Am 24.03.2011 20:38, schrieb Rex Kerr:

"Add up all the account balances, please!"

My job is to add up all of the account balances, which are decimal numbers with two entries after the decimal point, and appear after the first tab character on each line of the file accounts.txt

My job is to add up all the numbers, which are rationals, in the second column of a text file.

My job is to reduce a sequence of elements from an additive abelian group, with elements obtained at one index of an indexed data structure which needs to be condensed from an input data structure obtained with file i/o.

My job is to reduce a sequence of elements of a magma using its operation; the sequence is obtained, when possible, by application of two functions ("file i/o" and "extraction of magma elements") whose domain may not encompass the input.

isn't that upside down? the first one is perfectly abstracted ("what-level", no word about how to handle the details) , the next ones are more concrete ("how-level"), the last one is some wtf that just happens to be able to solve the given problem "by accident" while introducing more complexity.
going higher on the abstraction should make things simpler.

How can you use that as part of your high-level design, though?

Of course, if you don't have a description of your problem, you're going to have trouble solving it.  But even then, abstraction is not always useful:

  "Compute stuff from account balances."
  "Compute stuff from stuff."
  "Do stuff."

these three lines are equal. "do" means "compute" and "stuff" means "the sum of balances". there is no further abstraction possible. the end is reached. you need at least one "what to do" and one "apply to what"

XWWNdYu9d0aPwsOC5Zxd-vve3i [at] mail [dot] gmail [dot] com" type="cite">
It seems to me that you're taking something for granted about the right level of abstraction, but I'm not sure exactly what is being taken for granted.  Maybe if you supply an example it would clarify how it applies to software design / programming?

 --Rex

In addition, while we can't talk about the disadvantages of abstraction,
since there aren't any, we can talk about the advantages, since there
are many.

To get started exploring these, I highly recommend the paper, Free
Theorems, by Philip Wadler.

On 25/03/11 10:45, Tony Morris wrote:
> Yes, I understand this point of view and I even do this (specialise
> first) myself sometimes.
>
> However, abstracting first often (more often) gives a better result. A
> classic example of this in Haskell (or anywhere controlling effects, see
> below) is writing your functions in a monadic style (abstracted), making
> it possible to use in IO, however, having not been specialised to IO, it
> is not possible that they are using IO. Let me clarify.
>
> I will try to use Scala notation -- assume IO like Runar describes on
> his iteratee blog post. Suppose this function:
>
> def filterM[M[_], A](p: A => M[Boolean], as: List[A])(implicit m:
> Monad[M]): M[List[A]]
>
> While it is possible to use this function in IO (that is, there is an
> implicit Monad[IO] defined), I know for a fact that this function itself
> does not use IO -- it's simply impossible. And I know this because it is
> abstracted.
>
> So while I may be struggling to define the overall problem, I can say
> certain things to myself about my progress on solving it as a result of
> having abstracted.
>
> On 25/03/11 10:36, Josh Suereth wrote:
>> Tony -
>>
>> When I refer to excessive abstraction, it usually refers to when
>> someone has tried to create one or more layers of abstraction which do
>> not appropriately solve the domain in which they are in.
>>
>> That is, someone is writing an abstraction for calculating statistics
>> and makes a few assumptions about this domain which are inherently
>> untrue. At the time they wrote the asbtraction, those assumptions
>> seemed valid, but it was from a poor understanding of the domain.
>> The abstraction level becomes crippled and falls apart during the
>> course of code maintenance.
>>
>> To ensure the safest possible abstraction-level design, I take the
>> same approach Kevin mentioned of not abstracting until I feel
>> confident I can see enough of the problem domain to create an
>> abstraction. Either that or someone else has done the work for me
>> and I can pull it in (a.la scalaz). These abstractions
>> need to be constantly pruned to ensure they really do solve the domain
>> intended.
>>
>> Either that, or the domain needs to be split.
>>
>> That is my argument about excessive abstraction. One can try to
>> abstract too fast with insufficient knowledge and bungle the whole
>> project. This is of course worse when the person creating these
>> ignores the warnings from team members that their current view of the
>> problem domain is not complete.
>>
>>
>> - Josh
>>
>> On Thu, Mar 24, 2011 at 8:24 PM, Tony Morris > > wrote:
>>
>> On 25/03/11 09:39, Paul Butcher wrote:
>> > What am I missing?
>> >
>> You weren't observing excessive abstraction. I can assert this
>> confidently because I know that there is no such thing. It's not
>> even a
>> very long series of inference to observe that the very notion of
>> "excessive abstraction" is a self-defeating inconsistency. This
>> leads me
>> to questions such as, "why do some people believe in such a thing as
>> excessive abstraction?" I think I know the answer: they don't
>> understand
>> what abstraction even is -- no wonder they are making up untruthful
>> stories about it!
>>
>> There seems to be some amount of agreement here -- these stories,
>> despite their failure to identify the fundamental topic at hand, at
>> least address the issue of regular misunderstanding. In other words,
>> there is a great amount of enthusiasm of the topic, but it is
>> misdirected.
>>
>> The reason I am interjecting here is because I am quite certain
>> that you
>> were you to come to understand what abstraction even is, you'd have a
>> very liberating feeling of enlightenment and probably a very hearty
>> laugh at yourself -- I am promising you these things. Personally, I
>> value both a lot.
>>
>> I teach people what abstraction is. I use abstraction in my software
>> development. In fact, doing so has nil disadvantage and often with
>> both
>> direct and indirect advantages. I can teach you why this is the case.
>> First, we must understand what abstraction even is.
>>
>> There is no such thing as "excessive abstraction."
>>
>> This is an invitation.
>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>
>

On Fri, Mar 25, 2011 at 2:34 PM, Tony Morris wrote:
> In addition, while we can't talk about the disadvantages of abstraction,
> since there aren't any

uh huh.

So far it appears that there are several notions of what abstraction means in this thread:
1. A notion of abstraction in talking about the details, or lack thereof, of a problem domain driven by some form of (educated) ad-hoc analysis of said problem domain. (see Jim Balter's comments)
2. A second notion of abstraction is talking about purely mathematical concepts of abstraction (Tony's remarks).
3. A third notion of abstraction, one that isn't, is the conflation of building systems by hack or featuritis - not really a discussion starter.

Clearly, the general progression is from (1) to the point where discussions of (2) make sense.  Unless I'm mistaken, the original question is closer to (1) than to (2).  Is it reasonable to assume that there is an answer to the implied original question: "[What is] the perfect abstraction level[?]"  Further is is reasonable to assume that most problems of interest have unique "perfect abstraction levels" or are there a multiple of more-or-less equally "perfect" abstractions available to talk about a particular problem?  Based on the fact that there are often a number of specific pieces of software that emerge from attempting to "solve" a particular problem, each embodying their own "perfect" abstraction, I cannot help but feel that this conversation cannot yield a meaningful result.
It would be great to be proven wrong.

--
Jim Powers

On Fri, Mar 25, 2011 at 7:08 AM, Rex Kerr wrote:
> On Thu, Mar 24, 2011 at 4:55 PM, HamsterofDeath wrote:
>>
>> Am 24.03.2011 20:38, schrieb Rex Kerr:
>>
>> Too much abstraction is a distraction--you have to burrow down through the
>> layers of abstraction before you actually get to do anything.  So I don't
>> start very high level.
>>
>> that one i cannot follow. can you provide an example?
>
> Sure:
>
> "Add up all the account balances, please!"

This is out of order -- it's an abstraction of the job described
below. Clients often present either overly specific requirements,
where they do premature design by including all sorts of
implementation details that should to be abstracted out, or, as in
this case, they present insufficiently detailed (overly abstract)
requirements that need to be fleshed out with specific details.

> My job is to add up all of the account balances, which are decimal numbers
> with two entries after the decimal point, and appear after the first tab
> character on each line of the file accounts.txt

Ok. This can be abstracted as "produce the sum of a set of values
obtained from an input source". To produce an actual result, this
abstract description must be concretized, and the detailed
requirements set the constraints on that concretization.

> My job is to add up all the numbers, which are rationals, in the second
> column of a text file.

The numbers you will receive happen to be a subclass of the rationals,
so general facilities to add up rationals might be reusable, depending
on how they represent rationals and the ease of converting to and from
that representation to the two-place decimal representation. While you
have removed information about the format from the original
description, you have also added information -- that the numbers are
rational -- so this is not a proper abstraction. Note that one could
instead insert information that the input numbers are reals (of which
rationals are a subset), and head off in a different the wrong
direction.

And your later job descriptions are the same, inserting more and more
information gleaned from mathematical theory. Rather than simplifying
the description, they complicate it with implementation details that
might or might not play a role -- for instance, if we have a groupoid
package handy, we might or might not employ it in the solution, but
probably not since we have more efficient mechanisms that are commonly
used. That the numbers we need to sum can be viewed as elements of a
groupoid is concrete information, but not information essential to
getting the job done.

What I see here is a conflation of a) the process of abstracting from
a problem description by removing detail with b) recognizing that one
set of things is a subclass of a more abstract set of things. It's
possible to go too far with (a), such as "do stuff", but that's rather
contrived and not a real issue. But it isn't possible to do too much
of (b) -- that's simply acquisition of knowledge. The problem comes
when one crams the result of such a recognition, such as that decimal
numbers are elements of groupoids or toasters are breakfast food
cookers, back into the problem descriptions, ending up with such
foolishness as "my job is to build an appliance that can cook
breakfast food (generally)".

If you are interested in this topic, see this: http://www.infoq.com/presentations/Simplicity-Architect

On Thu, Mar 24, 2011 at 16:03, HamsterofDeath <h-star@gmx.de> wrote:

not exactly scala related, but i noticed that i usually try to code on
very high abstraction levels, while most other people design rather flat
(at least it looks like that from up here). imho, it's much easier to
remove an abstraction layer or go down a bit than add one layer or go
up, so i prefer ending up with code that is more abstract than necessary
than code that is too low level.
i try to solve problems by throwing "structure" and "abstract data
conversion descriptions" at them instead of solving them "by hand" using
algorithms.

votes? opinions?

--
Daniel C. Sobral

I travel to the future all the time.

Am 26.03.2011 02:09, schrieb Daniel Sobral:

6w3hC4KM5b5kntP44edWTXMbKj+VinDKDGC6H [at] mail [dot] gmail [dot] com" type="cite">If you are interested in this topic, see this: http://www.infoq.com/presentations/Simplicity-Architect

On Thu, Mar 24, 2011 at 16:03, HamsterofDeath <h-star [at] gmx [dot] de" rel="nofollow">h-star@gmx.de> wrote:

not exactly scala related, but i noticed that i usually try to code on
very high abstraction levels, while most other people design rather flat
(at least it looks like that from up here). imho, it's much easier to
remove an abstraction layer or go down a bit than add one layer or go
up, so i prefer ending up with code that is more abstract than necessary
than code that is too low level.
i try to solve problems by throwing "structure" and "abstract data
conversion descriptions" at them instead of solving them "by hand" using
algorithms.

votes? opinions?

--
Daniel C. Sobral

I travel to the future all the time.

will watch

i just had an ingenius idea:
written code should simply match the abstraction strategy of the human
memory. for example, if you are told to remember as many things as you
can (random numbers), you'll stop at a certain limit that you cannot
improve. if you write your code while never letting the number of
relevant and accessible symbols in your current scope grow beyond that
limit, you're fine. by following that rule, the amount of abstraction
should be "just right for the human brain".

new opinions?

On Sunday March 27 2011, HamsterofDeath wrote:
> i just had an ingenius idea:
> written code should simply match the abstraction strategy of the
> human memory. for example, if you are told to remember as many things
> as you can (random numbers), you'll stop at a certain limit that you
> cannot improve. if you write your code while never letting the number
> of relevant and accessible symbols in your current scope grow beyond
> that limit, you're fine. by following that rule, the amount of
> abstraction should be "just right for the human brain".
>
> new opinions?

Perfect! ... For when we start programming neural computers.

RRS

Apparently the number of "registers" in a young adult's mind in
typically around seven. But it is often about four but the mind has
tricks to emulate seven.

http://en.wikipedia.org/wiki/Working_memory#Capacity

On Mar 25, 6:09 pm, Daniel Sobral wrote:
> If you are interested in this topic, see this:http://www.infoq.com/presentations/Simplicity-Architect
>
> On Thu, Mar 24, 2011 at 16:03, HamsterofDeath wrote:
> > not exactly scala related, but i noticed that i usually try to code on
> > very high abstraction levels, while most other people design rather flat
> > (at least it looks like that from up here). imho, it's much easier to
> > remove an abstraction layer or go down a bit than add one layer or go
> > up, so i prefer ending up with code that is more abstract than necessary
> > than code that is too low level.
> > i try to solve problems by throwing "structure" and "abstract data
> > conversion descriptions" at them instead of solving them "by hand" using
> > algorithms.
>
> > votes? opinions?
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.

Am 27.03.2011 18:15, schrieb Randall R Schulz:
> On Sunday March 27 2011, HamsterofDeath wrote:
>> i just had an ingenius idea:
>> written code should simply match the abstraction strategy of the
>> human memory. for example, if you are told to remember as many things
>> as you can (random numbers), you'll stop at a certain limit that you
>> cannot improve. if you write your code while never letting the number
>> of relevant and accessible symbols in your current scope grow beyond
>> that limit, you're fine. by following that rule, the amount of
>> abstraction should be "just right for the human brain".
>>
>> new opinions?
> Perfect! ... For when we start programming neural computers.
>
>
> RRS
>
i meant:
i had an ingenious idea how to structure code in a way that makes it
perfectly understandable for other humans!

On Sun, Mar 27, 2011 at 9:37 AM, Joshua Gooding <skavookie@gmail.com> wrote:

Apparently the number of "registers" in a young adult's mind in
typically around seven.  But it is often about four but the mind has
tricks to emulate seven.

http://en.wikipedia.org/wiki/Working_memory#Capacity

With a small amount of training, normal people have been regularly getting the number of "facts" that can be remembered way up in to the hundreds and thousands for about 2,600 years. The classic technique, known as the "Memory Palace" or the "method of ioci" [1], is referenced throughout ancient Greek and Roman literature. The number "7" is apparently the average number for the completely untrained human mind. By way of contrast, it is reported that people trained in memorization can remember the order of a completely shuffled deck of cards in only a few minutes, for several years.

There's a really good book, very recently published, "Moonwalking with Einstein: The Art and Science of Remembering Everything" [2] by Joshua Foer that's a light introduction to the topic.

Classical education included memorization and memory training as a necessity. (This is how, prior to the 20th century, people were able to remember and recite long speeches, recall huge datasets, etc. without the aid of Google.) It might be worthwhile to revive some of these techniques specifically for remembering programming APIs.

Brian Maso

[1] http://en.wikipedia.org/wiki/Method_of_loci

[2] The book's author is a normal journalist with decent credentials who got interested in the competitive memory circuit (there really is one, people really train and compete in memory). He got a little obsessed with the subject, started training a lot, and ended up becoming the U.S. memory champion within 1 year, having never before even known about that world. The book is a really read, and a good lead in to the subject and techniques.
 

On Mar 25, 6:09 pm, Daniel Sobral <dcsob...@gmail.com> wrote:
> If you are interested in this topic, see this:http://www.infoq.com/presentations/Simplicity-Architect
>
> On Thu, Mar 24, 2011 at 16:03, HamsterofDeath <h-s...@gmx.de> wrote:
> > not exactly scala related, but i noticed that i usually try to code on
> > very high abstraction levels, while most other people design rather flat
> > (at least it looks like that from up here). imho, it's much easier to
> > remove an abstraction layer or go down a bit than add one layer or go
> > up, so i prefer ending up with code that is more abstract than necessary
> > than code that is too low level.
> > i try to solve problems by throwing "structure" and "abstract data
> > conversion descriptions" at them instead of solving them "by hand" using
> > algorithms.
>
> > votes? opinions?
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.

--
Best regards,
Brian Maso
(949) 395-8551
brian@blumenfeld-maso.com

Am 27.03.2011 19:35, schrieb Brian Maso:

4B8Cj3U0qrdvbU2Db3-_SghhHmKptdhy_Z_dt [at] mail [dot] gmail [dot] com" type="cite">

On Sun, Mar 27, 2011 at 9:37 AM, Joshua Gooding <skavookie [at] gmail [dot] com" rel="nofollow">skavookie@gmail.com> wrote:

Apparently the number of "registers" in a young adult's mind in
typically around seven.  But it is often about four but the mind has
tricks to emulate seven.

http://en.wikipedia.org/wiki/Working_memory#Capacity

With a small amount of training, normal people have been regularly getting the number of "facts" that can be remembered way up in to the hundreds and thousands for about 2,600 years. The classic technique, known as the "Memory Palace" or the "method of ioci" [1], is referenced throughout ancient Greek and Roman literature. The number "7" is apparently the average number for the completely untrained human mind. By way of contrast, it is reported that people trained in memorization can remember the order of a completely shuffled deck of cards in only a few minutes, for several years.

i don't think it's a good idea to write code using hundres of local variables at the same time just because the next programmer *could* train the loci thing for a few years if he wanted to.

4B8Cj3U0qrdvbU2Db3-_SghhHmKptdhy_Z_dt [at] mail [dot] gmail [dot] com" type="cite">
There's a really good book, very recently published, "Moonwalking with Einstein: The Art and Science of Remembering Everything" [2] by Joshua Foer that's a light introduction to the topic.

Classical education included memorization and memory training as a necessity. (This is how, prior to the 20th century, people were able to remember and recite long speeches, recall huge datasets, etc. without the aid of Google.) It might be worthwhile to revive some of these techniques specifically for remembering programming APIs.

i disagree.
code completion owns human memory. it can tell you exactly which method is available and which is not.
code completion owns human typing speed/accuracy.
"find symbol" is faster/more accurate than the human memory. i tend to write rarely used methods at a place where it makes sense and then forget about where i put the method - but i re-find it because i know how i named it using my ide's "find anything"-feature. no need to keep the whole structure in mind, just let the computer find the method.
and so on.

in general, i try to avoid "brute force thinking". we have computers for that. i follow my principles and by doing so, i can safely make a lot of assumptions about my code without having to remember much of it.

4B8Cj3U0qrdvbU2Db3-_SghhHmKptdhy_Z_dt [at] mail [dot] gmail [dot] com" type="cite">
Brian Maso

[1] http://en.wikipedia.org/wiki/Method_of_loci

[2] The book's author is a normal journalist with decent credentials who got interested in the competitive memory circuit (there really is one, people really train and compete in memory). He got a little obsessed with the subject, started training a lot, and ended up becoming the U.S. memory champion within 1 year, having never before even known about that world. The book is a really read, and a good lead in to the subject and techniques.
 

On Mar 25, 6:09 pm, Daniel Sobral <dcsob [dot] [dot] [dot] [at] gmail [dot] com" rel="nofollow">dcsob...@gmail.com> wrote:
> If you are interested in this topic, see this:http://www.infoq.com/presentations/Simplicity-Architect
>
> On Thu, Mar 24, 2011 at 16:03, HamsterofDeath <h-s [dot] [dot] [dot] [at] gmx [dot] de" rel="nofollow">h-s...@gmx.de> wrote:
> > not exactly scala related, but i noticed that i usually try to code on
> > very high abstraction levels, while most other people design rather flat
> > (at least it looks like that from up here). imho, it's much easier to
> > remove an abstraction layer or go down a bit than add one layer or go
> > up, so i prefer ending up with code that is more abstract than necessary
> > than code that is too low level.
> > i try to solve problems by throwing "structure" and "abstract data
> > conversion descriptions" at them instead of solving them "by hand" using
> > algorithms.
>
> > votes? opinions?
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.

--
Best regards,
Brian Maso
(949) 395-8551
brian [at] blumenfeld-maso [dot] com" target="_blank" rel="nofollow">brian@blumenfeld-maso.com

On Sunday March 27 2011, Brian Maso wrote:
> ...
>
> Classical education included memorization and memory training as a
> necessity. (This is how, prior to the 20th century, people were able
> to remember and recite long speeches, recall huge datasets, etc.
> without the aid of Google.) It might be worthwhile to revive some of
> these techniques specifically for remembering programming APIs.

'Cause it's so difficult to augment one's memory with digital
technology?? Or 'cause programmers are so resolute in their refusal to
document their work?

> Brian Maso

Randall Schulz

> From: h-star@gmx.de
> Subject: Re: [scala-user] the perfect abstraction level
>
> i just had an ingenius idea:

> <snip/> 

> new opinions?

You lack humility?

Am 27.03.2011 20:49, schrieb Chris Marshall:

COL109-W56989ADD48D1B9921B97DC8DBB0 [at] phx [dot] gbl" type="cite"> > From: h-star@gmx.de
> Subject: Re: [scala-user] the perfect abstraction level
>
> i just had an ingenius idea:

> <snip/> 

> new opinions?

You lack humility?

almost everyone thinks he's a bit smarter than the average person, i am no exception. but everytime a admit that, i get scolded :(

On Sun, Mar 27, 2011 at 11:17 AM, Randall R Schulz <rschulz@sonic.net> wrote:

On Sunday March 27 2011, Brian Maso wrote:
> ...
>
> Classical education included memorization and memory training as a
> necessity. (This is how, prior to the 20th century, people were able
> to remember and recite long speeches, recall huge datasets, etc.
> without the aid of Google.) It might be worthwhile to revive some of
> these techniques specifically for remembering programming APIs.

'Cause it's so difficult to augment one's memory with digital
technology?? Or 'cause programmers are so resolute in their refusal to
document their work?

It's not an either-or proposition. How about both augmenting memory digitally *and* with training? "Digital augmentation", if we can invent a phrase here, is great at rapid indexing, but is not going to be so good at helping one recall patterns and unindexed information. Better human memory is going to be a great compliment to that digital augmentation.

Here's a scenario to consider: I just recently had to re-aquaint myself with log4j XML configuration file syntax. It took me some time to rediscover all the log4j stuff I had forgotten since using log4j last: the names of appender classes, how to specify things to a formatter, whether or not I needed to create a custom appender for a particular way of reporting things -- I recalled doing something similar before but couldn't remember if I had created a custom appender or found an open-source one.

Would it have gone a whole lot faster if I *didn't* need to scour through 8-10 years of Google's indexed library of log4j material, but instead had this same material in my head? Yes, I'm sure it would have. Mind you, I've already learned this stuff several times. Unfortunately, I have limited capacity for remembering the minute details. Wouldn't it be great, though, if I could increase that capacity?

How about something *really* compilcated, like say the Scala language specification? Paul P. isn't going to be around telling us how the Scala compiler infers type information in wierd language corner-cases forever, you know. There's a reason saints like him are on this list answering questions, and the questioners aren't simply looking everything up through Google or stackoverflow: digital augmentation isn't useful in a whole lot of very important information-recall and pattern recognition cases. In many of those cases that digital augmentation misses, improved human memory would be a great benefit.

I'm just saying that, from the point of view of someone who's been programming long enough that I realize I've forgotten way more APIs than I can remember, I recognize that better human recall would be great. It turns out that I don't have to be satisfied with only remembering the 7 or so things that have most recently been on my screen.

Brian Maso

 

> Brian Maso


Randall Schulz

--
Best regards,
Brian Maso
(949) 395-8551
brian@blumenfeld-maso.com

On Sun, Mar 27, 2011 at 11:59 AM, HamsterofDeath <h-star@gmx.de> wrote:

i meant:
i had an ingenious idea how to structure code in a way that makes it
perfectly understandable for other humans!

Your ideas are intriguing to me and I wish to subscribe to your newsletter.

i'm sure there's a good reason why we cannot simply train our brains to deal with 100 information units in parallel, there might be something like exponential growth involved.
strategy/structure is the key to solve this problem, not adding more power.

Am 27.03.2011 21:25, schrieb Brian Maso:

AANLkTineWKAWbYs5feehzMyHjm0UtmMS5KvzhaTgw8sq [at] mail [dot] gmail [dot] com" type="cite">

On Sun, Mar 27, 2011 at 11:17 AM, Randall R Schulz <rschulz [at] sonic [dot] net" rel="nofollow">rschulz@sonic.net> wrote:

On Sunday March 27 2011, Brian Maso wrote:
> ...
>
> Classical education included memorization and memory training as a
> necessity. (This is how, prior to the 20th century, people were able
> to remember and recite long speeches, recall huge datasets, etc.
> without the aid of Google.) It might be worthwhile to revive some of
> these techniques specifically for remembering programming APIs.

'Cause it's so difficult to augment one's memory with digital
technology?? Or 'cause programmers are so resolute in their refusal to
document their work?

It's not an either-or proposition. How about both augmenting memory digitally *and* with training? "Digital augmentation", if we can invent a phrase here, is great at rapid indexing, but is not going to be so good at helping one recall patterns and unindexed information. Better human memory is going to be a great compliment to that digital augmentation.

Here's a scenario to consider: I just recently had to re-aquaint myself with log4j XML configuration file syntax. It took me some time to rediscover all the log4j stuff I had forgotten since using log4j last: the names of appender classes, how to specify things to a formatter, whether or not I needed to create a custom appender for a particular way of reporting things -- I recalled doing something similar before but couldn't remember if I had created a custom appender or found an open-source one.

Would it have gone a whole lot faster if I *didn't* need to scour through 8-10 years of Google's indexed library of log4j material, but instead had this same material in my head? Yes, I'm sure it would have. Mind you, I've already learned this stuff several times. Unfortunately, I have limited capacity for remembering the minute details. Wouldn't it be great, though, if I could increase that capacity?

How about something *really* compilcated, like say the Scala language specification? Paul P. isn't going to be around telling us how the Scala compiler infers type information in wierd language corner-cases forever, you know. There's a reason saints like him are on this list answering questions, and the questioners aren't simply looking everything up through Google or stackoverflow: digital augmentation isn't useful in a whole lot of very important information-recall and pattern recognition cases. In many of those cases that digital augmentation misses, improved human memory would be a great benefit.

I'm just saying that, from the point of view of someone who's been programming long enough that I realize I've forgotten way more APIs than I can remember, I recognize that better human recall would be great. It turns out that I don't have to be satisfied with only remembering the 7 or so things that have most recently been on my screen.

Brian Maso

 

> Brian Maso


Randall Schulz

--
Best regards,
Brian Maso
(949) 395-8551
brian [at] blumenfeld-maso [dot] com" target="_blank" rel="nofollow">brian@blumenfeld-maso.com

There's an old suggestion that a function should be three or five
lines long - like Japanese poetry. (Worked in Forth.)

Thanks,
-Vlad

On Sun, Mar 27, 2011 at 9:59 AM, HamsterofDeath wrote:
> Am 27.03.2011 18:15, schrieb Randall R Schulz:
>> On Sunday March 27 2011, HamsterofDeath wrote:
>>> i just had an ingenius idea:
>>> written code should simply match the abstraction strategy of the
>>> human memory. for example, if you are told to remember as many things
>>> as you can (random numbers), you'll stop at a certain limit that you
>>> cannot improve. if you write your code while never letting the number
>>> of relevant and accessible symbols in your current scope grow beyond
>>> that limit, you're fine. by following that rule, the amount of
>>> abstraction should be "just right for the human brain".
>>>
>>> new opinions?
>> Perfect! ... For when we start programming neural computers.
>>
>>
>> RRS
>>
> i meant:
> i had an ingenious idea how to structure code in a way that makes it
> perfectly understandable for other humans!
>
>

i wasn't thinking about the line number, but about compelexity. meaning:
number of relevant variables (explicit and implicit via directly re-used method calls)
number of possible paths through the function

-------- Original-Nachricht --------
> Datum: Mon, 28 Mar 2011 23:30:03 -0700
> Von: Vlad Patryshev
> An: HamsterofDeath
> CC: scala-user@googlegroups.com
> Betreff: Re: [scala-user] the perfect abstraction level

> There's an old suggestion that a function should be three or five
> lines long - like Japanese poetry. (Worked in Forth.)
>
> Thanks,
> -Vlad
>
>
>
> On Sun, Mar 27, 2011 at 9:59 AM, HamsterofDeath wrote:
> > Am 27.03.2011 18:15, schrieb Randall R Schulz:
> >> On Sunday March 27 2011, HamsterofDeath wrote:
> >>> i just had an ingenius idea:
> >>> written code should simply match the abstraction strategy of the
> >>> human memory. for example, if you are told to remember as many things
> >>> as you can (random numbers), you'll stop at a certain limit that you
> >>> cannot improve. if you write your code while never letting the number
> >>> of relevant and accessible symbols in your current scope grow beyond
> >>> that limit, you're fine. by following that rule, the amount of
> >>> abstraction should be "just right for the human brain".
> >>>
> >>> new opinions?
> >> Perfect! ... For when we start programming neural computers.
> >>
> >>
> >> RRS
> >>
> > i meant:
> > i had an ingenious idea how to structure code in a way that makes it
> > perfectly understandable for other humans!
> >
> >

Working memory is not relevant here. Working memory is merely the buffering between what sense you take from the world and those mechanisms used to store said information.

There is a bunch of literature for 5+-2 chunks of working memory (usually chunk is referred to as 2-3 characters worth) . What can be trained is how fast and how effectively you can persist those chunks into longer term memory.

Let's face it safely crossing the street requires more than seven chunks.

On 27 Mar 2011 19:35, "Brian Maso" <brian@blumenfeld-maso.com> wrote:

On Sun, Mar 27, 2011 at 9:37 AM, Joshua Gooding <skavookie@gmail.com> wrote:
>
> Apparently the numb...

With a small amount of training, normal people have been regularly getting the number of "facts" that can be remembered way up in to the hundreds and thousands for about 2,600 years. The classic technique, known as the "Memory Palace" or the "method of ioci" [1], is referenced throughout ancient Greek and Roman literature. The number "7" is apparently the average number for the completely untrained human mind. By way of contrast, it is reported that people trained in memorization can remember the order of a completely shuffled deck of cards in only a few minutes, for several years.

There's a really good book, very recently published, "Moonwalking with Einstein: The Art and Science of Remembering Everything" [2] by Joshua Foer that's a light introduction to the topic.

Classical education included memorization and memory training as a necessity. (This is how, prior to the 20th century, people were able to remember and recite long speeches, recall huge datasets, etc. without the aid of Google.) It might be worthwhile to revive some of these techniques specifically for remembering programming APIs.

Brian Maso

[1] http://en.wikipedia.org/wiki/Method_of_loci

[2] The book's author is a normal journalist with decent credentials who got interested in the competitive memory circuit (there really is one, people really train and compete in memory). He got a little obsessed with the subject, started training a lot, and ended up becoming the U.S. memory champion within 1 year, having never before even known about that world. The book is a really read, and a good lead in to the subject and techniques.
 

>
> On Mar 25, 6:09 pm, Daniel Sobral <dcsob...@gmail.com> wrote:
> > If you are interested in this...

--

Best regards,
Brian Maso
(949) 395-8551
brian@blumenfeld-maso.com

My brain is overloaded by the complexity resulting from you posting under  two different names.

-- Jim

On Mon, Mar 28, 2011 at 11:58 PM, Dennis Haupt <h-star@gmx.de> wrote:

i wasn't thinking about the line number, but about compelexity. meaning:
number of relevant variables (explicit and implicit via directly re-used method calls)
number of possible paths through the function

-------- Original-Nachricht --------
> Datum: Mon, 28 Mar 2011 23:30:03 -0700
> Von: Vlad Patryshev <vpatryshev@gmail.com>
> An: HamsterofDeath <h-star@gmx.de>
> CC: scala-user@googlegroups.com
> Betreff: Re: [scala-user] the perfect abstraction level

> There's an old suggestion that a function should be three or five
> lines long - like Japanese poetry. (Worked in Forth.)
>
> Thanks,
> -Vlad
>
>
>
> On Sun, Mar 27, 2011 at 9:59 AM, HamsterofDeath <h-star@gmx.de> wrote:
> > Am 27.03.2011 18:15, schrieb Randall R Schulz:
> >> On Sunday March 27 2011, HamsterofDeath wrote:
> >>> i just had an ingenius idea:
> >>> written code should simply match the abstraction strategy of the
> >>> human memory. for example, if you are told to remember as many things
> >>> as you can (random numbers), you'll stop at a certain limit that you
> >>> cannot improve. if you write your code while never letting the number
> >>> of relevant and accessible symbols in your current scope grow beyond
> >>> that limit, you're fine. by following that rule, the amount of
> >>> abstraction should be "just right for the human brain".
> >>>
> >>> new opinions?
> >> Perfect! ... For when we start programming neural computers.
> >>
> >>
> >> RRS
> >>
> > i meant:
> > i had an ingenious idea how to structure code in a way that makes it
> > perfectly understandable for other humans!
> >
> >

Chunks don't have a fixed size. Consider the seminal chunkng experiments by Adrian de Groot, where he showed that master and grandmaster chess players were indistinguishable under a host of intelligence and memory tests, but grandmasters excelled at the speed with which they could recreate briefly seen chess positions, presumably because they perceive the positions in larger chunks. Notably, their ability to recreate random arrangements of chess pieces on the board is not significantly better than that of weaker players.

This of course has applicability to the ability to read and comprehend code ... it increases as idioms become more familiar.

-- Jim


On Tue, Mar 29, 2011 at 4:51 AM, Chris Twiner <chris.twiner@gmail.com> wrote:

Working memory is not relevant here. Working memory is merely the buffering between what sense you take from the world and those mechanisms used to store said information.

There is a bunch of literature for 5+-2 chunks of working memory (usually chunk is referred to as 2-3 characters worth) . What can be trained is how fast and how effectively you can persist those chunks into longer term memory.

Let's face it safely crossing the street requires more than seven chunks.

On 27 Mar 2011 19:35, "Brian Maso" <brian@blumenfeld-maso.com> wrote:

On Sun, Mar 27, 2011 at 9:37 AM, Joshua Gooding <skavookie@gmail.com> wrote:
>
> Apparently the numb...

With a small amount of training, normal people have been regularly getting the number of "facts" that can be remembered way up in to the hundreds and thousands for about 2,600 years. The classic technique, known as the "Memory Palace" or the "method of ioci" [1], is referenced throughout ancient Greek and Roman literature. The number "7" is apparently the average number for the completely untrained human mind. By way of contrast, it is reported that people trained in memorization can remember the order of a completely shuffled deck of cards in only a few minutes, for several years.

There's a really good book, very recently published, "Moonwalking with Einstein: The Art and Science of Remembering Everything" [2] by Joshua Foer that's a light introduction to the topic.

Classical education included memorization and memory training as a necessity. (This is how, prior to the 20th century, people were able to remember and recite long speeches, recall huge datasets, etc. without the aid of Google.) It might be worthwhile to revive some of these techniques specifically for remembering programming APIs.

Brian Maso

[1] http://en.wikipedia.org/wiki/Method_of_loci

[2] The book's author is a normal journalist with decent credentials who got interested in the competitive memory circuit (there really is one, people really train and compete in memory). He got a little obsessed with the subject, started training a lot, and ended up becoming the U.S. memory champion within 1 year, having never before even known about that world. The book is a really read, and a good lead in to the subject and techniques.
 

>
> On Mar 25, 6:09 pm, Daniel Sobral <dcsob...@gmail.com> wrote:
> > If you are interested in this...

--

Best regards,
Brian Maso
(949) 395-8551
brian@blumenfeld-maso.com