thinkpad20 (u/thinkpad20)

thinkpad20 commented on Foreign data wrappers: PostgreSQL's secret weapon? splitgraph.com/blog/forei... · Posted by u/chatmasta

thinkpad20 · 6 years ago

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 commented on Algebraic Data Types: Things I wish someone had explained about FP jrsinclair.com/articles/2... · Posted by u/jrsinclair

dllthomas · 6 years ago

I find it often winds up clearer to pull things into multiple case statements, especially as the code grows more complicated. That said, there may be a difference in what we 're meaning by "most of the time," so let's be more precise. IME, most Haskell programmers will encounter use cases for multi-level matches (beyond simply pulling the first couple elements off a list) a small number of times per week (maybe month, depending on the programmer), whereas they're typically writing a case statement some number of times per hour.

I wouldn't call it a party trick, but I also wouldn't say it's the most common use of case by a long shot. I don't expect that you disagree.

thinkpad20 · 6 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.

thinkpad20 commented on Algebraic Data Types: Things I wish someone had explained about FP jrsinclair.com/articles/2... · Posted by u/jrsinclair

ufo · 6 years ago

Yes, I was just trying to say that matching on multiple levels is rarer. I agree with you that automatically binding new variables is the best part of pattern matching.

thinkpad20 · 6 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.

thinkpad20 commented on Slack’s new WYSIWYG input box is terrible quuxplusone.github.io/blo... · Posted by u/ingve

thinkpad20 · 6 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.

thinkpad20 commented on Algebraic Data Types: Things I wish someone had explained about FP jrsinclair.com/articles/2... · Posted by u/jrsinclair

mc3 · 6 years ago

What is the benefit of pattern matching in a language where any value can be of any type at runtime? You can just pattern match by saying if (obj.type === 'foo') {}; if (obj.type === 'bar') {}; etc in JS, as long as you have set up the convention that you set the 'type' field, and practically this is just as good.

The real benefit of pattern matching is the compiler checking at least that you have valid cases, and ideally that you haven't missed any cases.

thinkpad20 · 6 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)

thinkpad20 commented on The Value in Go’s Simplicity benjamincongdon.me/blog/2... · Posted by u/Cthulhu_

sagichmal · 6 years ago

"Code as art" implies a strictly different set of criteria than the ones I listed. If the Venn diagrams overlap a lot for you, that's great, but it's rare.

thinkpad20 · 6 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.

thinkpad20 commented on Keep your source code SIMPLE medium.com/@kevingoslar/k... · Posted by u/kevingoslar

thinkpad20 · 6 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.

thinkpad20 commented on Ask HN: Agriculture startups doing interesting work? · Posted by u/greenie_beans

elasticventures · 6 years ago

different set of problems; equipment failures and mold's & fungus become bigger problems. it's not a closed loop since we need fresh co2 to trigger photosynthesis and nothing is 100% failure proof.

thinkpad20 · 6 years ago

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

thinkpad20 commented on London Ultra Low Emission Zone cuts toxic air pollution by a third london.gov.uk/press-relea... · Posted by u/sails

thinkpad20 · 6 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.

thinkpad20 commented on Ethiopia Plants 350M Trees in One Day to Combat Drought and Climate Change bloomberg.com/news/articl... · Posted by u/auntienomen

simonsarris · 7 years ago

My condensed argument is that Slavery per se does not make countries rich. Rather I am only arguing that slavery, in many countries including the USA, Brazil, and others world-wide, did not contribute to the long term economic success of the nation nearly as much as many claim it does (or solely claim it does in the USA).

We don't have a counterfactual Twin Earth where those countries did not have slaves, but we know for sure slavery is not necessary for a country to be successful. And if we look at countries that had way more slaves, the advantage of simply having slave labor seems hugely insufficient for a country to be successful.

It is possible that the USA had slaves and was able to economically leverage them far greater than all the other countries that had slaves, but this seems unlikely, and such a scenario would also be the biggest gain for a counterfactual scenario that the USA would have been successful without them, too.

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