Live data from Hacker News

Fighting spam with Haskell at Meta (2015)

engineering.fb.com

61–70 of 85 posts

Re: Fighting spam with Haskell at Meta (2015)

#61

Wonder if Haskell is still around at Meta these days, does anybody know?

Yes, (and so is OCaml) but less than in the past, mostly for specialized and older projets. Most engineers at Meta will not encounter these languages. It's costly to integrate them with the internal tools and arguably not worth the effort. On the other hand, Rust is increasingly popular and well-supported and approved by the company.

[deleted]

Re: Fighting spam with Haskell at Meta (2015)

#62
post #22

Earlier quoted context omitted.

Every time I try to work on someone's Haskell code, I'm confronted with a slew of custom infix operators, and I find my previous experience is completely irrelevant as I learn the new DSL the authors chose to write (which more often than not also involves flexing their brain as hard as they can).

But that's like half of computing.. every new tool the world inflicts on you, configured in Jojo's Awesome Configuration Language, with some arbitrary made up grammar punctuated by Tourette outbursts of special character line-noise. That, or YAML, then a tool to template and generate the YAML, and then a stack of tools wrapped around that, ad infinitum. A little learning is the cost of not having to write the thing y…

Right, now imagine the templated YAML mess implemented in Haskell together with the app. By someone smart enough to liberally use Haskell's most complicated features

Re: Fighting spam with Haskell at Meta (2015)

#63
post #57

Earlier quoted context omitted.

What do you mean by "long time"? Why wouldn't it apply just the same to some Python file that defines a Maybe with a bit of unwrap and bind and orElse or whatever? Instead of things going boom and spewing a stack sometimes they just go Nothing instead, you don't need much more understanding than that. There is a lot of syntax in Haskell that is somewhat hard to understand at first but you don't actually need it to wr…

Long time, I mean possibly several weeks of full-time studying for an intermediate Python or C++ programmer. I'm not saying you need any CS theory to write Haskell or that it's super hard. But I think the learning curve is pretty steep, and it's hard to write code without a good understanding of the concepts. Just tweaking until it type checks isn't going to cut it. Consider this code. Generated from ChatGPT. This is…

This is a really good point. I have coworkers that don't really code, but can use ChatGPT to help them put together a Python app that does what they need with some common sense changes. I don't think I could even do the same with Haskell with a fair amount of coding experience+ reading up a lot on Haskell over the years. It may be obvious to those select few who are drawn to Haskell, but I think they greatly underestimate the challenges for the average person. That's the essence of what I've been saying to the parent thread that believes a subset of Haskell will become popular some day. I could be wrong, but just can't see it.

Re: Fighting spam with Haskell at Meta (2015)

#64

Earlier quoted context omitted.

I've encountered many otherwise solid engineers who are intimidated and/or put off by Nix (the language).

I count myself among them. And I wouldn't say I am "otherwise solid". I am solid. Nix is just a weird custom footgun-laden language in a place where I don't want to have to learn a weird custom footgun-laden language. It has other serious issues too, like the fact that it is declarative makes discoverability extreeemely difficult. What does setting `foo: true` do? You can't go-to-definition on it. You can only hope i…

you're not solid, by what you've just written here and in above threads.

Re: Fighting spam with Haskell at Meta (2015)

#65
post #57

Earlier quoted context omitted.

What do you mean by "long time"? Why wouldn't it apply just the same to some Python file that defines a Maybe with a bit of unwrap and bind and orElse or whatever? Instead of things going boom and spewing a stack sometimes they just go Nothing instead, you don't need much more understanding than that. There is a lot of syntax in Haskell that is somewhat hard to understand at first but you don't actually need it to wr…

Long time, I mean possibly several weeks of full-time studying for an intermediate Python or C++ programmer. I'm not saying you need any CS theory to write Haskell or that it's super hard. But I think the learning curve is pretty steep, and it's hard to write code without a good understanding of the concepts. Just tweaking until it type checks isn't going to cut it. Consider this code. Generated from ChatGPT. This is…

It is obvious, as long as you know what Functors and Semigroups for custom data types are. If you don't know it, you can still use it freely without fully understanding the meaning of `` and ``, because they are written almost as plain bullet points of components to treat as a single whole.

Re: Fighting spam with Haskell at Meta (2015)

#66

Earlier quoted context omitted.

I'm not fully convinced. FP is such a different paradigm than the leading imperative/OO design that most are comfortable with. Other languages that are too different like lisp, forth, Apl, Haskell, and Prolog are just too different for the average person IMO. I've given Haskell/OCaml/F# a go a few times and enjoy learning new paradigms and it certainly didn't click for me. I have a feeling it'll be even harder with m…

> FP is such a different paradigm than the leading imperative/OO design that most are comfortable with. I don't think most of FP is at all hard for most programmers to understand. Hell I interviewed plenty of Javascript devs that couldn't solve a simple fizzbuzz level question because they didn't know how to do for loops - they only knew how to use `.forEach()`! The hard bits in Haskell are: 1. Purity. I get it, but…

> waaaay too many operators, etc.

Haskell doesn't have operators, it's based on expressions consisting of function compositions, some of which can be infix and look like operators.

> This is just a collection of words. No clue of what is a function call, what is a variable name, etc.

That's by design, because all of them are expressions that can either reduce immediately or require runtime data to reduce fully.

> How about you pick between 8 alternatives...

How about you pick either of those and start using for real, and then come to the point it either works well or you find inefficiencies to look specific alternatives for? It doesn't take much.

Re: Fighting spam with Haskell at Meta (2015)

#67

Earlier quoted context omitted.

I've encountered many otherwise solid engineers who are intimidated and/or put off by Nix (the language).

I count myself among them. And I wouldn't say I am "otherwise solid". I am solid. Nix is just a weird custom footgun-laden language in a place where I don't want to have to learn a weird custom footgun-laden language. It has other serious issues too, like the fact that it is declarative makes discoverability extreeemely difficult. What does setting `foo: true` do? You can't go-to-definition on it. You can only hope i…

This shallow dismissal pretty much proves OPs point.

For starters, you compared Nix the ecosystem to Starlark, perhaps the smallest aspect of Bazel. But Bazel (the ecosystem) has a horrendous documentation problem as well.

I grant that "Nix" is a very overloaded term, but it seems like you don't know which part of Nix you are even referring to. "Somewhere... in all of Nix" is not something that makes any sense.

I fully admit that Nix has a steep learning curve. Very steep. But I don't think you know enough to give a thoughtful critique.

Re: Fighting spam with Haskell at Meta (2015)

#68

Earlier quoted context omitted.

I count myself among them. And I wouldn't say I am "otherwise solid". I am solid. Nix is just a weird custom footgun-laden language in a place where I don't want to have to learn a weird custom footgun-laden language. It has other serious issues too, like the fact that it is declarative makes discoverability extreeemely difficult. What does setting `foo: true` do? You can't go-to-definition on it. You can only hope i…

This shallow dismissal pretty much proves OPs point. For starters, you compared Nix the ecosystem to Starlark, perhaps the smallest aspect of Bazel. But Bazel (the ecosystem) has a horrendous documentation problem as well. I grant that "Nix" is a very overloaded term, but it seems like you don't know which part of Nix you are even referring to. "Somewhere... in all of Nix" is not something that makes any sense. I ful…

> For starters, you compared Nix the ecosystem to Starlark

No I compared the Nix language to Starlark.

> but it seems like you don't know which part of Nix you are even referring to.

Incorrect. I was referring to the Nix language, as was hamandcheese. He literally said it explicitly. I don't know how you could miss that.

> I fully admit that Nix has a steep learning curve. Very steep. But I don't think you know enough to give a thoughtful critique.

You're proving my point here. The very steep learning curve and "you need to be an expert before you can use it" aspects of Nix (both the language and the package manager) are exactly the problem.

Let me put it another way. Imagine I gave you a vacuum cleaner, and you tried to turn it on but it had a very complicated startup sequence so you needed to read the manual... but the manual was written in Egyptian hieroglyphics. You take it back to the shop and they say "nah this is a perfectly good vacuum cleaner. Sure it has a steep learning curve but you just need to spend some time learning it before you can criticise it".

That's obviously stupid right? For most people package management is like vacuum cleaning. It's a necessary task they want to think about as little as possible.

Nix is written by a vacuum cleaner collection & restoration club, who assume that everyone in the world is as obsessively into vacuum cleaners as them.

Re: Fighting spam with Haskell at Meta (2015)

#69

Earlier quoted context omitted.

I count myself among them. And I wouldn't say I am "otherwise solid". I am solid. Nix is just a weird custom footgun-laden language in a place where I don't want to have to learn a weird custom footgun-laden language. It has other serious issues too, like the fact that it is declarative makes discoverability extreeemely difficult. What does setting `foo: true` do? You can't go-to-definition on it. You can only hope i…

you're not solid, by what you've just written here and in above threads.

Care to point out something specific?

Re: Fighting spam with Haskell at Meta (2015)

#70

Earlier quoted context omitted.

This shallow dismissal pretty much proves OPs point. For starters, you compared Nix the ecosystem to Starlark, perhaps the smallest aspect of Bazel. But Bazel (the ecosystem) has a horrendous documentation problem as well. I grant that "Nix" is a very overloaded term, but it seems like you don't know which part of Nix you are even referring to. "Somewhere... in all of Nix" is not something that makes any sense. I ful…

> For starters, you compared Nix the ecosystem to Starlark No I compared the Nix language to Starlark. > but it seems like you don't know which part of Nix you are even referring to. Incorrect. I was referring to the Nix language, as was hamandcheese. He literally said it explicitly. I don't know how you could miss that. > I fully admit that Nix has a steep learning curve. Very steep. But I don't think you know enoug…

> Incorrect. I was referring to the Nix language, as was hamandcheese.

I am hamandcheese. I replied to your comment. You didn't describe a single aspect of Nix-the-language. You wrote this:

> What does setting `foo: true` do? You can't go-to-definition on it. You can only hope it is well documented (it isn't) or try to find the place that reads that key ... somewhere... in all of Nix... Good luck.

It's appears (despite the wrong syntax, another clue that you are not particularly well informed) that you are referring to a NixOS module option. Or maybe a Home Manager module option. Either way, not a language feature.

Post reply on HN