Hacker News Reader

Comment by agentgt | Hacker News Reader

Seriously?

I am assuming you are not a database expert but basing this on the look and organization of the code and not the data structures and design. If that is not true than please share your findings instead of teasing us.

I'm curious would you do the same with your editor (or IDE)? You should see the source code for those behemoths (with the exception of the rewrites like nvim) they are pretty nasty.

Are you going to pick a different editor just because Vim or Emacs (or whatever editor) has nasty code?

Guess what IDE has pretty clean code and is extremely modularized... Eclipse. I can tell you Eclipse is not a comfortable editor (and I use it all the time because I'm used to it not because the code is elegant).

Mature projects often have pretty ugly code but they are mature and stable. Ugly code also doesn't necessarily mean poor design (e.g. if your editor is single threaded and has nice looking code its still single threaded).

View on HN

There's a difference of category between your and parents example. Editors and IDEs will not make your code crash when it is deployed no matter how flaky or not they are. Databases on the other hand can.

I wouldn't imagine it being controversial to prefer well engineered code over less so for bits you will need to depend on.

Yes but databases are not your normal application, library or tool. They require a fair degree of expert knowledge and I agree even more are a critical component.

I would much rather choose a battle tested database that has the features I want, performs well to my testing and profiling than "familiar" looking code. Because good looking code is really more often or not familiar looking code.

So unless the OP is an expert I believe basing the most critical aspect of your application just because the code isn't to your liking is sort of asinine.

Have you looked at MySQL's source code? Pretty tangled, and that's an excellent database.

Also vim is not flaky. The insides may be a nightmare, but it's very solid.

If there was a new editor with little history I think the quality of its code could help to decide whether it is worth switching and learning (Editor switch is very expensive for a programmer).

Mysql and PostgreSQL offer similar functionality, people use both systems for similar tasks. When you try to decide between the two, you find conflicting arguments all over the web. I think in such case looking at the quality of code can be a key signal to help you make a good decision.

I do agree that projects with ugly code can still be extremely useful and in many case an optimal choice, but such project will more likely become obsolete quicker and will cause problems more often than project with high quality code.

> Mysql and PostgreSQL offer similar functionality, people use both systems for similar tasks. When you try to decide between the two, you find conflicting arguments all over the web. I think in such case looking at the quality of code can be a key signal to help you make a good decision.

It would be pretty low on my check list. The number one for me would be profiling and testing the databases. IMO you should do that first. Even the ability to extend the database with plugins would be higher on my list than code quality (this is for a database). Probably 10 other things would be higher on my list than code quality (again for databases... for libraries thats a different story).

I'd disagree with your analogy. If your text editor crashes, it will cause a few minutes of lost work. If your database engine mangles your data, your site will be down for however long it takes you to restore from backups.

Looking over code would give you more than just an impression of its style; it would also give you a feel for the quality of the product. If most of the code you look at is of poor quality, it is very unlikely that the product, at a high level, will be any better.

> I'd disagree with your analogy. If your text editor crashes, it will cause a few minutes of lost work. If your database engine mangles your data, your site will be down for however long it takes you to restore from backups

So you are going to base the crashing of a database on the cursory non expert runtime of your eyes. Why not just test the database, read the doc, ask other experts.

Secondly rarely do most developers extend their database so their is very little need to know that codebase and they probably should not change that codebase (given the criticalness).

You know what developers extend often... their editors and IDEs. The code quality (in terms of readability) of that should be much higher.

Now obviously if you have nothing but the code to base (like no doc, no benchmarking, no existing mind share, etc...) and are generally knowledgeable in the area than yes code quality would be a good decision criteria but I remind you the OP said it was the major reason between Postgres and MySQL which are probably written by superior experts than the OP.

>So you are going to base the crashing of a database on the cursory non expert runtime of your eyes.

You look over the source code to decide whether the database is worth proceeding with. I would assume the OP did other research as well, even if code quality was the deciding factor.

And again, I don't find the text editor analogy a compelling argument.

Perhaps Operating System would be a better example.

It is hard to map an analogy 100% (after all it is an analogy).

> I would assume the OP did other research as well, even if code quality was the deciding factor.

I wouldn't assume anything about the OP particularly given how poor the original comment was (including not telling what his/her findings were).

If I view the source code to an operating system, and it looks like it was written by an amateur, I'm probably going to try to find a better option.

I would say his comment implied he went with Postgres. I generally think of MySQL, which, if memory serves, was started by people with little database knowledge, as not being as high quality as Postgres, which came directly out of another relational database project.

Reply on news.ycombinator.com