Hacker News Search

daliwali 9y ago

Popularity is not an indicator of anything other than popularity. McDonalds is the most popular burger sold in the world, that does not make it good. Length is an important consideration and most never consider it, partly why software is notorious for getting bloated over time. At some point it would be easier to rewrite code from scratch with less complexity and overhead.

kristianc 9y ago
> Popularity is not an indicator of anything other than popularity. McDonalds is the most popular burger sold in the world, that does not make it good. It doesn't make it good, but it does mean that it's unlikely to make you ill.
haburka 9y ago
Popularity means more eyes have looked at it, more issues have been made, more contributors exist. Of course, I've had issues with dependencies that were popular but generally it holds that a library that's been around for a while and still finding usage means that it does a good job at it. The difference between code and a burger is that anyone can consume a burger but code is consumed almost exclusively by professionals. A better comparison would be power tools where you'll often find that if a brand is popular, it tends to make solid, long lasting products.
- daliwali 9y ago
  The point was more about popularity having no correlation with anything else. There is tons of unpopular code that is really, really good, these are hidden gems. Likewise, there is popular code that is quite bad or mediocre regardless of number of contributors. To rephrase: PHP is the most widely used server-side scripting language on the web. That does not make it good.
  - seanwilson 9y ago
    > Likewise, there is popular code that is quite bad or mediocre regardless of number of contributors. Like what? If you're looking for a JavaScript library for example, you can't really go wrong picking one that has many contributors, an active issue tracker, thousands of stars, lots of forks etc. Unless it's some core part of your stack, I don't see how it's practical to spend a lot of time hunting down super well implemented libraries that aren't likely to be supported in the future because nobody uses them. > To rephrase: PHP is the most widely used server-side scripting language on the web. That does not make it good. I'm not a huge fan of PHP but you can still write good software in it. Libraries are relatively easy to swap out compared to say operating systems and programming languages. Personally I find many of the best libraries tend to be the most popular ones.
    - daliwali 9y ago
      I have a rather unpopular opinion that JS libraries get popular for reasons unrelated to merit, such as corporate backing (React), appeal to beginners (jQuery), and adding syntax sugar that has no value to end-users (Underscore/Lodash, Babel). They are symptomatic of organizational problems related to herding programmers at scale. To beat the average, by definition you can't just do what everyone else is doing and expect outstanding results. If your problem is unique there won't be a library for it. If you find or create a hidden gem, it's your secret weapon, you are its user and responsible for it.
      - seanwilson 9y ago
        I use React, jQuery, Lodash and Babel and think they're great projects. What equivalent projects would you replace them with? What are you using that you consider a secret weapon? Going back to my original comment, I don't understand how you can pick these libraries as examples of things you should avoid if you read the source code.
emodendroket 9y ago
> Popularity is not an indicator of anything other than popularity. McDonalds is the most popular burger sold in the world, that does not make it good. On the other hand, McDonald's is pretty reliable and you know you're getting something palatable that is probably safe to eat (in the short term, anyway). You don't need to pick the best-in-class library for everything.
horsawlarway 9y ago
You sound very close to advocating a "Not invented here" approach. (https://en.wikipedia.org/wiki/Not_invented_here https://en.wikipedia.org/wiki/Not_invented_here) There are some rare cases where that makes sense (Keyword: RARE), but most times I've seen developers take that stance, it leads to longer development times, less consistent code, more maintenance work, and generally pretty shitty outcomes. Popularity is ABSOLUTELY an indicator of things other than just popularity. However you need to understand why the thing is popular and vet that against your needs. Finally: McDonalds IS good. I don't eat there often, but they provide a consistently satisfactory experience for their customers. There's a reason you can find McDonalds nearly everywhere on the planet. It's popular to diss on companies that have become large iconic chains, but they're large iconic chains for a DAMN good reason. Plus, they're solving supply chain issues you aren't even considering, much like large popular libraries are handling use-cases and problems you don't even know about. Can I make a better burger? Sure. Can I make a better burger for the same that McDonalds charges, as consistently as McDonalds does? Fuck no. The same probably applies to your software.
- khedoros1 9y ago
  > Finally: McDonalds IS good. I don't eat there often, but they provide a consistently satisfactory experience for their customers. There's a reason you can find McDonalds nearly everywhere on the planet. McDonald's is consistent, predictable, cheap, generic, and ubiquitous. Sometimes those are good qualities. "Good enough" is usually good enough, after all. Regionally, there are a half-dozen choices that I'll take over McD's: Less iconic world-wide, but as cheap or cheaper, just as consistent, and more pleasing to the palate. I think that's closer to what they were advocating: Not necessarily building it in-house, but also not taking popularity as a reliable indicator of code quality (beyond a bar of minimum acceptability).
  - horsawlarway 9y ago
    If it hadn't been for the last sentence: >At some point it would be easier to rewrite code from scratch with less complexity and overhead. I'd agree, and probably wouldn't have commented. But I think being all of these things: >consistent, predictable, cheap, generic, and ubiquitous. Means you have a damn good product. No one is claiming you can't get something better, but come on, I'd love to have software that's consistent, predictable, cheap, generic, and ubiquitous. If those words describe a popular library, and you decide instead to build your own thing in-house... you better have a really REALLY good reason for doing it.

dom0 9y ago

Reviewing dependencies avoids dragging shitty, obviously broken and/or horrifically inefficient code around. You don't want to use a data serialization library that is so poorly written that it likely corrupts stuff sooner or later, do you? Or a crypto library that documents almost nothing and requires you to review x86 assembler to find how parameters are actually interpreted cough? Taking at least a cursory glance at the code is one part of vetting dependencies before using them. Other activities would be: checking use of best practices ("Your parser written in K&R C is probably fine without fuzzing and any tests"), availability of documentation ("source is there, no?"), checking for known vulnerabilities and bugs (First open issue: "Library segfaults when parsing long lines of []{}"), maintainership ("Last commit: 2004") and portability ("(void*)a + (int)5.7").

Animats 9y ago
You don't want to use a data serialization library that is so poorly written that it likely corrupts stuff sooner or later, do you? Python's CPickle comes to mind. There's a race condition in there somewhere, but I've never been able to reproduce it with a small program. [1] Using the version of Pickle written in Python works. This sort of thing is why I'm somewhat negative on the argument that "if Python is too slow, write the important parts in C". It's too easy to break Python's memory model in C code. [1] http://bugs.python.org/issue23655 http://bugs.python.org/issue23655
- dom0 9y ago
  On the other hand it's fairly easy to not break Python's memory model if you don't unlock the GIL :) Edit: Ah that kind of bug can be ... tricky.
seanwilson 9y ago
> You don't want to use a data serialization library that is so poorly written that it likely corrupts stuff sooner or later, do you? Or a crypto library that documents almost nothing and requires you to review x86 assembler to find how parameters are actually interpreted cough? If it corrupts data and has terrible documentation it wouldn't be popular. It's usually very obvious from the community around the library if it's got major problems or not.

MattConfluence 9y ago

I program a lot of Python using PyCharm, and one of my favorite features of this combination of language and IDE is how easy it is to hop into the source of your dependencies. Anything you have imported into your code you can bring up the context menu for and click "go to declaration" (or use the relevant keyboard shortcut). Python dependencies are source code, not compiled blobs, and the import syntax makes it very explicit where definitions come from. If I'm unsure how to do something with the library I usually look at the source of the relevant module before looking up online docs.

reitanqild 9y ago
Java, Maven and Netbeans is almost as easy but since dependencies are compiled I have to click one more time, -download sources- and there I have it.
- jdmichal 9y ago
  Eclipse will automatically attempt to download sources from Maven when you jump into a dependency.
  - reitanqild 9y ago
    I suspected it was easy in eclipse as well and should possibly have mentioned that. That said let me add that IntelliJ probably has similar systems.
    - nazgul17 9y ago
      If you don't have the source, IntelliJ will decompile the binary and I must say it does a terrific job. It also handles downloads via Maven, but I have only done it only once and don't remember the details.
Entalpi 9y ago
This is why I love C++ and C even though you cant find the source you can read the headers.
- sigjuice 9y ago
  What programs or libraries are these for which you can't find the source but have the headers available to read?
  - smitherfield 9y ago
    Anything proprietary? Trivial example: Windows or MacOS system headers.
    - sigjuice 9y ago
      Doh! Of course. Being on Linux almost all the time has given me tunnel vision.
  - Matthias247 9y ago
    All proprietary third party libraries which one might depend on. And depending on the domain that could be at lot.
lr4444lr 9y ago
I think the ease with which your IDE lets you get and debug into the source code of your dependencies (assuming your language lets you do this) is definitely something I overlooked in my earlier development career as pivotal to better understanding not only the dependencies, but how to think about software from other peoples' POV, which when done often enough gives you a better intuition for where and why different bugs manifest. JetBrains indeed makes some awesome products.

mixedbit 9y ago

Just a brief study (~few hours) of mysql and postgresql sources allowed me to made a definite decision which of the two is a better choice for all my web projects.

brianwawok 9y ago
Do tell ")
lufte 9y ago
Please elaborate. Did you write a blog post or something like that to document the experience?
agentgt 9y ago
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).
- samastur 9y ago
  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.
  - agentgt 9y ago
    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.
  - crucini 9y ago
    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.
- mixedbit 9y ago
  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.
  - agentgt 9y ago
    > 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).
- juliangoldsmith 9y ago
  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.
  - agentgt 9y ago
    > 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.
    - juliangoldsmith 9y ago
      >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.
      - agentgt 9y ago
        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).