From b28795e7f7a99938f3f497d784e2b6ab5dab7ac4 Mon Sep 17 00:00:00 2001 From: bnewbold Date: Mon, 27 Jun 2016 12:16:25 -0400 Subject: elm post polished (finally) --- posts/elm-everything-broken.md | 143 +++++++++++++++++++++++++++-------------- 1 file changed, 96 insertions(+), 47 deletions(-) diff --git a/posts/elm-everything-broken.md b/posts/elm-everything-broken.md index 6e86cf6..a9978d1 100644 --- a/posts/elm-everything-broken.md +++ b/posts/elm-everything-broken.md @@ -1,12 +1,11 @@ Title: Everything Is Broken (Installing Elm Edition) Author: bnewbold Date: 2016-05-06 -Status: draft *This post is a narrative rant (in the same vein of Dan Luu's ["Everything is Broken"][danluu] post) about my problems one afternoon getting a Fancy New -Programming Language to work on my laptop. Skip to the end for my thoughts on a -solution.* +Programming Language to work on my laptop. [Skip down](#nowwhat) for my +thoughts on solutions.* [danluu]: https://danluu.com/everything-is-broken/ @@ -20,7 +19,8 @@ solution.* A few folks here at the [Recurse Center][rc] had nice things to say about the [Elm programming language][rc], and after watching Evan Czaplicki's ["Let's Be -Mainstream" talk][0] I got pretty excited also. Let's try Elm! +Mainstream" talk][0] I got pretty excited also. "Let's try Elm!" and the +adventure begins. [rc]: https://recurse.com/ [elm]: https://elm-lang.org @@ -52,9 +52,9 @@ get `cabal` set up, open a terminal and paste a command, etc? --> Weird that these build-from-source directions involve curl-to-file magics. Why not just clone the repo and use a Makefile, which is roughly the same number of -commands to enter? I clone repo and run the script from there instead. I'm on -Debian stable ("jessie"), so installing GHC (the most popular way to use -Haskell) is easy. I seem to have a recent version of cabal: +commands to enter? I clone repo and run the build script from there instead. +I'm on Debian stable ("jessie"), so installing GHC (the most popular way to use +Haskell) is easy. I seem to have a recent-ish version of cabal: 
 bnewbold@eschaton$ cabal --version
@@ -80,8 +80,9 @@ GHCi cannot safely continue in this situation.  Exiting now.  Sorry.
Uh-oh! Not sure what that means. A search returns [a FAQ entry][faq-entry] -about "Duplicate Directions". It doesn't seem like *I* have done anything -wrong. I'll update `cabal`'s package index: +about "Duplicate Directions" which talks about linker flags, but *I* didn't +compile anything by hand so it doesn't seem like *I* have done anything wrong. +I'll try updating `cabal`'s package index: [faq-entry]: https://wiki.haskell.org/GHC/FAQ#Duplicate_Definitions @@ -93,8 +94,8 @@ http://hackage.haskell.org/packages/archive/00-index.tar.gz : ErrorMisc "Error HTTP code: 502" -At first I assumed I was doing something wrong, or maybe the WiFi was flakey, -but it turns out that the Hackage package repository [is +No go! At first I assumed I was doing something wrong, or maybe the WiFi was +flakey, but it turns out that the Hackage package repository [is down](https://status.haskell.org/): > hackage.haskell.org down @@ -105,13 +106,13 @@ down](https://status.haskell.org/):
As far as I know, the only Debian packages out of the huge stable archive which -don't receive security updates are a set of web browser, mediawiki, and all -V8/node.js packages and libraries. +don't receive security updates are web browsers, mediawiki, and all V8/node.js +packages and libraries.
-Well, wasn't even sure if updating my package index would fix the problem. I'll -give up and try npm, which these days has been [sort of -packaged][deb-node] in Debian. I'll just uninstall npm when I'm done +Well, it wasn't even clear if updating my package index would fix the problem, +it was just a wild guess. I'll give up and try npm, which these days has been +[sort of packaged][deb-node] in Debian. I'll just uninstall npm when I'm done installing Elm. I install with `apt` (which pulls in a huge list of `nodejs` packages), but then can finally run: @@ -161,8 +162,8 @@ package, which just installs a symlink /usr/bin/node which points to /usr/bin/nodejs. -Looks like Debian wants to call node.js `nodejs` while npm/Elm expects it to -be called `node`. Ok, I create this shim named `node` in my `~/bin` directory +Looks like Debian wants to refer to node.js as "`nodejs`" while npm/Elm expects +it to be "`node`". Ok, I create this shim named `node` in my `~/bin` directory (which is on my `$PATH`), and make it executable: 
@@ -218,8 +219,8 @@ npm ERR! not ok code 0
 Whoops. There is [a github issue][elm-issue] that has some tips about this: the
 recommended solutions online are basically "upgrade node.js and npm" or
 "disable SSL security". That doesn't sound great, but i'm feeling very
-impatient at this point so I tried disabling SSL checks with npm config set ca
-null`, but even then I get the same certificate error. Enough of that approach:
+impatient at this point so I tried disabling SSL checks with `npm config set ca
+null`, but even then I get the certificate error. Enough of that approach:
 
 [elm-issue]: https://github.com/elm-lang/elm-platform/issues/100
 
@@ -232,21 +233,21 @@ Poking around a bit more, I find the promisingly-titled "`fubar.sh`" script in
 the `elm-platform` repo cloned earlier, which seems to nuke the local user's
 Haskell (`cabal`) stuff (but doesn't muck with system-wide package, eg `apt`
 managed GHC libraries).  After running `fubar.sh` the `BuildFromSource.hs`
-script seems to start working, though Hackage is still down (now, an hour after
-I started this process, approaching 5 hours total downtime), so I can't install
-dependencies.
+script seems to start working (success!), but Hackage is still down (now, an
+hour after I started this process, approaching 5 hours total downtime), so I
+can't install dependencies.
 
 I search for a hackage mirror and find that [FPComplete runs
 one](https://www.fpcomplete.com/blog/2015/03/hackage-mirror).  In addition to
-their directions I had to set `remote-repo-cache` in my `~/.cabal/config`, like
-so:
+their configuration instructions I had to set `remote-repo-cache` in my
+`~/.cabal/config`, like so:
 
     remote-repo: hackage.fpcomplete.com:http://hackage.fpcomplete.com/
     remote-repo-cache: /home/bnewbold/.cabal/packages-fpcomplete
 
 After that I `cabal update` and run the `BuildFromSource.hs` script again. It
 fails to build the dependency `websockets-snap`, but I try installing that
-regularly (`cabal install websockets-snap`) and that works, then all the
+regularly (`cabal install websockets-snap`) and that works, and then all the
 dependencies with BuildFromSource.hs build. Yay!
 
 I still get an error with compiling Elm itself though:
@@ -259,8 +260,8 @@ It [sounds like](https://github.com/elm-lang/elm-platform/issues/30) I am using
 an out of date version of GHC (the Haskell compiler): I have 7.6.3 (the version
 that comes with Debian), and Elm wants 7.10. Fair enough: unlike a package
 manager, I can see how new features in the compiler would be helpful, and when
-I go back and look this is in the README. Fortunately there is a new version of
-GHC in the `jessie-backports` repo, so:
+I go back and check this was outlined in the README. Fortunately there is a new
+version of GHC in the `jessie-backports` repo, so:
 
 
 sudo apt install -t jessie-backports ghc
@@ -289,32 +290,44 @@ bnewbold@eschaton$ elm-repl
 
 Success!
 
-Throughout this debugging experience I had problems with both my external
-[Lenovo Thinkpad USB keyboard][keyboard] glitching (workaround: unplug and
-re-plug) and with WiFi at the Recurse Center disconnecting (workaround: reset
-wifi card). Others here using GNU/Linux have the same wifi problems, but we
-don't have a fix yet... something to do with wireless regulatory zones.
+To be clear, once I got this far I had few or no problems with Elm. The
+language seems reasonably clean and well documented for it's maturity, and it
+was only this install procress that felt horribly broken.
+
+Throughout this debugging process I had problems with both my external [Lenovo
+Thinkpad USB keyboard][keyboard] glitching (workaround: unplug and re-plug) and
+with WiFi at the Recurse Center disconnecting (workaround: reset wifi card).
+Others here using GNU/Linux have the same wifi problems, but we don't have a
+fix yet... something to do with wireless regulatory zones.
 
 It's not all pain though; installing the `elm.vim` syntax highlighting plugin
 was very easy, just a single `git clone` into `~/.vim/bundle/`.
 
 [keyboard]: https://www.amazon.com/Lenovo-ThinkPad-Compact-Keyboard-TrackPoint/dp/B00F3U4TQS
 
+
+
 So Now What?
 ----------------
 
-TODO: dan's auto-testing tips
-
-There was a great long-form blog post by Same Boyer a few months ago
-(["So You Want To Write a Package Manager"][5]) which discussed Rust's package
-manager, Cargo.
-
-[Yehuda Katz and Carl Lerche][6] designed Cargo.
-
-Ironically, given the difficulty I had installing it, the Elm language's
+There was a great long-form blog post by Sam Boyer a few months ago ("[So You
+Want To Write a Package Manager][5]") which describes the jumble of *system*,
+*language*, and *project* dependency manager problems I experienced above. Sam
+basically concludes that Rust's project/language dependency manager (Cargo)
+both encapsulates best practices for dependable and reproducible builds, while
+still allowing rapid evolution of a package "ecosystem". Cargo was designed by
+[Yehuda Katz and Carl Lerche][6], and along with the
+[crates.io](https://crates.io) archive it does sound very nice. My personal
+feeling are usually that system-wide package managers (like Debian's `apt`) are
+underappreciated by many young-but-not-bleeding-edge projects, but acknowledge
+that there probably is also a need for higher tempo cross-platform project
+dependency mangement for non-library projects (eg, desktop applications and web
+apps).
+
+Ironically (given the difficulty I had installing it), the Elm language's
 package manager has a great `diff` tool for checking that any changes in the
-API conform the [documented][8] [semantic versioning][semver] conventions. For
-[example](https://gist.github.com/badboy/a302dd0c9020e5759240):
+API conform to the [documented][8] [semantic versioning][semver] conventions.
+For [example](https://gist.github.com/badboy/a302dd0c9020e5759240):
 
     $ elm-package diff evancz/elm-html 3.0.0 4.0.2
     Comparing evancz/elm-html 3.0.0 to 4.0.2...
@@ -335,9 +348,44 @@ API conform the [documented][8] [semantic versioning][semver] conventions. For
             defaultOptions : Html.Events.Options
             onWithOptions : String -> Html.Events.Options -> Json.Decode.Decoder a -> (a -> Signal.Message) -> Html.Attribute
 
-This change information is then used to *[programatically enforce][7]* the
-versioning rules and prevent a whole class of simple but annoying  breakages
-due to API change.
+This API change information is then used to *[programatically enforce][7]* the
+semantic versioning rules for submissions to the Elm language library archive
+and prevent a whole class of simple but annoying breakages due to unexpected
+API changes. It can't detect *every* breaking change (eg, those which are
+internal), but it can detect enough to be worth the effort.
+
+Another option for detecting fixing breakage is integration testing at the
+package ecosystem level. Debian's [reproducible builds][repro] effort has built
+out one such system, and continues to catch thousands of "failed to build from
+source" (FTBFS) bugs along the way. Dan Luu's ["Everything is Broken"][danluu]
+blog post (which to some degree inspired this one) mostly focused on the lack
+of quality tests for many contemporary software projects, and proposed the use
+of smart fuzzing and heuristically-generated tests to work around the huge
+technical debt this represents. As far as I can tell there are hardly ever
+automated integration tests for entire package archives; blame for dependency
+problems is usually attributed to a bug in one package (instead of being seen
+as a systemic failure), and such problems are seen as an unavoidable cost of
+rapid and distributed development.
+
+I think we can do better. For example, some contemporary languages test
+compiler changes for regressions against a broad snapshot of public code
+written in that language; I know Go and Rust specifically do this to identify
+problems before compiler releases, and the Python community occasionally runs
+tests against the PyPi archive when considering syntax changes or feature
+deprecations. And Debian's unstable and testing archives enforce a waiting
+period so that human testers can turn up conflicts before packages can be moved
+into stable or backports. I think we can and should automate these processes as
+much as possible, and give direct feedback to library developers and package
+maintainers when they push updates. Commercial Continuous Integration services
+like Travis CI and Circle CI should offer more common target platforms (eg, ARM
+architecture, more versions of distributions), and if they don't we should
+build and host our own testing infrastructure. CI builds scripts should closely
+match the official installation instructions for a given platform, so we catch
+problems with those instructions quickly.
+
+We have more and more developers in the world wasting more and more days
+wrangling with dependency hell, but despite that I think we're closer than ever
+to taming the beast.
 
 [5]: https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527
 [6]: https://mail.mozilla.org/pipermail/rust-dev/2014-March/009090.html
@@ -345,6 +393,7 @@ due to API change.
 [8]: https://github.com/elm-lang/elm-package/blob/master/README.md#publishing-updates
 [semver]: http://semver.org/
 [appcheck]: http://www.linuxfoundation.org/collaborate/workgroups/lsb/linux-application-checker-getting-started
+[repro]: https://tests.reproducible-builds.org/debian/reproducible.html
 
 

 
-- 
cgit v1.2.3