Photos - Google+

On cloud sites, like google docs (drive and picasa) - I want the ability to easily find docs, photos, etc, by permission.

I prefer not to make anything public unless really certain.

But I had accidentally done so.

Heck: I would actually like to have to jump through hoops like retyping a password to make something public.

Lack of keyword parameters a big cause of programming .... errors, bugs, inefficiency

Sometimes the title says it.

I wonder how much inefficiency has been introduced into programming, how many bugs caused, because positional parameters became the default standard for programming languages long ago.

If not actual bugs because two parameters are flipped in a way that is not detected by the type system, how about inefficiency.  "I can't remember the order of the arguments, so I must look them up..."

Microsoft's IntelliSense helps ... but I'm usually an macs user,  Don't have that.  IntelliSense has almost beenh enough to make me switch.

---

Bjarne says that keyword parameters almost made it into a C++ standard, and lost only because of legacy C issues. He suggests parameter objects.  Cool.  So, I want to automatically create a parameter object for each and every function.  

Hmm....  I think that I could write a preprocessor that did that, munging the symbol table.

Something like

ParameterObject.NamedParameter1()...

Unfortunately, parameter names do not get into the symbol table.

Chaining, or Why You Should Stop Returning Void - Zero Wind :: Jamie Wong

Chaining, or Why You Should Stop Returning Void - Zero Wind :: Jamie Wong:

Bjarne Soustrup's recommendation on how to do keywords in C++:

FunctionFooParameterObject()
    .keyword_parameter1(val1)
    .keyword_paraemeter3(val3)
    .keyword_parameter5(val5)
    .call_it()

Works.

Only real hassle is that it is a lot of dang code to write.

Google "cloud" tool shortcomings

Are Google docs and blogger cloud? Whatever.

Google docs:

• unintelligible URLs
• not clear how indexed they are - I do know that docs that I have "cross posted" between my wiki (mediawiki) and Google docs have been indexed, by Google, on the wiki, but not on Google docs.
• "It doesn't exist if you can't google it"

Blogger:

• no formatting in comments
• can't link to a particular comment

? permalinks ?

Jamie Wong's An Argument for Mutable Local History

http://jamie-wong.com/2012/05/25/an-argument-for-mutable-local-history/

Argues for mutable local history, and hence rebase.

I think all of these arguments apply also to global history, at whatever level.

But I want immutability as much as possible.

Again, I conclude that it is not the absolute history we what to mutate. It is our VIEW of the history.

(Although there are valid reasons to really want to edit history, e.. to drop stuff that you are not legally allowed to use.)

Futures make sets safe

Set notation is very convenient.

E.g.  

index_set = { 1, 2, 3}
array[ index_set ] = 0

rather than a loop

But a problem with set notation is that intermediate sets can be very large.

E.g.  

index_set = 1, 2, 3 ...
array[index_set] = random()
array = array[i] where i < 5 

rearranging

index_set = 1, 2, 3 ...
small_index_set =  i IN index_set, where i < 5
array[small_index_set] = random()

If the array[index_set] = assignment makes things real, this statement is impractical. Whereas array[small_index_set] = is finite sized.

Futures make this sort of manipulation feasible.

Pattern: Ordered Lists, with Associative Lookup and Update

One of my friends (TC) complained that XML had too much order.  He said that XML structs should be unordered, like Perl hashes, associative arrays.  Indeed, JSON has unordered key=alue pairs, and ordered lists: the former is not the latter.

I'm not so sure.  I keep running into situations where I want to have an ordered data structure, but where I also want an associative lookup and/or update.

For example, my shell PATH.  It is definitely order dependent.  But I often want to do operations such as

• is DIR already in PATH
• add DIR to PATH if it is not already present
• prepend or append
• add DIR to PATH next to DIR_already_in_path
• just before, or just after
• replace DIR0 in PATH (assuming it is already there) with DIR1

For example, hook lists - like hook lists for emacs.

For example, like Bash PROMPT_COMMAND. This really isn't a hook list, but imagine that it is, using ; as the separator (gets more complicated with IFs, etc.).  Here I have been wanting a more general associative lookup, not just exact matching.

• E.g. replace any element that looks like a command that invokes my logical-path program.*logical-path.* with a different invocation of that program

Just like associative arrays, hashes, have greaty impoved programmer productivity by being built in data structures in Perl and Python (and to a weaker extent in C++ STL std::map), it may be worth thinking about standardizing ordered associative arrays. Using Perl associative array syntax (not my favorite, but it's easy at hand):

$OAA{key}  # error if more than 1 match?
$OAA{key:1} $OAA{key:2} ... # first match, second match, ...
$OAA{key:#} # number of matches
$OAA{key} = value # replace. error if no match
$OAA{key} = {} # delete - or some other way of indicating droppage
$OAA{key} <<= value # insert just before
$OAA{key} >>= value # insert just after
$OAA{key:*} = ... # replace all occurrences

We might distinguish key from value, as in key=value.  Or we might allow the key and the value to be the same, i.e. the entire value might be matched against.

We might require key to be exactly matched - or we might allow regexps, or arbitrary expressions.

$OAA{i WHERE $OAA{i} < 2} = ... # replace all occurrences

We might allow the value to have structure, with fields.

$OAA{rec WHERE $OAA{rec}.age > 10 and $OAA{rec}.weight <70 br="br">$OAA{.age > 10 and .weight <70 blockquote="blockquote">Nothing that you can't do with map here - but the notation may be more pleasant. And compact, pleasant notation matters. (As opposed to compact unpleasant notation.)

Verges on relations.

---

Extend to multi dimensional?