CH

December 29, 2016

Arrival

Filed under: film — Benjamin Vulpes @ 9:04 a.m.

I rarely attend the cinema, but when I do it's for films with lots of any combination of shoosting, large-scale (mostly CGI, these days) sets well-served by the large screen, titties, robots, fucking, aliens, and the orgiastic liberation of chemical energy through through a Cambrian diversity of Internal Combusion Engine variants and the hysterical contraptions to which humans bolt them. The trailer for Arrival1 featured aliens and US Military trucks, and so made it to the qualifiers on a bye.

It scores poorly on the shoosting and general excitement front, outshone egregiously by the trailer for Valerian and the City of a Thousand Planets which in one short minute and a half features tekmological shoosting, stabbing contests, aliens, and titties, not to mention sci-fi transformers of mysterious potential energy into kinetic energy2 but even that only entertaining insofar as it reminded me of the trailer for the second Guardians of the Galaxy3 which features not just shoosting and titties but ALSO Dwayne "The Rock" Johnson delivering the best lines in a trailer released in 2016 for a film scheduled for 2017:

Psychic: If I touch someone, I can feel their feelings. You feel...TOUCHES LEAD...love.
Male Lead: Yeah, I guess I feel a general, unselfish love for just about everybo--
Psychic: No! Sexual love!
Male Lead: No, no I don't.
Psychcic: For...SWIVELS, LOOKS AND THEN POINTS AT FEMALE LEAD...her!
Male Lead: No...
Dwayne "The Rock" Johnson: LAUGHING UPROARIOUSLY: She just told everyone your deepest, darkest secret!
Male Lead: Dude, come on. I think you're overreacting a little bit.
D "TR" J: You must be so embarrassed! LAUGHS MORE
Male Lead: IS EMBARRASSED
D "TR" J: POUNDING HIS CHEST: Do me! Do me!

Arrival is an excruciating ode to the holy mother's spring sacrifice. Instead of dazzling with feats of shoostment, punching, swordplay, or skillful maneuvering of ICEmobiles, Arrival wallops one incessantly with the great sacrifice of parenthood and just how far woman will go for her babies, especially if that baby is everyone and the sacrifice just the guy she hooked up with that one time when everyone got real stressed out about aliens.

Arrival is a lovely treatment of a story I'll probably never read, doing fair service to the original's devices while still kowtowing to the American demand for a twist or reveal in the last two acts. The sound work is downright excellent when the aliens aren't making noise, most of the visual work entirely serviceable, barring the poorly rendered encampment & artifact flyover with clouds moving at entirely the wrong speed whose inclusion I can only chalk up to nepotism. Not only is the flyover render bad it also goes on forever demanding the audience just fucking sit there and suffer through its poverty of execution for holy fuck like three minutes.

I attended, paying homage to Youthful Hijinks of the Author. I can't imagine what anyone else might get out of it.

  1. 2016, Denis Villeneuve. []
  2. What disappoints me most about sci-fi/action movies as I grow fat and poor is that my ability to suspend disbelief just...droops when I regard the marvelous interstellar conveyances in ways that it simply does not when someone entertains me with feats of ICE -- even if the feats are entirely simulated! That I have firsthand experience with the dissipation of energy through modest engines of four, six, and eight cylinders and bodies representative of that to which they're typically attached makes, for some reason, even the simulated romping of vehicles bound to the rules of physics just a little bit more real for me. Taxes the willing-suspension-of-disbelief muscle just a little less, if you will. I don't rebel against technological firearms in quite the same way, as they don't flagrantly contradict the constant order-of-magnitude estimator running constantly in the back of my head. Smith's "Tiny Cricket" is an excellent gag in this vein. []
  3. A corn-syrup entertainment franchise for which I have a perverse fondness rivaled only by my fondness for Coors Lite, which is actually waning these days as I've discovered the glorious commodity Willamette Valley grape. Did you know that if you blend fermented grapes with terroir into other fermented grapes with terroir you get MORE TERROIR? []

December 28, 2016

vpatch adding multi-channel support for trinque's ircbot and logbot

Filed under: common lisp, programming — Benjamin Vulpes @ 11:10 p.m.

Notice, January 8, 2017:

THESE VPATCHES DO NOT APPLY CLEANLY THROUGH A STRICT V IMPLEMENTATION

I discovered tonight that I ground these patches incorrectly. Full story in the logs (it is a short, must-read synopsis of a stupid mistake I made in grinding these vpatches).

Life's roadmap winds long, detours riddle it, dead-ends dog it, corndogs may be found in odd appendices along with the odd Coors Light. One of the waypoints (to relay blocks via irc to #chainstate on Freenode and to maintain my own #trilema logs) is an irc bot with multiple channel support. trinque did the bulk of the work with a 1-2 ircbot/logbot combo, for which I am pleased to present signed vpatches adding multiple-channel support.

replacement vpatches

I've taken these vpatches down to avoid confusion. You may find the originals at phf's viewer, and the updated versions at the replacement page.

ircbot

The changes to `ircbot' are relatively simple. I renamed the `channel' slot to `channels', and updated the connection/reconnection logic to map over the list of channels, connecting to each.

logbot

Surgery performed on logbot went a bit deeper:
- updated the schema definition such that messages sent over the `pg_notify' channel contain the message target (eg the IRC or handle to which a message is addressed) instead of the message text, so that the broadcasting process can relay it correctly
- updated `get-and-purge-outbox-messages' to accept a `target' parameter, which it uses to find the relevant outbox messages
- updated `logbot-send-outbox' to accept a `target' parameter
- updated the `logbot' class to use `channels' semantics in place of the previous `channel' semantics

I've been running this in production for a few weeks now, and it powers my loggotron. The thing currently doesn't record privmessages or ACTION items, so trinque's working on a patch that will save all raw protocol messages instead of parsing them into text and then selectively saving some.

veh patch: hashes_and_errors.vpatch

Filed under: common lisp, programming — Benjamin Vulpes @ 12:54 a.m.

First, the meat:

hashes_and_errors.vpatch
hashes_and_errors.vpatch.ben_vulpes.sig

Now, the potatoes:

The following vpatch modifies my original V implementation as follows:

Over 5x speedup of press operations:

; compiling file "/home/b/common-lisp/veh/veh.lisp" (written 27 DEC 2016 11:47:45 PM):

; /home/b/common-lisp/veh/veh.fasl written
; compilation finished in 0:00:00.076
VEH> (time (press :press-root "/home/b/src/tmsr/trb" :target-dir "scratch" :head "makefiles.vpatch"))
No signatures found for patch mod6_privkey_tools_wBeginHeight.vpatch
Evaluation took:
  15.533 seconds of real time
  4.467000 seconds of total run time (0.175000 user, 4.292000 system)
  [ Run times consist of 0.014 seconds GC time, and 4.453 seconds non-GC time. ]
  28.76% CPU
  22 lambdas converted
  51,647,726,990 processor cycles
  2 page faults
  14,880,672 bytes consed

#<SB-IMPL::PROCESS :EXITED 0>
; compiling file "/home/b/common-lisp/veh/veh.lisp" (written 27 DEC 2016 11:48:55 PM):

; /home/b/common-lisp/veh/veh.fasl written
; compilation finished in 0:00:00.091
VEH> (time (press :press-root "/home/b/src/tmsr/trb" :target-dir "scratch" :head "makefiles.vpatch"))
Evaluation took:
  2.413 seconds of real time
  0.874000 seconds of total run time (0.153000 user, 0.721000 system)
  36.22% CPU
  32,620 forms interpreted
  22 lambdas converted
  8,021,794,410 processor cycles
  21,115,072 bytes consed
T

Achieved by filtering the list of signatures to consider when verifying a vpatch down to those whose filenames contain the filename of the vpatch in question.

Compares hashes after applying every patch.

Originally, I intended to use the Common Lisp Ironclad library for hashing files, but ran into the following crazy:

b@hnm ~/src/tmsr/trb $ sha512sum /home/b/src/tmsr/trb/scratch/bitcoin/src/bitcoinrpc.cpp
a1812ac4e4425986e8574ebf837c6b1a84e4772e01b46e4e1caef098496226f7321a3fabc5249b55ce6365863f2c25fef0005f4bcde7188603b0805c77256bc0  /home/b/src/tmsr/trb/scratch/bitcoin/src/bitcoinrpc.cpp
b@hnm ~/src/tmsr/trb $ sha512sum /home/b/src/tmsr/trb/scratch/bitcoin/src/test/util_tests.cpp
1360397ac0c494d5003656deb41494de4480c56bbe46254a09f193682a9e7813fe133a45c93699835e6de89951c350ad2a7e59bcf8b1307a7670cc1db5f22e24  /home/b/src/tmsr/trb/scratch/bitcoin/src/test/util_tests.cpp

---

VEH> (byte-array-to-hex-string (digest-file :sha512 #p "/home/b/src/tmsr/trb/scratch/bitcoin/src/bitcoinrpc.cpp"))
"a1812ac4e4425986e8574ebf837c6b1a84e4772e01b46e4e1caef098496226f7321a3fabc5249b55ce6365863f2c25fef0005f4bcde7188603b0805c77256bc0"
VEH> (byte-array-to-hex-string (digest-file :sha512 #p "/home/b/src/tmsr/trb/scratch/bitcoin/src/test/util_tests.cpp"))
"174fbbb374a2052d62922dc1f48748f1b4693c40ce7bda05e5d9022bf0618f717caf5a173023d3fbd0ac5a52f9effc64116fac1310d546dd68d3f073e6b08e20"

That's right, the Ironclad I had on disk hashed *some* files correctly, and *other* files incorrectly. The ever-attentive phf pointed out that this had been fixed within the past 2 years. I thought for a bit and solicited input from the forum on hashulator tradeoffs, electing to fall back to the Drepperific `sha512sum' until such a time as I either pillage SHA-512 from Ironclad or reimplement it myself.

Anyways, this modification checks file hashes for every file touched in every patch, after every patch.

Error handling for external programs

You'll note that I wrap `sb-ext:run-program' with some lightweight error handling. It quite simply checks the process exit code, and signals an `external-program-error' condition if the external program didn't exit with a 0. You can see in `verify' where I handle the `external-program-error' condition, inspect the program's stderr for a magic string ("BAD signature"), and then either signal a more specific condition (`bad-signature-error') or allow the previously-signaled condition to bubble through. Tidy little use of the CL condition handling system.

As a part of this, I also tidied up the semantics around running external programs in veh. This was necessary to pass in stdin arguments (for patch), and to remove a few ugly `(apply #' run ...)' stanzas.

Misc.

- excised a few comments
- `press' exit value is now either T or a condition, if signaled (and not the return value of `rm')

I intend to put V down for a while, barring patches to address outright showstoppers that need fixing. Publishing vpatches frequently isn't necessarily A Good Thing, tickles the programmer's desire to feel relevant and as though he's contributing when it's more likely he's just shuffling deck chairs around; much fun can be had sailing with a steady wind abeam and a glass of rosé in hand.

December 27, 2016

"How To Learn Programming"

Filed under: philosophy, programming, software development — Benjamin Vulpes @ 8:28 a.m.

Don't worry, I'm not going to give you any useful pointers. As a matter of fact, if you read this and walk away completely deflated and as though I've torn the inspiration to make a career change from your hands, we'll both be better off. I'll have fewer kids working for starvation wages and reinventing all of JavaScript every year and a half saturating my marketplace, and you'll be spared all sorts of personal tribulations and the crippling insanity that comes of intimacy with modern computing1. You shouldn't learn Python, you shouldn't learn Ruby (let's be real, you were just going to use Rails anyways), you definitely shouldn't learn JavaScript, and if you value the power of independent thought, also avoid products of the cube farm like Java and Swift/Objective-C2.

That said, since you're here and reading this nonsense, I'm going to go out on a limb and assume that you're not of the brain-dead crab-pot postulators of such pap as "there's no such thing as wide variance in human ability at a broad spectrum of tasks, all competence can be traced to genetic predisposition to competence at the task in question", are in fact a smart cookie willing to work your ass off for meagre dopaminergic rewards in the short term, and have a passing interest and some amount of learned skills that make you, as the numbskull linked above might say, "good at computers". Perhaps someone even told you that you might eke great piles of loot food credits from Capital's demand for more Labor to turn its ever-multiplying cranks of complexity. None of that will be enough: you'll need tenacity, a solid dose of ability to pretend that some things are true while pretending some other completely contradictory things are also true, a healthy disregard for public opinion (if you want to preserve your sanity), and a historical bent so that you may at least work to build the leg up on the rest of the market that is grokking the historical reasons behind why Android sucks so fucking bad. Moreover, you'll need practical reasons to soldier through the nonsense, like a fearless leader or the promise of untold wealth. Pure fun or "joy of it" will get you precisely nowhere, when it wears off and the slog proper begins.

"Programming", as the touchscreen-using public knows it, consists nearly entirely of building soi-disant "apps". This domain decomposes into an enumerable set of subdomains: browser user-interface development ("webapps", "javascript apps", "single-page applications", "mobile-first websites", and more recently "React", "Elm", "Vapor" and other friends. Same old show, new cast of characters.), server-side development ("microservices", "Django", "Docker", "Rails", "Node.js"), and (generously) "operations" ("DevOps", "NoOps", "ContainerOps"), and "native" development ("React Native", "Atom", "Balompagus", "Objective-C", "Swift", "Java")3. In-browser UI development reduces to "some JavaScript that draws shit on the page and talks to backend services", "backend services" reduces to "a thin layer of glue code that handles HTTP requests, retrieves data from a data store (typically SQL4, although there are very fun mistakes to make in this domain as well), and then transmutes that data into a response to the original HTTP request". "Native development" reduces to "figuring out how the fuck to imitate AirBnB's latest nightmare of complexity with the fewest lines of code and most adherence to how Apple or Google want you to build that kind of "experience" (gag) on their respective platforms.

Building "experiences" (barf)5 in the browser is an unmitigated disaster. You can't really understand how miserably fucked up building "apps" (as the public call anything with buttons on a screen at which they can paw with their grease-coated sausages6) in the browser is, you must understand where browsers came from and how they evolved into the shitshow you haul around in your pocket every day. In the beginning, there was plain text. Then, some people structured that text, wrapping paragraphs in <p> (known as "markup") to indicate that they should be styled as paragraphs, using other markup for eg lists, and so on and so forth7.

So take a step back and think about what your browser is trying to do under the hood: take some text, marked up with various tags, apply some visual rules to it with CSS, and then execute COMPLETELY ARBITRARY CODE to oh you know maybe rearrange the ordering of lists, or replace your cursor with a spinning dick blowing loads whenever it draws over the character V or T, or oh I know pre-validate that you put a credit card number into that form input so that we can save ourselves a round trip to our servers from the user's browser. That's totally a good reason to shoehorn an impossibly bad programming language into the browser, mhm.

Fast-forward a decade. Web sites are passé, and people want at the very least "responsive" websites, and ideally "mobile first experiences" (drink). This means that the website that once needed to render nicely and quickly at 600x800 and maybe a few larger monitors now needs to look good on the 15" Macbook Pro Retina monitor (a monster of pixels, owned by everyone involved in "experience design", that no actual customer owns and yet whose pixel-count drives ~all design considerations in the industry), the Nexus Pucksell with its trapezoidal screen, the iPhone 7XXL with nearly the same number of pixels as the 15" Macbook Pro Retina but that uses an entirely different user interface built around poking at buttons drawn on a screen rather than pointing and clicking with a mouse and typing with a keyboard, and miscellaneous 4-year old Android phones that the User Experience expert in question has around from his last job but doesn't use any more except when he wants to make his devs lives miserable. On small budget projects.

It gets worse: because everyone involved in web dev was fathered by the kinds of neutered not-thinkers that women in America must settle for and the women aren't smart enough to have the children sired by actual quality sperm that didn't come from their meal ticket out of some perverse adherence to the local traditions of Beer, Monogamy, and Sports, your website won't even feel slow to the average cell phone user until you serve over a dozen megabytes (That's rather a lot of bytes. The last time I checked, the CH homepage clocked in at a trivial sub-30 kilobytes [kilo, mega, giga...you do recall the SI names for orders of magnitude from your elementary education, don't you?]) of uncompressed JS and CSS that you probably aren't even serving to clients anyways. This means that there is zero pressure for people to build lightweight websites anymore, which pretty much guarantees that nobody building websites is even going to think about the repercussions (either performance or security!) of pulling in a library to trim whitespace off the beginning of strings. For example.

So that's "the frontend". A soul-killing hodgepodge of 3 "programming languages" (HTML for the text and its structure, CSS for an approximation of what it should look like, and JS for responding to user input like clicks and taps), executed all together by "The Browser" and differently by each browser. Obviously (or perhaps not obviously, I have no idea how much you know about how your apps work), these things running in the browser have to get their data from somewhere. That somewhere are your "backend services".

"Backend services" are, well, Wordpress in other languages. All systems evolve until they can send mail, and all programming languages evolve until they reproduce a Wordpress-like Content Management System (CMS). They're of variously (I hesitate to say "great", but maybe) "less heinous than the alternatives" (will suffice) quality, where "the alternatives" are the poor Drupal framework. Which you don't want to use, unless you have some amount of cause to use it and Jesus fuck surely there's a programming language you like more than PHP, right? Anyways, all that WP does is respond to requests for web pages with data from its database wrapped up in HTML. Maybe with some CSS. JS if you hired someone to make a modal or a carousel or some other Web 3.14 inanity happen to your website (which, don't. It'll break in a year and you'll be out another 3k. Plus they always look horrible). Funny story, I recently heard tell of a Wordpress plugin that pulled in an entire JavaScript framework to render a modal. Does it serve that JS on all pages or just the ones where its modal is active? Was the JS compressed? GOOD QUESTIONS, KIDDO.

I digress. Backend services respond to HTTP requests with data from the database. Sometimes they write data to the database. Sometimes they poke other backend systems. Generally, though, they're "the pure function of the server: glorious, stateless, and without any user-interface cruft", to paraphrase a man who taught me much. Backend systems, eschewing as they do the complexities of managing user interface state are far simpler systems to build and maintain that clicky-pointy-tappy UI's. Every language used in serious force for web development (some languages are not, believe what you may) features one of these mega frameworks in which other web devs have encoded their knowledge and best practices around building web applications. In Python one has Django, and in Ruby one has Rails. PHP has Yii, and I hear that PHP is an entirely adequate(ly) object-oriented programming language these days, so who knows maybe that's a thing the budding webdev might consider using, except for how don't.

Finally, there is the wasteland of "native application development". Once upon a time this was just "software development" after the phrase was bastardized to mean "software running on consumer desktops" and not "missile control systems", but the poor notion's been degraded even further to now signify any drawing of buttons on a screen by any old monkey anywhere. It's not like she cares about the degradation, she's just happy to be with someone who can pay for dinner and maybe a kid. "You're a software developer too! Don't listen to what those mean guys on the internet say, I love you and that's all that matters." Not that any of us could afford to educate a kid in this America, but fuck I digress again.

"Native App Dev" is a glorious term for reading through Apple and Google's documentation for how to build list views and swiping image carousels on iOS and Android and then copying code from Stack Overflow that you can sorta-kinda beat into doing what the designer on staff has demanded, all naïve of the actual engineering constraints in play. Building UIs in this fashion is mostly configuration, if you can keep your designers on a tight leash and force them to design things that fit into the (admittedly inane) touch paradigms of the two platforms.

Building apps in the browser sucks, but at least a million people are out there sorta willing to lend the five brain cells they have left after playing in rock bands through their forties in resolving your problems with JavaScript and `undefined'. Plus it's sorta this weak Lisp Machine knockoff where you can kinda look at ("inspect") the web page and Chrome or Firefox will make a cursory attempt to tell you why the p tag doesn't have the spacing you might want it to have. Moreover, once your "browser apps" grow in complexity to the point where you're maintaining user state and redrawing things based on what you want to show them...well, at first you'll want to use a framework like React to get you 90% of the boilerplate you don't know that you need yet but the odds are solid that in two or three years you'll look back at whatever you built and curse fluently at the time you wasted using bloated toolkits. Nevermind that the only reason you built "apps" of the scale you did on your first dabblings is because all of the hard stuff was handled for you. Granted, you'll have a better notion of how badly those libraries handled it and with opinions and assholes in hand you'll set out to begin another cycle of the Great JavaScript Circle of Life where someone who's only ever built UI's in the browser with JS finally gets fed up with it all and decides to write the One True Frontend Framework to Solve All Everything That Sucks About Building UIs In The Browser. Hopefully you read this first and realize that contributing to the Circle of JS/Life is not actually a worthy use of your time.

Building apps for iOS and Android is no better; you're stuck in the hell that is Other People's IDEs (Integrated Development Environment, handling compilation and code browsing and documentation and autocompletion and all the civilized niceties that Emacs provides poorly and only after extreme customization). Java has the advantage of a compiler over JavaScript8, but it's pretty easily tricked and moreover Java the language is pretty repulsive to the aesthetically-inclined. Objective-C has over Java that...it has a C-like syntax? And is tangentially related to the Legacy of Steve Jobs? I suppose there's the hot new jam of Swift, and if you bite off that mountain of lurking WTF let me know what you find; all I learned in building Swift apps is that Apple apparently can't ship a compiler/IDE toolchain that doesn't require regular restarts9.

Backend systems are the refuge of those inadequate for the task of building end-user interfaces, and of people who recoil from the notion of building user interfaces (due to aforementioned insanity in technology choices). "Nope", one guy demonstratedly capable of building iOS and Android systems told me one time, "I simply will not build mobile applications." One wonders "why" for approximately five minutes, and then realizes that a high-performing backend dev in the SV-driven market pulls down just about as much as your typical high-performing frontend dev -- and without all of the insanity of user interface development (the "technology" choices are bad enough, but have you ever met a self-styled user-experience visionary?). This odd confluence of the derpiest and some of the sharper knives (in the sense that they have a stiff internal resistance to dumb shit, and a nose for finding it) breeds such monstrosities as Rails (grasshopper, explaining the ways in which Rails development wears on my will to live is beyond the scope of this piece, but let it suffice to say that I recently saw the following line of code and recoiled in horror: `authenticates-with-sorcery!'). Most appealingly, you get to work with sane-ish linuxes, and your systems remain stable while the suckers working in the browser and on iOS and Android chase every single operating system release with if not actual slavering excitement then full-bore Stockholm syndrome.

However, despair not. There are other "kinds" of "programming"! You could configure SharePoint websites for any of a million small/medium business with SharePoint websites. This will also make you a Microsoft stoolie, and unfit for civilized company. Also you'll be stuck with the same problems. SalesForce idem, although I don't think you have to buy the Microsoft party line to hack on their shit. You could get a plain-Jane analyst job, and then apply your not-insignificant thinker to solving business problems with technology, and nobody would tell you which languages you had to use. Shit, I know options houses with Excel spreadsheets that take an hour to run, and that's after hand-optimization.

Or you could move into the "embedded" space, and compile programs in whatever language to run on tiny devices in the "Internet of Things". Making software to run on smaller and smaller chips is an excellent career bet for the next decade, as corporate focus moves from the "one person, one device, one chip" model to a rat-king of devices infiltrating every aspect of American life.

If you're really ambitious, you could even shoot for an actual auto-didact's "Computer Science" degree. Just keep in mind that if you do this correctly, you'll not "learn programming" nearly as much as you'll learn about theories of computation. Two litmus tests: if you write a single line of code in your first semester, you got scammed; and if you don't know the lambda calculus and its combinators by the end of the third semester, idem.

The point that I apparently need at least one more glass of wine to get out is that you'll need to pick a project to "learn programming" in the context of. If you know statistics, pick up a book on what's called "Machine Learning", but is really just applied statistics, and start working through the exercises. If you've already got the hang of physics and the related mathematics, consider writing a simple physics simulator. If you want to see the results of your work, consider building a simulation of agents controlling physical objects in a simulator someone else built, like in the game development program Unity.

If you have utterly no fucking idea where to start, consider buying a Raspberry Pi and beating it into a robotic cat feeder. You might not ever finish the project, but you'll either learn how to learn how to work with the linux shitshow or you'll flunk out of computer-related auto-didactery 101.

The point is that one cannot "learn programming" quite so simply as asking "how do I learn programming". Rather, you must have a place you're trying to get to, whether that's making more money than you otherwise might or solving problems that are just too tedious to solve properly in Excel.

In any case, you really shouldn't "learn programming". The world doesn't need more programmers, and you don't need to wreck your head on the shoals of Von Neumann and his band of merry mongols. If you insist, though, I'll be here. Don't expect me to help, though, this ain't Stack Overflow.

  1. You either go batshit nuts and move to a cave, hook up with crypto-terrorists like The Bitcoin Foundation, or retreat into the soft embrace of Dunning-Krugerism telling yourself that "this is fine, man", surrounding yourself with other middling schmucks all the while merrily self-deluding yourselves into the kind of complacency that makes crushing a six pack in front of The Game so damned seductive for the typical American male. []
  2. The joke's on you if you think you're "just going to learn Swift...". There are a few decades of internal Apple API's that'll need rewriting before you don't accidentally absorb some Objective-C on your way to Swift "mastery". The joke's on me if you write your app in Objective-C and then come crying for help. []
  3. Pop quiz: which of this paragraphs parenthetical appellations did I make up? []
  4. Another of those hoary old languages that refuse to die because they're just so miserably adequate for the tasks to which humans put them. []
  5. The degree and earnestness with which people lie to themselves about their work ("user experience visionary", "Full-stack JavaScript engineer", "Rails guru"), is a strong proxy for the quality of the work they produce, its utility to the market, and in precisely which market they hawk their goods and services. []
  6. True story: the extremely large iPhones exist to capture the bariatric market. []
  7. There was a whole pile of crazy around documents referring to other documents, semantically organizing the world's knowledge, it got as full-bore tin-woman as you might expect with very bad results). Eventually, some well-intentioned asshole (funny how it always goes the same exact way. Every. Single. Time. ) in search of a solution to some specific problems but not smart enough to evaluate the implication of his design on the world then applied a healthy dose of Cascading Style Sheets (henceforth CSS) to the Hypertext Markup Language (henceforth HTML) and turned browsers, which until that point had not done a whole lot to style the web pages shown to users into a so-bad-it-came-out-the-other-side-into-amusingly shitty knockoff of InDesign (This is unfair to CSS. Inline styling was a thing, and picking the right resolution of technical accuracy for a good read is hard.). To compound all of the above, someone decreed (this would have been at the height of the Browser Wars) that their company needed something other than the Java applets that were a) in use and b) causing all sorts of havoc at the time (It may sound crazy to someone "learning programming" in the dusk of 2016, but people loaded and executed Java code into their browsers "once upon a time". That you don't find this a laughably bad idea on its face should start to give you an idea of the yawning chasm of crazy you'll have to eat if you want to "learn programming".) . Thus was born JavaScript, a crime for which many are liable and will likely only discharge their debts by providing entertaining deaths []
  8. Now that you mention it there are comtranspilers for JavaScript that turn a sane-ish language into valid JavaScript. There's PureScript, TypeScript, ParenScript, and ClojureScript JUST TO NAME A FEW. One could in theory compare the different $LANG_THAT_TRANSPILES_TO_JS but by the time you got through the top three entries on your list the JavaScript "community" would have moved onto another one and showstopper bugs would emerge in the three you tested and do you begin to understand why I think that opening your wrists might be a better use of time than "learning programming"? []
  9. It's so bad that I actually got into the habit of preemptively quitting Xcode because its auto-completion backend would crash and never notify me. The easy and humiliating solution was simply to restart Xcode whenever it failed to complete symbols I was typing. And yes, before you ask, I'd quit Xcode regularly expecting the autocompletion framework to work again on reboot only to discover that I'd mistyped the symbol prelude. Such is the cost of shitty tooling. []

December 22, 2016

veh.lisp genesis.vpatch

Filed under: bitcoin, software development, tmsr — Benjamin Vulpes @ 11:06 p.m.

At phf's prodding, I present in this post a genesis vpatch and corresponding signature for my Common Lisp implementation of asciilifeform's V. In case you've forgotten, V is a hard-crypto software source distribution tool that gives The Republic delightfully hard guarantees about who has endorsed what changes to a software project. Details are here: V-tronics 101.

It is useful for code-savvy folks in The Republic to reimplement basic tools like this. Multiple implementations of an ambiguous specification provide far more value than the "many eyes" mantra of open source advocates. For example, an implementation in Python might burn the eyes of a Perl hacker, and the Perl be entirely inscrutable to a man who's never touched it before, and even were such a man to sit down and learn Python for the purpose of auditing another's V implementation, it is in no way obvious that the time cost of his learning the language combined with the risk that he misses details in the audit is a better resource expenditure than simply implementing the tool again in his language of choice. Multiple implementations provide the Republic defense in depth, in stark contrast to the Silicon Valley software monocultures, and demonstrate to the Peers that the authors understand the goals and subtleties of the project in question.

phf did not just prod me to post my implementation, however. The charges are serious, so allow me to quote in full:

phf: ben_vulpes: this subthread since your response to my original statement is one example of what i'm talking about. in this case none of the v implementations are on btcbase, because nobody wants to sign own hacks, because the cost of failure is too high.

For an example of just how this notion that "the cost of failure is too high" came to be:

mircea_popescu: to put it in you'll have to sign it. if it turns out later to have a hole, people will negrate you.

To contextualize phf's comment properly: the man set up a spiffy loggotron (the one I cite here constantly, actually) and then hared off to the desert for a few weeks without ironing some stability issues out first, which left us without logs for a bothersome amount of time. While kicking a process over may be acceptable (in some contexts, on the deficit budget the Republic operates), that style of process monitoring and uptime insurance only works if someone is available to restart the process in question whenever it goes down. Which it wasn't, and for which he was roundly scolded upon his return.

So yes, the reputational costs of operating critical infrastructure (in phf's case, the canonical log of the Forum's dealings) for The Republic and then letting that infrastructure fail is rather steep. Note, however, that he has since ironed the stability issues out and the whole episode largely left behind. No negative ratings were issued as a result, that's for damn sure.

The brouhaha that kicked off my rewrite of my V implementation is barely worth going into1 but for four details: the discovered bug was not a hole, but required that an operator attempt an action actively harmful to their own health; the implementation's author fixed the problem in short order; was already a member in good standing of the #trilema Web of Trust; and the issue was discovered by members of the Republic and not leveraged into an attack.

Much of the Republic's otherwise incomprehensible-to-outsiders behavior may be chalked up to precisely this sort of "trust building exercise", and there is no way to build a nation of men but this way. A strong reputation buttresses a sapper against charges of treason, leaving space for the WoT to entertain the notion that the sapper is not treasonous but has merely made a mistake. Moreover, fear of failure's repercussions must always be evaluated and mitigated in the same way that one performs security analyses: "What are the downsides here? How might these changes fuck my wotmates? How pissed could they reasonably get at me for hosing them thusly? How would I respond to allegations of treason?" Not that anyone's on the stand for such, but one must entertain the gedankenexperiment.

So, in the spirit of:

phf: but the reason i made those statements yesterday is because i think that like saying things in log is an opportunity to be corrected, so does posting a vpatch, it could be a learning experience. instead the mindset seems to be http://btcbase.org/log/2016-02-20#1411214
a111: Logged on 2016-02-20 22:45 phf: "i, ordained computron mircea lifeform, in the year of our republic 1932, having devoted three months to the verification of checksums, with my heart pure and my press clean, sit down to transcribe vee patch ascii_limits_hack, signed by the illustrious asciilifeform, mircea_popescu, ben_vulpes and all saints."

I am proud to publish a genesis vpatch for my own V implementation in Common Lisp. It is a "harem-v" (which is to say a V implementation that this individual uses in the privacy of his own workshop, and may not suit your needs or even desires), but I daresay that it is correct in the important places. Even if it is wildly incorrect in those important places, it demonstrates quite completely that The Republic outperforms classic "open source" communities by reproducing and spot-checking each other's work instead of pretending to read it and only ever actually grepping for hateful words in order to be a most respectably-woke Github contributor. I also offer it in the spirit of the above log line: to seek correction and feedback on best practices from peers more competent with the parens than myself.

genesis.vpatch
genesis.vpatch.sig

Updated 12/27/2016 with hashes_and_errors.vpatch

hashes_and_errors.vpatch
hashes_and_errors.vpatch.ben_vulpes.sig

One simplification from v.pl and v.py that I made in this implementation is that I iterate naïvely through all of the signatures (until one is found that verifies) when confirming that a patch has a signature from wot-members, rather than sorting the list of patches and signatures and making assumptions about patch/signature naming. This slows `press' operations down significantly, but `flow' calculations complete nearly instantly.

Enjoy! If you find anything heinously wrong, do let me know. I shan't be falling on my sword over it, but I will fix it if you can show me that it is in fact broken.

Updated 01/04/2017 with 2017_cleanup.vpatch

2017_cleanup.vpatch
2017_cleanup.vpatch.ben_vulpes.sig

  1. tl;dr: a V implementation was willing to press to heads for which it had no signatures. Its author has since remedied that. []
Older Posts »

---