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.

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.

On (US) Amazon the two separate listings are http://www.amazon.com/Microsoft-Xbox-Wireless-Controller-Win... and http://www.amazon.com/Xbox-360-Wireless-Controller-Glossy-Bl...

The PS3 controllers may work differently, but I do not find them as comfortable to use as the 360 controllers personally.

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.

I also use Emacs (and Vim).

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.

I use both Vim and Emacs, and in most contexts Evil-Mode within Emacs that emulates most of Vim's vanilla functions.

Emacs also has modal editing that allows for per mode based keybindings.

Where Vim wins out though on the keybinding game is with its grammar that enables a great deal of mnemonics and the ability to bind keys based on key sequences that do not all have to be prefix keys except for the last key in the sequence, which is the case with Emacs currently.

That opens up a lot more options for generating terse keybinds that are simply not possible with the way Emacs binding system currently works, and coming from Vim I found the system extremely confusing until I read how Emacs keymaps lookups work in greater detail.

That spills over into what is possible with Evil-Mode bindings as well to a degree because of the prefix key requirement with the sequences.

And in Emacs, because of its keymap hierarchy system it is extremely easy to have custom keymaps shadowed and overruled by a higher ranking mode mapping, which again coming from Vim is not obvious what is happening there and how to overcome that behavior.

Even though I now grok how Emacs processes keymaps, I still much prefer Vim's system that allows for any key sequences to be interleaved to make very terse sequences.

The workaround to the situation with long chord sequences that use the Meta and Control keys is that I will bind the frequently used command to the hyper or super keys which are largely not used by modes nowadays and are much less crowded as a result.

There is no inherent reason why Emacs could not move towards a key sequence rather than a chord sequence binding scheme, so resolving the quagmire is at least tractable.

I do use Emacs chords where they are reasonable though rather than changing states just to interact with a REPL or a VCS mode, and in the context of working with Lisp I always use Emacs' chords as paredit obviates the need for any of Vim's grammar, which by default lacks a sexp object or ways of transposing objects well.

Then force unique passwords without requiring the users to remember them, something which is both easier for users and more secure.

Perhaps a more cogent axiom is to reason ethically rather than aim to maintain politeness. That has the added effect of distilling whether the audience is someone that can be reasoned with and large subset of polite etiquette is encapsulated within the constraint of ethical reasoning. If that was followed it would help maintain a decent signal to noise ratio as well.

Org-mode has an exporter for latex and making new skeletons for its export is fairly straight forward. I am liking it a lot and have changed to that over writing tex by hand nowadays.

I feel much the same.

Even on OS X the potential of NeXTstep remains largely unrealized as most apps do not take advantage of the APIs in a way that allows leveraging heterogeneous apps into a conceived workflow.

As a result, a fantastic opportunity to create an environment that is composable in a consistent, homogeneous manner is wasted.

What is worse is that such an environment does not exist anywhere in computing.

The closest thing that exists to realizing an entirely composable or scriptable environment is emacs, and that environment has not incorporated progress in graphics into its ecosystem.

Consequently, the capacity to compose workflows that interact with graphics is not possible, leading to a reliance on console style UIs for the most part.

I think that GNUstep losing steam has less to do with people who care choosing OS X and more to do with Gnome and KDE having a head of steam already by the time GNUstep came about, a characteristic that has lead to many cases of used technology being a consequence of circumstance rather than merit.

I just want an entirely scriptable, composable computing environment anywhere, and it is maddening that such does not exist as everyone would benefit from such.

Currently users either have to remain attached to a UNIX CLI userspace that does have composability or only have that composability in a small subset of applications due to the lack of a uniform interface in which to do so.

What computers are best at is what is least accessible in computing presently, leading to people having to do automatable tasks manually.

It's a tragedy that such is the case after decades of examples of how to achieve that being partially implemented.

Computing has even regressed greatly in this regard in the past decade due to giving our generated data to gatekeepers, when the data was local machines at least then we could apply rules to the data to transform it according to the user's whims, such as filtering out noise in a RSS feed, automating archival of useful information etc.

Now users are entirely reliant on the gatekeepers allowing them to transform information, often which is neither possible or comes accompanied with distracting ads or other attention parasites.

I would gladly switch to an ecosystem that realized the vision NeXTstep et al. had so that managing complexity and transforming data did not entail abandoning solidly engineered GUI applications in the process, sadly this is another case where computing has been unsuccessful in achieving ambitious goals.

Yeah, aside from when /r/haskell gets relatively flooded by people who do not normally frequent the subreddit it is of exceptional quality and an example of a well-run community with one of the highest signal to noise ratios on the Internet.

Haskell having a high barrier to entry likely helps that along a great deal though.

Compare the quality in commentary on nontrivial subjects between /r/programming and /r/haskell for instance.

There will be an enormous amount of disinformation in the former, a state that is incredibly confusing for someone that lacks familiarity in the specific domain as discerning noise will not be easy.

On the other hand, /r/haskell largely in part does not comment as though they were an authority when they are not sufficiently competent to comment on a subject, so the signal remains high.

The subbreddit is fairly active given the niche current user base, and it is big enough that there are a decent amount of domain experts that comment.

The subreddit is also very polite.

I do not recall ever seeing a flame war break out there, which is notable compared to how often any discussion on the topic will break down into inanity, something which even occasionally happens here (such as https://news.ycombinator.com/item?id=6190005 from a couple of days ago).

Dtrace has tomes and many hours expounded upon its usage; sadly it is not also available on Linux.

The Little Schemer and Reasoned Schemer are tremendously fun reads. Little Schemer's writing and presentation style is the standard by which I compare all technical books now.

The books happen to use scheme as their teaching platform but the books are entirely about communicating the concepts that happen to be a part of scheme.

The way the Little Schemer teaches recursion is absolutely brilliant.

If I found myself teaching an intro programming class that would be a part of the curriculum as it is short and communicates the concept in a way that is inescapable while not being dry whatsoever and can be entirely read in a few short settings at most.

By the way, I know from personal experience that at least the majority of the books listed in Jao's scheme bookshelf can be readily worked through in a Common Lisp that supports full TCO, which according to an article from 2011 (http://0branch.com/notes/tco-cl.html) is at least

CMUCL SBCL CCL Allegro LispWorks

I happen to have used SBCL, but I imagine the others would work just as well for these purposes.

Having not worked through them, I cannot confirm whether Programmer avec Scheme or Lisp in Small Pieces can be worked through in CL with slight modifications to the source but I do not see why not.

Google suggests that there does not exist a translation of Programmer avec Scheme anywhere, and no reviews are available on either amazon.fr or amazon.com; that is unfortunate.

So a specific graphics toolkit then? Is it one that is included with Matlab or another toolkit that is necessary to pay in addition for?

Mathematica is also incredibly well documented both online and within the program itself. The program supplied documentation and help is actually useful, something which is unfortunately not common in computing.