Robert: Robert Ramey (via Skype)
Ralf: Ralf Mikulla (table host)
Other: other participants
Robert: Robert Ramey (via Skype)
Ralf: Ralf Mikulla (table host)
Other: other participants
Greetings.
Ralf: I try to explain what's going on here: The people all discussed one subject and one question, "What about libraries and frameworks? Which libraries do you use, how do you use them, what problems do you have?". To summarize it: There were totally different people here, some students but also some professional software engineers. I identified four topics: 1) Triangle between learning, enabling, and efficiency. There were some people who said: "Well, we don't use any other frameworks or libraries because we want to write them ourselves." A typical C++ beginners attitude, I would say. Others said: we need them, they enable us to do something; and then comes the question "how efficient is this?". 2) Documentation. People said documentation is important. Some people wanted more tutorial like documentation and not typical library documentation like Doxygen. 3) How to manage dependencies. Many people said they don't know any solution; some of them just commit the source code to their own projects; I showed a thing we do in our company (which is doing logistics and traffics) where we have used the Java tool Maven, also for C++ and dependency management. 4) We covered the management of patches for libraries because when you use other libraries (especially open source), you often find problems; then the typical way to deal with that is to have repositories of patches. Exemplary libraries that people used where googletest, catch, boost, Qt, and some special libraries like open graph. That's what I wanted to summarize. In order to provoke you, we had some people who neither liked nor used boost and stated the following opinions: Sometimes the code quality is not good enough, sometimes they did not like the header implementations, and the library was not complete enough (eg someone needed several days to get the planar graph tests for the boost graph library working). What is your opinion, Robert?
(At 4:50)
Robert: That sounds like a good summary. I have actually something to say if anybody asked me on any of those questions: The first question was about whether it is useful to use libraries as opposed to writing something yourself. For a lot of things, I don't think writing it yourself is good. For example when you are writing your own shared pointers, any one of those things is a huge effort to get right. When you are a student, maybe you don't appreciate that. But the fact is, that any of the components that are in boost (and other library like CGAL or Qt) just entail a lot more effort to get right then first meets the eye. Every project starts out really simple. Frankly, anybody can start a project; but only a small portion of the people implementing any of this functionality actually finish it. So that's what I think: If there is something already made, it is not economic to redo it yourself. Now, if you don't find something of good quality or that matches, that would be a separate question. But I see many people thinking that they can take a boost library, or even standard library, and do a better job, because they can make a faster vector or whatever. I think they are almost always wrong. But since they haven't finished their job yet, and there is no real comparison, I can't prove that. So that is what I have to say about the choice of whether or not to use a library.
(At 6:35)
Robert: Documentation, that is a running festering sore in the whole issue of software development. Programmers don't know how to do it, they don't like to do it, it is tedious, they do it at the end, and it's just the minimum that they are required to do to have somebody accept it. For open source packages, 98% to 99% have no documentation at all. For the person who wrote the package, the situation is that only they will understand the code even though they think anybody will understand it by looking at it. But it shows that throughout, this has come up as an issue. I was actually hired by someone to write the documentation for their library. I have been complaining about bad documentation for a long time. I made a presentation at CppCon 2 years ago about boost Units, and the whole presentation was about what the documentation didn't include, and what you really need to use the library. I also made a presentation last September about how to make a boost library, and frankly the major part of that talk was on how to write a document that helps people use the library. And I have made a proposal for this coming CppCon about what I believe is the right method to make a documentation. I won't go into too much of it here, but I will agree that this is a big problem, and whoever lays the issue is exactly on point and I am taking it upon myself to take a crack at it. So we'll see how that works out.
(At 8:25)
Robert: Dependencies is another festering sore: We have never been able to get it right. My personal view is that people have had unrealistic expectations about what an automatic dependency manager can do. In the final analysis you have to make the dependency related to the particular application you are making. I also won't go too much into that because it starts to spiral down hill into complaints and into the most arcane discussion. It's been going on for years, it's never really been satisfactorily resolved. And I think it is because the question isn't posed properly. But I haven't been able to make headway on convincing anybody else of that.
(At 9:10)
Robert: So I think the boost libraries, they suffer from all the problems that other libraries do, but to a lesser degree. They are reviewed, they are tested regularly, they are required to have documentation. All of these things, they could be better, but it's certainly going to have a lot more tests, a lot more documentation, and a lot more code review than anything you are going to write yourself. And not to mention, it's free. Now unless you are working for free, you are spending your money on something that has already been done. You can do that, and if its a sort of technical inquiry, maybe that's fine. But I am always under huge pressure to get the job done as soon as possible. So I'm a big believer and heavily dependent on the usage of libraries. I spend all my effort in doing the thing that is not already done and which is my special area of expertise. So, I think that sum's up my views on those questions. Is there anything more you want to ask about?
(At 10:20)
Ralf: First of all I can say I fully agree with almost everything you said.
Other: You mentioned that one argument for boost is that it is free. If I remember correctly, you mentioned on a cppcast that you were pushing the model that some boost libraries should be payed for so that the developers can actually finance themselves while putting in a lot of time to develop that.
Robert: Okay, that's a fascinating question that I threw out. That's a pipe dream. Right now, the world of software development and music and intellectual property is sort of in a state, where I don't think many content creators are getting fairly compensated. In software, we all depend on software we get from somebody else, and I don't think that's a bad thing. It's a good thing, but personally, I'd like to see the question considered: is there a way to figure out some system by which some people who have done really stellar accomplishments, which have tremendous value and are used by many large companies, to get some compensation for that? This is a whole different area that goes beyond software development. It probably will never be solved, there are so many interests, with their finger in the pie. I have been working in companies where they had the opportunity to use some library that did not have a boost license. I said: call the author and offer him a thousand bucks; it is going to save 30.000 dollars of our effort, it's going to save us a few man months to get it working, and it probably still won't be as good. Why don't you just call him and offer him a thousand bucks? They didn't want to do that, because they were afraid it will set a precedence or whatever. So in this kind of environment, where we are really in a situation where I believe that people who put in extraordinary effort, and who are very accomplished and have done a huge amount to move the world forward, are not being recognized, and they are not being compensated for their extraordinary work they have put in. What I was talking about there is like a utopia. Something of such a huge sea change, I wouldn't expect it to see in my lifetime. On the other hand, I am almost 70 years old, so my lifetime isn't that long either, so maybe you guys will see the change, maybe you'll get to be rock stars.
(At 13:30)
Other: Wouldn't a solution be something like the model that some libraries do with a free version under GNU GPL and a commercial version when you want to use it for closed source development?
Robert: I think that's interesting, I have seen environments like that. I think CGAL promotes that model. I have no idea what the future is going to look like. Actually, we don't have a clear idea of what it should look like. I do believe that the GPL with its, let's call it infectious, nature has been counter productive. So now some things are dual license, but once you have a situation like that where the company lawyer has to get involved, then it is not cheap anymore because the entire time he wastes on it is about as much as you would have, and he is even more expensive than we are. So, I don't know what the real solution is, I am really just kind of complaining about the problem.
Ralf: Yes. So I think if you are using libraries, especially open source libraries, you should know what you are doing. So you know the licenses. That is one point; but the other point is, you have to be prepared to manage it yourself, so that you have your own patch sets, which belong to your product and your environment, and you have to manage them, and that's kind of the cost this model has for you. And it has many many advantages, like many tens of man years of work, which are in it, and you should know that you should take these measures.
Robert: Your first point is very interesting. I can take a piece of open source software, I like the license, I try it out, I like it and incorporate it, that's fine. But it doesn't release me of the responsibility to make it work. It's just like when I build a house: Well, I don't buy all the plumbing, and the faucets, and all of that; if the house falls apart, I can't come up and say I'm not responsible for that because I didn't buy the plumbing. I am responsible for the whole thing. So open source, as it is, is not any different than any other kind of work that we acquire. So there are solutions to that, and the problem is not unique to us. I guess I want to put it that way. We still have the responsibility for making things work. I would love to see that people, for example, decide to use the serialization library, which saves a lot of time. I would like to see them all, on their own setup, run the boost test suite that comes with it. It's about 250 different code modules which end up in about 1200 different tests that take about 30 to 45 minutes to run. But honestly, if I had my big company and I am depending on the library, what the heck is 45 minutes, which is going to run in the middle of the night anyways, to make sure at least it passes all the tests that the author expected to pass. And yet, as a practical matter, I don't think I have ever come across a user who is running those tests. As part of boost, I run them here. Sometimes people think they find a bug, or there is a confusion, or they want to do something that is not clear how to do, or even make a pull request; they make the change in their own system, but they don't even rerun the tests. There is a big discrepancy of what people say that should be done, and what people do themselves. Now there is an issue that running the test is an extra pain, and there are problems like that. But even so, I would like to see anybody that acquires an open source package to be able to run the tests that come with it and certify them on their platform (remember, with C++ every platform is a little bit different), to verify before they get serious about it that it actually passes the tests on their platform. And that would also give me huge feedback on all the nooks and crannies and bugs that might happen in places I can't personally test. So, anyway, that's an interesting subject I went on too long about, but it touched a nerve.
Ralf: I fully agree, and I once made a talk about the use of open source software; one of my points was that you have to give back something to the community, and that is actually the feedback you have created in your own system. For example, we build the open source software that we use in our continuous integration system to see that it at least compiles. Your remark that we should also use the tests there, that is something that we have to discuss internally, but I think it is a good idea.
Robert: There is an obstacle, when talking about the boost tests -- and they are better than others: the whole executing the test is always more complicated than it should be. That's really the problem with our infrastructure and tool infrastructure. Not just boost, C++ development has a couple of really bad spots: one is the build and the configuration management, and it is still after many years awkward and clunky and doesn't work well. So in a sense I understand why people don't do it, it should be totally idiot proof. Because we want to think about something else. But in practice, it is a pain in the neck. So this is something that we really have to fix, both on our end and also on the user end.
(At 20:15)
Ralf: Are there any other questions or remarks.
Other: So I also fully agree. A couple of times I had the question of what the root cause was and how you could fix it. So for instance if people actually do a pull request or they put in their own time, but haven't run the test, then is it just maybe a communication problem or is it some kind of character trait that usual developers have that they actually try to avoid testing, or what do you think is the root cause?
Robert: I think you touched on all the points. To start with, people who discover a problem and fix it in their code, they're confident that they know what they are doing. They just believe testing isn't necessary because it is so obvious. I think that is certainly human nature. That is number one, and that goes double for programmers, because we are kind of over-confident of our own abilities. That is a problem. And then two, frankly setting up the boost test setup is more work than it should be. So those two things conspire to keep people from running those tests. If we had those tests running simply, so that whenever you get an open source package, right away you could test it without doing any special setup or hassles like that, then we could start to demand: I could say anybody who sends a pull request has to attach the output of the test results, otherwise, I won't even look at it. That would solve the problem, and I could do that now, but since people can't easily generate those test results, it wouldn't work for me. How does that sound for an answer?
Ralf: Why does boost have its own test tool?
Robert: Well, now we are going back to the first question. Because it was made by programmers who don't even think by library solution is something that they can't do better; so they had to make their own setup, and that's where we are.
(At 22:40)
Other: But with regards to having to run the tests yourself: Personally, the solution that I really really prefer to do is I just use what my package manager of my operating system delivers, and I expect them to run the tests. I think it solves a lot of the problems we have talked about. And it also has another advantage: I have to trust my OS developer to begin with, so I think they are the best bet on also maintaining a repository that works well. I think if you use that, I am not so sure why I should bother running the tests if they hopefully do.
Robert: Okay, so let's talk about that for a second. Let's talk about C++ and typical C++ libraries. C++ is a tremendously mixed language, and it varies depending on the compiler and platform. Some people like using wide characters, some people not. Some people are compiling their library as a DLL, other people as a static library. Some use certain particular compile time switches, some don't use RTTI, some don't use exceptions. So when you get a library package, it's not like you get an executable that is already built to run on your system. It's really a building block, and you are probably going to have to alter some settings in order to make it work with your code. Maybe there are compiler settings, maximum stack length, I don't know. So, once you look at all the possible combinations, you begin to understand that there's no way that I can test ahead of time for every possible configuration that people might have. The serialization library is in a certain state, and it's been there for 13 years, and now somebody comes up: "Ah, we can build C++ on Android". And Android has it's own set of quirks, which I am not familiar with. There is no way that I can know ahead of time that somebody is going to invent a system called Android and that it's got its own special set of features. And then there is this other issue that a particular library, eg serialization, depends on the STL library, which comes from your vendor, and also depends on operating system calls -- for failure characters/error codes, input/output etc. So the idea that we can get something pretested just as when extending a part of the source code that we presume has already been tested, is not really realistic because your combination of settings and features and etc is not something that I have included in my test set. So you can't really depend on me to do that part for you. But what you should be able to ask me to do is say "hey, when I download a package I should be able to get a push button test". I think that is a reasonable expectation that we really will be able to deliver.
Ralf: As I said before, you are responsible for the software you are delivering. So you should make your tests, which are in your environment. Beyond that, I fully agree.
Robert: Ok. Well, that was easy.
Other: It was really fun and informative. I am really happy about your responses, I found them really great, and also the moderation was good. I think this was a great Skype session.