One of my favorite Scheme reads was an e-mail discussion on whether it was possible to add OOP to a functional programming language, and then the author goes on to do so in a trivial amount of code. A cursory search doesn't turn up the exchange I had in mind though, or I would link it.
Shannon was an electrical engineer by training and while all of his works have applications in computer science, their origins were solutions to engineering or math problems.
The Emacs documentation is excellent and among the handful of products that have documentation that approaches that of Vim's in any meaningful way, but the PDF does not have interpage links like the one in the OP does. That is not as important as it is with Vim's documentation because of how the documentation is written and because the topics are more self-contained, but it is a significant difference.
The documentation within Emacs has such links though and the topics are slightly more discoverable because the documentation can be searched without knowing its prefixes for different sections ahead of time. I have to know that some commands are organized with i_<topic> to find some insert mode documentation for instance with Vim. They are consistent in their semantics though, but that is one gotcha for newcomers and something I did not realize initially. Without that merely doing :h <topic> won't return what the user is actually wanting the documentation for as topics shadow each other in their naming and are made distinct with the naming prefixes.
This includes both the user's manual, the reference manual, and platform specific information in one file. The user's manual is a subset of the reference manual, and that is 500-600 pages long by itself. The reference manual is enormous, but that is the nature of reference manuals. What is even more shocking is how clear the reference material is despite its breadth and technical subject.
It's an excellent example of how to write quality documentation. What Vim's maintainers get, and what is often neglected in products, is that the documentation is part of the product's value and must be as high of a priority as the rest of the product. If you have had the misfortune of working with Cadence's OrCAD (or pretty much any engineering software) the value of excellent documentation being available is very apparent.
Despite OrCAD's potentially 20k+ USD cost the documentation is very scant and greatly harms its barrier to entry for user's; as a result understanding how it works require tutelage from another expert as though writing has not yet been invented and stories are still only being passed down orally.
Well, provided that you find the 360 controller's d-pad acceptable, the wired xbox 360 controller works directly, however the wireless 360 controller does not work directly, a different wireless controller that specifies working with the PC has to be purchased and uses a specialized receiver as well. However, once that is accomplished it works well. I do find it obnoxious that it both requires an external USB receiver and the typical wireless 360 controller does not work with the PC. Still, that is the one I use, and it works well.
Are you talking about the ones advertises for PC or the ones not sold for PC? When I bought mine (circa 2010) I had to purchase one advertises for PC as the one I had for the 360 before would not work with it otherwise. It seemed nonsensical to me that such was the case.
From the page. "Xbox 360 Controller for Windows works with most Windows XP-based PCs and Xbox 360, delivering a consistent and universal gaming experience."
It comes with a wireless dongle thing you plug in to your PC. Both the controllers that come with your 360 and this controller can be swapped between your PC and your 360 on demand by pushing the resync button on the controller and on the device simultaneously.
I've never heard of a 360 controller that didn't work both with the PC dongle and the 360 itself.
(replying to the child post) The products are not the same if for no other reason than because one comes with the receiver and ordering the other product does not, and that the receiver is even required is not something that is apparent beforehand without research, so the buyer must understand that having the product work as expected will require purchasing either the receiver as a stand alone product or as the bundle which is distinguished by being labeled as "...for Windows."
Naively, I had expected beforehand that the controller to use 802.11(a|b|g|n|ac) or bluetooth and therefore not need another receiver provided that those protocols were already available on the PC, but in the case of the wireless Xbox 360 controller another component is necessary for better or worse.
Luckily, I researched the situation before purchasing another controller with its usage on the PC in mind, so I did not encounter a potential headache until the solution dawned upon me.
Hopefully the next generation PS4 or Xbox One wireless controllers work without taking up a port on the PC with a wireless receiver again.
There actually exists two separate Microsoft Wireless 360 controllers, the one that specifies for Windows will work on both the PC and for the Xbox 360 (after syncing the controller with the appropriate receiver, something which is somewhat tricky if the PC receiver and the console receiver are within the controller's wireless range).
However, the one which does not specify "...for Windows" will not work with the PC, which is the distinction I am attempting to express when recommending it as an option for PC gaming.
The "For windows" version is simply bundled with the wireless receiver. Once you have one of those, you can use any 360 controller.
I regularly use both the controller that came with my 360, and another 360 controller that I brought separately (with no "for windows" marking) in addition the controller that came with the wireless receiver.
I find trackballs (the Logitech M570 in particular) much more comfortable to use over long periods of time personally. The only criticism I have of their design is that having the trackball on the side entails removing a lot of area where additional mouse buttons could have been placed, and I enjoy having extra buttons there to bind to debugging/build/vcs keys.
I have read it from the beginning, and the individuals who maintain the documentation likely have as well.
What format supports interpage linking, can be displayed both electronically and is print quality, and can be read on virtually every platform?
The only print quality formats are postscript or PDF and from that only PDFs can be viewed electronically as well being print ready.
So, there does not exist a solution that is not PDF in this case, especially if other attributes are desired such as the readers not requiring a costly license to use.
I am not incredibly happy with that being the case, but there are open source readers and exporters for (most) PDFs nowadays so it is more or less a non-issue.
If you have not already and can do so, I highly recommend adding Dtrace to your C development toolkit. Dtrace, Valgrind, and GDB make rooting out C runtime issues a lot more pleasant and complement one another well.
Indeed. It's a pity DTrace is not available in Linux (there are two ports, none work for real work). It's also a pity DTrace in OS X is starting to bit rot.
A clean room reimplementation of Dtrace is on my list of ideal computing wants that will probably never happen.
Also on the list is everyone targeting the same hypervisor for device drivers (such as Xen) so that hardware support is excellent for all operating systems and all devices.
I would really, really like a clean room reimplementation of Hexray's IDA pro so that I can use it on OS and architecture, an LLVM front end for Plan 9/Inferno OS, a clean room reimplementation of ZFS, GNUstep to have at least a 1:1 implementation of Cocoa so that no matter the OS and architecture one can target that GUI kit and we have inter-application reuse of functionality through scripts like we have for CLI apps, and a clean room reimplementation of AutoCAD and Candence's Orcad.
And as someone who uses a CAS or equivalent environment a lot, I would really appreciate if an ecosytem such as julia, ipython, or octave would reach and exceed Mathematica and Matlab in ease of use, degree of combination and semantics possibilities, and power as well as efficacy.
I really would like to be able to use Plan 9/Inferno OS all the time but developer tools are not comparable to any BSD or Linux ecosystem and there is not a good GUI toolkit available (I would like GNUstep here is why I want the implementation to succeed).
People who can reverse engineer software and hardware is a very small population compared to the res of the dev population though and they are very likely to end up in a lawsuit if they try.
Lispworks is an excellent commercial IDE as well, however its editor is not as nice (but similar to Emacs) as using Emacs itself and the license is quite expensive compared to other IDEs/toolchains, but it offers greater code introspection than what is available in SLIME.
Personally, I use SLIME + Emacs as I do not do enough CL development to warrant dropping over a thousand USD for a license and I find SLIME good enough for my usage.
