mheathr

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.

Programs and procedures yield algorithms.

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.

(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.

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.

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.

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.

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.

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.

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.