ISC Releases the First Look At BIND 10 172
Ethanol writes "Internet Systems Consortium, producers of BIND 9 (the most popular DNS implementation on the internet), have spent the past year working on a successor, BIND 10. It's entirely new code, redesigned and rewritten from the ground up, and now the first glimpse of what it will eventually look like has been released. 'This code is not intended for general use, and is known to be inefficient, difficult to work with, and riddled with bugs. These problems will all be fixed over the next couple of years, as functionality is added and refined, and the software matures. However, the codebase has a good framework for moving forward, and the software is capable of serving as a DNS server with significant functionality.' (Full disclosure: I work for ISC and I'm one of the engineers on the project.)"
How (Score:0, Interesting)
Is that pronounced? Does it rhyme with sinned or blind ?
It doesn't look very understandable to me (Score:5, Interesting)
Well, I took a look at the code, and it's a typical "modern" C++ design. There's a gazillion classes in an "everything-is-an-object" hierarchy, using the latest and greatest "patterns" in superfluously complex ways. Doesn't anybody care about simplicity in design any more? Granted, BIND9 code was a mess, but this IMO is not much of an improvement. Ugly C++ is just as bad as ugly C. For example, why, for the love of God, would you replace a simple enum with a class with a member variable set to a constant value, and with each instance of the class created by a named constructor with a hardcoded constant in it? In src/lib/dns/message.h there are four of these. And what's with all the wrappers? I suppose it's their definition of "extensibility" -- a framework where everything is accessed through wrapped pimpls, so that anybody could change the implementation without changing binary compatibility with... oh, wait, it's an executable, so WTF? When you change something, you have to rebuild it anyway. So all you really get is ugly wrappers over ugly wrappers over actual code. Why do you need these wrappers anyway? What's wrong with boost's base64_encoder, for instance, that you need to wrap it with an encodeBase64 function, which instantiates a 20 line local BinaryNormalizer class in an anonymous namespace, the purpose of which, as far as I can see, is to pad the binary input with zeroes in case some evil application decides to read past the end of the vector. Oh, wait, this is only called from encodeBase64, and the read-past-the-end thing never happens. So WTF?
That's just four files I looked at, and already it's WTF piled on WTF. Maybe I ought to submit it to thedailywtf.com and see if it's accepted...
Bizzarro world of DJB haters (Score:3, Interesting)
Enforcing your copyright over original content is a bizarre license scheme? Patching considered bad? Actually doing something you promised is wrong? Public Domain is a license?
Wow, you really have drunk the DJB haters kool-aid.
Re:It doesn't look very understandable to me (Score:3, Interesting)
> If you could send critiques like that to the developer list instead of posting them to slashdot,
> it'd have a better chance of getting attention from the other developers
The problem is that I simply don't see what sort of "attention" I would want in such a situation. Yes, I could write up a mile-long list of complaints about the code, but it would not do any good because they would all add up to: "your code sucks; throw it all out and start over". It's not just one little thing or two little things, it's everything. It's the whole approach to interface design that plagues all open source projects and it's caused by releasing too early. Once the code is "out there", there is a chance that somebody will start using it, so you start worrying about breaking the API and inconveniencing these (often imaginary) users. If you know from the start that you intend to release early, you end up designing safety factors like pimpl into the API, in case you want to change something. I would advocate the opposite route: let the API float until the implementation settles, because you don't know how to best access the implementation until you have the implementation. And once we state our positions, there is nothing that can be done short of starting from scratch, which in not an option for a codebase many years in development.
Furthermore, my gripes have a very different focus; I care passionately about code size. To me, code simplicity is the most important goal. Simple code is easier to understand, easier to maintain, less buggy, and faster to run. I believe that code simplicity is best objectively measured by measuring the size of the resultant execuables, because "simple" should primarily mean "simple for the computer". Thus, most of the complaints I am likely to make about your code will relate to what it looks like to the computer. That's where your pimpls and out-of-line wrappers and externally visible long names all are painfully obvious. And it's also where no modern developer ever thinks of looking. No modern C++ programmer looks at the assembly his source code generates, and so he remains ignorant of where all the horrendous bloat is coming from. He doesn't understand that objects aren't real and that abstractions have costs. And from that lack of understanding comes a horrid implementation, from which then comes a horrid API.
I can complain all day about your design, but you won't know how to fix it until you understand the above problem and learn to see your code from the computer's point of view. Then I won't have to tell you what is rotten about your code, because you'll know it. Thousand-instruction functions will burn your eyes and you'll scream "but I didn't know!" and maybe then, grasshopper, will you achieve true enlightenment.