Re: Great SWT Program

On Jan 16, 4:24 am, b...@xxxxxxxxxxx (Bent C Dalager) wrote:
My machine's notepad.exe is 67.5KB. This is about 1/100 the size of
emacs.

And, of course,

quite adequate for plain old text editing. No built-in IDEs and other
nonsense, but then, none necessary. When I want that type of
functionality I'll use a *real* IDE like Eclipse.

[implies that I'm a liar]

No, you're the liar, King of all Liars.

None of the nasty things that you have said or implied about me are at
all true.

The difference lack of bloat can make. Eclipse is larger than
emacs, but eclipse is also a vastly superior IDE with, particularly, a
vastly superior user interface.

Then again, an IDE is pretty much /all/ that Eclipse with JDT is
whileas emacs is so much, much more.

Again irrelevant. When I need an IDE, Eclipse is superior to emacs.
When I need a mailreader, Eclipse isn't, but Thunderbird is. And so
forth.

The competition tends to mostly beat emacs on at least one of small
size or higher quality, and frequently on both.

Small apps that only do /one/ thing[snip]

If I'm doing one thing, then I don't need the app to be able to do
anything else. If I'm doing *more* than one thing, I take advantage of
a nifty feature of modern, graphical operating systems known as
"multitasking", in which it's possible for the user to run more than
one interactive job at a time and easy and convenient to switch among
these foregrounding different ones at different times.

The "bundling" inside of emacs is not an advantage. It merely leads to
bloat. If I need five of some set of ten things that emacs does, I can
get five specialized applications that each to their particular job
better than emacs does that job AND avoid wasting any disk space or
memory on the other five jobs of the ten.

Stop speculating about me. You keep getting things seriously wrong. In
the future you will limit your claims about me to repeating things
that I have explicitly claimed about myself.

[threatens to continue telling lies about me][insults deleted]

I don't respond well to threats.

None of the nasty things that you have said or implied about me are at
all true.

An interactive application taking several megabytes of RAM is par for
the course. But we had been discussing launching something repeatedly
in a loop in a noninteractive script, a circumstance where something
that heavyweight is automatically an extremely suspect choice of tool
for whatever job it's being used there to do.

/If/

No. No ifs. It will always be more efficient to launch a streamlined,
noninteractive app.

Modern hardware and operating system software does not change this
fact. It only reduces the impact of any inefficiencies. If the bloated
interactive app takes 5 seconds to start up on a slow system and 2 on
a fast system, while the streamlined app takes 5 milliseconds on the
slow system and 2 on the fast system, the difference is:

4995ms on the slow system, in favor of using the streamlined app; and
1998ms on the fast system, in favor of using the streamlined app.

Using the bloated app costs nearly five seconds on the slow system.
Using the fast system reduces this to two seconds, but does not
eliminate it.

Running it 1000 times in a loop makes this especially visible. By the
time the bloated app has even gone from splash screen to fully loaded
on the first iteration of the loop, the parallel loop using the
streamlined app has already *run to completion*. All 1000 iterations.

These are based on a fairly generous number for the startup time of
the large, complex interactive application and a fairly realistic
number for the startup time of the streamlined sed-like app.

In practise, many large, complex interactive applications take far
longer to start up, sometimes over 30 seconds on decent hardware. Few
take only one or two seconds. None take mere milliseconds.

Caching repeated invocations doesn't change this very much. My
observation has been that large applications start up in maybe half
the time on repeat invocations, so 5 seconds the first time and then 2
to 3 the second time, or 30 the first time and 15 or so the second.

Still slow, in other words.

[nonsense, including calling emacs "small and nimble", deleted]

Launched repeatedly. Thousands of times. In a loop.

Again, this is effortless on anything styling itself as a modern OS.

You are wrong. Windows XP does all kinds of caching, but starting up
e.g. Firefox is not especially faster for a second invocation than for
a first. It is somewhat faster, but it is not "blindingly fast" as it
would have to be for launching it in a loop to be at all bearable.

AND EVEN IF IT WAS QUITE FAST, loading a lot of interactivity-
supporting baggage that you don't need is simply inefficient any way
you slice it. Even if the loop took just 4 seconds instead of 2
because the interactive app took 4ms instead of 2ms to start up,
that's still 2 wasted seconds. May not sound like much, but it's not
zero either. And if that loop is 10,000 instead of 1000 iterations it
becomes 20 seconds, or a third of a minute. If it is increased to
millions of iterations, we're now looking at saving *hours* by using
the 2ms starer-upper instead of the 4ms one.

[implied insult deleted]

None of the nasty things that you have said or implied about me are at
all true.

For that situation an entirely different order of tool-streamlining is
appropriate than for the situation of interactive use in individually-
long-duration, serial rather than parallel, sessions.

[insult deleted]

None of the nasty things that you have said or implied about me are at
all true.

Also, see above.
.

Relevant Pages

  • Re: Walkthrough Instruction Error
    ... Well what you didn't say was that your code couldn't be run from the IDE. ... Whether or not it is in process or out of process is in itself insignificant, what is important is the overhead of marshalling and synchronization. ... The only advantage out of process has is it doesn't necessarily pull the app down if it crashes. ...
    (microsoft.public.vb.general.discussion)
  • Re: Great SWT Program
    ... The result of typing 'emacs' with no arguments at a shell. ... such as a graphical port or even a completely ... unrelated app, could have been given the file name "emacs" and put on ... That's the bit that makes sense -- using ctrl+Z for undo follows the ...
    (comp.lang.java.programmer)
  • Re: Great SWT Program
    ... superior it would displace other editors given time. ... In the case of vi and emacs vs. normal editors, ... is a recipe for disaster if it's true: there's a state the editor can ... train extensively on every app separately not scale in the modern age, ...
    (comp.lang.java.programmer)
  • Re: IDE for C++: KDevelop vs Emacs vs Other
    ... > via Emacs's simpler interface. ... You're using Emacs as an IDE, ... In fact, Prolog *always* seemed easier and more, well, ...
    (comp.os.linux.development.apps)
  • Re: Really dumb LISP question.
    ... Emacs isn't my perfect ... menus and tree views and panes and panes and panes are the way to make a ... Using a normal IDE lets me have a visual tree of the project's sources at left, and I can find things in it very very quickly, much quicker than by messing around in an emacs dired buffer, or typing in paths directly and possibly making a mistake doing so. ...
    (comp.lang.lisp)