Source Navigator is the perhaps the most amazingly useful freebie I've ever downloaded. It's absolutely indispensible for making sense of large C/C++ codebases (and it has some support for other languages too). The cross-referencing ability is particularly useful; it's great to be able to call up a graphical call-tree of any function.
You need to look into ACE. ACE is a set of middleware libraries that were designed for precisely the purpose you describe - high-performance, mission-critical systems. Doug Schmidt, the guy behind ACE, has written numerous papers on the usses surrounding such systems, which are also available on that site. He was the first to document a number of important patterns in high-performance netwrked systems, like Reactor, Proactor, and Futures. He's also written books, including books of patterns for distributed reliable systems.
From that site you can also find TAO, a free CORBA framework based on ACE. TAO is the test bed and driving force behind the CORBA realtime spec, which is a version of CORBA for realtime systems which demand high and deterministic performance. I believe TAO includes services supporting failover and other reliablity strategies.
ACE and TAO aren't just research software. They are used in mission-critical systems by major defense and aerospace contractors. I work at one such.
Sorry to sound ilke a shill. I'm not paid by them or anything; I'm just a programmer who uses ACE for his job and has been favorably impressed with it.
I've been buying Cheapass Games lately, and I've been very pleased with them. They're cheap (duh), they put original game mechanics ahead of fancy packaging or gimmicks, and they incorporate a healthy amount of humor.
As someone who was homeschooled from birth through highschool, I can vouch for the fact that curiousity and learning are a child's natural state. In my experience most of the homeschooled kids I knew didn't think of education as something boring but compulsory, but as a natural and often exciting part of life and play. It takes a concentrated, long-term effort on the part of the school system to to turn something that kids naturally do into something they see as a chore to be avoided. This accounts for the success of families who choose "unschooling" (unstructured, self-directed learning), which according to the conventional wisdom would produce idiots.
Believe me, I combed through the manual. The manual didn't even mention that the battery was in the rear, and the diagram it showed for accessing the battery didn't give enough context to make it clear *where* in the car it was located.
I rented a Volvo station wagon recently while my car was being repaired. One day my wife needed her car jump started. I opened up the hood, only to discover that the battery was nowhere to be found.
After much investigation, I discovered the battery buried under floor of the rear cargo area, firmly locked in place by steel brackets which made the use of jumper cables a losing proposition.
Then again, if you consider things like _foo and __bar__ to be just as ugly as Perl sigils, you won't find ruby to be any more of an abomination than Python!
Every serious C++ programmer should have Stroustrup on the language itself, Josuttis on the STL, and Scott Meyers' "Effective C++" books. Alexandrescu's "Modern C++ Design" and Jusuttis' new book on templates also come highly recommended.
Wrong. In C/C++ a variable is a box. In Ruby (as in Python and many other dynamic languages) a variable has reference symantics, making the "nickname" metaphore reasonably apt.
Most of the examples given needed rewrites to remain viable. It's easy to look at a package from afar and declare it "perfectly sufficient". Things look different when you have to work with a system daily. In particular, rewrites often address shortcomings in a system's capacity for extension. Just compare the number of third-party extensions available for Netscape 4.* vs. the number now available at mozdev.org for Mozilla and Firebird.
A bigger problem, to my mind, is when a half-dozen projects with the noble intention of replacing an aging kludged-up tool are started, all of which suck in different ways, and none of which learn from each other. And then they lose momentum and stagnate.
Examples? Most programmers agree that "make" is overdue for replacement, but despite many attampts (cmake, jam, cons, ant) no one has managed to come up with one that is compelling enough to catch on. CVS is a crufty mess, but none of it's potential replacements are mature enough or have the kind of widespread tool support to make much of a dent in CVS installations. And there are dozens of written-from-scratch applications which differ primarily on the GUI toolkit they are based on, which would be better apps if they incorporated the best features from all into a joint effort. My idea of the perfect browser combines features of Konqueror, Galeon, Epiphany, Firebird, and Safari.
Even if you're installing off a set of CDs, apt-get works brilliantly. Just tell it what you want to install, it figures out all the necessary dependencies, and asks you for the CDs it needs.
Of course, upgrading off the net is where it really shines - apt-get update; apt-get install; get a cup of coffee, and if it really needs to know anything before upgrading a package it'll ask you. No tedious hunting for RPMs, no downtime.
...is how this is superior to putting a network of power generation satellites in earth orbit. What's the benefit of taking them all the way to the moon?
Because a) Mono is an implementation of the open ECMA-standard components of.NET, done without any knowledge of MS's implementation; and b) Mono is much more likely to help than to hinder MS, at least in the short term.
People look for a traditional western storyline, and they can't handle characters who are both good and bad, and stories that deal with multiple social issues, without offering panaceas at the end.
Ironically, one of the biggest reasons I dislike Anime is it's lack of subtlety. I've watched GitS, Cowboy Bebop, and various others that people have recommended to me as the "cream of the crop", and the aspect that stuck with me more than anything else was just how one-dimensional the characters were. Anger, angst, happiness, and humor are all layed on with a trowel.There are no in-betweens. Humor is always slapstick. Hatred is complete. Anime contains very little of the subtlety of live-action film, Western OR Eastern., and I've yet to see any indication otherwise.
So I watched it, and yeah, it was better than a lot of the anime I've seen, but it still sucked by any conventional film standards. Animation was horrible (I don't care how good of a painter you are, this is *animation*, the pictures are expected to move fluidly). The dialog was unremarkable at best (yes, I watched the subtitled version). The plot was cliched and confused (not confusing; confused). Animation still can't show fights worth crap; fights are always broken down into a montage of "scenes" - a girl rolls, a kick connects, a gun fires, a wall cracks. Worst of all, like all anime, it was way too wrapped up in it's own visuals. Note to anime filmmakers - I'm impressed when a live action film achieves an iconic visual style, because I recognize how difficult that can be given the realities of lighting, camera limitations, physics, and acting. I'm far less impressed when an animated film achieves a similar style, becaus by definition it's a completely controlled environment where (at least theoreticaly) anything is possible. So when Our Cloaked Hero stalks away, wreathed in steam, through a downpour, in perfectly noir-lit streets, I'm not going to oblige you be saying "wow". It's not like you had to arrange for the damn fog machines.
Also: anime depictitions of "angst" are as laughable as they are ubiquitous. Downcast eyes and hunched shoulders do not a Tormented Hero make. Don't think that a few seconds of canned backstory footage is a substitute for decent acting when trying to drag some character sympathy from the audience.
I get the impression that when fans sit down to watch anime, all the standards which they might otherwise apply go right out the window, because it's ANIME!!!
I don't know why people do this... they have to realize by now that a libel suit (or any suit) against any kind of media or publishing organization is just free publicity for the defendant. The most unfortunate outcome of this is that babbling fools like Atrios get all the attention while better, more insightful bloggers get tarred with the same stigma of unprofessionalism without any of the benefit of publicity.
Which got them from Ruby, which got them from Smalltalk, which got them from god knows where...
I swear, the most annoying thing about Python is not the language, but it's users who are convinced that Python invented all things good. Ironically, Python's generators are unusably broken (they don't work with exceptions) compared to any other language's implementation. No doubt that this admitted failing will be touted as a "feature" by Pythonistas in a few years...
You list back the services that I listed, and say they aren't needed - and yet when I read the spec, it described some of those very services. Not to mention the many, many TBDs remaining in that spec. This is why I'm encouraging understanding existing technologies - you don't know you've reinvented the wheel until you're aware of what else is out there. And then a year later you read over the existing technology's specs and realize "wow, these guys were dealing with exactly the same issues we had, only they gave them different names. I wish I'd read this back then!"
And in response to your camera example? I can give a good guess: probably ordinary-priority, asynchronous best-effort semantics. But just because the camera-plugged-in signal just requires asynchronous best-effort semantics doesn't mean some other event won't require different semantics. Sometime later someone may decide that an event needs high-priority delivery. That's the advantage of having a solid messaging infrastructure - you don't have to worry too much about what kind of message passing semantics you'll need down the road, because you know that no matter what they are, you'll be able to specify them and have them taken care of, transparently.
You haven't read much about CORBA, have you? CORBA *is* a message bus, just as much as it's distributed object architecture, and just as much as it's an RPC framework. CORBA facilitates the passing of messages between objects - whether they be actual objects in an OO language, or simply applications; whether they be on the same mechine or different. That's pretty much the definition of a message bus.
Regarding D-BUS: I've seen nothing so far that explains why D-BUS couldn't have been implemented on top of CORBA. There's no reason for a lightweight desktop-integration bus to specify low-level crap like the protocol used, bit-ordering in packets, etc. There's no need for any coupling at all between passing messages between apps and how those messages are passed. Marshalling, dynamic service repositories, naming services, protocol abstraction, QoS issues - it's all been solved already. Why invent yet another TCP publish-and-subscribe protocol when you can build on one that's already there - and in addition, be able to swap shared-memory for TCP if TCP turns out to be too slow, or choose synchronous semantics when you discover that certain messages really need to have gauranteed delivery. Sure, put an extra-simple facade on it if developers don't like working with IDL; but don't reinvent RPC. It's been done too many times already, and half of the stuff that makes CORBA complicated you're going to wind up recreating by the time you're done anyway.
Slashdot Mirror
Source Navigator is the perhaps the most amazingly useful freebie I've ever downloaded. It's absolutely indispensible for making sense of large C/C++ codebases (and it has some support for other languages too). The cross-referencing ability is particularly useful; it's great to be able to call up a graphical call-tree of any function.
You need to look into ACE. ACE is a set of middleware libraries that were designed for precisely the purpose you describe - high-performance, mission-critical systems. Doug Schmidt, the guy behind ACE, has written numerous papers on the usses surrounding such systems, which are also available on that site. He was the first to document a number of important patterns in high-performance netwrked systems, like Reactor, Proactor, and Futures. He's also written books, including books of patterns for distributed reliable systems.
From that site you can also find TAO, a free CORBA framework based on ACE. TAO is the test bed and driving force behind the CORBA realtime spec, which is a version of CORBA for realtime systems which demand high and deterministic performance. I believe TAO includes services supporting failover and other reliablity strategies.
ACE and TAO aren't just research software. They are used in mission-critical systems by major defense and aerospace contractors. I work at one such.
Sorry to sound ilke a shill. I'm not paid by them or anything; I'm just a programmer who uses ACE for his job and has been favorably impressed with it.
I'd be happy to implement missing features in FOSS applications in return for money.
I don't understand why the bounty system never caught on for FOSS...
I second the recommendation for Source Navigator. It's been a a great help to me in comprehending legacy codebases.
I've been buying Cheapass Games lately, and I've been very pleased with them. They're cheap (duh), they put original game mechanics ahead of fancy packaging or gimmicks, and they incorporate a healthy amount of humor.
As someone who was homeschooled from birth through highschool, I can vouch for the fact that curiousity and learning are a child's natural state. In my experience most of the homeschooled kids I knew didn't think of education as something boring but compulsory, but as a natural and often exciting part of life and play. It takes a concentrated, long-term effort on the part of the school system to to turn something that kids naturally do into something they see as a chore to be avoided. This accounts for the success of families who choose "unschooling" (unstructured, self-directed learning), which according to the conventional wisdom would produce idiots.
(See title)
Believe me, I combed through the manual. The manual didn't even mention that the battery was in the rear, and the diagram it showed for accessing the battery didn't give enough context to make it clear *where* in the car it was located.
I rented a Volvo station wagon recently while my car was being repaired. One day my wife needed her car jump started. I opened up the hood, only to discover that the battery was nowhere to be found.
After much investigation, I discovered the battery buried under floor of the rear cargo area, firmly locked in place by steel brackets which made the use of jumper cables a losing proposition.
Then again, if you consider things like _foo and __bar__ to be just as ugly as Perl sigils, you won't find ruby to be any more of an abomination than Python!
Every serious C++ programmer should have Stroustrup on the language itself, Josuttis on the STL, and Scott Meyers' "Effective C++" books. Alexandrescu's "Modern C++ Design" and Jusuttis' new book on templates also come highly recommended.
A variable is a box
Wrong. In C/C++ a variable is a box. In Ruby (as in Python and many other dynamic languages) a variable has reference symantics, making the "nickname" metaphore reasonably apt.
Most of the examples given needed rewrites to remain viable. It's easy to look at a package from afar and declare it "perfectly sufficient". Things look different when you have to work with a system daily. In particular, rewrites often address shortcomings in a system's capacity for extension. Just compare the number of third-party extensions available for Netscape 4.* vs. the number now available at mozdev.org for Mozilla and Firebird.
A bigger problem, to my mind, is when a half-dozen projects with the noble intention of replacing an aging kludged-up tool are started, all of which suck in different ways, and none of which learn from each other. And then they lose momentum and stagnate.
Examples? Most programmers agree that "make" is overdue for replacement, but despite many attampts (cmake, jam, cons, ant) no one has managed to come up with one that is compelling enough to catch on. CVS is a crufty mess, but none of it's potential replacements are mature enough or have the kind of widespread tool support to make much of a dent in CVS installations. And there are dozens of written-from-scratch applications which differ primarily on the GUI toolkit they are based on, which would be better apps if they incorporated the best features from all into a joint effort. My idea of the perfect browser combines features of Konqueror, Galeon, Epiphany, Firebird, and Safari.
Even if you're installing off a set of CDs, apt-get works brilliantly. Just tell it what you want to install, it figures out all the necessary dependencies, and asks you for the CDs it needs.
Of course, upgrading off the net is where it really shines - apt-get update; apt-get install; get a cup of coffee, and if it really needs to know anything before upgrading a package it'll ask you. No tedious hunting for RPMs, no downtime.
Variable Assigment in Java
Using Perl Regular Expressions to Process text
Python Operator Overloading
Using Lisp Macros
...is how this is superior to putting a network of power generation satellites in earth orbit. What's the benefit of taking them all the way to the moon?
Because a) Mono is an implementation of the open ECMA-standard components of .NET, done without any knowledge of MS's implementation; and b) Mono is much more likely to help than to hinder MS, at least in the short term.
People look for a traditional western storyline, and they can't handle characters who are both good and bad, and stories that deal with multiple social issues, without offering panaceas at the end.
.There are no in-betweens. Humor is always slapstick. Hatred is complete. Anime contains very little of the subtlety of live-action film, Western OR Eastern., and I've yet to see any indication otherwise.
Ironically, one of the biggest reasons I dislike Anime is it's lack of subtlety. I've watched GitS, Cowboy Bebop, and various others that people have recommended to me as the "cream of the crop", and the aspect that stuck with me more than anything else was just how one-dimensional the characters were. Anger, angst, happiness, and humor are all layed on with a trowel
So I watched it, and yeah, it was better than a lot of the anime I've seen, but it still sucked by any conventional film standards. Animation was horrible (I don't care how good of a painter you are, this is *animation*, the pictures are expected to move fluidly). The dialog was unremarkable at best (yes, I watched the subtitled version). The plot was cliched and confused (not confusing; confused). Animation still can't show fights worth crap; fights are always broken down into a montage of "scenes" - a girl rolls, a kick connects, a gun fires, a wall cracks. Worst of all, like all anime, it was way too wrapped up in it's own visuals. Note to anime filmmakers - I'm impressed when a live action film achieves an iconic visual style, because I recognize how difficult that can be given the realities of lighting, camera limitations, physics, and acting. I'm far less impressed when an animated film achieves a similar style, becaus by definition it's a completely controlled environment where (at least theoreticaly) anything is possible. So when Our Cloaked Hero stalks away, wreathed in steam, through a downpour, in perfectly noir-lit streets, I'm not going to oblige you be saying "wow". It's not like you had to arrange for the damn fog machines.
Also: anime depictitions of "angst" are as laughable as they are ubiquitous. Downcast eyes and hunched shoulders do not a Tormented Hero make. Don't think that a few seconds of canned backstory footage is a substitute for decent acting when trying to drag some character sympathy from the audience.
I get the impression that when fans sit down to watch anime, all the standards which they might otherwise apply go right out the window, because it's ANIME!!!
I don't know why people do this... they have to realize by now that a libel suit (or any suit) against any kind of media or publishing organization is just free publicity for the defendant. The most unfortunate outcome of this is that babbling fools like Atrios get all the attention while better, more insightful bloggers get tarred with the same stigma of unprofessionalism without any of the benefit of publicity.
Which got them from Ruby, which got them from Smalltalk, which got them from god knows where...
I swear, the most annoying thing about Python is not the language, but it's users who are convinced that Python invented all things good. Ironically, Python's generators are unusably broken (they don't work with exceptions) compared to any other language's implementation. No doubt that this admitted failing will be touted as a "feature" by Pythonistas in a few years...
...The GTK team will invent the scroll bar!
You list back the services that I listed, and say they aren't needed - and yet when I read the spec, it described some of those very services. Not to mention the many, many TBDs remaining in that spec. This is why I'm encouraging understanding existing technologies - you don't know you've reinvented the wheel until you're aware of what else is out there. And then a year later you read over the existing technology's specs and realize "wow, these guys were dealing with exactly the same issues we had, only they gave them different names. I wish I'd read this back then!"
And in response to your camera example? I can give a good guess: probably ordinary-priority, asynchronous best-effort semantics. But just because the camera-plugged-in signal just requires asynchronous best-effort semantics doesn't mean some other event won't require different semantics. Sometime later someone may decide that an event needs high-priority delivery. That's the advantage of having a solid messaging infrastructure - you don't have to worry too much about what kind of message passing semantics you'll need down the road, because you know that no matter what they are, you'll be able to specify them and have them taken care of, transparently.
You haven't read much about CORBA, have you? CORBA *is* a message bus, just as much as it's distributed object architecture, and just as much as it's an RPC framework. CORBA facilitates the passing of messages between objects - whether they be actual objects in an OO language, or simply applications; whether they be on the same mechine or different. That's pretty much the definition of a message bus.
Regarding D-BUS: I've seen nothing so far that explains why D-BUS couldn't have been implemented on top of CORBA. There's no reason for a lightweight desktop-integration bus to specify low-level crap like the protocol used, bit-ordering in packets, etc. There's no need for any coupling at all between passing messages between apps and how those messages are passed. Marshalling, dynamic service repositories, naming services, protocol abstraction, QoS issues - it's all been solved already. Why invent yet another TCP publish-and-subscribe protocol when you can build on one that's already there - and in addition, be able to swap shared-memory for TCP if TCP turns out to be too slow, or choose synchronous semantics when you discover that certain messages really need to have gauranteed delivery. Sure, put an extra-simple facade on it if developers don't like working with IDL; but don't reinvent RPC. It's been done too many times already, and half of the stuff that makes CORBA complicated you're going to wind up recreating by the time you're done anyway.