>> I have to admit that when I first looked at the Thrift compiler I was a >> bit puzzled by the choice of language and the dependence on Boost. then >> I realized that they probably didn't have open sourcing it in mind when >> they made that decision.
I'll provide the historical backstory here in case folks are interested. C++ was actually chosen *because* of the early commitment to open source. C++ was by far the best available option for ease of distribution and installation. Using Python would have required everyone to have the right Python extensions, like PLY, which are not part of the core language. This work started in 2006 -- Python has continued to gain popularity over the past 4-5 years, not all developer were so on board with it back then. Same issues with Java -- the core language does not have a parser built in. Also, there are still a fair amount of people interested in Thrift that fall in the religiously-anti-Java camp (I am not one of them, I like Java, but I accept that for better or worse a lot of systems-y people dislike it). Not all Linux distributions have consistent Python/Java interpreters setup as part of vanilla installs (notably, the images we were using at Facebook did not include a Java runtime, as we generally had no need for it). And if you don't have root, dealing with things like site-packages and paths is a big headache. So, using those languages would have meant putting a big hurdle in front of many users considering trying out Thrift. By contrast, lex/yacc are *completely* standard. You'll be hard-pressed to find a *NIX distro anywhere on Earth that doesn't have working versions out of the box, they've been around forever and their interfaces are super stable. Like the autotools, even if they're not the prettiest things to work with, everyone has them lying around, and they almost always just work. Choosing C++ meant that for 99% of users, getting the compiler up and running (step one in evaluating Thrift) was as simple as (1) download (2) configure (3) make. Boost was *not* originally a compiler dependency, and I agree it can be a real pain to work with (perhaps comparably to maintaining site-packages for Python, or adding JARs to your environment classpath, etc.). If our goal is ease-of-installation-and-use (optimizing for the Thrift user), then my vote is to work on removing boost as a dependency to build the compiler. If the goal is elegance and maintainability of the compiler code (optimizing for the Thrift developer, which theoretically benefits the user indirectly), then I agree that something like Java is probably better. Anyways, that's the story on why the Thrift compiler was written in C++. Cheers, mcslee -----Original Message----- From: Bjorn Borud [mailto:[email protected]] Sent: Thursday, August 26, 2010 4:46 PM To: [email protected] Subject: Re: Thrift compiler in Java (have parser, willing to hack) Roger Meier <[email protected]> writes: > Yes, that's an important issue! > > what do you think about a compiler that only needs C as described in > https://issues.apache.org/jira/browse/THRIFT-506 I have to admit that when I first looked at the Thrift compiler I was a bit puzzled by the choice of language and the dependence on Boost. then I realized that they probably didn't have open sourcing it in mind when they made that decision. (a lot of much more trivial code I have written at various companies in the past have had far more pointless constraints and dependencies due to, for instance, in-house standard libraries that "everyone" must use). choosing a language that produces platform specific binaries for a tool that is, by nature, cross language and cross platform, is unfortunate. even more so when we are talking about a moving target. (meaning, you have to expect that people need to upgrade the compiler relatively often until Thrift settles somewhat). (I gave this some thought a few months ago and my conclusion then was that Python would probably have been the best choice (mature enough, understandable enough for "non-native speakers", present on almost all platforms, no platform specific binaries to distribute, "unoffensiveness" etc). Note that I am no Python developer -- I just thought that for this type of tool Python would probably be easier to sell to some majority of developers across the language spectrum. And no, I didn't ask a representative cross section of programmers for their opinion so it is entirely within the realm of the possible that I am dead wrong :-)). > compile that one for different platforms and make it available for > each version on the download web site? I've spent years of my life developing software in C/C++ that needs to compile to lots and lots of OS/hw targets and I miss both the development process and the release building about as much as I miss having to hear Michael Bolton's music in public spaces. -Bjørn
