thinkpad20

6 yıl öncediscuss

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.

thinkpad20

7 yıl öncediscuss

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.

thinkpad20

7 yıl öncediscuss

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.

thinkpad20

7 yıl öncediscuss

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

thinkpad20

7 yıl öncediscuss

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
    }

Moreover, pattern matching usually involves pulling information out of the object at the same time. In the above example, maybe you want to do something with the middle element:

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

All of this would be possible to do with a series of if conditions, but significantly harder to read and implement correctly.

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”
    }

While having a type system is helpful in all of the ways a type system is generally helpful, there’s nothing about this code which wouldn’t also be handy in a dynamic language like JavaScript. For further evidence of this see Erlang and Elixir, dynamic languages which make heavy use of pattern matching.

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

thinkpad20

7 yıl öncediscuss

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.

thinkpad20

7 yıl öncediscuss

> 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.

thinkpad20

7 yıl öncediscuss

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

thinkpad20

7 yıl öncediscuss

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.

thinkpad20

7 yıl öncediscuss

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.

thinkpad20

7 yıl öncediscuss

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.

thinkpad20

7 yıl öncediscuss

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.

thinkpad20

7 yıl öncediscuss

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.

thinkpad20

7 yıl öncediscuss

> 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...

thinkpad20

7 yıl öncediscuss

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.

thinkpad20

7 yıl öncediscuss

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.

thinkpad20

7 yıl öncediscuss

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?

thinkpad20

7 yıl öncediscuss

> 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.

thinkpad20

7 yıl öncediscuss

> 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?

thinkpad20

7 yıl öncediscuss

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.

thinkpad20

Submissions

Julia Dependent Types Debate (2014)

Tech Start-Up Fires Engineers Amid Union Organizing Effort

Gzip vs. Bzip2 vs. XZ Performance Comparison

Traders scheme to cash in on Trump's tweets

Douglas Crockford explains why JSON doesn't have comments

How X Window Managers Work, and How to Write One (2014)

VT100 Terminal Art: old text-based animations you can run in your terminal

Life is (NP-)Hard (2010)

Show HN: SimpleArgs, an argument parser you already know how to use

Robin Hood Hashing should be your default Hash Table implementation

Sublime/TextMate theme editor in JavaScript

comments