thinkpad20

On the subject of foreign data wrappers, there's an extension for storing columnar data in Postgres which is implemented via this concept: https://github.com/citusdata/cstore_fdw

I haven't used it myself but it's pretty cool that it's out there.

I find that Haskell (both mine and that of others) involves a lot less pattern matching than ReasonML, since control flow is often expressed by type classes. Unfortunately, these are lacking in reasonml, and I think that might contribute to why you tend to see more explicit pattern matching there. But maybe that’s an incorrect impression. In either case, it’s not common all the time, but neither is it particularly rare.

My examples were deliberately dumb, but I’ve certainly use this ability to pattern match at arbitrary depth innumerable times. It most commonly appears when looking at a tuple of N values, and I want to enumerate specific pairings of values.

Nevertheless, if that was the only benefit of it, one might argue it’d be more of a party trick. But it’s simply one more facet of a very powerful, simple-to-use technique for expressing how your code reacts to the shape of your data.

I’m curious how much exposure you’ve had to languages which support it — you might find it more useful than you think.

I just noticed that it was converting all of the &’s I typed into & escapes. Didn’t realize how much further it went.

Pattern matching goes significantly beyond checking “foo.type”. It adds the ability to specify exactly (as exact as the language and your data allows) what case you’re dealing with. For example, a list of length three where the first and last elements are empty strings. Having to specify this with a series of if statements often leads to verbose and error-prone code, but it’s trivial in a language like reasonml:

    switch (mylist) {
      | [“”, _, “”] => x
      | _ => y
    }

    switch (mylist) {
      | [“”, middle, “”] => middle ++ “!”
      | [“foo”, x] => String.reverse(x)
      | _ => “never mind”
    }

The power of pattern matching grows clearer as more complex data and rules are introduced. For example, it works just as well with nested lists:

    switch (mylist) {
      | [outer, [middle, [inner]]] => outer ++ middle ++ inner ++ “!”
      | _ => “never mind”
    }

(Code typed on my iPhone so forgive the dopey examples)

I think you have a very specific, and not widely shared, definition of “code as art.” Code as art does not mean code full of pointless Rube Goldberg mechanisms or following some esoteric golden ratio whatever. For me, “code as art” means code which is well-abstracted, readable, correct, concise, maintainable, extensible, well-documented, performant, etc — I.e. reflecting the things that matter to me as a developer. The process of getting to the point where the code has all of those things, or as many as possible, is indeed the “art” of coding. To assume that the result is some horrible morass of spaghetti that no coworker wants to read is a strange one for sure.

Error: ENOENT, no such file or directory '~/foorc'

I can’t count how many times I’ve seen error messages that look like this, often with no context at all, in JavaScript apps, even widely used ones like npm and webpack. Proper error handling is never easy, but the JS community seems particularly given to avoiding it.

Seems like there's plenty of CO2 to go around. What's the issue?

As a Chicago resident worried about the terrible air quality here, this gives me some hope that things can be improved if the political will can be mustered.

I think the problem is that no one was arguing that slavery per se makes a country rich. The argument was that it did in the case of the US.

First of all, I have heard and read from numerous sources that I trust that slavery played a huge role in the early American economy. But that on its own would be a simple factual dispute.

The second issue is that regardless of the accuracy of the claim, downplaying the value of slavery is a way to devalue the debt owed to black Americans and has been used as such in arguments. The less valuable slavery was, the less white Americans should feel owed to pay back. So I think there’s a significant moral cost to this argument, and yes I think it’s disrespectful. But again, it’s factually controversial as well.

I had also made a variety of significant points which GP failed to respond to, instead focusing only on a hyper-literal interpretation of one subset of my argument. ¯\_(ツ)_/¯

The fact that England, another state with a horrific history of exploitation and colonialism, was also guilty of slavery, is hardly exculpatory for the US. Whether slavery was economically beneficial in every single historical example is a separate question from whether it was beneficial to the United States.

Perhaps my choice of the term "direct" is overly specific, but I feel like this is a very nit-picky quibble. The underlying point I was trying to make doesn't change, which is that the United States benefited hugely (in purely economic terms) from slavery. Whether or not we would have been as, less, or more successful without it, or whether it has been helpful to others, is an orthogonal discussion. As I said, I am not making the claim, and never intended to, that slavery was the only cause of American prosperity. If this is the primary dispute you have with what I said, I readily accept the correction and we can move on.

However, if your intention is to dispute the claim that slavery was immensely beneficial to the development of the American economy, or to suggest that the morality of American slavery was somehow mitigated by other historical examples of slavery, I strongly disagree. I think in general this mentality is incredibly disrespectful. Acknowledging the role played in our success by the (unwilling) sacrifice made by millions of slaves and Native Americans is the very least that we can do.

Not to be "that guy," but I think the real reason we'll never colonize Mars is simply that we're going to run out of time. Climate collapse and/or nuclear war will probably set in long before we have the technology or wherewithal to terraform a planet millions of miles away. We may be only a decade or two from severe environmental catastrophe, which makes the prospect of Mars colonization pretty far-fetched at best.

To be clear, I don't think studying this is a waste of time. On the off chance that we get there, that'll be great (setting aside the concerns of this article of course). It just gives me a sense of a terminally ill person planning their retirement. Sorry to be the downer here.

If slavery makes a country rich, why isn't Africa rich?

I never made the claim that any country can become rich simply by having slavery. The question of why the West is so much richer than e.g. Africa or Brazil is obviously vastly complex and does not boil down to "because of slavery." But whether or not the American South was richer than the North at the time of the civil war, it certainly very very wealthy, and slavery was instrumental in this.[0] I don't think this is really controversial.

Native Americans had slaves:

The existence of slavery in these or other societies does not in any way absolve the US from its past in this regard. Pointing an accusatory finger at some Native Americans who enslaved prisoners of war and the like, in contrast to a vast and extremely profitable business empire built on systematic enslavement, which has had ripple effects of racism on individuals and communities since, seems incredibly tone-deaf. Even more so when you consider that we killed the Native Americans by the literal millions.

[0] https://www.history.com/news/slavery-profitable-southern-eco...

America’s success was the direct result of ethnic cleansing of millions of Native Americans and the backbreaking labor of millions of slaves. The comparison is ridiculous. We were the exploiters.

This project is very interesting and I think it’s great that this is being studied, but we already have a technology for reducing greenhouse gasses in trees and other plants. They do not have expensive and pollution-causing manufacturing processes, contribute to biodiversity and natural ecosystems and don’t produce lasting waste. Perhaps I’m being cynical, but it seems like the ultimate driver of this technology is still profit. There’s a lot of trademarks and business speak in this article.

I’m curious to what extent this is just innuendo and FUD, and how much there’s legitimate speculation (if there could be such a thing) as to Nadal and/or Federer doping. I’ve never heard even a whisper of doping suspicion with Roger, and this is the first I’ve heard of Rafa, but I don’t follow the sport super closely so maybe there are storylines I’ve missed. I know there have been other high profile tennis players to get caught doping, but my impression was that it was uncommon among today’s athletes. The way your comment is worded suggests that many in the know suspect either or both of doping — is this accurate?

Just as natural languages derive directly from our needs to do things with, and communicate about, things in, and state of in the real world, such as running away from lions, attracting mates, and (more recently) engaging in commerce, mathematics derives directly from our needs to do the exact same sorts of things: count chickens (or the number of lions you are running away from), mark time, distance, and rate (as you run from them) and their relationships, and so on.

This is a pretty half-baked comparison. Math is great for describing things which can be defined precisely and their interactions. Numbers, physical systems, economics, etc.

Human language can be (and is) used for these purposes as well, but more broadly is useful for an entirely different purpose: expressing emotions, sussing out the meaning of things, developing relationships, providing a voice for the human condition. Mathematics is ill-suited at best for these purposes. Both language paradigms may be able to quantify how fast one has to run to get away from a lion. Only one of them can express why you’d want to, or the terror you’d feel trying to do so.

In Rust 1.36.0, the HashMap<K, V> implementation has been replaced with the one in the hashbrown crate which is based on the SwissTable design. While the interface is the same, the HashMap<K, V> implementation is now faster on average and has lower memory overhead. Note that unlike the hashbrown crate, the implementation in std still defaults to the SipHash 1-3 hashing algorithm.

The wording here confuses me. They say they took the implementation from hashbrown, but then finish by saying that the implementation is different. What am I missing?

It doesn’t eliminate them entirely; it’s just very smart about allowing packages to be built exactly once, and having a deterministic output such that it can be determined before a package is built whether a prebuilt version is available. This prebuilt version can either be the result of a previous build on your machine, or on another machine served from a repository.

Of course, there are times when you need to compile yourself, but most slow-to-compile packages, such as Aeson, Lens, Servant or the aforementioned Parsec, and many more on top of that have prebuilt binaries available when built from community snapshots (nixpkgs/nixos). You can even pin your package definitions to guarantee that you’re building something that will have prebuilt versions available. New project build is usually less than a minute or two, sometimes substantially so (anecdotally). Again, not always, but usually.

Can you really do it in python with an arbitrary function? What if your function takes a dictionary, set, or some other unhashable type as an argument?

I wish Haskell had better syntax for records, but to be honest it’s very rare that it actually presents a real issue in practical code that I write. Sure, it can be a bit awkward to update nested records, but I struggle to think of more than a few cases where it’s caused me any real grief, and even then it was only an issue of convenience (having to write a slightly more awkward line of code) as opposed to causing bugs or preventing a satisfactory solution to a problem. I readily admit it’s something that could be improved, but I think it’s more of a hobby horse than a real problem. YMMV of course. For what it’s worth, I’ve written tens of thousands of lines of Haskell over the past few years and have barely ever used lenses. They’re really there as a convenience for people who are familiar with them. Understanding lenses is by no means a prerequisite to writing practical code in Haskell.

I find it hard to co-sign on your assertion that all non-trivial programs require mutation. This hasn’t been my experience at all. While having access to side-effects is certainly essential (which Haskell is fully capable of doing), mutation is quite rarely needed in my experience. In the cases that it is, IORefs are trivial to use. On top of that Haskell has MVars, which I hazard to claim are the best concurrent mutation primitive I’ve ever had the pleasure of using. Quite the opposite of being crippled.

Try using nix instead. Aside from being a fantastic package manager for many languages it’s a godsend for Haskell. The lengthy compilation times with Haskell are one of the not so wonderful parts of the language, but they largely disappear with nix, and the Haskell ecosystem on nix is very well supported, with a large community. Honestly I’ve been developing Haskell for years and have never once used stack. I did use cabal before I discovered nix, but since then I’d hardly dream of using anything else.

“as much as I love China and can understand their politics due to the size of their country”

The size of China is not the source of their politics; the source is a totalitarian state that ruthlessly suppresses any dissent and maintains constant surveillance of its people. Not to imply that you meant otherwise, but the citizens of mainland China are no less deserving of political rights than those of Hong Kong; rather, they have simply been denied them by those in power. The 30th anniversary of the Tiananmen Square massacre was only last week —- it could have ended similarly in Hong Kong. Also, unsurprisingly, Chinese media has been almost completely silent about these protests and many on the mainland are completely unaware that anything is happening at all.

Conflicts which the military industrial complex has no interest in us ever getting out of, as recent events in Yemen demonstrate. Not to mention what's looming on the horizon in Venezuela or Iran.

https://www.opensecrets.org/industries/lobbying.php?cycle=20...

ReasonReact is a fantastic project that is written in OCaml (with Reason syntax). In addition to being a wonderful frontend framework, it's also a great introduction to the language.

A global counter is difficult because shared global mutable state should be difficult —- it can wreak havoc on your code. That said, if you’re really set on it it’s not particularly bad

    counter :: IORef Int
    counter = unsafePerformIO (newIORef 0)

    usesGlobalState :: IO ()
    usesGlobalState = do
      count <- readIORef counter
      putStrLn (“the counter was “ ++ show count)
      modifyIORef (+1) counter

Anecdotally, I find it incredibly rare that such a thing is desirable, when you could instead create it in an IO monad and pass it through to functions that need it. But, it’s there when necessary. And making this kind of anti pattern hard is a strength of these languages, not a weakness.

Haskell is still a pretty awesome language tho, so using it on the frontend is pretty sweet. Nothing about the language is problematic here (with the possible exception of laziness which is one reason why I personally prefer purescript). And Miso is actually pretty awesome and easy to use. The main issue is with tooling, especially the slow compiler. My hope is that a wasm backend will be developed soon, hopefully along with subsequent speed improvements. Compiling a ton of non-DOM library code to obscure JavaScript makes no sense. Not to discredit the work of the ghcjs team, which created something pretty awesome and useful, but most of that would make a lot more sense in wasm. Beyond that, it needs bells and whistles like webpack integration and source maps. But really, despite its warts, it is quite usable for frontend and shouldn’t be discounted.

I normally wouldn't value those things as highly but I find that compiler speed and tooling makes a huge difference to me for front-end dev specifically, because I'm constantly doing the code->compile->use cycle, and a slow compiler is a pain there. But I'd happily use PureScript again, and am still considering returning to it for this project at some point.

Mainly I was more interested in ReasonML than OCaml (syntax- and tooling-wise), and the recommended toolchain there is bucklescript. I'm not really aware of the differences between bucklescript and js_of_ocaml, or how easy it would be to switch, but I have no complaints with bucklescript so far.