jasone

Check out the creative use of emoji in the running header!

Been there, done that. I published my doctoral research code [1] so that others could inspect, verify, replicate, extend, etc. YMMV, but the feedback I received from other researchers ranged from neutral to surprisingly positive (e.g. people using it in ways that pleasantly surprised me). But let me expand on my own experiences while developing that software, trying to figure out how to replicate the then-current state of the art.

At the time there were two widely used software packages for phylogenetic inference, PAUP* [2] and MrBayes [3]. The source code for MrBayes was available, and although at the time I had some pretty strong criticisms of the code structure, it was immensely valuable to my research, and I remain very grateful to its author for sharing the code. In contrast the PAUP* source was not available, and I struggled immensely to replicate some of its algorithms. As a case in point, I needed to compute the natural log of the gamma function with similar precision, but there was no documentation for how PAUP* did this. I eventually discovered that the PAUP* author had shared some of the low-level code with another project. Based on comments in that code I pulled the original references from the 60s literature and solved these problems that had plagued me for months in a matter of days. Now, from what I could see in that shared PAUP* code, I suspect that the PAUP* code is of very high quality. But the author significantly reduced his scientific impact by keeping the source to himself.

[1]: https://github.com/canonware/crux

[2]: https://paup.phylosolutions.com/

[3]: http://nbisweden.github.io/MrBayes/

Per the comments on that blog post, this was previously discussed on HN: https://news.ycombinator.com/item?id=14170041

Corrected link: http://donw.io/post/github-comments/

I emphatically disagree -- compile times are definitely on my short-list of worst things about C++. Long compile times disrupt flow, and it requires great ongoing mental effort to work around slow compilation.

Here's a poignant anecdote. At one point while working on HHVM at Facebook I finally snapped, spent 2-3 days doing nothing but optimizing the build system to speed up trivial incremental compilation (e.g. a whitespace change). My efforts resulted in... 24 seconds best case. I spent years on that project pipelining my coding, that is, making a small change, asynchronously launching a build, fixing issues from the previous build attempt, ad nauseam, and the pipelining was oftentimes 3+ deep due to latency. That cognitive load severely impacted productivity.

That said, I agree that C++ has a lot of other terrible problems too!

I was happy to see this article at least mention the option of making ransom payment illegal. Maybe we'll get there once insurance stops being a viable fallback.

The article is blatantly toxic in tone, which is an obvious red flag. As to the science, causality is much harder to ascertain than is correlation. In this case it appears to me that the foundational assumptions required by the CausalImpact R package are violated, thus making the conclusions invalid. I wouldn't even blink at a claim of correlation, but causation? This paper doesn't deliver on its claim.

I've done quite a bit of remote MTB/gravel riding/touring (e.g. much of the Great Divide Mountain Bike Route [1]), and have settled on loading GPX tracks onto a Garmin head unit. Turn-by-turn is pretty useless, because the notion of a "turn" is too ambiguous to be useful. Anyway, with a GPX track loaded the head unit will display the path, and you can tell when you deviate significantly. Oftentimes the turns are onto nearly invisible tracks; situational awareness will sometimes save you, but expect to miss some turns. This may sound unreliable, but it's a huge step up from everything else I've tried.

[1] https://www.adventurecycling.org/routes-and-maps/adventure-c...

This is an interesting, if long, take on Rust's ranges and some of their creaky design elements. I found it particularly interesting due to having recently researched Rust's ranges while adding ranges to my own programming language project. A few remarks from my perspective outside the Rust mindset:

- An awful lot of the problems have to do with ownership semantics. If ranges are immutable, referentially transparent, those problems go away.

- The author suggests (in the "Where to from here" section) that ranges should be convertable to iterators, rather than inherently iterators themselves. In my experience this works very well. Ranges can always be integer-based, and, as long as the collection can efficiently be mapped onto integers, conversion to/from iterators is trivial.

- The notion of "directional" ranges seems ill-posed. As described, such a range would actually be more like a vector. Also, in a language which uses wrap-around integer types (modular arithmetic semantics), a "backwards" range is still well-defined and finite. For example, an 8-bit 6..3 range is 6..=255 + 0..3 (the complement of 3..6).

I've been playing this as a road trip game since a friend introduced me to it in high school. Depending on the age of the people playing (and/or the fraction of concentration the driver needs to devote to driving) we also play with 3- or 4-letter words. 6 is a bit much for me to keep track of in my head.

I disagree with your assessment that Dvorak has been obsoleted by other layouts. I used Dvorak 1998-2001, and again since 2018. Before I re-learned it in 2018 I did a bunch of research on Colemak, Workman, and the rich set of other optimized layouts people have created this century. There are compromises in every layout, and I came to the conclusion that Dvorak was within spitting distance of minimally pessimal, other named layouts less so.

The caveat to my perspective is that I don't care where hotkeys are. I minimize mouse use, and with both hands on the keyboard it just doesn't matter very much. I've used emacs and vim with both layouts. My faded recollection with respect to emacs is that it was equivocal, and Dvorak is actually a bit better for vim.

I remember one of my first experiences with Facebook's HPHP, compiling a "hello world" PHP program. I can't remember anymore whether the binary was over 20 MiB or over 200 MiB (both seem plausible in retrospect!), but I do remember the existential dread that ensued. In my experience, massively bloated binaries should instill only slightly less fear than brittle ocean-boiling build systems. Tears will surely result from either.

In my experience, the critical key to weight loss/maintenance is consistent logging. That can be a daily tally in your head, a phone app, paper, whatever. But it must be consistent. Whether you log calories, "points", and/or nutrients is less critical, but if you're just logging calories, you'd better have some other mechanism for maintaining some nutritional balance.

300X is 30000%. Which do you mean? (300X or 300%)

I started using OCaml in 2017, and had a rough start. But since then Dune (https://dune.build/) and the now-excellent LSP implementation have resolved the biggest issues I had. I haven't had such a pleasant development environment since Turbo Pascal! (To be fair, IntelliJ was also pretty good other than the shortcomings of Java.)

Yes, but note the absence of syntactic support. Effects will be usable for writing libraries and experimentation, but routine use won't be very ergonomic until a later release.

The shift keys take up precious thumb cluster space, and their standard location is also useful. IMO the "best of both worlds" option is just worse.

Thumb shift keys are definitely an (incremental) improvement over the traditional placement, but they require a yet bigger commitment to retraining from the standard keyboard layout. I've been using Kinesis keyboards for 25 years, and finally this year committed to moving the shifts to the thumbs. This was worthwhile for me, but I hesitate to recommend the, ahem, shift to others.

Yes, the cargo bike is much better for transporting children, for the simple reason that the children are suspended on the same wheels as the rider. Kid trailers have two wheels, typically of smaller diameter than normal bicycle wheels. That's a double-whammy, because the trailer wheels don't follow the same track (they hit potholes the rider doesn't feel), and the impacts are harder due to reduced wheel diameter. Trailer suspension does not solve these problems. Aside from child hauling, trailers are harder to manage, assuming the load can instead be put directly on the bike.

I put over 7,000 miles on a Surly Big Dummy, much of it hauling my son from age <1 to 7. It was far safer and more comfortable for him than a trailer would have been. I've also ridden thousands of miles with a B.O.B. cargo trailer and a Tout Terrain trailer, and I would always choose the cargo bike if at all suitable to the conditions. The only thing I prefer the trailer for is hauling gear for trail maintenance.

As a very satisfied kakoune user (already a rather fringe designation), why might I want to use helix instead, or in addition?

Erlang APIs are designed around the availability of dynamic pattern matching on messages, but static message typing is definitely feasible. The only feature of Erlang that stands out me as fundamentally incompatible with static typing is "live upgrade". And although this feature might be critical in the context for which it was designed (Ericcson telecom switches), it appears that very few Erlang-based deployments use live upgrade; the most common practice is to restart services.

Counterpoint: I have used Kakoune for a year now, immediately following sixteen years of heavy vim use. I find Kakoune far more intuitive than vim, because the feature set composes so well. Within the first few weeks I understood the command set well enough to combine features to solve editing problems I would have had to look up solutions to if using vim.

Regarding the worry of visual distraction of selections slowing down editing, I found the opposite to be the case as I became more fluent with Kakoune. Motions modify the selection, and it is quite common for the selection to serendipitously contain what I want to modify. Constantly visible selection(s) lead me to implicitly take advantage of motion and use fewer keystrokes.

Regarding multiple selections outside the visible window, you are right that there's no visual feedback for those selections, which is a degraded experience compared to when all selections are visible. But that's no worse than the experience of a global search/replace in vim. You are arguing that in an edge case, Kakoune is no better than vim, which doesn't seem like a meaningful detraction.

Is there something about glass blowing which makes it air-inefficient? My vague recollection from my time as a low brass player in college is that the prof's lung capacity measuring apparatus (yes, really) put most of us in the 3-4L range, with one outlier around 5L. Granted, we were trained for such magnificent feats of blowing hot air, but so too must glass blowers be.

A few years ago this was still true, but since then Dune (originally called jbuilder) has dramatically changed the ease with which OCaml projects can be set up.

As for batteries included, there are several options for foundational libraries; I found there to be too many choices rather than too few when I first started developing in OCaml.

It's quite common for the selection created by motion to have immediate subsequent use. I do use the ';' or ' ' commands to clear the selection or end multi-selection, but typically only once per major operation. On top of that, it is common to start some new editing sequence which automatically resets or extends the selection in a natural way.

Multiple selection has surprised me in its usefulness. It took a bit to get used to multi-step operations (select, then move/expand/match, then modify, etc.), but the beauty of this is that it's possible to incrementally undo these steps, unlike having to get the whole thing right in one go in vim. I find myself using regex captures in multiple selection -- another example of how I confidently use basic kakoune functionality where I used to rely on recorded macros in vim.

I switched to kakoune from vim in early 2020, and I really like it (previously: emacs 1994-2004, vim 2004-2020). It's worth prefacing what follows by saying that I heavily relied on the visual selection features in vim.

kakoune provides a limited orthogonal toolset that composes extremely well. After a week using kakoune I felt at least as confident with its command language as I did with vim's after years of use. Aside from a few vim plugins that were super helpful, I didn't miss anything after transitioning, except for the 'R' command (and to a lesser extent proper integration between the 'r' and '.' commands).

I worried that kakoune's multiple selection paradigm wouldn't scale well, that it wouldn't be routinely useful, etc. On the contrary, I use multiple selections heavily, often as a more ergonomic alternative to recorded macros, constantly for rectangle-based operations (whether multi-line editing, indenting, ASCII art creation, whatever).

Oh, for you tmux lovers out there, kakoune integrates amazingly well. All of its multi-window functionality directly uses tmux panes, with a server application (think emacs-server) tying everything together.

In terms of ecosystem, vim is much richer. But kakoune is a practical, beautifully designed tool.

Bruce's reviews were singularly masterful. He consistently condensed valuable layers of meaning into terse prose in a way that I have never experienced otherwise. As I would uncover these layers during repeated readings, I would develop the unshakable feeling that even as brilliant as Bruce was, he must have put great care and effort into his writing.

This is the third time I've watched this video (admittedly with a bit of distraction today). After the first time I went off and learned about modular implicits, which appear to be a huge ergonomic improvement, especially the way the JaneStreet library APIs are designed. The second and third times I got increasingly sad that so much brain power is being sucked up by algebraic effects, to the detriment of other advancements. Oh well, that's their decision to make; JaneStreet continues to do huge service to OCaml in myriad ways, and I really value these tech talk videos as part of that.

This sunk cost fallacy argument is easy to apply to many languages. Of the ones for which I've approached expert-level knowledge, C++ stands out as the one with the biggest sunk cost for the least gain. But let me tell you about my experience over the past couple years with OCaml, and why I think experts of Haskell, ML, and related languages are motivated by epiphany rather than sunk cost.

First, my CS background. I started programming in 1991, and have used dozens of languages major and minor over that time. At one time or another, I developed especially deep knowledge of the following: C, Perl, PostScript, Python, C++, and PHP. Functional languages always hovered at the edge of my interest, but never seemed practical enough to apply to the sorts of systems programming I love.

In 2017 I decided to spend some time broadening my understanding of language concepts, and made a list of languages to learn more about: OCaml, Julia, Clojure, Scala, Scheme, Haskell, Rust, Erlang, Go, Swift, and Kotlin. Learning OCaml ended up being such a transformative experience that I use it almost exclusively now. As an aside, I must say that it wasn't easy; it took the better part of a year to acquire the knowledge and experience necessary to feel productive.

Why is OCaml (and presumably Haskell) so good? The resulting programs feel like beautiful self-consistent crystalline structures rather than balls of mud. Furthermore, the powerful type system allows refactoring from one crystalline structure to another such that inconsistent hybrid crystals rarely occur. This is a much different experience from reshaping a ball of mud. The routine elegance and safety of these program representations aid in discovering the essences of solutions, and I have written programs I never would have discovered in other languages.

Killer features: - The powerful type system clarifies design, aids refactoring. - The module system (in combination with generics) enables truly modular design. - Effectless computation (pure functions, immutable data) simplifies reasoning about state.

I have some complaints about OCaml (and every other language I know), but it stands out as by far the most fulfilling to use. Going forward I will prefer to spend my programming time using languages more like OCaml, Haskell, Rust, etc. than those I used for the first 25 years.

This would have to have been at Facebook. Rachel and I worked in close physical proximity for quite a while, and as it happens, I was a major Tejava consumer (but not an actor in this particular incident). For years, Facebook routinely maintained ample Tejava supplies, but then suddenly the 0-6 bottles per day stocking became the new norm. Many here fault the participants for making the commons tragic; my take remains that someone made a terrible decision to limit supply (probably due to cost), and it turns out that several of us employees countered with negative sentiment that made it a net loss for the company. I did not begrudge those who beat me to the inadequate supply, but I did begrudge the shortage.