* Raymond Wiker wrote: > Another factor that I forgot this time round is that of > "document compatibility": people and organisations keep buying (new > versions of) MS Word and Excel simply because they have become almost > universal, and because the "input filters" of competing programs are > not good enough to make sense of Microsoft's underdocumented formats.
This is to understate the problem slightly. People keep buying *new* versions of these programs because they are essentially virii. Each new version of Word produces documents that old versions will not deal with correctly. The format is also closed so it is not possible to usefully reverse-engineer it. And people send you stuff in Word which is important to your business. Therefore you *must* keep upgrading, *even if Word is more expensive to own than other products*. Open document formats can not compete against closed ones without essentially regulatory help.
Note that the sense in which Word, say, is a virus, is much stronger and more toxic than the sense that Gabriel claimed Unix was a virus in the worse-is-better paper.
Robert Monfera <monf...@fisec.com> writes: > > b) Installation tools for add-on packages?
> > XEmacs 21.* already comes with those. They work point&click, even > > automagically (e.g. automatic download of AucTex mode when you > > first visit a *.tex file) and network-transparently. What more do > > you need?
> People completely new to Emacs may not know much about TeX, either - let > alone about the way of installation via just going through the *.tex > file. Also, although network-transparency does work on Windows, usually
Well, AFAIK the automagic installation is not particular to AucTeX and *.tex files, but rather a part of the package management system: At least on my old 21.* beta for Windows, when I visit a file for which the system knows that a major mode exists that is not installed, then it offers to download it (IIRC). I just picked tex as an example since that's where I found out about this feature.
I generally don't like this kind of automagic, but others do...
One way or another you can just as well go to Options/Manage Packages/ List&Install and do the selection and installing "manually", point and click style, also from your local hard-drive. This is all described in Options/Manage Packages/Help...
> Emacs and XEmacs freezes or won't exit properly when used. On Linux, > the Windows softmodems won't work (on Windows, they do, making the > machine 10-20% slower). There are indeed some annoyances because of > these silly reasons mostly occurring when someone is transitioning from > Windows.
Yes, all things Windows should be avoided where possible, or strange things will happen (not only w.r.t. Emacs). Sadly it is the casual users that get hit by this, and they can't do anything about it.
> > If you want "better" pre-configured settings, try BeOpen's Infodock
> AFAIK it doesn't work with Windows :-) Maybe the OP should just change > to Linux? (It was news to me anyway that Windows is being used for > embedded development.)
Yes, you are right, I remembered incorrectly: Only the OO-Browser is available in precompiled format for Win32. Sorry for that. OTOH it should probably pose no problem to contract with BeOpen for support on Windows...
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 http://www.opensource.org/halloween1.html]
> * Robert Posey <mu...@raytheon.com> > | You have to use the materials and people available to get the job done.
> this is the core of your attitude, I presume, so I'll let it stand out as > something with which I _profoundly_ disagree, in one particular aspect: > that such materials and people should not be vastly improved in order to > get the job done. I have always believed that whatever was available to > me were no more than _raw_ materials, and that failure to shape the raw > materials into something better fit for the tasks at hand was the best > way possible _not_ to complete those tasks.
I agree with you about what should be done, unfortunately I work for very large company where I am totally unable to affect hiring policies. The concept of spending time improving the tools, even something as minor as EMACS customization is strongly discouraged. In fact, given the near zero overhead budgets, it could even be illegal to use customer money to improve tools. It certainly would have to be approved.
> in particular, a computer does not serve very simple, well-defined needs, > and it consequently always needs work to make it do exactly what I want.
> machines that serve simple, well-defined needs are called "appliances", > which is why I call otherwise interesting computer hardware that runs > anything Microsoftish "Windows appliances".
> | I guess I made a mistake when I mentioned a Microsoft Product, I always > | expect technical issues to be debated without strong emotions.
> good engineers and scientists are the most passionate people I know. > moreover, I'm confident that this is a univeral truth: competent people > _feel_ strongly about quality. that's what makes it possible for them to > keep quality on top of their list at all times -- if they had to _think_ > about quality consciously, it would be like using the conscious mind to > walk or to drive a car or to make love.
Being passionate is not excuse for lack of ability to make rational arguments, when people let their emotions control them, they fail to make arguments that convince people. I certainly agree that good engineer approach their work more as an obsession, that a job. I have never met a good engineer, much less a great one who wasn't constantly striving to do better.
Actually I am considered somewhat of a fanatic myself, however in the specification driven world it is hard to get features included that would actually reduce cost. This is mostly a result of the contract and cost center driven concept my company works under. Since each project is largely financially separate, the project manager never wants to pay for any additional training, or tool development. Thus you get a lot of tools that maybe adequate for the task, but lack the features that would be needed for they to be applicable to other projects. This of course a stupid way to manage a company, but I have been unable to convert anyone who matters. The management loves to talk process but won't spend any money on it. Of course the management is constantly wondering why we don't get more reuse, while refusing to give time and budget to produce reusable products. Since every program is measured in isolation, the fact that it produces code that is hard to maintain, and not reusable is not properly accounted for. The software people do make a lot of effort to do the best they can, but they are too tied to the idea that each software module should do no more than the actual written requirements. Their has been some improvements, but it is still not where it should be.
> however, it has become clear to me in the past few years that lots of > people have no emotions connected to their rational faculties whatsoever > -- they simply feel _nothing_ when it comes to anything factual -- which > is why you hear them claim that emotions are irrational. yeah, _their_ > emotions are irrational. technical people, however, seem to be able to > deal with science and engineering as well as people emotionally, while > the "people people" are restricted to deal with people emotionally and > cannot fathom that anyone can possibly feel anything about a program.
> so _I_ guess you have never met a single competent engineer in your life, > and now that you do, in this newsgroup, you stick to your belief that > those who _feel_ anything about engineering and science must be madmen.
I never mean to say that they shouldn't feel strongly, but that shouldn't blind them to both sides of an issue. To become so emotionally attached to a EDITOR is a problem. If any complain about EMACS drives them to attack the the commentator, they have lost touch with reality. EMACS is a fine program, BUT many people hate EMACS with equal passion. When you allow your emotion to so blind to other points of view, your engineering ability has been severely compromised.
> this also explains why you react so emotionally to Emacs. it was never > made for people like you. its very existence is probably an affront to > your very belief system.
> | EMACS is just a editor, perhaps its the best one, but it is still just an > | editor.
> exactly. you feel _nothing_ about software. probably sort of like I do > towards sports as entertainment.
> | One of the things that does piss people off is extreme over reaction to > | ANY complain about EMACS.
> don't flatter yourself. competent people get pissed off at idiotic > complaints about anything, but there are literally millions of complaints > about Emacs that have been taken very seriously by its developers and > have caused competent people to make changes to Emacs to improve it.
> you, however, couldn't produce a constructive complaint about Emacs if > your life depended on it, so don't pretend to speak for any experience > other than serving up some idiotic complaints that truly annoy people.
Yet again a silly comment, since at least one person involved with the creation of EMACS has agreed with one of my complains. 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. I find it impossible to believe that anyone who has contact with many people using a version of EMACS that has not been customer configured has not heard a lot of complains. Engineers need to realize, that when you are talking about human interfaces that how easy there are to use is an undeniable quality factor. Is it the only one, of course not. However, to assert that none of my arguments are valid, you have to prove that many people don't have problems with EMACS. None of my complains ever stated anything about EMACS being bad, or that people using it were wrong. I also never stated that I liked how things were run at my company. However, the paranoid of the EMACS Zealots has made them see things that aren't there. Like I have said many times, I like XEMACS and plan to learn it better. However, if I have time to contribute anything to the package it will be to make it easier to use.
> I wonder, sometimes, why people who have demonstrated to have zero clue > need to prove it so many times over. they don't grow clues by denying > that clues exist, so why this need to pretend that what they have done > was clueful? "ANY complain[t] about Emacs", for instance, is such an > obviously bogus and self-serving exaggeration that it's _ridiculous_.
Read my posting again, and see if I ever said anything to justify the reactions people made.
> | I for one find that people that can't handle criticism about their badly > | often have the most doubts about their own point of view.
> is that why you can't handle criticism of your reactions here?
> by the way, wishful thinking like "there's something wrong with those who > hate me" is a very useful psychological defense mechanism for those who > are mentally unprepared to accept that other people aren't hateful to > begin with and don't react without reason or observable cause. it is > fairly interesting to watch people respond to criticism as if criticism > of _them_ has to come from psychopaths, while they are eminently able to > criticize just about anything, usually without justifiable reasons.
If any of you hate me for my comments you need serious help. I certainly don't even dislike anyone in this conversation. I personally believe that hating anyone is a serious flaw, but this conversation is so far from justification for hate that baffles me that you would even mention the word.
Deleted more unfounded comments from someone who has serious issues.
> I work for very > large company where I am totally unable to affect hiring policies. The concept > of spending time improving the tools, even something as minor as EMACS > customization > is strongly discouraged. In fact, given the near zero overhead budgets, it > could even be illegal to use customer money to improve tools. It certainly > would have to be approved.
Are you never allowed to go home?
All the elisp I've ever written was done at home. Things I thought would be useful at work then found their way here. I can't imagine anyone busting you for spending a few seconds ^Xi-ing a defun or two to your own ~/.emacs. You could even wait until lunchtime....
(And, yes, I've tried VS. I find it utterly baffling.)
Robert Posey wrote: > If you think the widely recognized relatively steep initial learning curve > of EMACS doesn't exist you have lost all touch with reality.
I always thought 'having a steep learning curve' meant 'learning quickly'. Also, i thought that a 'learning curve' was attributed to the person that learns, not to the thing being learned.
As a non-native english speaker, could someone explain this to me?
> > I work for very > > large company where I am totally unable to affect hiring policies. The concept > > of spending time improving the tools, even something as minor as EMACS > > customization > > is strongly discouraged. In fact, given the near zero overhead budgets, it > > could even be illegal to use customer money to improve tools. It certainly > > would have to be approved.
> Are you never allowed to go home?
> All the elisp I've ever written was done at home. Things > I thought would be useful at work then found their way here. > I can't imagine anyone busting you for spending a few seconds > ^Xi-ing a defun or two to your own ~/.emacs. You could even > wait until lunchtime....
There are problems with this in the overregulated environment of a Defense contractor, but I am doing this to learn and customize EMACS. We also have the IT people to content with, you must understand that we are not allowed install anything on our computers without permission. Actually I do this often, but I am unwilling to do it for a huge group. Of course for the company to get much lift off of the improved tools they have to be standardized at least a functions supported level. I had an amazingly hard time convincing TI(former owner) to get a support person to write a macro for Mentor to automate a 15 minute process, with dozens of entries that didn't change, but in which any mistakes caused the process to abort. They did give me an award for it I will admit. However, if the support person hadn't been a friend, it would have never happened. In this environment, the tractability requirements make it very valuable to have all products produced under costly controls. While most customizations of an editor would be okay, the reluctance to spend much time on this is widespread. Of course no outside vendor tool set is ever going to meet all our requirements without some customization, but there is great reluctance. BTW if anyone has any cost savings numbers to support using customizable tools like EMACS, please post them or send them to me at mu...@raytheon.com. I by no means like the environment I am in, but I graduate in a year or so. Its not worth it to change at the moment.
Muddy
> (And, yes, I've tried VS. I find it utterly baffling.)
I will admit that VC and VJ are more than a little baffling, but Visual Basic, when combined with Visual Basic for application is by far the easiest
> Robert Posey wrote: > > If you think the widely recognized relatively steep initial learning curve > > of EMACS doesn't exist you have lost all touch with reality.
> I always thought 'having a steep learning curve' meant 'learning quickly'. > Also, i thought that a 'learning curve' was attributed to the person that > learns, > not to the thing being learned.
> As a non-native english speaker, could someone explain this to me?
I am not sure which is correct, but I have usually heard it used to describe the process of learning a task. Each new concept or task has a learning curve that is relatively fixed. However, a person learning the new task may start at different places on the curve. Thus the proper usage is to say a person is ON a Learning Curve and a Process has a Learning Curve. They can also progress at different rates up or down the curve. In the formal model, I not sure how exactly the rate of progress is modeled. I am only familiar with concept of people starting at different places on the curve. I think the concept of going down a learning curve refers a person forgetting a process they are not using. I maybe completely off on the formal concept, but that is the usage in this company.
Robert Posey <mu...@raytheon.com> wrote: > I went so far as to explain why the > initial learning curve was a problem. Do I think its wise that companies > don't make the effort to hire good people and train them on powerful tools > like a customized version of EMACS can be.
I'm sure Mr. Naggum's rant is better, but here's mine:
How long does it take to learn that the up-arrow moves you up in the file, the down arrow moves you down, the left- and right-arrows do the obvious things, control-x control-s saves and control-c control-s exits? To learn to make minimal use of an editor is the work of seconds.
Marking text and deleting or copying takes a few more seconds to learn. Yes, to learn too nontrivial things takes a while, but most of what beginners do with editors is trivial. (I would say that most of what advanced users do with editors is trivial, but there are people who do EMACS Lisp as automatically as they breathe.) Most of the rest is specialized to the application and, therefore, is limited.
I used vi for years before learning how to cut-and-paste between files.
> Of course not, but having no desire to > rise above a lead technical position there is nothing I can do about that.
That's another thing about what you say. Technical lead is going to be responsible for specifying positions and qualifying candidates. You have to be if you expect to get the people you need to do the job. That is, if you take the job you say you don't want to rise above, you WILL BE responsible for setting some of these policies. In that case, you should take my advice: Don't hire people who expect that their employer will train them in what they need to know. Usually, new people are dropped in to firestorms and will need to get up to speed on their own because everyone else is busy doing the work they're paid to do. Instead, look for people who are willing to take a pile of specifications and such and figure out what to do on their own, or with a minimum of involvement from the others on the team. I'll pay for your copy of O'Reilly's _Learning GNU Emacs_ and _Using Vi_, but don't expect me to read them to you, or force you to read them yourself if the information contained therein is what you need to do your job properly.
I don't like hiring people who are Microsoft-oriented because they tend to be married to Microsoft Technical Support. If I hire you (and I DO hire people) I'm paying YOU for YOUR knowledge and I'm not getting my money's worth if the sum total of that knowledge is Microsoft's 800-number for technical support. Yes, if you have a well-defined question with a known answer (that somehow didn't make it into the documentation, where the answers to all well-defined questions should be) it may be cheaper in this one instance to have you ask someone at Microsoft for that answer.
However, in the long run, I, as an employer, benefit more if you develop a deep understanding of the systems you work on and the environment that you work in and that requires mucking about with the innards (I like to call it "spelunking" because it is) in a way that may not be immediately productive. I should also point out that many of the questions asked of anybody's technical support are not well-formed and, as a result, the answers those people get are ambiguous, misleading, or just plain wrong.
Now, I personally don't know any systems for which using Microsoft Visual Studio is a requirement and I sure don't work on any for which it is an available tool, so the learning curve difference (and it's not as large as you think--it's just that you've already climbed the one already so it looks smaller than it was at the time) is not significant in my case. YMMV, but to make sense, you've got to pick whether you approach things as an embedded systems programmer or a Windows application developer. The two approaches are different. Right now, and as a senior embedded systems programmer, you look an awful lot like a Windows application developer to me.
* Michael Kappert wrote: > I always thought 'having a steep learning curve' meant 'learning quickly'. > Also, i thought that a 'learning curve' was attributed to the person that > learns, > not to the thing being learned.
The general use, I think, is that there's a certain amount you have to learn before you can begin to use something in a reasonable way (be it a program or a violin). If the amount you have to learn is a lot (say for a violin), then the curve is described as `steep'. It only really makes sense to talk about it that way if you consider the time it takes too -- the learning curve for a violin is not steep in any reasonable sense if you're willing to spend 50 years on learning it.
I think that it's pretty clear that the ability to deal with a really aggressive learning curve in this sense is one of the characteristics which used to distinguish real computer people from the general population. We all have our stories of how the first job we did after college involved being an office and a cheque book and told to make a supercomputer by next week. And part of the trick is to know that you *can* do this frightening thing, certainly in my case after a couple of instances of being given some thing to do which I had no idea even how to start, and discovering that I could just read the manual and fight my way through it, I don't get frightened by learning hard things any more.
But I think now that everyone uses computers, many more people are just not willing to put this effort in, and they want something that they can use competently immediately with no effort. Many people perhaps can't do the fast-learning thing, and sadly others, who could, are being spoiled by the received wisdom that it should not be necessary. Sometimes I wonder why this has not happened for things like musical instruments -- you don't hear people saying `the violin should just not be so difficult to play!'.
Whether it is *possible* to have an immediately-usable program which is not just crippling later on, when all the easy stuff starts getting in the way, I don't know. I suspect it may be, but I haven't seen one. Certainly things like the Windows GUI fail dismally here for me (I haven't used the visual-foobar environments though).
> Robert Posey wrote: > > If you think the widely recognized relatively steep initial learning curve > > of EMACS doesn't exist you have lost all touch with reality.
> I always thought 'having a steep learning curve' meant 'learning quickly'. > Also, i thought that a 'learning curve' was attributed to the person that > learns, not to the thing being learned.
An interesting question actually.
If a learning curve is plotted as skill level on the dependent axis vs. time on the independent axis, then of course people have learning curves, not the thing being learned - unless for a particular task there is strong enough similarity between people that each learner's curve is essentially identical.
I believe most people elide the distinction between an individual's learning curve for a task and the task's average learning curve, especially when comparing tasks: It is easier for almost everyone to get started using VS than to get started using Emacs, so we can simply compare average learning curves.
As far as the steepness of learning curves, this surprised me at first but logically you are of course correct - a steep learning curve would imply a task which is easily or at least quickly learned to a high degree of skill. However, despite all logic, people often speak of steep learning curves for tasks that are difficult and lengthy to acquire. My best guess here is that they confuse the actual interpretation of the graph (which would lead to your conclusion) with the natural implications of being confronted with a steep hill in physical reality - such a hill is difficult and lengthy to climb.
> Robert Posey <mu...@raytheon.com> wrote: > > I went so far as to explain why the > > initial learning curve was a problem. Do I think its wise that companies > > don't make the effort to hire good people and train them on powerful tools > > like a customized version of EMACS can be.
> I'm sure Mr. Naggum's rant is better, but here's mine:
> How long does it take to learn that the up-arrow moves you up in the > file, the down arrow moves you down, the left- and right-arrows do the > obvious things, control-x control-s saves and control-c control-s exits? > To learn to make minimal use of an editor is the work of seconds.
> Marking text and deleting or copying takes a few more seconds to learn. > Yes, to learn too nontrivial things takes a while, but most of what > beginners do with editors is trivial. (I would say that most of what > advanced users do with editors is trivial, but there are people who do > EMACS Lisp as automatically as they breathe.) Most of the rest is > specialized to the application and, therefore, is limited.
People still have problems, why is another question. Part of the problem is many people are used to Windows type method and out of the box Emacs is much different.
> I used vi for years before learning how to cut-and-paste between files.
> > Of course not, but having no desire to > > rise above a lead technical position there is nothing I can do about that.
> That's another thing about what you say. Technical lead is going to be > responsible for specifying positions and qualifying candidates. You have > to be if you expect to get the people you need to do the job.
Not here, I have never had the chance to hire my own people. It happens, but the much more common event is that they are assigned. Even when you have a choice, it tends to be very limited.
> I don't like hiring people who are Microsoft-oriented because they tend > to be married to Microsoft Technical Support. If I hire you (and I DO > hire people) I'm paying YOU for YOUR knowledge and I'm not getting my > money's worth if the sum total of that knowledge is Microsoft's 800-number > for technical support.
I actually don't use anything but Word or Excel for my main job. I haven't found MS to ever be much help at all unless it was a business oriented question.
> However, in the long run, I, as an employer, benefit more if you develop > a deep understanding of the systems you work on and the environment that > you work in and that requires mucking about with the innards (I like to > call it "spelunking" because it is) in a way that may not be immediately > productive. I should also point out that many of the questions asked of > anybody's technical support are not well-formed and, as a result, the > answers those people get are ambiguous, misleading, or just plain wrong.
I agree, except that our systems are Embedded and most of the windows and Linux environmental knowledge is only helpful in comparison. Most of the code I write, or design runs on system without operating systems. If they do have an operating system its VxWorks. So while all knowledge is helpful, when I have a choice I am much more impressed by a software person's hardware or signal processing knowledge than anything to do with general purpose computers. In fact too much experience with large system software design is a big minus, it seems to create a mindset that doesn't understand real time. This maybe why I value the ability to customize Emacs less than some, even though it is potentially more valuable in a real time world due to the large number of custom construct needed. If I can find someone who knows both worlds, that wonderful. However, at my company you can be sure that they will be gone soon.
Muddy
> Now, I personally don't know any systems for which using Microsoft Visual > Studio is a requirement and I sure don't work on any for which it is an > available tool, so the learning curve difference (and it's not as large > as you think--it's just that you've already climbed the one already so > it looks smaller than it was at the time) is not significant in my case. > YMMV, but to make sense, you've got to pick whether you approach things > as an embedded systems programmer or a Windows application developer. > The two approaches are different. Right now, and as a senior embedded > systems programmer, you look an awful lot like a Windows application > developer to me.
That maybe because I don't directly write much of the Embedded code, and write more windows stuff on the side. I design Embedded Test Algorithms, which are even lower level than the rest of the Embedded code. When I become involved with the code, its in the integration stage. I have debugged many, many times more code than I have written. I guess my actual coding experience in 15 years as a hardware designer, then systems engineer is split about 50/50. I not saying that no one uses EMACS here, I just saying that it has failed to be standardized as a choice. My whole point has been apparently wasted on the flamers. I have tried to say over and over again that their debate methodology was flawed. Remember I use EMACS even though I don't use often enough to over come the curve. I never said it wasn't worth the effort, I said the curve was higher than it needed to be. Looking at the latest versions, it is clear the developers agree with me since they have made major efforts to make it easier to use. If software companies that produce good software continue to ignore the out of the box issues that MS has done at least fairly well on, MS will continue to dominate. Calling the people who complain about these issues stupid, lazy or any other insult is not fighting Bill Legions, its surrender.
> As far as the steepness of learning curves, this surprised me at first but > logically you are of course correct - a steep learning curve would imply a > task which is easily or at least quickly learned to a high degree of skill. > However, despite all logic, people often speak of steep learning curves for > tasks that are difficult and lengthy to acquire. My best guess here is that > they confuse the actual interpretation of the graph (which would lead to > your conclusion) with the natural implications of being confronted with a > steep hill in physical reality - such a hill is difficult and lengthy to > climb.
I stand corrected, I believe Harley maybe correct.
Robert Posey wrote: > Visual Studio does have tags in a primitive way of bookmarks. It > works pretty well for the simple jumping around I do.
That doesn't have much to do with Emacs's tags. The point of tags is that a tags table is generated automatically, and then you tell it "go to the definition of such-and-such a function" and it uses the information in the tags table to do it. Visual Studio has a similar feature, but it doesn't use the word "tags", and the information is stored in some opaque and undocumented format. :-)
-- Gareth McCaughan Gareth.McCaug...@pobox.com sig under construction
> > Visual Studio does have tags in a primitive way of bookmarks. It > > works pretty well for the simple jumping around I do.
> That doesn't have much to do with Emacs's tags. The point > of tags is that a tags table is generated automatically, > and then you tell it "go to the definition of such-and-such > a function" and it uses the information in the tags table > to do it. Visual Studio has a similar feature, but it > doesn't use the word "tags", and the information is stored > in some opaque and undocumented format. :-)
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?
In article <38AAF94F.6B44D...@raytheon.com>, Robert Posey <mu...@raytheon.com> writes:
> ... > I don't use often enough to over come the curve. I never said it wasn't worth > the effort, I said the curve was higher than it needed to be. Looking at > the latest versions, it is clear the developers agree with me since they > have made major efforts to make it easier to use. If software companies that > produce good software continue to ignore the out of the box issues that MS > has done at least fairly well on, MS will continue to dominate. Calling the > people who complain about these issues stupid, lazy or any other insult is > not fighting Bill Legions, its surrender.
most people who are seriously into software development don't mind the initial effort to learn a tool that gives them muchg more in the long run
--
Hartmann Schaffer
It is better to fill your days with life than your life with days
>> As far as the steepness of learning curves, this surprised me at first but >> logically you are of course correct - a steep learning curve would imply a >> task which is easily or at least quickly learned to a high degree of skill. >> However, despite all logic, people often speak of steep learning curves for >> tasks that are difficult and lengthy to acquire. My best guess here is that >> they confuse the actual interpretation of the graph (which would lead to >> your conclusion) with the natural implications of being confronted with a >> steep hill in physical reality - such a hill is difficult and lengthy to >> climb.
>I stand corrected, I believe Harley maybe correct.
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.
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...
* Robert Posey <mu...@raytheon.com> | I agree with you about what should be done, unfortunately I work for very | large company where I am totally unable to affect hiring policies.
what part do you agree with? I'm talking about _educating_ people that have already been hired, because whatever was hired was raw material, and education is what shapes them into something the company can use.
| Being passionate is not excuse for lack of ability to make rational | arguments,
you extrapolate from unwillingness to treat a bozo like you as an adult with _ability_ to make rational arguments. this is a _fantastically_ unintelligent extrapolation.
| when people let their emotions control them,
emotions always control people. that's their fundamental function. the question is _which_ emotions. some day you will understand this.
| I never mean to say that they shouldn't feel strongly, but that shouldn't | blind them to both sides of an issue.
what does it _take_ to make you understand that you're the one dreaming up this utter crap about other people? I have told you that I can see _some_ advantages with _everything_. _why_ is this something you have to keep denying all the time? nobody here is blinded, except you, perhaps.
| To become so emotionally attached to a EDITOR is a problem.
you don't understand how emotions work in technically apt people, so now it's a "problem". grrrrreat! tell you wat, bozo, _nobody_ is _attached_ to an editor, emotionally or otherwise. you don't have to be _attached_ to feel something, you see. well, perhaps you do, but you're not the prototype of all people on earth, now, are you?
| If any complain about EMACS drives them to attack the the commentator, | they have lost touch with reality. EMACS is a fine program, BUT many | people hate EMACS with equal passion. When you allow your emotion to so | blind to other points of view, your engineering ability has been | severely compromised.
*sigh*. if only you could listen to yourself instead of expecting that others will listen to you. _nobody_ suffers from what you would dearly hope they suffer from so _you_ could ignore them. and I mean _nobody_. you don't understand jack shit about software and how it affects people with a working intelligence _and_ working emotions. as soon as you realize this, you could be worth talking to. so far, there is no sign that your brain is able to accept anything you don't already agree to.
| If you think the widely | recognized relatively steep initial learning curve of EMACS doesn't exist you | have lost all touch with reality.
are you in really touch with Reality, "Muddy"? whoever _actually_ thinks these things you dream up? I keep telling you: nobody. your enemies are figments of your not very well developed imagination.
| However, to assert that none of my arguments are valid...
nobody has asserted any such thing.
| However, the paranoid of the EMACS Zealots has made them see things that | aren't there.
_really_? how about the many demonstrations that you are arguing against some really stupid stuff that _nobody_ has actually ever said?
| Read my posting again, and see if I ever said anything to justify the | reactions people made.
just _how_ stupid are you, "Muddy"? do you really think nobody did that _before_ they reacted to your incredibly retarded and unfounded opinions?
| > by the way, wishful thinking like "there's something wrong with those who | > hate me" is a very useful psychological defense mechanism for those who | > are mentally unprepared to accept that other people aren't hateful to | > begin with and don't react without reason or observable cause. it is | > fairly interesting to watch people respond to criticism as if criticism | > of _them_ has to come from psychopaths, while they are eminently able to | > criticize just about anything, usually without justifiable reasons. | | If any of you hate me for my comments you need serious help.
I'm _amazed_ by your reading comprehension, "Muddy". I said "[you] are mentally unprepared to accept that other people aren't hateful to begin with", and now your response proves just that.
you're an idiot, Robert Posey. shut your trap and leave us alone.
* Robert Posey <mu...@raytheon.com> | However, at my company you can be sure that they will be gone soon.
so this really boils down to your still working at a place that is deeply dissatisfying to you, but it serves your personal needs better to blame Emacs (and/or Common Lisp) than to get out of your miserable situation.
over the years, we have had a lot of people like you in comp.lang.lisp and the Emacs newsgroups. I guess this is so because people think it's OK to blame these tools, but not OK to blame some other tools (such as Microsoft's cruftware), for the simple reason that being miserable in the majority makes people feel a lot _safer_ than being in a small minority (whether one would be miserable there or not). I do my very best to make people feel unsafe and a lot more miserable in the majority, so it shall appear, if not be, safer and better to be in the minority, instead.
your apologia for remaining at a miserable place are unconvincing at best.
Unrelated to this thread, I just visited comp.object (which I do every once in a while). Among others, there is an easily identifiable loser who can't stop posting pointless articles and opening debates he predictably fills with his useless mantra. Top contributors always prove him wrong, but he does not change or quit despite the constant humiliation. It seems that too much tolerance and laissez-faire freedom of speach does not work out well on that newsgroup (->comp.object.moderated), and I prefer self-defence of a newsgroup over moderation. c.l.l. is the forum of a community, whose members should have the right to try to reject noise and open newcomers' eyes to (possibly shared) values.
It is reasonable to expect Robert to make his comments more carefully and constructively so that he cannot be accused of repeated, aimless hostility towards values many people foreseeably believe in. This is not to say he brought up points unworthy of discussion.
On 16 Feb 2000 09:49:07 +0100, Marco Antoniotti <marc...@parades.rm.cnr.it> wrote:
> Another problem is 'etags'. Last time I checked (I should give it > another try, is my fellow countryman Potorti` listening :) ), > DEFMETHOD and friends did not get the right treatment.
Without ILISP, the standard tag commands seem to work fine. etags is supposed to correctly handle any kind of DEFSOMETHING form. Here is what the Emacs manual says: "In Lisp code, any function defined with DEFUN, any variable defined with DEFVAR or DEFCONST, and in general the first argument of any expression that starts with `(DEF' in column zero, is a tag.". Which specific problems are you referring to?
Thank you to everyone who responded to my question regarding coming to EMACS from a background of the MS Visual tools. I am trying to locate the documentation necessary for me to start using EMACS in a more optimal fashion. I appreciate the tip for Meta-tab and Meta-/ symbol completion - this has already been very helpful. The eldoc module described below also sounds useful, but I have been unable to locate it. Can anyone point me to this module and any standard LISP resources (ie somewhere that I could have searched for this module myself - yahoo was unhelpful).
Thanks again, Jonathan
On 15 Feb 2000 10:45:27 +0000, Philip Lijnzaad <lijnz...@ebi.ac.uk> wrote:
>On 14 Feb 2000 23:45:33 +0000, >"Gareth" == Gareth McCaughan <Gareth.McCaug...@pobox.com> writes: >Gareth> In the same vein, if you type the start of a function >Gareth> invocation
>Gareth> y = f(
>Gareth> then it pops up a "tool-tip" box showing you the function's
>Does this involve a paperclip ?-)
>Gareth> signature, and as you enter arguments it keeps the type of
>For emacs lisp, there is eldoc:
>;;; eldoc.el --- show function arglist or variable docstring in echo area
>which works wonders; I suspect there are more language-specific versions of >such functionality out there (starting with etags and find-tag).
Jonathan <n...@spam.com> writes: > The eldoc module > described below also sounds useful, but I have been unable to locate > it. Can anyone point me to this module and any standard LISP resources > (ie somewhere that I could have searched for this module myself - > yahoo was unhelpful).
It's in the standard distribution. To activate it, put this in your .emacs:
