> The learning curve might be in the form of functionality achieved or percentage > of task finished vs effort expended (with effort on the y axis) to get you the > colloquial result. Time isn't really a factor except insofar as there's > only so much energy you can devote per unit time.
I think I'm getting the picture. I'd replace 'percentage of task finished' by 'percentage of skills acquiered'.
> One of the big questional about learning curves is plateaus and inflection > points: > Some tools require you to work very hard to get anything done at all, but once > you have learned them, you can do all the rest without further expenditure of > energy; others are more linear, and some of the most annoying have a sharp > upward slope right before the end rather than at the beginning...
True. And I suspect Emacs falls in the first category, while VS falls in the last... Also, the learning curve crucially depends on the task at hand. Some tools may have learning curves with infinite slope with respect to some tasks.
On Wed, 16 Feb 2000 15:49:02 -0800, Coby Beck <cb...@mercury.bc.ca> wrote:
>Erik Naggum <e...@naggum.no> wrote in message >news:email@example.com... >> * Robert Posey <mu...@raytheon.com> >> you're an idiot, Robert Posey. shut your trap and leave us alone.
>I, for one, believe Robert Posey has every right to post, and I don't share >at all the above sentiments.
Erik regularly treats people this way. I wonder how many people have really stopped using this group because of his rants...
-- Kenneth P. Turvey <kt-...@SprocketShop.com> -------------------------------------------- The world is full of fools and faint hearts; and yet everyone has courage enough to bear the misfortunes, and wisdom enough to manage the affairs, of his neighbor. -- Benjamin Franklin
Robert Monfera <monf...@fisec.com> writes: > 1. What packages do you use to facilitate Lisp programming? > - ANSI compatibility and "inferiority" > - indentation support (with caveats, e.g., the use of the SERIES pkg) > - lambda list display, documentation display > - integration with references like Hyperspec > - debugging tools (object browser, inspector, debugger) > - interaction with the implementation - tips in addition to vendor doc > ....
oo-browser from beopen.com seems useful for browsing classes (I don't use it because my screen is too small...:-( ).
For the rest, Franz's ELI package with Erik Naggum hyperspec.el + w3. It's great.
* Kenneth P. Turvey | Erik regularly treats people this way. I wonder how many people have | really stopped using this group because of his rants...
well, since you appear to wonder, the answer is simple: my influence on such is much less than the rate of readers who succumb to accidents.
however, it is a well-known fact that idiots on the Net drive out people who have something to contribute, in very large numbers. I'm but a very mild counter-force to that overpowering drive in society to dumb down everything by telling people they have "rights" to post their drooling idiocy everywhere, and in particular that only those who criticize the idiots should have no right to do so.
I do wonder, however, why it is better to be preoccupied with _people_ than to be preoccupied with principles and ideas and actions, and why it is OK to post inane drivel about people in articles with zero technical merit or even contents, but not OK to flame morons _in_ technical areas. I wish sometimes that those who have such a dramatic need to discuss _me_ would at least be "kind" enough to form a fan club or something equally disgusting instead of pretending they are caring about anything more intelligent than the personal nonsense we see in the National Enquirer.
> I wish sometimes that those who have such a dramatic need to discuss _me_ > would at least be "kind" enough to form a fan club or something equally > disgusting instead of pretending they are caring about anything more > intelligent than the personal nonsense we see in the National Enquirer.
Robert Posey wrote: > I was only equating them with the set and goto operations some one > mentioned, Visual Studio's go to definition, and got use of definition > works pretty well. I will agree however that Microsoft is that worst at > using strange formats to store files. My most favorable guess as to > why they do this is that they are trying to Stifle competition, if not > they are utter idiots. Are you sure its undocumented, have you looked at > their website?
Actually, I haven't. Maybe the format of Visual Studio project and workspace files is documented there. It doesn't seem very likely to me, though...
-- Gareth McCaughan Gareth.McCaug...@pobox.com sig under construction
I know that this might be an obvious question, but I can't seem to figure out how to nicely compile and load LISP code that I am working on in a buffer into a LISP process running in another buffer through ELI. I am running Allegro CL with ELI. After starting an Allegro LISP interpreter (fi:common-lisp), I start working on my code in another buffer, but when I make a change to my code I have to type: (load "/filepath/filename") in the interpreter window to reload the changes. Is there a way of doing this automatically? (If I simply need to write an emacs function to do it, I believe I can at this point; however, I would imagine this would be a necessary feature and that it probably already exists.)
Gareth McCaughan <Gareth.McCaug...@pobox.com> writes: > Robert Posey wrote:
> > I was only equating them with the set and goto operations some one > > mentioned, Visual Studio's go to definition, and got use of definition > > works pretty well. I will agree however that Microsoft is that worst at > > using strange formats to store files. My most favorable guess as to > > why they do this is that they are trying to Stifle competition, if not > > they are utter idiots. Are you sure its undocumented, have you looked at > > their website?
> Actually, I haven't. Maybe the format of Visual Studio > project and workspace files is documented there. It > doesn't seem very likely to me, though...
It also doesn't matter with MicroSoft: Generally, even when they "document" their interfaces or file formats, they leave out critical pieces of information, and anyway they feel not bound in any way to maintain any form of useful compatibility with the documented stuff in future releases. Given that, they might as well not document it at all.
Note e.g. that many parts of the Word "document" formats have been "documented" by MS. This nevertheless leaves the task to handle Word files extraordinarily difficult...
Erik Naggum <e...@naggum.no> writes: > it's funny how you guys have to take so vocal parts in what you seem to > dislike that I do, and overdo it in so stupid ways, too -- I have yet to > see one of you being able to interject any technical contents to your > flames about me: they're all about how much you dislike me or what I do;
That's because that is the heart of their problem with you, not technical issues.
Technically, your points are usually right on the money. It's just that you are completely intolerant of technical mistakes, especially when people who you believe are wrong keep arguing with you.
Given that people are fundamentally irrational beings (even techies, with their emotional passions about excellence), it usually takes a fair bit of patience to convince them of the error of their ways.
Many people don't have that patience, which is fine. The right thing for them to do is simply ignore those that have demonstrated their inability to understand arguments.
Being so quick to call people morons and idiots is usually overkill. There are many levels of idiocy, and the pain should be measured out accordingly.
Most people expect a certain amount of civility, even in cases of disagreement. This is why people have problems with your rants.
> this all lends credence to the view that you guys can't help yourself, > but I most certainly can, and can be blamed for not doing so.
This does not follow. Usenet is all about arguing and discussion -- gossip, really. If your ranting style is the current topic, well then so it goes. You blast away at someone, they talk about it. It's *interesting*.
-- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, bl...@infomatch.com The Rhythm has my soul.
> > I am a new LISP programmer - coming from a background of the Visual > > Studios tools - and trying to figure out how to setup a similar > > environment in emacs. I use the Allegro CL package and their > > "fi:common-lisp" editing mode, which does provide some nice features > > (indenting, color-coding code, etc), but I still feel that it lacks a
> ^^^^^^^^^^^^ Automatic indenting is IMHO not a "nice" feature, it is > essential for any serious programming to take place, especially in the > team context: Without AI(<g>), you will either have to spend some > amount of your attention to manual indenting and/or produce unevenly > indented and therefore badly-readable code (remember: you write code > for your fellow programmers, not for the computer).
> > lot of the features of the MS tools. I understand that others who have > > been using emacs have discovered that it is a superior tool; however, > > I am at a loss to make this discovery for myself. Are there any > > on-line documents that document emac's functionality as far as making > > the MS tools "like having your power drill replaced with a hammer"?
> Let's turn this question around: Try to list what functionality from > the Visual Studio environment you find missing, why, and what you are > trying to achieve when you use this functionality. Given this list, > the readers of c.l.l will most likely be only to happy to point out
> a) ways to obtain the functionality, or > b) explain other/better ways of obtaining the indented result, or > c) explain other/better strategies alltogether of achieving the real > objective,
> where appropriate. This approach will probably help you more than > some on-line documents (for this, just read the fine documentation > that comes with your Emacs)...
> To find out various general (and specific) statements of the > functionality of Emacs, just do a search on c.l.l for articles related > to Emacs (I've written a couple myself, and most other regular posters > here have done so, too.) on DejaNews.
> Some basic aspects that sum up the differences between VS and Emacs > for me are: Emacs is not MicroSoft, Windows, Visual, Point&Click, > it's programmable in a real programming language (Emacs Lisp), it > has incorporated the combined experience of over 20 years of Emacs > editing. It's not trying to compete on flashiness, it's competing > on real-life usability. This difference in spirit permeates nearly > all design decissions, so it's just a worlds apart experience.
> Regs, Pierre.
> -- > Pierre Mai <p...@acm.org> PGP and GPG keys at your nearest Keyserver > "One smaller motivation which, in part, stems from altruism is Microsoft- > bashing." [Microsoft memo, see
Centuries ago, Nostradamus foresaw a time when Janos Blazi would say:
>I have been using EMACS for years. Still: there is a piece of functionality >I'd like to have (and it is in VC):
>A list of the (5 to 10) files I worked with most recently. Maybe I just >cannot find it.
It's there, at least in GNU Emacs; I don't recall how I configured it to work.
[Note: redirected to comp.emacs, as this isn't really a Lisp question...] -- "Using Java as a general purpose application development language is like going big game hunting armed with Nerf weapons." -- Author Unknown cbbro...@hex.net - - <http://www.ntlug.org/~cbbrowne/lsf.html>
"Janos Blazi" <jbl...@netsurf.de> writes: > I have been using EMACS for years. Still: there is a piece of functionality > I'd like to have (and it is in VC):
> A list of the (5 to 10) files I worked with most recently. Maybe I just > cannot find it.
There are a number of packages that offer this and/or similar functionality. Personally I use recent-files.el which is part of the XEmacs' edit-utils package. AFAIK this only works with XEmacs, but it might have been ported. There are other packages which do similar things on FSF Emacs as well (desktop?).
Recent files offer's you a persistent list of the n files you recently visited, and it includes options to make some files part of a permanent list.
Robert Posey <mu...@raytheon.com> writes: > If you think the widely > recognized relatively steep initial learning curve of EMACS doesn't exist you > have lost all touch with reality. I have heard 100's of people complain > about it, and since we are talking about a human factors issue this is > absolute proof. So unless you have knowledge of well conducted surveys > that disprove this basic point, you are the one making invalid unsupported > statements.
There's a widely held perception that Emacs is difficult to use because it has 100s of commands that are all obscure control keys and the like - but this is largely a consequence of people not being told the right things about Emacs when they start learning it. (A similar thing happens with Lisp syntax and parens.)
After hearing one of these standard complaints one time from someone who wanted students to have to use a very cut-down Emacs-like editor instead, I decide I'd write down a list of the commands students would need to know in order to edit text and Lisp source code, save to files, etc. I tried to keep it fairly minimal, but not completely. So I included M-/ and undo, for instance. The final list contained something like 12 commands. (Sorry, I don't have it handy these days, but I'm pretty sure the results would be similar if I did it again.)
It's simply a fact that it's not difficult to learn 12 commands. The chief problem is when someone comes to the task with an attitude that Emacs sucks, and it's the wrong kind of editor, and no one should be forced to use it, and so on.
please allow me to tell you that your crime is creating personal expressions of fair complexity and representing them in a writing style that often results in very long sentences, which are difficult both for the average and advanced readers to understand because it takes a lot concentration and memorization and plus logic skills to parse and absorb them in its totality, but even with said skills one is not sufficient to appreciate its significance because its content is also usually abstract and dense, and also almost always odd and original with the attribution of being extremely condescending to the average intellect whom have at least the acuity or instinct to sense your arrogance. as you know that the philosopher, logician, social activist, and Nobel laureate in journalism Bertrand Russell is renowned for his clarity and lucidity in his expositions among other things said in one of his biography that one of his advise or principle in writing clearly (i forgot which) is to make sentences as short as possible. i wonder if you have considered that? (needless to say, i'm sure you have. the previous question is merely a form of expression used for its side effects.) as far as writing goes, last but least i think that some years ago you started to embrace this shitty and not-currently-orthodox all-lower-case "no capitalization in the first letter of a sentence" habit of representation of typed text that added the difficulty of scanning your outpourings. i bumped into your defense of it the other day but did not have time -- as now you know why -- to see what the fuck you are talking about.
you have a lot of other ranking crimes reeking through geek space that are just purely offensive to someone who have never read your stuff before regardless how educated they are, but i do not have time to entail and demonstrate them in this short letter at the moment.
i do wish that some other time when i have plenty of leisure that we could sit down and sigh over some of the peculiarities and singularities of life and universe in general and perhaps i can fix some of your illness in the writing temperament area so that perhaps you could be more effectual in its execution.
Jeff Dalton <j...@todday.aiai.ed.ac.uk> writes: > It's simply a fact that it's not difficult to learn 12 commands. > The chief problem is when someone comes to the task with an attitude > that Emacs sucks, and it's the wrong kind of editor, and no one > should be forced to use it, and so on.
Furthermore all of these commands can be found in the menu when working in a GUI environment nowadays, except the usual text-motion commands, which are on their usual cursor arrow keys.
In article <x23dqjyhpc....@todday.aiai.ed.ac.uk>, Jeff Dalton <j...@todday.aiai.ed.ac.uk> wrote:
>It's simply a fact that it's not difficult to learn 12 commands. >The chief problem is when someone comes to the task with an attitude >that Emacs sucks, and it's the wrong kind of editor, and no one >should be forced to use it, and so on.
The fact remains that Lisp instruction (eg, see Winston & Horn or google for Lisp courseware on the Web) and the Lisp community (eg, see Marco Antoniotti ;-> ) tend to unnecessarily overspecify the text-editor to be used, and invariably this is (Gnu or X) Emacs.
d...@goldshoe.gte.com (Dorai Sitaram) writes: > In article <x23dqjyhpc....@todday.aiai.ed.ac.uk>, > Jeff Dalton <j...@todday.aiai.ed.ac.uk> wrote:
> >It's simply a fact that it's not difficult to learn 12 commands. > >The chief problem is when someone comes to the task with an attitude > >that Emacs sucks, and it's the wrong kind of editor, and no one > >should be forced to use it, and so on.
> The fact remains that Lisp instruction (eg, see > Winston & Horn or google for Lisp courseware on > the Web) and the Lisp community (eg, see Marco > Antoniotti ;-> ) tend to unnecessarily overspecify the > text-editor to be used, and invariably this is (Gnu or > X) Emacs.
I admit I just used 'vi' a few minutes ago :)
-- Marco Antoniotti =========================================== PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26 http://www.parades.rm.cnr.it/~marcoxa