thinkpad20

Joined 13 years ago

Karma
2,032
Submissions
605
Member since
Apr 1
Software developer in Chicago. Interested in functional programming and related topics, such as logic, type theory, programming language theory, and such-like. Haskell-phile but I try not to be douchey about it :)

http://github.com/adnelson

View on Hacker News

Recent submissions

Comment · 6 years ago
Comment · 7 years ago
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.
Comment · 7 years ago
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.

Comment · 7 years ago
I just noticed that it was converting all of the &’s I typed into & escapes. Didn’t realize how much further it went.
Comment · 7 years ago
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)

Comment · 7 years ago
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.
Comment · 7 years ago
> 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.

Comment · 7 years ago
Seems like there's plenty of CO2 to go around. What's the issue?
Comment · 7 years ago
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.
Comment · 7 years ago
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.
Comment · 7 years ago
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.

Comment · 7 years ago
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.

Comment · 7 years ago
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.

Comment · 7 years ago
Comment · 7 years ago
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.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton