Wednesday
Dec052018

Being Ready

link: https://www.huffingtonpost.com/entry/michelle-obama-black-president-barack-obama_us_5c068256e4b066b5cfa5ca4e

Michelle Obama said "I never believed the US was ready for a black president in 2008."

I never believed this country was ready to rekindle the errors of blind hatred in 2016 through 2018.  But here we seem to be.  Some fools believe blind hate might not be so bad if it serves politics- what's a church shooting or lynching or two as long as there is re-election and the victims weren't likely to vote your way?  And there are other fools that believe in speak no evil hygiene that casts millions as forever-flawed and does nothing towards reconciliation, healing and unity.  For we are one people and one nation.  I tell you it is a fool that believes in either “cultural contamination" or "cultural appropriation" as absolute unforgivable sins.  It is a foolish nation that values divide over unity.            

Absolutism does not serve this country well.  Are we not a mixing pot of huddled masses, here, but only for the outrageous luck of our adaptable ancestors?    

Last night at my daughter's 5th grade 'A Christmas Carole' play, a beautiful foreign princess played the Ghost of Christmas Present, in the clothes of her ancestral traditions - veiled beads and dangling gold - but her costume came with an emphasis on red and green.   All the elements were there to offend both liberal and conservative, and yet, let me assure you, new different and included can be ever so beautiful without dimming anything that has been.

It might never be an easy path, but I think that child knows a better way.  I hope the rest of us can follow.  I hope we are ready.

Thursday
Nov292018

Sacre Bleu, a Review of the Book By Christopher Moore

Perhaps I got off to a bad start with Moore's book 'Sacre Bleu' by listening to it over an uncomfortable dental visit. 

There is a moment in his book "Bloodsucking Feinds" where snapping turtles make a particularly poor impression on a potential mother-in-law.  The moment is genius, doubly so if, quite inadvertly, you've lived through some version of it yourself.  My version includes a forgotten garage door opener in my pants pocket, the love of my life, a partial state of undress, a few moments of youthful lust and a two hour early visit from her parents who were wondering why the garage door was malfunctioning.  Oh, and two pet ferrets, not snapping turtles, and the ferets had nothing to do with lust and that's why they are in this sentence over here.  Christopher Moore's version is better.

I like most of what Christopher Moore writes, so I kept at Sacre Bleu despite a start that included lidocane injections in chapter 6 and some of drill noise and spitting in chapter 7.  And then at some point I realized that the book was not for me.  It isn't just that the book isn't my cup of tea - sure I like impressionist painters, I like Paris, I paint a bit myself with acrylics, I've even build robots that try to paint, I liked Moore's other books, I mostly like his humor, and I'm not adverse to reading something a bit smutty.  All of which suggests, I should enjoy.  But the book stubbornly was not for me, and I was not its intended audience.

I normally breeze through a book, but Sacre Bleu was my own personal literary version of mountain climbing.  I pressed on.  I read the book.  I had to fight myself to finish it, I haven't given up on a book since sixth grade* unless you include reference items like encyclopedia, technical manuals and cookbooks.    Eventually I read all of Sacre Bleu.  

And there was a big pay off at the end.  You should totally go buy the book right now... go go go... just run out right now don't even finish this blog post, just go buy your own copy right away.  Get the audiobook and the ebook.

And I just lied because I really like almost everything else Christopher Moore has wrote, and I want him to do well and write more great things.  Much like humanity has forgiven the long dead impressionists of their sins and those they troubled, I'll forgive Moore for this cryptic liturgy on passion.  Sacre Bleu might even be great, as the story unwinds near the end like a pecular tangled Jimsonweed Georgia O'Keefe that nearly seems to be mooning its audience, there is something real and true in there.  At least if you can ignore the borrowed tropes and reflections Moores plucks from his earlier works.  That what inspires us, truely it can be fickle and cruel.   Inspiration and relentless obsession, once lost, how and where can they be reclaimed?

I haven't read Moores 1994 Coyote Blue book yet... maybe I'll give that one a try next to finish reading his published works.    And maybe leave the dentist visit out of the next story. 

*"Where the Red Fern Grows", I am sorry I do not know you.  

(Image (C)2018, "honoring O'Keefe", acrylic on canvas, painted by my daughter, Tessa)

Wednesday
Nov212018

A Harsh Criticism of Rust 

I really like the rust programming language.  It does so many things elegantly, beautifully, concurrently and safely.  It feels like the future and I consider myself a rust-fanboy.  But what's not to like?   Here is my list of terrible things about rust (or perhaps computer science in general.) 

TLDR:  My list includes (1) Rust gets all "I can't let you do that dave." (2) I hate how slow I am learning rust (3) Rust brings new concepts and search words fail me (4) Documentation alone is not a teacher for beginners  (5) Simple mathematical ideas obscured by long verbage, you are not my type (6) Methods.are(not).easy(toprogram) but ever so easy to use. (7) the many ways to count and loop and collect and iterate can be unclear but maybe that is on English, (8) unsafe blocks because why have just one emensely complex computer language when you can have almost four between safe rust, unsafe rust, methods and macros (9). All the cool toys Nightly offers have uncertain prices (10) rust has a great community and you'll probably need it in order to learn rust.

  1. "I can't let you do that Dave."  Getting hung up on doing something the wrong way still works in most other languages - maybe slowly or with potential for errors or thousands more watts of cpu cycles burned than needed or uncertain behavior.  But they still work, you can go forward.  But Rust, Rust doesn't just get argumentative, it gets in your way. For me, I had trouble passing generic Vectors Vec to a function.  There is almost certainly a way to do it, maybe, right?  Rust stands in praise of don’t repeat yourself (DRY) code writing… and it should as it can be verbose.  But when it comes to random subsampling a population represented by a vector... For a full day I did't have a lot of hope that mere mortals could write a generic population polling function that works with on Vec, Vec,  Vec or any other Vec you can throw at it without lots of repeated code and unhelpful "I can't let you move what may have already been moved Dave" type errors.   See my comment in comment section for working code.  The frustration abated as I learned the function required trait and lifetime closures and how Rust's creators envisioned a solution.  Most languages don't treat you like a cat that just pooped outside its litter box merely because the cat and litter box both exist allowing the possibility of said fecal infraction, but Rust, rust fights even that possibility.   
    There is something "steep learning curve" about that harassment, from borrow checking to generics to implementing traits.  And "borrowing" in combo with other rust "features" like "lifetimes" intersect in ways that detours (or forbids?) common CS problem approaches that you'll need to unlearn as you learn rust.  On the plus side, generics and traits and implementations are really powerful in rust, and I've picked up better programming practices... thank you Rust... even though I didn't really want my nose rubbed in it - and that's a terrible way to treat your programmer by the way. 
  2. A while ago I came across a 2015 reddit thread "Is Rust a good first programming language to learn?" At first I thought Yes, because I'm a rust fan boy and think of all the messiness that could be avoided if only I learned rust first and skipped learning non-rust friendly programming techniques - then I got reasonable.  Now my answer is yes only if you are lucky enough to have a great human mentor or excellent course + classroom enviroment.  I hate how slowly I am learning Rust,  for me- knowing comes from doing but the bloody compiler won't let me do until I already know how.  a catch 22.  I picked up python in a week.  I love Mathmatica because I can program small marvels in twenty lines of code.  And in rust, I keep at it for months and keep improving and learning and feel like I'm making progress but I am still in discovery.  I started by thinking, ok, structs are simple enough.. but when I wanted to sort generic vector A, (a list of things that may or may not make sense to talk about in terms of greater or less than),  by the values in Generic Vector B a partially ordinal vector that makes  does make sense in terms it parts being greater and less than other parts), I suddenly found myself needing to know almost everything about structs, traits, enums, generics, lifetimes, implementations and functions headers all at once to make any progress in coding (Hint: use a fn to return a tuple.  Then vectorize the collected tuples and don't try to learn every nuance of the type system).  Perhaps rust was build by people that know everything for people that know everything or are are willing tolerate a learning curve shaped like the Cliffs of Zion.  Sometimes slow progress comes from Rust’s width alone between ?thousands? of macros or safe and unsafe features in the standard standard library.   This week I met the handy vector .retain(|x| x%5 ==0 ) function that lets you depopulate select elements from a vector array.    I should probably buy a rust book.  The online doc's are pretty good, but hard to scribble notes all over and easy to get lost in, and rust's autogenerated documentation has curation priorities that a human teacher mostly wouldn't.   And did I mention the rust path of learning the way through a maze by running into walls again and again? Where hard found wins work, I feel like I've learned something universal that could improve the way I write rust code and everything else. 
  3. Rust has certain concepts that are new and really conceptual. If you don't agree, type "Elison Function" into google and count results until you get something the pertains to coding.   New ideas arise from other ideas like ownership and no garbage collection and how those ideas create a moire effect of additional implications, many unnamed or at least rare outside rusts community.  When I wrote a rust prime number toy, there was a CS programming pattern that amounted to “2 is a prime.  Check new numbers for primality from last tested value to last known prime squared - across available CPU's.  After test phase, use new primes found to grow the original list of primes & transfer new knowledge across all CPU cores by borrowed pointer and repeat to inch the knowledge base larger.  (know2)->grow3!->sow3->(know2,3)->grow5!,6,7!,8->sow5,7->(know2,3,5,7)->grow(10..=48) ..." That sounds simple, and the prime number program wasn't complex and the idea not new... but "know/grow/sow/repeat" as a problem strategy would have a name had concurrent rust somehow predated C.  Blazingly fast too. And backward from most  prime number search codes in that it was building prime numbers as much as finding them.  Maybe this paradigm does have a name and I just don’t know what it is called.   I still feel a little bit of pride the elegant high speed parallel solution rust's Rayon library crate allows.  But certain rust paradigms are still pretty opaque to me  - like functions returning boxed closure trait objects - each step makes sense but the whole makes me wonder.  Are there even words I can search Google for that describe what rust is doing there?  Others make me feel like coding rust walks me around some idea or pitfall that was deemed "not the rust way."   It is hard to explain, but there is a rust way and you learn the rust way mostly by letting the compiler beat you up and force you to debug perfectly reasonable code (in any other language) until you stop running into the invisible brick walls.  And it hurts to refactor and recode until you start to have useful cargo compiler conversations and have memorized enough of the documentation that even the autogenerated docs makes sense at a glance.  What is the rust path?  I’d guess it the rust path is bigger than most concise programming ideals, and might be something to do with what it means to be the computer or the computed.    The upside is compiled rust code just works and runtime errors are mostly a theoretical possibility rather than theoretical certainty. 
  4. RustDoc auto documentation.  Wonder of simplification and yet possible source of Rust's near freakishly large spool of mediocre documentation?   Meaningful connections between idea, convention and practice are hard to come by in autogenerated docs, aside from a few examples.  I get why semi-automatic documentation is a thing and that the goal is documentation, not teaching beginners.  Part of me thinks semi-automatic documentation is brilliant, and the other part of me snidely thinks  "If you were given a dictionary made from only the very words Shakepeare used, would you know any  Shakespeare?".to_string().string_replace("Shakepeare","Rust") 
    I wrote that last paragraph before I ever published a rustdoc, and now that I have the Frank crate on crates.io I can say doing rustdoc well is a minor effort, but there can suprises that increase doc disorder. 
  5. Conversions.  Rust has a thing where type conversion within complex mathematical ideas rapidly becomes deeply layered and indecipherable.   For me, mathematics is visual.  I understand “a=(b+c*d-e)/%65536” but
    let conv_b = b as f64;
    let conv_dc = (c as f64) * d;
    let conv_e = (conv_b  + (conv_dc as f64) - e) as usize;
    let a:u32 = u32::from((conv_e%65536usize ) );

    Might be the same, but seems segmented and deeply murky.  Rust doesn't let me just willy nilly type convert and I find myself writing code to do terribly simple math with alarming frequency in rust.  Even worse, write a generic Mean fn for all primitive vectors types and experience serious hoop jumping.  Rust probably does this the right way by forcing blame for subtle typecasting errors on the programmer rather than just making it easy.   But I have moments where I wish I could just type typeconversion!(a=(b+c*d-e)%65536) or mylist.mean() and follow with a proof of correctness by assertions.  I don't really want to be programming type conversions for every generic possible in my programs over and over again in rust.  Not just that, but my brain works a specific way- I grew up with one math idea fitting on one line.  Two lines and its little number story that unfolds.  But baby fed it becomes a story problem really obscures.  I have trouble following parenthesis mazes without color clues so extra parentesis don't improve my comprehension and I have trouble following overarching mathematical goals and objectives when every step gets spoon fed and broken up by "here comes an airplane landing in the hanger."     How can a language that is so beautiful when it comes to "(2..).filter(|x| (x%6)==0 && (2 * x - 1)%11==0).take(100).collect()" be so grimly pedantic when it comes to the murky uncertainties of converting types?  
    Yes, type conversion is a wellspring of undefined behavior in many languages - that said I'm not sold that conversion must always be a wellspring of undefinied behavior or that the best way forward is to force the programmer into type minimalism or risk hours coding custom type conversion for each and every special little type of information encoded while forgoing broad generics and coding for all the typical and edge cases that can be imagined.                 
  6. data.methods() seem really complicated to program.  Not to use, in that they are a joy.  Methods tie types of data to functions and memory lifetimes and often follow the flow of the programmer's thoughts.  If you have a list called vector, its pretty obvious what vector.ranked() might do compared with to vector.sort().ranked(), while  ranking_count_num_greater_function(vector) seems a bit clunky.  So how to go from a function to a vector?  Code the function, then create a trait and implment a method for a data structure - and hope and pray that you got lifetimes and lazy functional operations just so. Witness:
    The impl boiler plate to methodize a funtion .. for me, newbie, it burns.  As mentioned in section 5, a primitivegenericvector.mean() function gets real complicated.  It's tricksy to get each detail right for each type situation, and actually easier to just write code for each of the vector primative.  One typo and multiple errors pop up across the impl that in sum do not clarify or point a newbie in the right direction.  I really wish there was a more automatic way to impl![rank_count_num_greater()] for the datatype and memory lifetimes the function rank_count_num_greater already uses.  I sense that there is great power in methods in rust, especially where it comes to extending what rust itself is and can do as a language.  Maybe I'll get a more complete understanding eventually - right now methods seem 'evolving boiler plate code meets deep wellspring of arcane magic' best not for newbies complex.  I'm still lured in by the "Joy to use" and presently risking "newbie burns" with methods every chance I get.    
  7. Another language, more numeration methods.   This is perhaps a complaint about human computer interface, but that CS disconnect issue of 0..10 being what humans think of as First=1  to Tenth=10 and what computers think of the ten elements 0,1,2,3,4,5,6,7,8,9 is unfortunate.  I can't even explain it easily because your human mind will naturally fight to skip the lines filled with numbers.  There are a considerable number of online rust help responses where a stymied rust beginner asks to loop between 1 and 10 and the helpful reply is a iteration of 1..10 (1,2...9) or 0..10 (0,1...9) or 2..9 (1,2...8), and even  sometimes 1..11 (1, 2...10), or ..=10 (0,1..10) or 1..=10 (1,2..10).  Insert hundreds of variant examples here involving for loops, slices , iter() or rand.   Once you start seeing the beginners and helpers make this lingual numeration communication clarification mistake in hundreds of different ways - you start to see it almost everywhere.  I conclude all humans have some weakness for this kind of lingual/CS bait and switch, much like dogs do for squeaky squeeze toys.    Sure, Rust lets you do Std::Ops::RangeInclusive::new(1,10) or Std::Ops::RangeBound::new(1,11) should you be willing to risk conciseness for ~30 additional characters.  So that's better, even if nobody will use it... um... I guess.  Maybe rustfmt auto-comments for undocumented numerical ranges with "// RangeInclusive 0 upto 9" and "//RangeBound 0 almost to 9" would help.   Squeeeeeeeeeeeeeek.
  8. Unsafe.  I approached rust as "learn safe first" bifurcation.  That approach seemed strongly recommended by the rust documentation itself.  That might not be wise, I'm not functioning at the level I want to just yet, and I still need to learn unsafe features to solve certain problems - or just use someone elses crate with unsafe buried in it anyway and cheat myself from learning rust the hard way.   Trying to only write safe rust is a mildly rewarding intellectual puzzle but there is no guarantee that the puzzle at hand actually has "ideal solution” in safe code.   If you need to pass through one of those invisible rust programming walls to solve a problem - just use the unsafe keyword and get to your madness.   I think I'd be farther along in learning rust if I just embraced unsafe earlier and often... but my work doesn't require mission critical safety either.  Unsafe is part of why rust is great.
  9. Cha-Cha-Cha-Changes and nightly only features... also known as "Can't compile the standard library with your incompatible nightly build of rust, so yea, good luck with that."  Rust is still changing from version to version.  Mostly healthy, almost all improvements with few downsides as far as I can tell.  I like the 2018 Use syntax.  I like the error handling sugar ?   But nightly is downright slippery and some nice if unstable features only available in nightly compiles seem destined to stay in nightly, or randomly wink out of existence.   Nightly lured me in with toys and tools I couldn't afford without a next-release rewrites.   Not such a big deal for me, I'm just learning rust with toy programs that I mostly just throw away - but my tip for rust newbie learners is try learning to ice skate on flat smooth ice, not the pretty shifting glacier that is rust nightly.  Nightly (may/could/will?) frostbite you eventually and perhaps in a way that makes leads a newbie to abandon their first rust project.  
  10. Learning rust the easy way requires a community.  Easily the worst thing about Rust might be the people that love Rust, especially when you start rust and get so frustrated with it you are willing to write a ten point blog rant critical of rust and about how python, java or C or Ruby or whatever is so much better than rust because your sorry ass code just runs.  Terrible self serving blog posts like this one that hint at a happy helpful rust community has gotta seem strangely mythical to new arrivials.  If your gut response is “What obvious utter drivel, the low level virtual machines are the same so why would the dev comunity be any different?”, if you are an unhappy troll living in a subterranean server farm or the like and want to share your inner pain with the world, if you are someone for whom the mere notion of asking for help would be difficult -  Rust might not be for you.   But even if you are not a perfectionist, rust may well be absolutely perfect for you.  Easily the best things about rust is near guarenteed correctness at runtime, great speed, safety and concurrency.  Rust's perfectionism is the root of why it requires some mentoring, so if you do manage to learn rust, maybe consider tutoring others as your skills come up to speed.  
Friday
Nov162018

Rust's rand::distributions

Rust's rand crate, a external library for generated randomness, moved from 0.5.5 to 0.6.0 and wow... what new goodies!  There are now ways to generate random distributions that follow a number of probability distributions.  Wow... so many non-uniform probability distributions (Normal, binomial, bernoulli, LogNormal, Poisson, Exp, Gamma, ChiSquared, StudentT, FisherF) are available hinting at genius and insanity obsession at once.  I love it!

Yes, actually love it.  Conceptually at least... still playing with it.  The big book of random (https://rust-random.github.io/book/intro.html) contends rand 0.6.0 isn't crypto grade, but I'll contend it is certainly aiming for full featured.  Slight worries about compile times and new version bloat... Historically rust doesn't seem to be great about take only what you need.  Then again, Rust's cargo library version manager makes my point mostly moot, opt in to an earlier version as you wish.  Almost pure goodness!

 

 

 

Saturday
Nov102018

Rust on Arduino - When will that boulder get to the top of the hill Sisyphus?

This fall I got a fun little Hallowing from Adafruit and thought I'd try to cross compile something in Rust Lang (https://www.rust-lang.org/) for it.  Wow that board is has 48Mhz speed demon with 32 Kb of RAM and and 256k flash rom program memory plus a !8MB! SPI flash drive loads and saves... and a 8192 color 128x128 dot TFT display with 4bit blues and reds and amazing 5bits for vibrant greens.  Easily twice the computational power of your average 1976 mars lander!   

The sorry state of the Rust programming language on Arduino right now is "I am not smart enuff to make it work".   I blindly hope that's changing... perhaps I am merely not patient enough.     I really thought rust+arduino might be a happy couple soon, not all that long ago, and the last AVR Rust language fork was released almost simultaniously with this post so perhaps they are yet destined to be together. (https://github.com/avr-rust).  

I'm a fan of Arduino C, and a fan of Rust.  Rust would be a strong choice for hack hardened electronics - the language is designed to be resistant to memory attacks and undefined states - weaknesses frequently exploited in compiled C.  Executable rust programs run nearly as speedy as C or faster if you can leverage low bar easier to code multithreading in rust.  Rust's no garbage collection means timing could theoretically be more stable for  two wire sync and communication by bitbanging a cpu pin HI and LO without a clock - a common situation for hobbiests aiming for low cost and working with color LEDS displays.)   If your next router was running rust, a good number of security vulunerabilities might just not exist in the way they do now.  Then again, maybe rust wouldn't help since the WIFI Alliance goals for 802.11 compliance were ease of use over security and rust isn't going to fix a security model that evaportates the instant a local USB cord is plugged into a router.

My present barriers to entry:

(1) RUST executable sizes are larger than ARDUINO C.  With effort not double, but still harrowing for a hallowing 32kb system.   James Munn has a great post https://jamesmunns.com/blog/tinyrocket/  on how to  get rust shrinkage.

(2)  I don't presently have projects that really needs Rust's security or parallelism even if I would prefer to write in Rust.  If I take up programmed robotic painting again, a Raspberry Pi with multiple coresc and configured with 4mb of (slow) virtual memory should work for the build on device.  

(3) No Rustified Arduino cross compile IDE exists so far as I can tell, at least nothing like the sweet sweet https://www.arduino.cc/en/Main/Software.  Long arcane configurations and rustc command lines should not deter me, but do, especially when I follow examples and still get "That probably worked a few versions ago type" errors.

(4). Did I mention the "that probably worked a few versions ago with a specific unstable AVR fork off the main rust nightly branch " type errors?  Good news, there's a better way and I just don't seem to be up to speed yet.  Yea.  And I'm reaching for that single thread slow ass Ardino C IDE to do a library search again (The cross platform Arduino C IDE really is execellent in so many ways... super kudos to the Arduino team of Massimo Banzi, David Cuartielles, Tom Igoe and David A. Mellis.  If only they each loved rust... soft wet weeping sound ensues along with the the unformed thought "if only Claude Monet had painted entwined lovers atop just one of his usual pastoral haystacks in contented shades of iron oxide and colbalt turquoise.")

I do want to see Rust come to Ardino, and since it barely, almost, sort of, sputterlingly, has- maybe I should add "and BE EASY!"   I really think Arduino+Rust would make the world better.    I like C, but how much of the worlds computational security woes come from that code base?  Perfectly tallented C programmers write wonderful things that compile and run and still have hidden hordes of gremlins inside.   I really do hope the state of Rust on the Arduino platform changes soon... I'm not quite ready to jump in and swim yet.

I think I started this post in October 2018, as of December 2018 I found this link in RUST 2018 docs that has lots to offer on the subject.  https://rust-embedded.github.io/book/ - a whole book exists that's progress!    

https://techsparx.com/software-development/rust/rust-for-avr-arm-embedded.html - more links and a sense of progress