Hacker News Reader

Comment by aardvark179 | Hacker News Reader

“But net/net, when a GHC contributor rolls up his or her sleeves, they on average have a bigger range than people who argue about ReactJS vs Ember.”

I think that’s going to be true for most people who have both the skill to contribute to anything like GHC and the drive to do so, I’m not convinced it’s specific to Haskell no matter how much you’d like that to be true.

View on HN

They didn't say it was specific to Haskell, the wording was "than most other languages".

My intuition is that they are right. More powerful and fitting tools with a higher learning curve attract different kinds of people than stuff that is tailored for the mainstream.

There are also pragmatists who are extremely smart and capable and choose to deepen their expertise in Java (for example). But at _first glance_ it says more about a person if they are proficient in a specialized language than a mainstream one.

Maybe what I’m saying is that I give better odds for the typical senior Haskell hacker to get a useful diff into GHC than I do for the typical senior JS developer to get a useful diff into v8.

I actually think this is what is holding back the Haskell community from broader adoption. The senior Haskell hackers are much more interested in building compilers and runtimes and the like so the things that most developers really benefit from are missing.

The IDE support, dependency management, performance monitoring and application frameworks are all just plain worse in the Haskell ecosystem than others.

Smarter maybe holding the language back because it doesn’t correlate with shipping useful application software as well as other traits such as being customer oriented or empathetic to other workflows.

Reason #9143346356 why I’m so grateful for VSCode even though I’d never use it: haskell-language-server —-lsp is pretty good.

It’s kinda sad it can’t precise go to definition on libraries, but otherwise it’s really sweet.

it's sweet but can't do basic go to definition?

Go to definition in libraries is different than basic go to definition

But something solved for 20 or more years in IDEs for mainstream languages.

With the possible exception of Visual Studio, the only thing that mainstream IDEs have been “go to”-ing in the presence of an NP-hard dependency resolution graph for 20 years is the wrong place with a UI that simply exudes confidence.

You are sort of making my point for me. In theory dependency graph traversal is NP hard but in practice you can use heuristics to get to really good accuracy.

This really good accuracy is almost always better than the system not working at all. Very frequently (not always) the Haskell community let’s the perfect get in the way of the good on issues like this and I end up with tooling that is worse than 20 year old IDEs.

Oh I also agree that haskell-language-server makes the wrong precision/usefulness tradeoff. Codex for example can usually get you somewhere at least useful.

I was just pointing out that “solved” is a strong word for anything Eclipse or JetBrains did 5-10 years ago :) It’s easy to forget how shitty all the IDE stuff was before VSCode forced LSP through the clogged artery of language tooling.

I was personally using “go to definition” for Java with whatever IDEA’s tool was called in 2001-2002 (renamer?) and had the full suite of modern refactors in C# with Resharper by 2005.

I honestly haven’t seen much of an improvement in IDE productivity in the last 5-10 years compared to Resharper circa 2008 but if Haskell could get to parity with that it would be a huge win.

I once inherited a medium size python service and small front end at work that was primarily developed by someone that was super into Haskell. He chose to use mongodb and built a lot of functionality around the constraint that he didn't know what an index was.

I'm very thankful his manager didn't let him write it in Haskell. Now he's where he belongs back in academia doing NLP research.

In fairness, enthusiasts from lots of language communities got duped into using MongoDB.

Why would you say duped? Is there some major problem with mongoDB? The way you've stated this makes it sound like there's some common knowledge I should be aware of.

> Is there some major problem with mongoDB?

Yes, plenty. It's mostly useless for relational data.

Nowadays that's clear on the documentation and you won't get loud people proclaiming that it's useful there, but there was a time when both of those were false.

By relational data do you mean data that has no nesting or arrays? Or data that you always want to query with a join? Something else?

That that you would want to query with a join and have invariants that spread through those places you would want to join.

Just keeping invariants of any kind is already non-trivial and will probably break at some point in a long lived system.

I see so reference data that you want included in an object for which you're willing to pay the performance overhead of a join rather than denormalize across many object representions in your database. This model has some downsides when it comes to reasoning about scale and denormalization isn't necessarily a consistency quagmire when you can use transactions to keep multiple objects in sync. More generally you can absolutely do this types of queries in modern data systems whether or not they are "relational".

Yeah, I guess I should retract my claim that people aren't claiming it's useful for relational data anymore.

Anyway, I was focusing on invariants. But yes, destroying your performance every time you need an atomic change or joining values also makes it bad for relational data.

That doesn't mean it's useless, just that it should not be used on the most common problem people have with their data.

Postgres literally beats MongoDB at JSON in benchmarks. Y'know, the thing that's supposed to be Mongo's bread and butter?

Which benchmark is that?

https://www.enterprisedb.com/news/new-benchmarks-show-postgr...

Unfortunately that benchmark was very inaccurate. They tuned the postgres configuration and didn't tune MongoDB. They also used an unsupported, experimental driver without connection pooling on MongoDB.

For example: they measured Query B execution time on postgres: 41m3s, mongodb: 1h13m3s. When MongoDB measured Query B with a supported driver, the execution time was only 3m30s more than 10x faster than postgres!

You'll find details here: https://www.mongodb.com/blog/post/benchmarking-do-it-right-o...

Thanks for that info. Statistics, misunderstandings, lies, benchmarks, database benchmarks...

Mongodb was a lot easier to manipulate json in for a while vs postgres, but once postgres got json path support it evened out a bit imo.

Say you have some json and nested in it somewhere is an array of objects, and you want to just map over that and update those objects. I was writing a migration to do that in Postgres <11 once and it was not fun to try and figure out how to do it.

I haven't worked with Mongo in years though, so no clue how it has evolved since like 2015.

> He chose to use mongodb [...]

I find it rather surprising that somebody who uses Haskell, i.e. clearly sees the value of types as an aid for reasoning about programs, would default to using a schemaless database which gives you essentially zero ways to reason about your data.

It makes much more sense coming from someone who doesn't really like static typing and so prefers run-time, informal reasoning.

He was using python 2.7 so he would have lost the type safety after he fetched the data anyway

That's not the same thing. There's value in a schema even in a dynamically typed language.

For example, if you have a bug in your codebase due to e.g. a runtime type error, you can generally troubleshoot and fix it, but if your data is in an inconsistent state, it may be impossible to fully recover.

Reply on news.ycombinator.com