|
From: Pascal J. B. <pj...@in...> - 2016-05-06 12:26:44
|
<Joe...@t-...> writes: > it in a positive way) view on what's actually important. As a result, > those days, programmers view code in a tinier window than when I > started computing on a 9" screen over 30 years ago. > That's no progress to me! LOL. Indeed. >> Something like the Smalltalk >> code browser: there's no notion of file then. > > It works nicely for Smalltalk, because unlike C or Common Lisp, the > semantics of a method body does not depend on a myriad of definitions > that appears in lexical order before it in the source file. > - No macros nor any variations to the syntax; > - Nothing like operator precedence (except unary operators); > - class and instance variables are one window away. > Hence IMHO, any parallel is not applicable. Reader macros can be treated as a dependency (at the form level). But you're right that a requirement for an IDE nowadays is to include an execution environment where the source being edited is also compiled and loaded. In modern Java IDE and C/C++ (with clang) IDE, they compile the source at least. In lisp we'd have to add the run-time environment, to be able to identify correctly more elements, notably if we don't have a global static analyser. This is what slime does. Granted it's possible to write lisp programs that will fight even this step, but remember that macros and reader macros should be idempotent, so there's already some provision in the standard to help IDE there. Also, with the promotion of ASDF, package and system set up has become more declarative (rather than procedural); modern lisp code is more compatible with an IDE treatment. > In summary, the 'function at a time' might work with programs with > strong locality, e.g. tree structured. But not when you need to > implement a collection of event handlers. Those hide the flow and > ordering of messages and calls -- in Smalltalk too. Indeed, I had such an example in a recent Android program I had to maintain; it sent events to communicate between modules (assumedly on different threads). This kind of dependency could also be taken into account by the IDE and it could provide navigation helpers, either because (as in the case of this Android program) it uses a "standard" communication mechanis, or because the programmer could declare such dependencies to the IDE. Notably in lisp, we have the advantage of using symbols that can be easily identified across modules. Navigating to uses of a given symbol could be all that is needed for the basic feature. -- __Pascal Bourguignon__ http://www.informatimago.com/ “The factory of the future will have only two employees, a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment.” -- Carl Bass CEO Autodesk |