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.
(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.
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.
The Lisp Hackers interviews are also a good resource and quite interesting. The use case I found the most surprising was a developer using CL to prototype chip ideas at Intel before implementing them in C or C++. All the interviews in one book can be found here: https://leanpub.com/lisphackers
If the language can do so competently, why not? I think that would be a great leap forward for programming as it would consolidate efforts developing libraries, documentation, and tools.
There are at least 6 that are explicitly used (there are more in practice but they are mostly transparent of rare and even realizing this will require reading some of the more esoteric documentation): visual line mode, insert mode, ex mode, normal mode, replace mode, visual block mode.
While I respect the research done concerning modal UI and the associated consequences of that in the context of HCI, in practice I do not find that there is ever any confusion about what mode I am in when using Vim after using the editor for many hours, and if one was supremely concerned with avoiding such confusion UI changes per state could be implemented so that the changes were unavoidably obvious (such as by changing the entire background to a different color on a context switch).
The design has some nice benefits elsewhere too with how Vim uses it.
However, I do not find Emacs chording emphasis particularly demented either though, especially once the full array of modifiers are used.
The amount of chords is only really burdensome due to how many domains Emacs covers though IMO, as it makes collisions with short chords much more frequent as the amount of keybinds necessarily expands.
I find the criticisms of Vim usually extremely exaggerated and generally indicative of ignorance concerning its design, some of which you have correctly noted and addressed in your response.
That is not to say that Vim is without its imperfections, but the design is well thought out, coherent, and well documented which makes the learning curve bearable.
I find a mixture of chords and modes in Emacs quite nice using Evil-mode as I can choose to either avoid changing states or not, unlike in Vim.
As I have noted elsewhere though, there is no intrinsic reason why Emacs must use chording over a modal design or some other means of using individual key sequences to invoke commands.
It is merely a matter of redesigning how commands are invoked across Emacs, something which some people are working on and may be interesting in the future.
I do wish there was something up to date that was similar to Practical Vim but for Emacs though as that was a very illuminating and fun text.
Do you know of some documentation that elucidates CEDET more than the documentation on the site does? I have read that documentation a few times and have yet to grok what it really does and how one would use it in practice. It seems extremely powerful but I do not see how an end user takes advantage of it or how an extension writer would use it to compose an IDE for a new language.
Certainly use whatever tools you like, however emacs and Sublime Text cannot be compared directly to one another.
Sublime Text and Vim or some other text editor can be, however text editing is a small component of emacs' utility to its users.
The reason is that emacs is an environment for running emacs lisp applications, and those target pretty much every imaginable niche.
There exists decades of development in that vein for emacs to the extent that for some domains it is an entirely self-contained ecosystem for that space.
The environment homogeneity is distinctly different from any other app which targets a subset of the tasks associated with an overall workflow; if we narrow the domain to just development a possibly valid comparison would be Visual Studio because of how the environment absorbs every interrelated aspect of development from communication to debugging etc. within one overall application.
Light Table may one day be similarly versatile though and a possible emacs alternative.
I am a big Vim fan and promote its design for the most part, however with Lisp paredit and redshank covers text object movement, editing, and refactoring entirely so there is no benefit to using Evil-mode there once paredit and redshank is understood.
One downside though it that it will leave users wanting that in all languages, something which is sadly not available elsewhere as fluidly. I find myself thinking,"this is great, but what would really improve this situation is if it was inherently structured so that I could exploit that" in other contexts.