7 ms·

This article keeps coming up every once in a while and reminds me of all those “Why JS sucks”, “Never use PHP”, “Java is enterprise only”, “Ruby only works on h

This article keeps coming up every once in a while and reminds me of all those “Why JS sucks”, “Never use PHP”, “Java is enterprise only”, “Ruby only works on hobby projects” etc... But then in real life people built great software with all the above, so I’ll just say a great classic: pick something you know, use it well, build something good, end of story! No tool will fix wrong assumptions or bad design, we can dive into philosophy here but I’m more of a practical person so... :)

larrik 6y ago
This advice is fine for programming languages, but not for data stores. Using them incorrectly (or in MongoDB's case and sometimes MySQL's, correctly) could lead to things like data loss or crashed servers. Simply building your product on one of them is not proof they are good enough.
- Geminidog 6y ago
  No, there are programming languages that are just plain bad to use, his philosophy is wrong not only for datastores but for reality in general. All tools, including programming languages can be bad no matter the skill of the user.
  - artificial 6y ago
    Found the person that doesn't like BrainF*ck. /s
    - redwall_hp 6y ago
      With Excel as a data store!
  - 01acheru 6y ago
    Glad to see that you actually know what is right ;) All tools can be bad, but that means that probably you cannot use it well or build something good with it. Every good enough tool can be used to build something good enough, or else it wouldn’t be good enough. And it’s also realistic to assume that every tools popular enough is good enough for something. But you see, it’s starting to get philosophical over here
    - rowanG077 6y ago
      You can create the grand canyon with an infinite supply of plastic spatulas. Does that mean a plastic spatula is good tool for creating grand canyons? Of course not.
deleted 6y ago
[deleted]
Geminidog 6y ago
Your post implies that there is no tool on earth that "sucks" and that it's not the tool, it's the person. It's impossible for EVERY tool to be good. This isn't reality. There has to be tools that are patently bad to use and people have used these bad tools to build great things. But it doesn't change the fact that a tool can be horrible to use. I would argue that at the time the article was written, Mongo was definitively a bad tool. Things have changed, but not all things.
- deleted 6y ago
  [deleted]
- at-fates-hands 6y ago
  > Your post implies that there is no tool on earth that "sucks" and that it's not the tool, it's the person. I got more of a "stop complaining about tools. Pick one you like, use it and build something with IT instead. I feel the same way. Developers are a fickle bunch. One tool works, but then in order to be "cool" you have to bag on it and then propose some other obscure tool you think is better that nobody has ever heard of. It seriously reminds me of people arguing over music. Its totally uncool to like a mainstream band because everybody else likes that band and its not cool to like them. So then you have all the "cool" people who listen to all the obscure "awesome" bands who Rolling Stone magazine tells you to listen to, so then you go around telling people you listen to the Shithouse Rats. "Oh you've never heard of the Shithouse Rats? Well, they're kind of obscure." and now you're one of the of the cool kids.
  - 01acheru 6y ago
    Yeah that was my point, 100%! And by the way I really like you music analogy, and it’s emblematic of something even larger: they read about Shithouse Rats on Rolling Stone, named after a song of Bob Dylan or Muddy Waters or the group itself (don’t know which one) and all of them are quite famous and mainstream. You’ve got to love mankind, we are awesome!
  - skrtskrt 6y ago
    I feel there can be a fair reason behind this, which is basically that using a tool no one else uses, even if it’s great for the use case, is likely to be a losing battle. Hard to get using it approved at work, less usage means fewer bugs are caught and features developed, etc. So people evangelize their favorite tools because it benefits them directly to have them adopted more widely.
Geminidog 6y ago
>No tool will fix wrong assumptions or bad design, we can dive into philosophy here but I’m more of a practical person so... :) And no design can fix a bad tool, we can dive into the practicalities here but I'm more of a philosophical person so...:)
throw1234651234 6y ago
The only practical application of MongoDB I can justify to this day, is if you have a form builder, that allows users to build completely custom forms. Forms.io gives you the form schema in such a scenario as JSON out of the box. That gets matched with answers as JSON. Saving this to MongoDB directly, rather than SQL seems to simplify things. With anything else, at the end of the day, you are enforcing FK constraints anyway, so might as well use SQL. I never had issues with MongoDB performance. One caveat to this is that I am yet to see a project that needs database sharding in real life, and I have worked on projects with millions of entries in a table and hundreds of writes a minute.
- CodesInChaos 6y ago
  Most relational databases have some level of json support nowadays. So I'm not sure how much it simplifies in that case.
  - throw1234651234 6y ago
    There is appeal to the json being directly searchable in the database, ala MongoDB. Specifically for analytics/reporting. The problem is that most analytics/reporting/BI tools SAY they support MongoDB and then they tell you to write a "connector" for each entity, at which point it's easier to just move it to SQL.
jimbokun 6y ago
> “Why JS sucks”, “Never use PHP”, “Java is enterprise only”, “Ruby only works on hobby projects” All of these have at least a little bit of truth to them, and you should know about the downsides of technologies, even if you decide to use them anyways.
bdcravens 6y ago
In each of those language examples, there are examples of great software that migrated away from those languages for different reasons.
TomSwirly 6y ago
It would be more useful if you addressed the specific issues brought up in the article, rather than generically tried to dismiss all articles critical of any programming language...
jeff-davis 6y ago
I would argue that a lot of weaker elements in the stack (e.g. PHP) work well because of a stronger database. A good database system does a lot to catch errors (including consistency problems), isolate them, and roll them back. Moreover, it will allow you to move performance problems into the database, where it's likely to be handled more efficiently with less application code (e.g. joining in the database is likely to be more efficient than a naive join algorithm implemented in the application). Some will argue that these are misfeatures and should be handled in the application. In some cases, that is true; but you are probably going to need some other aspects of the stack to be very robust and performant to get reasonable results. In other words (please excuse my examples as they are intended for illustration and not flamebait), PHP over Posgres might be fine; Haskell over MongoDB might be fine; but PHP over MongoDB is playing with fire. I'd still say that, in most cases, the database layer is the first place to start to work toward a robust system. Even a proven-correct Haskell program can fail miserably if there was a minor bug three versions ago that wrote some bogus data that wasn't caught by a good database layer.
gher-shyu3i 6y ago
It really depends. Things can be built despite of the technology. I saw this especially at an employer who was heavily invested in golang. Countless times I've thought to myself that they wouldn't be having the issues they were having, sunken costs, reinventing the wheel, etc. if they used a proven technology like the JVM instead of drinking the kool aid and using the latest fad of the day. Tons of money was sunken into it, and it was made to work by force, but not everyone would be able to bear that cost, and it still causes massive inefficiencies due to poor tooling.

larrik 6y ago

This advice is fine for programming languages, but not for data stores. Using them incorrectly (or in MongoDB's case and sometimes MySQL's, correctly) could lead to things like data loss or crashed servers. Simply building your product on one of them is not proof they are good enough.

Geminidog 6y ago
No, there are programming languages that are just plain bad to use, his philosophy is wrong not only for datastores but for reality in general. All tools, including programming languages can be bad no matter the skill of the user.
- artificial 6y ago
  Found the person that doesn't like BrainF*ck. /s
  - redwall_hp 6y ago
    With Excel as a data store!
- 01acheru 6y ago
  Glad to see that you actually know what is right ;) All tools can be bad, but that means that probably you cannot use it well or build something good with it. Every good enough tool can be used to build something good enough, or else it wouldn’t be good enough. And it’s also realistic to assume that every tools popular enough is good enough for something. But you see, it’s starting to get philosophical over here
  - rowanG077 6y ago
    You can create the grand canyon with an infinite supply of plastic spatulas. Does that mean a plastic spatula is good tool for creating grand canyons? Of course not.

deleted 6y ago

[deleted]

Geminidog 6y ago

Your post implies that there is no tool on earth that "sucks" and that it's not the tool, it's the person. It's impossible for EVERY tool to be good. This isn't reality. There has to be tools that are patently bad to use and people have used these bad tools to build great things. But it doesn't change the fact that a tool can be horrible to use. I would argue that at the time the article was written, Mongo was definitively a bad tool. Things have changed, but not all things.

deleted 6y ago
[deleted]
at-fates-hands 6y ago
> Your post implies that there is no tool on earth that "sucks" and that it's not the tool, it's the person. I got more of a "stop complaining about tools. Pick one you like, use it and build something with IT instead. I feel the same way. Developers are a fickle bunch. One tool works, but then in order to be "cool" you have to bag on it and then propose some other obscure tool you think is better that nobody has ever heard of. It seriously reminds me of people arguing over music. Its totally uncool to like a mainstream band because everybody else likes that band and its not cool to like them. So then you have all the "cool" people who listen to all the obscure "awesome" bands who Rolling Stone magazine tells you to listen to, so then you go around telling people you listen to the Shithouse Rats. "Oh you've never heard of the Shithouse Rats? Well, they're kind of obscure." and now you're one of the of the cool kids.
- 01acheru 6y ago
  Yeah that was my point, 100%! And by the way I really like you music analogy, and it’s emblematic of something even larger: they read about Shithouse Rats on Rolling Stone, named after a song of Bob Dylan or Muddy Waters or the group itself (don’t know which one) and all of them are quite famous and mainstream. You’ve got to love mankind, we are awesome!
- skrtskrt 6y ago
  I feel there can be a fair reason behind this, which is basically that using a tool no one else uses, even if it’s great for the use case, is likely to be a losing battle. Hard to get using it approved at work, less usage means fewer bugs are caught and features developed, etc. So people evangelize their favorite tools because it benefits them directly to have them adopted more widely.

Geminidog 6y ago

>No tool will fix wrong assumptions or bad design, we can dive into philosophy here but I’m more of a practical person so... :) And no design can fix a bad tool, we can dive into the practicalities here but I'm more of a philosophical person so...:)

throw1234651234 6y ago

The only practical application of MongoDB I can justify to this day, is if you have a form builder, that allows users to build completely custom forms. Forms.io gives you the form schema in such a scenario as JSON out of the box. That gets matched with answers as JSON. Saving this to MongoDB directly, rather than SQL seems to simplify things. With anything else, at the end of the day, you are enforcing FK constraints anyway, so might as well use SQL. I never had issues with MongoDB performance. One caveat to this is that I am yet to see a project that needs database sharding in real life, and I have worked on projects with millions of entries in a table and hundreds of writes a minute.

CodesInChaos 6y ago
Most relational databases have some level of json support nowadays. So I'm not sure how much it simplifies in that case.
- throw1234651234 6y ago
  There is appeal to the json being directly searchable in the database, ala MongoDB. Specifically for analytics/reporting. The problem is that most analytics/reporting/BI tools SAY they support MongoDB and then they tell you to write a "connector" for each entity, at which point it's easier to just move it to SQL.

jimbokun 6y ago

> “Why JS sucks”, “Never use PHP”, “Java is enterprise only”, “Ruby only works on hobby projects” All of these have at least a little bit of truth to them, and you should know about the downsides of technologies, even if you decide to use them anyways.

bdcravens 6y ago

In each of those language examples, there are examples of great software that migrated away from those languages for different reasons.

TomSwirly 6y ago

It would be more useful if you addressed the specific issues brought up in the article, rather than generically tried to dismiss all articles critical of any programming language...

jeff-davis 6y ago

I would argue that a lot of weaker elements in the stack (e.g. PHP) work well because of a stronger database. A good database system does a lot to catch errors (including consistency problems), isolate them, and roll them back. Moreover, it will allow you to move performance problems into the database, where it's likely to be handled more efficiently with less application code (e.g. joining in the database is likely to be more efficient than a naive join algorithm implemented in the application). Some will argue that these are misfeatures and should be handled in the application. In some cases, that is true; but you are probably going to need some other aspects of the stack to be very robust and performant to get reasonable results. In other words (please excuse my examples as they are intended for illustration and not flamebait), PHP over Posgres might be fine; Haskell over MongoDB might be fine; but PHP over MongoDB is playing with fire. I'd still say that, in most cases, the database layer is the first place to start to work toward a robust system. Even a proven-correct Haskell program can fail miserably if there was a minor bug three versions ago that wrote some bogus data that wasn't caught by a good database layer.

gher-shyu3i 6y ago

It really depends. Things can be built despite of the technology. I saw this especially at an employer who was heavily invested in golang. Countless times I've thought to myself that they wouldn't be having the issues they were having, sunken costs, reinventing the wheel, etc. if they used a proven technology like the JVM instead of drinking the kool aid and using the latest fad of the day. Tons of money was sunken into it, and it was made to work by force, but not everyone would be able to bear that cost, and it still causes massive inefficiencies due to poor tooling.