Emacs history, and "Is Emacs difficult to learn?"

Emacs history, and "Is Emacs difficult to learn?"

[Emanuel Berg]

> Remember he [RMS] is talking about secretaries in early days of
> computing learning Emacs and learning programming in the
> process.  I am sure secretaries had no CS degrees and more
> importantly they belonged to a period when computers were not
> common place and were quite the cutting edge.  I just laugh when
> young kids in this day of Google complain that Emacs is
> primitive and is difficult to learn.  I consider it a joke.

Oh! That's not a joke, that's *sad*! Those secretaries back then
read *books* all they childhood, and they wrote diaries, and
letters. In school, if they did not have math and logic, they had
languages - perhaps even Latin - and even if they "only" had
French, German, or whatever, those languages were acquired in a
very systematic way, with classification, parts of speech, all
that formal stuff. (This is a dubious way of learning a language,
but it certainly trims your brain to think in a focused way.)

As for the secretary part later on, they had skills like manual
copying - to write with both hands, the same text, simultaneously,
on two papers! Those gorgeous wenches at age 22 would - with
*skills*, not beauty - scare any monk of medieval Europe back to
their monasteries for good!

I'm not in the least surprised those blondes, redheads, etc. could
use Emacs with a high degree of fluency in but a couple of days.

*But*: The kids of today are another ball game. They are not
benefited by Google. On the contrary. Their brains are destroyed,
or severly confused, by (a)social media, IM, and cell phones, that
has made them all jittery with nervous energy, and with an
attention span of like one meter straight ahead, and with no self-
confidence. Those sad kids-for-life can't learn Emacs, not because
Emacs is difficult, but because they can't learn anything.

> One does not have to be a Technologist to use or be proficient
> with Emacs.

100% correct! I think everybody that types every day should learn
to do that in an advanced editor. I never used vim, but I heard
that is good, too.

You have got this "Technologist" stuff (your word, but OK)
backwards. Yet another history lesson from the "youngster": Once
upon a time, when the paleo-programmer logged onto a mainframe,
there was a shell, and some tools. The paleo-programmer tried them
out, and they were cool. But they were few and didn't do that
much. The tools spread a small net, and the fish caught were
smaller still. Then came Emacs, and by time, it became not a big
net, but an industrial fishing expedition. It gave tremendous
leverage for access and productivity.

I've heard this story told, by a guy - it doesn't matter: I
believed him. And all my experience with Emacs since confirms
this.

So you see, I'm not saying "I'm a 'Technologist', so I use Emacs,
and in such a cool way!" - I'm saying, "Because I want to be a
(better) 'Technologist', I'm using Emacs as a Kon-Tiki, to go from
Peru to Polynesia, and learn everything about it in the process".

If you, on the other hand, write poetry or whatever with Emacs, I
have absolutely no problem with that, and I consider it completely
normal that different persons do different things. I guess I was
just born that generous :)

[ meta - I didn't read any messages after I said I was done
feuding. This because I feared that there were shots at me in
those messages, and then I had to fire right back, and we'd never
get anything done. This was a practical measure, and shouldn't be
interpreted as "I left in total disgust". If you *really* think I
should read something between then and now, mail me, and I'll do
it. ]

> That you have to be super-human to learn and use Emacs is more
> of a myth and in reality has no truth to it.

Just to hammer the nail, I agree, and I am very surprised you
think I thought so.

> We can learn a lot from these secretaries and each other.

... and that's the whole point discussing a common interest.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Emacs history, and "Is Emacs difficult to learn?"

[Jambunathan K]

Emanuel Berg <embe8573@student.uu.se> writes:

>> Remember he [RMS] is talking about secretaries in early days of
>> computing learning Emacs and learning programming in the
>> process.  I am sure secretaries had no CS degrees and more
>> importantly they belonged to a period when computers were not
>> common place and were quite the cutting edge.  I just laugh when
>> young kids in this day of Google complain that Emacs is
>> primitive and is difficult to learn.  I consider it a joke.

Welcome back!  This time let's talk about Emacs!

We are discussing - http://www.gnu.org/gnu/rms-lisp.html

What fascinates me in that article is this,

    ,----
    | They used a manual someone had written which showed how to extend
    | Emacs, but didn't say it was a programming. So the secretaries,
    |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    | who believed they couldn't do programming, weren't scared
    |     ^^^^^^^^
    |     ^^^^^^^^
    | off. They read the manual, discovered they could do useful things
    | and they learned to program.
    `----

The magic phrases are - "didn't say it was a programming" and
"believed".

Belief or No-Belief, learning, stopping short of saying the whole truth
- all seem interesting to me.  Do they help or hinder learning?

Specifically, if someone is interested in introducing Emacs to a
non-Emacs user, what strategies should they adopt to maximize their
chances of having a new convert.  I welcome any insights from both the
victors and the vanquished on the "Convert to or introduce Emacs
battle".

Personally, my first love with Emacs was when someone showed M-q to me
and the most uglily indented text aligned nicely between the margins.

> If you, on the other hand, write poetry or whatever with Emacs,

Not a poet here.

Re: Emacs history, and "Is Emacs difficult to learn?"

[Rustom Mody]

On Monday, July 29, 2013 8:16:05 PM UTC+5:30, Jambunathan K wrote:
> Personally, my first love with Emacs was when someone showed M-q to me
> and the most uglily indented text aligned nicely between the margins.

I started using emacs in the early 90s because I wanted something better than an interactive shell for teaching interaction with a (pre)haskell interpreter.  Dunno if comint mode existed then -- I at least did not know about it.
Wrote my own mode which used to crash not just emacs but even linux in interesting ways! Couple of years later, found scheme-mode written on top of comint and search-n-replaced it for my purposes.

> Specifically, if someone is interested in introducing Emacs to a
> non-Emacs user, what strategies should they adopt to maximize their
> chances of having a new convert.  I welcome any insights from both the
> victors and the vanquished on the "Convert to or introduce Emacs
> battle".

Find myself increasingly on the vanquished side nowadays.
This has many sides: For one I can corroborate Emanuel's observation that today's kids are more 'spoilt' -- as google gives more and more, attention-span gets less and less.


I am frequently asked to use something more 'modern/reasonable' etc than emacs (eclipse/sublime-text etc).

Some of the reasons are simply noob-acclimatization issues like tutorial uses C-f/b/n/p instead of cursor keys, non-use of cua keystrokes etc.

However some things are from the pov of an old user more crucial:
 - poor support for refactoring
 - poor support for mainstream languages like java

which make it quite hard to sell emacs in an eclipse-d world.

Re: Emacs history, and "Is Emacs difficult to learn?"

[Phillip Lord]

> Some of the reasons are simply noob-acclimatization issues like tutorial uses
> C-f/b/n/p instead of cursor keys, non-use of cua keystrokes etc.
>
> However some things are from the pov of an old user more crucial:
>  - poor support for refactoring
>  - poor support for mainstream languages like java

It is a shame that Java support is in the state it is. I used Emacs for
many years for coding Java, and wrote of the smaller parts of JDEE. But,
it's functionality is quite a bit lacking now compared to things like
eclipse. 

Having said that, I haven't written any Java seriously for quite a few
years now. The only reason I use it these days is when I am teaching it,
and then I still use Emacs; the amount of effort it takes to set up a
new project in Eclipse is a huge problem when you want to write three
classes to demonstrate inheritance or whatever and then move on. And,
then I need to build the classes into a website, all of which would have
to be done outside eclipse.

Perhaps this is where Emacs is at it's best. If I were writing in one
language, on one project for several months at a time, I'd use eclipse.
But I use many languages, with custom tools, for specific purposes. At
the bleeding, chaotic edge, it's Emacs every time.

Phil

Re: Emacs history, and "Is Emacs difficult to learn?"

[Barry Margolin]

In article <mailman.2028.1375109070.12400.help-gnu-emacs@gnu.org>,
 Jambunathan K <kjambunathan@gmail.com> wrote:

> Emanuel Berg <embe8573@student.uu.se> writes:
> 
> >> Remember he [RMS] is talking about secretaries in early days of
> >> computing learning Emacs and learning programming in the
> >> process.  I am sure secretaries had no CS degrees and more
> >> importantly they belonged to a period when computers were not
> >> common place and were quite the cutting edge.  I just laugh when
> >> young kids in this day of Google complain that Emacs is
> >> primitive and is difficult to learn.  I consider it a joke.
> 
> Welcome back!  This time let's talk about Emacs!
> 
> We are discussing - http://www.gnu.org/gnu/rms-lisp.html
> 
> What fascinates me in that article is this,
> 
>     ,----
>     | They used a manual someone had written which showed how to extend
>     | Emacs, but didn't say it was a programming. So the secretaries,
>     |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>     |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>     | who believed they couldn't do programming, weren't scared
>     |     ^^^^^^^^
>     |     ^^^^^^^^
>     | off. They read the manual, discovered they could do useful things
>     | and they learned to program.
>     `----
> 
> The magic phrases are - "didn't say it was a programming" and
> "believed".
> 
> Belief or No-Belief, learning, stopping short of saying the whole truth
> - all seem interesting to me.  Do they help or hinder learning?

Wasn't a similar phenomenon responsible for the popularity of PC 
spreadsheets? Businessmen were already familiar with doing spreadsheets 
on paper, and adding up rows and columns of data by hand. When 
spreadsheet software came out, no one told them they were "programming" 
when they put "SUM(A)" in a field and it totalled all the values in 
column A, so they didn't know they couldn't do it because they weren't 
programmers.

However, this type of programming can usually only get you so far. 
Creating an init file that sets personal options (there was no 
"Customize" facility in those days), or puts together a sequence of a 
half dozen commands (like a keyboard macro -- I don't think the early 
versions had a way to save these) are pretty easy for anyone. When you 
start adding complicated conditionals, loops, etc., non-programmers get 
confused.

You can see this kind of thing on a daily basis these days at Stack 
Overflow, where there are questions from hundreds of non-programmers 
trying to create web sites and database applications, when all they know 
about programming they learned by copying examples from web sites. You 
get SQL questions from people who don't even know what a JOIN is.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: Emacs history, and "Is Emacs difficult to learn?"

[Luca Ferrari]

On Mon, Jul 29, 2013 at 5:37 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> On Monday, July 29, 2013 8:16:05 PM UTC+5:30, Jambunathan K wrote:
>> Personally, my first love with Emacs was when someone showed M-q to me
>> and the most uglily indented text aligned nicely between the margins.
>
> I started using emacs in the early 90s because I wanted something better than an interactive shell for teaching interaction with a (pre)haskell interpreter.  Dunno if comint mode existed then -- I at least did not know about it.
> Wrote my own mode which used to crash not just emacs but even linux in interesting ways! Couple of years later, found scheme-mode written on top of comint and search-n-replaced it for my purposes.
>

I started using Emacs because (i) I hated vi with a passion, since it
was the _only_ editor university was teaching us and I was wondering
why and (ii) because I found it incredibly faster than more other
editors. For instance, while doing my master degree thesis, a latex
document that resulted in almost 300 pages, emacs was able to le tme
search forward and backward incrementally, while other editors, even
those latex-branded, were sinking parsing such a large document.
Therefore I decided Emacs had to be my editor of choice, and then I
used to program almost everything I had in almost every language
ranging from java, perl, php, etc.

I teach some web stuff in high school, and I'd love students use emacs
but I have to face that students are not living a point and click
generation and they do not understand the real power of using
keystrokes. Moreover, as already said, they are brain damaged and this
does not help. To learn Emacs (as to learn anything else) you need
attitude.




> I am frequently asked to use something more 'modern/reasonable' etc than emacs (eclipse/sublime-text etc).
>

This is something happens to me too: my colleagues often look at me
like a nerd because I don't use something more eye-candy like
ultraedit/eclipse/netbeans/whatever. But I feel comfortable with my
keys and the speed of emacs.

There are however a few places where Emacs should get a real improvement:
- IDE-like support and code autocompletion (cedet and autocomplete are
very helpful, but there is still a gap with some major IDEs)
- prebuilt and preconfigured packages: often configuring emacs is a quite tricky
- inclusion in base systems: the first thing I often do when
installing a new system is to add emacs since it is rarely used as a
default editor.

Luca

Re: Emacs history, and "Is Emacs difficult to learn?"

[Chris Van Dusen]

On Jul 29, 2013, at 9:46 AM, Jambunathan K <kjambunathan@gmail.com> wrote:
> 
> We are discussing - http://www.gnu.org/gnu/rms-lisp.html
> 
> What fascinates me in that article is this,
> 
>    ,----
>    | They used a manual someone had written which showed how to extend
>    | Emacs, but didn't say it was a programming. So the secretaries,
>    |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    | who believed they couldn't do programming, weren't scared
>    |     ^^^^^^^^
>    |     ^^^^^^^^
>    | off. They read the manual, discovered they could do useful things
>    | and they learned to program.
>    `----

Although he mentions Bernie Greenberg, I don't see a link to his article.

Here is that article.  The relevant section is IX.

http://www.multicians.org/mepap.html

Chris.

Re: Emacs history, and "Is Emacs difficult to learn?"

[Emanuel Berg]

Jambunathan K <kjambunathan@gmail.com> writes:

> | They used a manual someone had written which showed how to
> | extend Emacs, but didn't say it was a programming. So the
> | secretaries, who believed they couldn't do programming,
> | weren't scared off. They read the manual, discovered they
> | could do useful things and they learned to program.
>
> The magic phrases are - "didn't say it was a programming" and
> "believed".

I believe in phrases, but not in magic.

What: "I told a girl she should do programming, and she said 'Oh,
little ol' me, that's boys' stuff', and run away. Next time, I was
a bit more clever, and more intelligent with respect to the 'girl
psyche', so I didn't mention programming, and it worked like a
charm."

I don't believe in that. I believe in capacity, and those girls
had it. From there, it is the easiest thing in the world to bring
forward that capacity, and you don't have to resort to any Slim
Shady street smartness to do it.

The honor belongs to those girls, and not to some dude 'fooling'
them into doing what he wanted them to. (Of course, *he* didn't
need any fooling. He got it right from day one!)

> Not a poet here.

That was an example.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Emacs history, and "Is Emacs difficult to learn?"

[Emanuel Berg]

Rustom Mody <rustompmody@gmail.com> writes:

> I started using Emacs in the early 90s because I wanted
> something better than an interactive shell for teaching
> interaction with a (pre)haskell interpreter.  Dunno if comint
> mode existed then -- I at least did not know about it.  Wrote my
> own mode which used to crash not just Emacs but even Linux in
> interesting ways! Couple of years later, found scheme-mode
> written on top of comint and search-n-replaced it for my
> purposes.

A couple of years back a made a very small project in Haskell
[1]. I used Emacs, of course, and cannot recall any
problems. Wasn't there even a Haskell mode to deal with it?

Haskell is a bit too advanced and ambitious for me. Programming
isn't pure and it will never be. Recursion in every conceivable
direction, set functions, and a phobia for "side-effects", and all
other functional programming hangups, they just get me thinking to
much *how* I do things, instead of the desired balance of how,
what, why, when, etc.

> I am frequently asked to use something more 'modern/reasonable'
> etc than Emacs (Eclipse/sublime-text etc).

I did Eclipse once on a project with some other people. We were
all on the same level so I couldn't force them to use Emacs, but
regardless of any lack of support for Java in Emacs (which by the
way I never noticed, but thankfully my Java experience is limited)
-- regardless of that I'd prefer Emacs without the slightest
doubt, because Eclipse really got my blood boiling with
frustration. I remember my and my Spanish friend wading through
the jungle of menus for a good 15 minutes just to get to the place
to increase the font *size*. But even though he was from Spain, I
was the guy who lost my head, because I was so used to everything
just working in Emacs.

> Some of the reasons are simply noob-acclimatization issues like
> tutorial uses C-f/b/n/p instead of cursor keys, non-use of cua
> keystrokes etc.

While I think the Emacs kill ring, and the shell kill ring for
that matter, is a lot better than the Windows/Mac OS cua
"clipboard" (or whatever they call it), the cursor keys (as you
mention) are the huge advantage because then you don't have to
reach all the time, and then reset, to make an edit. Instead, you
just type and type.

But to call it "keys" - the cursor movement keys in Windows and
Mac OS that correspond to Emacs keystrokes are but a subset of all
such Emacs functionality. Besides, there is always Elisp if you
need more.

I agree that this is the obstacle newcomers have to overcome, but
this is only a matter of patience. Or perhaps attitude: if they
start Emacs, and find their cua stuff doesn't work, and
immediately start hammering the Escape key in panic, and then
never use Emacs again, of course Emacs "sucks". If they don't do
that, they shouldn't have any problems.

Muscle memory is apt at learning. People that are right handed,
and get their right hand cut off in a machine, will be just as
good ping pong players with their left hand, in almost no time,
because not having a right hand will force them to do *everything*
(including opening doors) with their left. There is no better
sparring partner than necessity.

By the way, what you mention is what made me "fall" for Emacs, the
shortcuts, in combination with the US keyboard layout that I use
for typing. Some guys told me I should change, and I told them,
"Why? I don't care the US people have different shortcuts for the
programming special chars, I know the ones *I* have." But then I
changed, and I instantly (in one evening) realized that it is not
about "other" shortcuts, it is about *better* shortcuts. Emacs and
a new keyboard layout made for an all new, incredible typing and
programming experience.

> However some things are from the POV of an old user more
> crucial: poor support for refactoring - poor support for
> mainstream languages like Java

"Refactoring"?

As for Java, I don't think it is a coincidence that Emacs offers
poor support for that... (Again, I never experienced that, but I
believe you.)

> which make it quite hard to sell Emacs in an Eclipse-d world

I gave up changing other people a long time ago. First, I never
succeeded even once, and believe me, I tried. Second, if I'd do
that all my efforts would amount to that, and I'd never do
anything productive at all (and be frustrated by failure on top of
that).

[1] http://user.it.uu.se/~embe8573/candelim/

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Emacs history, and "Is Emacs difficult to learn?"

[Emanuel Berg]

phillip.lord@newcastle.ac.uk (Phillip Lord) writes:

> Perhaps this is where Emacs is at it's best. If I were writing
> in one language, on one project for several months at a time,
> I'd use eclipse.  But I use many languages, with custom tools,
> for specific purposes. At the bleeding, chaotic edge, it's Emacs
> every time.

Well, that is one of the advantages with Emacs, that all you
typing goes there, be it mail, writing, programming, whatever. To
have one editor for each PL is a bad idea, generally speaking, but
also in almost all specific cases that I can think of. It doesn't
matter how good those editors get at one thing, you will always
find yourself lacking one feature from editor A in B, or strike a
"B's shortcut" in A, and wonder why it didn't work. The only thing
that could make it better would be if you never, ever do anything
but one PL. But that programmer I've yet to meet. And I wouldn't
want to be him, either.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Emacs history, and "Is Emacs difficult to learn?"

[Emanuel Berg]

Luca Ferrari <fluca1978@infinito.it> writes:

> I started using Emacs because (i) I hated vi with a passion,
> since it was the _only_ editor university was teaching us and I
> was wondering why and (ii) because I found it incredibly faster
> than more other editors. For instance, while doing my master
> degree thesis, a latex document that resulted in almost 300
> pages ...

Yes. Some people say Emacs cannot be used instead of the
Open/LibreOffice word processors, because you want documents that
are pleasant to the human eye, not just stuff that are to be
parsed by computers. This is not true: if you use LaTeX in Emacs,
not only do you have all the pros of the *editor*, you have so
much more precision (math formulas, etc.) and "beauty" (ToC,
references, etc.) as for the final result.

The same can be said of HTML/CSS (in Emacs, as compared to
"WYSIWYG"-editors), although I wouldn't put HTML/CSS on the same
level as LaTeX anytime soon.

> I teach some web stuff in high school, and I'd love students use
> emacs but I have to face that students are not living a point
> and click generation and they do not understand the real power
> of using keystrokes.

Yes. Did you read the very long GEH discussion on the mouse
vs. the keyboard? It all started in a thread on how to reduce the
Emacs boot time.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Emacs history, and "Is Emacs difficult to learn?"

[Emanuel Berg]

Barry Margolin <barmar@alum.mit.edu> writes:

> When spreadsheet software came out, no one told them they were
> "programming" when they put "SUM(A)" in a field and it totalled
> all the values in column A, so they didn't know they couldn't do
> it because they weren't programmers.

But that's not programming, either. That's bookkeeping. In the
world of science and technology, perhaps it is set theory,
relational algebra, or simply stats. It is not programming.

> When you start adding complicated conditionals, loops, etc.,
> non-programmers get confused.

And that is because branching, iteration, looping, and so on *are*
programming. For example, I don't consider HTML programming, but I
*do* consider SQL programming (domain-specific and data-oriented,
but nonetheless) because in SQL, but not in HTML, those stuff that
you mention are there.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Emacs history, and "Is Emacs difficult to learn?"

[Rustom Mody]

On Tuesday, July 30, 2013 5:30:35 PM UTC+5:30, Emanuel Berg wrote:
> Barry Margolin writes:
> 
> > When spreadsheet software came out, no one told them they were
> > "programming" when they put "SUM(A)" in a field and it totalled
> > all the values in column A, so they didn't know they couldn't do
> > it because they weren't programmers.
> 
> 
> But that's not programming, either. That's bookkeeping. In the
> world of science and technology, perhaps it is set theory,
> relational algebra, or simply stats. It is not programming.

Heres Simon Peyton Jones on why spreadsheets are just FP in disguise
http://web.cecs.pdx.edu/~black/S3S/PeytonJones.ppt

In the same way, R is stats+programming
sql is relational-algebra+programming
[And oldtimers will remember SetL]

Re: Emacs history, and "Is Emacs difficult to learn?"

[Emanuel Berg]

Rustom Mody <rustompmody@gmail.com> writes:

> Heres Simon Peyton Jones on why spreadsheets are just FP in disguise
> http://web.cecs.pdx.edu/~black/S3S/PeytonJones.ppt

OK, I take that back, at least until I've read that article. It
depends on how you use spreadsheets. Summing a column is not
programming, but yes, there is a second page, or sheet, to
spreadsheets.

> In the same way, R is stats+programming

What is R?

> sql is relational-algebra+programming

Yes. And as long as you don't do that fancy cursor iteration and
stuff, perhaps it is simply a computer implementation of
relational algebra, with some glue to make it stick together with
everything else, that is the computer (like the indexes, and
ordered sets - of course you don't need that in an abstract, math
model, that shouldn't be searched or otherwise optimized)?

> [And oldtimers will remember SetL]

Never heard of. What is that, set theory + programming, as in the
"set language"?

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Emacs history, and "Is Emacs difficult to learn?"

[Stefan Monnier]

> depends on how you use spreadsheets. Summing a column is not
> programming, but yes, there is a second page, or sheet, to
> spreadsheets.

Same as "writing (setq smie-indent-basic 8)" is not programming, indeed.


        Stefan

Re: Emacs history, and "Is Emacs difficult to learn?"

[Emanuel Berg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> depends on how you use spreadsheets. Summing a column is not
>> programming, but yes, there is a second page, or sheet, to
>> spreadsheets.
>
> Same as "writing (setq smie-indent-basic 8)" is not programming,
> indeed.

No, but that is not the Elisp of Emacs I speak of, when I speak of
the Elisp of Emacs. That's just an interface, albeit a good one,
to specify settings.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Emacs history, and "Is Emacs difficult to learn?"

[Aurélien DESBRIÈRES]

Luca Ferrari <fluca1978@infinito.it> writes:

> On Mon, Jul 29, 2013 at 5:37 PM, Rustom Mody <rustompmody@gmail.com> wrote:
>> On Monday, July 29, 2013 8:16:05 PM UTC+5:30, Jambunathan K wrote:
>>> Personally, my first love with Emacs was when someone showed M-q to me
>>> and the most uglily indented text aligned nicely between the margins.
>>
>> I started using emacs in the early 90s because I wanted something
>> better than an interactive shell for teaching interaction with a
>> (pre)haskell interpreter.  Dunno if comint mode existed then -- I at
>> least did not know about it.
>> Wrote my own mode which used to crash not just emacs but even linux
>> in interesting ways! Couple of years later, found scheme-mode
>> written on top of comint and search-n-replaced it for my purposes.
>>
>
> I started using Emacs because (i) I hated vi with a passion, since it
> was the _only_ editor university was teaching us and I was wondering
> why and (ii) because I found it incredibly faster than more other
> editors. For instance, while doing my master degree thesis, a latex
> document that resulted in almost 300 pages, emacs was able to le tme
> search forward and backward incrementally, while other editors, even
> those latex-branded, were sinking parsing such a large document.
> Therefore I decided Emacs had to be my editor of choice, and then I
> used to program almost everything I had in almost every language
> ranging from java, perl, php, etc.
>
> I teach some web stuff in high school, and I'd love students use emacs
> but I have to face that students are not living a point and click
> generation and they do not understand the real power of using
> keystrokes. Moreover, as already said, they are brain damaged and this
> does not help. To learn Emacs (as to learn anything else) you need
> attitude.
>
>
>
>
>> I am frequently asked to use something more 'modern/reasonable' etc than emacs (eclipse/sublime-text etc).
>>
>
> This is something happens to me too: my colleagues often look at me
> like a nerd because I don't use something more eye-candy like
> ultraedit/eclipse/netbeans/whatever. But I feel comfortable with my
> keys and the speed of emacs.
>
> There are however a few places where Emacs should get a real improvement:
> - IDE-like support and code autocompletion (cedet and autocomplete are
> very helpful, but there is still a gap with some major IDEs)
> - prebuilt and preconfigured packages: often configuring emacs is a quite tricky
> - inclusion in base systems: the first thing I often do when
> installing a new system is to add emacs since it is rarely used as a
> default editor.
>
> Luca

GNU Emacs is an Extensible Editor.

Extensible (word) have it's importance in the way that the limit with
GNU Emacs is you.

GNU Emacs is not difficult to learn and by the way it will teach you
Computer Sciences.

C-h i have been be and is at this time my best teacher!

Thanks Richard and all maintainer for that great tool.

P.S. : try GNU Emacs out of X you will discover and OS in the OS ;-)

-- 
Aurélien DESBRIÈRES
Run free! Run GNU.ORG

Re: Emacs history, and "Is Emacs difficult to learn?"

[Aurélien DESBRIÈRES]

Luca Ferrari <fluca1978@infinito.it> writes:

> On Mon, Jul 29, 2013 at 5:37 PM, Rustom Mody <rustompmody@gmail.com> wrote:
>> On Monday, July 29, 2013 8:16:05 PM UTC+5:30, Jambunathan K wrote:
>>> Personally, my first love with Emacs was when someone showed M-q to me
>>> and the most uglily indented text aligned nicely between the margins.
>>
>> I started using emacs in the early 90s because I wanted something
>> better than an interactive shell for teaching interaction with a
>> (pre)haskell interpreter.  Dunno if comint mode existed then -- I at
>> least did not know about it.
>> Wrote my own mode which used to crash not just emacs but even linux
>> in interesting ways! Couple of years later, found scheme-mode
>> written on top of comint and search-n-replaced it for my purposes.
>>
>
> I started using Emacs because (i) I hated vi with a passion, since it
> was the _only_ editor university was teaching us and I was wondering
> why and (ii) because I found it incredibly faster than more other
> editors. For instance, while doing my master degree thesis, a latex
> document that resulted in almost 300 pages, emacs was able to le tme
> search forward and backward incrementally, while other editors, even
> those latex-branded, were sinking parsing such a large document.
> Therefore I decided Emacs had to be my editor of choice, and then I
> used to program almost everything I had in almost every language
> ranging from java, perl, php, etc.
>
> I teach some web stuff in high school, and I'd love students use emacs
> but I have to face that students are not living a point and click
> generation and they do not understand the real power of using
> keystrokes. Moreover, as already said, they are brain damaged and this
> does not help. To learn Emacs (as to learn anything else) you need
> attitude.
>
>
>
>
>> I am frequently asked to use something more 'modern/reasonable' etc than emacs (eclipse/sublime-text etc).
>>
>
> This is something happens to me too: my colleagues often look at me
> like a nerd because I don't use something more eye-candy like
> ultraedit/eclipse/netbeans/whatever. But I feel comfortable with my
> keys and the speed of emacs.
>
> There are however a few places where Emacs should get a real improvement:
> - IDE-like support and code autocompletion (cedet and autocomplete are
> very helpful, but there is still a gap with some major IDEs)
> - prebuilt and preconfigured packages: often configuring emacs is a quite tricky
> - inclusion in base systems: the first thing I often do when
> installing a new system is to add emacs since it is rarely used as a
> default editor.
>
> Luca
>
>


GNU Emacs is an Extensible Editor.

Extensible (word) have it's importance in the way that the limit with
GNU Emacs is you.

GNU Emacs is not difficult to learn and by the way it will teach you
Computer Sciences.

C-h i have been be and is at this time my best teacher!

Thanks Richard and all maintainer for that great tool.

P.S. : try GNU Emacs out of X you will discover and OS in the OS ;-)


-- 
Aurélien DESBRIÈRES
Run free! Run GNU.ORG

Re: Emacs history, and "Is Emacs difficult to learn?"

[Phillip Lord]

Emanuel Berg <embe8573@student.uu.se> writes:
>> In the same way, R is stats+programming
>
> What is R?

A programming language designed for doing stats. It's a really, really
bizarre language which messes your head up, but is perfect for stats.

And, yes, there is an emacs package for it. Very good too!

http://ess.r-project.org/

Phil

Re: Emacs history, and "Is Emacs difficult to learn?"

[Rustom Mody]

On Tuesday, July 30, 2013 8:52:53 PM UTC+5:30, Aurélien DESBRIÈRES wrote:
> GNU Emacs is an Extensible Editor.
> 
> Extensible (word) have it's importance in the way that the limit with
> GNU Emacs is you.

Some years back Thien-Thi Nguyen wrote in response to a noob asking why he should learn emacs: (which I promptly saved in my quotes file :-) )
 
real programmers use their brain.
real programmers program their brain.
often, real programmers' brain-programming program is emacs.

Re: Emacs history, and "Is Emacs difficult to learn?"

[Rustom Mody]

On Tuesday, July 30, 2013 9:04:06 PM UTC+5:30, Phil Lord wrote:
> Emanuel Berg  writes:
> > What is R?
> 
> A programming language designed for doing stats. It's a really, really
>> bizarre language which messes your head up, but is perfect for stats.
> 
> And, yes, there is an emacs package for it. Very good too!
> 
> http://ess.r-project.org/

Also worth mentioning -- and theres babel, part of org-mode, part of (of-course) emacs with which one can do some things like piping shell/python -> elisp -> R very neatly
http://orgmode.org/worg/org-contrib/babel/intro.html#meta-programming-language

Re: Emacs history, and "Is Emacs difficult to learn?"

[Emanuel Berg]

aurelien@replicant.io (Aurélien DESBRIÈRES) writes:

> GNU Emacs is an Extensible Editor.
>
> Extensible (word) have it's importance in the way that the limit
> with GNU Emacs is you.

Yes. In that sense, Emacs resembles the Unix/Linux shells, where
you can customize, and extend, in the .rc and .profile files. I
think this should be the rule, rather than the exception, to just
about any piece of software. But it is not - so it is good to have
Emacs and zsh!

> GNU Emacs is not difficult to learn and by the way it will teach you
> Computer Sciences.

The practical side to it, at least. The most important side.

> Try GNU Emacs out of X you will discover and OS in the OS

Yes, and that was the Kon-Tiki point I made a couple of messages
back. But on a Unix/Linux system, it doesn't really matter from
where you run Emacs. X is a windows system, from where you can run
Emacs either in its GUI incarnation (using a WM on top of X), or
in an X terminal (like xterm or urxvt, with 'emacs -nw'), *or* you
could have Emacs in a Linux VT (the tty's). That Emacs is an OS
within the OS is a great point!

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Emacs history, and "Is Emacs difficult to learn?"

[Emanuel Berg]

Rustom Mody <rustompmody@gmail.com> writes:

> Some years back Thien-Thi Nguyen wrote in response to a noob
> asking why he should learn emacs

Unfortunately, no one can be "told" what Emacs is. You have to use
it yourself.

> real programmers use their brain.
> real programmers program their brain.
> often, real programmers' brain-programming program is emacs.

Not only real programmers program their brain. This is the same
thing Muhammad Ali did, bragging at press conference, or people
spending time in jail, always making their beds perfectly, and
counting the number of push-ups they do every day. It is just
something that everybody that has problems, or challenges, in
their lives, can benefit from. A lot.

And: perhaps all this "noob" talk discourages people from making
their first post? (Not saying, that all quiet people are newcomers
to Emacs. But some are.) Perhaps that word shouldn't be used at
all.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Emacs history, and "Is Emacs difficult to learn?"

[Barry Margolin]

In article <87a9l4rs76.fsf@VLAN-3434.student.uu.se>,
 Emanuel Berg <embe8573@student.uu.se> wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> >> depends on how you use spreadsheets. Summing a column is not
> >> programming, but yes, there is a second page, or sheet, to
> >> spreadsheets.

You can also put "IF" expressions in cells.

> >
> > Same as "writing (setq smie-indent-basic 8)" is not programming,
> > indeed.
> 
> No, but that is not the Elisp of Emacs I speak of, when I speak of
> the Elisp of Emacs. That's just an interface, albeit a good one,
> to specify settings.

The very first program I wrote was a BASIC program that was just a bunch 
of PRINT statements, to make some simple ASCII art (it was the command 
insignia from ST:TOS).  Was I not programming, just because it was a 
simple, linear set of statements? I "taught" the computer to do 
something it couldn't previously do. I know it was trivial, but you have 
to start somewhere.

I think that almost anything that tells the computer to perform a set of 
operations can be considered programming. Some programs are more complex 
than others, and some programmers have more skills and know how to make 
the computer jump through more hoops.

It's like many other skills. If someone only knows how to play 
"Chopsticks" on the piano, they're still making music. They're not going 
to get hired as a professional musician, though.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: Emacs history, and "Is Emacs difficult to learn?"

[Emanuel Berg]

Barry Margolin <barmar@alum.mit.edu> writes:

> The very first program I wrote was a BASIC program that was just
> a bunch of PRINT statements, to make some simple ASCII art (it
> was the command insignia from ST:TOS).  Was I not programming,
> just because it was a simple, linear set of statements? I
> "taught" the computer to do something it couldn't previously do.

*Laughter*! Cool! I hope you still have that program.

No, I think *that* was programming, for the reason you tell, but
also because there were several statements, and collectively they
form a program that does something.

> I think that almost anything that tells the computer to perform
> a set of operations can be considered programming.

Well, at least if that is done non-interactively. If you use a
program - a spreadsheet, or a paint program (do to pixel GFX), and
you just use the features of that program - sum a column, draw a
square, etc. - with the tools of that program - I don't consider
that programming.

I wrote some more on this, here:

http://unix.stackexchange.com/a/53842/13136

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Emacs history, and "Is Emacs difficult to learn?"

[Emanuel Berg]

Rustom Mody <rustompmody@gmail.com> writes:

> ... why spreadsheets are just FP in disguise
>
> http://web.cecs.pdx.edu/~black/S3S/PeytonJones.ppt

I tried to print that file with 'lpr', but I got only white pages
with a few goofy chars each. Then I tried to browse it with
Emacs-w3m, but it just displayed gibberish when I chose not to
download it, but instead tried to "display" it. Then, 'file'
revealed:

>> PeytonJones.ppt: Composite Document File V2 Document, Little
>> Endian, Os: Windows, Version 5.1, Code page: 1252, Title: Slide
>> 1, Author: Peyton Jones, Template: Stream, Last Saved By: Simon
>> Peyton-Jones, Revision Number: 105, Name of Creating
>> Application: Microsoft PowerPoint, Total Editing Time:
>> 5d+17:47:27, Create Time/Date: Wed Nov 7 22:57:44 2001, Last
>> Saved Time/Date: Fri Dec 5 20:01:38 2003, Number of Words: 1127

Well, I'm not going to "read" any PowerPoint, that's for sure.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Emacs history, and "Is Emacs difficult to learn?"

[Emanuel Berg]

Chris Van Dusen <cavandusen@gmail.com> writes:

> Here is that article.  The relevant section is IX.
>
> http://www.multicians.org/mepap.html

Are you sure? I just read that, and I couldn't find any
secretaries, or any "don't mention programming". It was about how
good Emacs is, compared to what was there before.

The only interesting thing (that I thought, anyway) was when he
said Emacs has brought about an enthusiasm for Lisp. I had Common
Lisp at university, but I would *never* have done a fraction of
all this Elisp, if it weren't for Emacs. So that's spot on.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Emacs history, and "Is Emacs difficult to learn?"

[gottlieb]

On Tue, Jul 30 2013, Emanuel Berg wrote:

> Rustom Mody <rustompmody@gmail.com> writes:
>
>> [And oldtimers will remember SetL]
>
> Never heard of. What is that, set theory + programming, as in the
> "set language"?

Yes (set language).  Developed at New York University (my home
institution) originally by Jack Schwartz.
The first validated Ada "complier" (it actually was an interpreter) was
written in setl.

allan

Re: Emacs history, and "Is Emacs difficult to learn?"

[Emanuel Berg]

phillip.lord@newcastle.ac.uk (Phillip Lord) writes:

>> What is R?
>
> A programming language designed for doing stats. It's a really,
> really bizarre language which messes your head up, but is
> perfect for stats.
>
> And, yes, there is an emacs package for it. Very good too!
>
> http://ess.r-project.org/

Cool! I like stats, like all boys, I was about to say. Probably
MATLAB draw some inspiration from R, in that case. And possibly
even from FORTRAN, the legacy "number crunching language" number
one. (Or so they say.)

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Emacs history, and "Is Emacs difficult to learn?"

[Emanuel Berg]

gottlieb@nyu.edu writes:

> Yes (set language).  Developed at New York University (my home
> institution) originally by Jack Schwartz.  The first validated
> Ada "complier" (it actually was an interpreter) was written in
> setl.

Cool facts, I really appreciate it.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Emacs history, and "Is Emacs difficult to learn?"

[Rustom Mody]

On Wednesday, July 31, 2013 2:49:15 AM UTC+5:30, Barry Margolin wrote:
> I think that almost anything that tells the computer to perform a set of 
> operations can be considered programming. Some programs are more complex 
> than others, and some programmers have more skills and know how to make 
> the computer jump through more hoops.

I think that computer science is impoverished by the penchants of academic computer scientists.

Analogy: Say I am a physicist and since E = mc2 therefore mass is just energy and therefore we dont need to study mechanics/statics etc.  Just heat light electricity etc is enough.  I dare say this would create a skewed view of physics and create impoverished physicists out of students who came under such a regimen.

In the same vein CSists emphasise algorithms too much over data.
From the typical academic viewpoint: Elisp is just a lisp with some additional features suitable for editor-writing.
From a data viewpoint: Elisp is more different from vanilla lisp than lisp is from C, given its primitive data-structures like buffer, window etc.
Anyone who knows the goings-on of the typical academic setup will know that the first view has more traction there than the second.
And thence follows the reduced respectability of VB, Cobol, sql, spreadsheets as compared to 'serious' languages like C/C++.

Some more of the foibles of us academics in my blog-post and the followup:
http://blog.languager.org/2011/02/cs-education-is-fat-and-weak-1.html

> It's like many other skills. If someone only knows how to play 
> "Chopsticks" on the piano, they're still making music. They're not going 
> to get hired as a professional musician, though.

Heh! In that category myself. My friends and colleagues think I am a musician.
But for me it remains ever a black art how real musicians can take a random tune and add a left-hand in real-time.

Re: Emacs history, and "Is Emacs difficult to learn?"

[Rustom Mody]

On Wednesday, July 31, 2013 10:17:17 AM UTC+5:30, Rustom Mody wrote:
> From a data viewpoint: Elisp is more different from vanilla lisp than lisp is 
> from C, given its primitive data-structures like buffer, window etc.

Meant 'primitive' as in language-primitives ie builtins :-)

Re: Emacs history, and "Is Emacs difficult to learn?"

[Phillip Lord]

Emanuel Berg <embe8573@student.uu.se> writes:

> phillip.lord@newcastle.ac.uk (Phillip Lord) writes:
>
>>> What is R?
>>
>> A programming language designed for doing stats. It's a really,
>> really bizarre language which messes your head up, but is
>> perfect for stats.
>>
>> And, yes, there is an emacs package for it. Very good too!
>>
>> http://ess.r-project.org/
>
> Cool! I like stats, like all boys, I was about to say. Probably
> MATLAB draw some inspiration from R, in that case. And possibly
> even from FORTRAN, the legacy "number crunching language" number
> one. (Or so they say.)


R was originally inspired by S which was a commercial equivalent. But
there are now many. many libraries for R. including things like
bioconductor which is great if you handling biological data.

R by itself doesn't come with an integrated GUI like matlab, although
you can use R studio which is nice (or Emacs which is my poison). It's
main advantage over matlab is you don't have to spend time fighting with
the license server which can be a tremendous pain.

Phil

Re: Emacs history, and "Is Emacs difficult to learn?"

[Stefan Monnier]

> main advantage over matlab is you don't have to spend time fighting with
> the license server which can be a tremendous pain.

Of course, there's also Octave for that.


        Stefan

Re: Emacs history, and "Is Emacs difficult to learn?"

[Emanuel Berg]

Rustom Mody <rustompmody@gmail.com> writes:

> In the same vein CSists emphasise algorithms too much over data.

I agree that the focus on algorithms is uncalled for, but what do
you mean by "data"?

> From the typical academic viewpoint: Elisp is just a lisp with
> some additional features suitable for editor-writing.

Yes, and isn't that correct?

> From a data viewpoint: Elisp is more different from vanilla lisp
> than lisp is from C, given its primitive data-structures like
> buffer, window etc.

I don't know what "Vanilla Lisp" is but I did Common Lisp and
Elisp, and they were virtually identical to me until I learned
some of the fine tunings of Elisp, which all related to the
specific domain, that is Emacs.

But I don't think Lisp (in general, Elisp/CL/etc.) is that far
from C. Or, it depends how you use them. The way I use them, they
are close.

> Anyone who knows the goings-on of the typical academic setup
> will know that the first view has more traction there than the
> second.

Again, I don't understand the "data" viewpoint. Data structures
and algorithms are the same, or very close, in my mind. Lots of
algorithms don't even work - and how could they? - if not for a
specific data structure. (Is this what you mean by "data"?)

> And thence follows the reduced respectability of VB, Cobol, sql,
> spreadsheets as compared to 'serious' languages like C/C++.

SQL is respected. There is nothing wrong with VB, or VBA, as
*languages* (they are just BASIC offshots like all the others),
the problem are those disgusting IDEs, and especially the MS
Access database wizards. From a theory standpoint, they are the
opposite of MVC. From an emotional standpoint, they make me want
to puke. I don't know anything about Cobol. C is highly respect in
theory and practice, perhaps because of Unix, perhaps because it
is so cool. C++ is far from as stable/gentlemanly as C, but it
works, and is fast, with development, and with execution. It is
the language that the man on the street *still* is (by far) most
likely to associate with programming.

Note that there is no "C/C++". Those are two different languages,
with different tools, and with different libraries.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Emacs history, and "Is Emacs difficult to learn?"

[drain]

> Specifically, if someone is interested in introducing Emacs to a
> non-Emacs user, what strategies should they adopt to maximize their
> chances of having a new convert.  I welcome any insights from both the
> victors and the vanquished on the "Convert to or introduce Emacs
> battle".

The key is to tailor Emacs to the needs of the non-user. I was able to get
a (female) art historian completely addicted to Emacs because I took her
dissertation and broke it down into org-mode headlines. I sent her a video
of this process -- how effortless it was -- and also explained how her
thesis would have been much more coherently structured with regular
headlines and subheadlines.

Secondly, I showed her how effortlessly I could format paragraphs.

Thirdly, we originally started out as language exchange partners (she was
correcting my German; I was correcting her English), and she was impressed
with how obsessively organized and stable my system was. Then I showed her
split screen and macros. The following template would automatically be
inserted every single time:

******* (1) "via" und "in the long run"

ORIGINAL

But on the long run I would like to speak per voice chat.

KORREKTUR

But in the long run I would like to speak via voice chat.

ERKLÄRUNGEN

(a) Im Englischen sagt man "in the long run" anstatt von "on the long run."
"In
the long run" ist ein spezieller Ausdruch auf Englisch.

(b) Wir benutzen die Präposition "via" in diesem Zusammenhang anstatt von
"per."

All I do is copy the incorrect text, enter a numeric argument for the Nth
correction, type M-x gt RET and it produces:

******** (1)

ORIGINAL

But on the long run I would like to speak per voice chat.

KORREKTUR



ERKLÄRUNG

. . .

Anyway, the point is, you can't just send someone a video of you editing a
couple different .cpp buffers in multiple windows, or entering commands
into the shell. You have to really convince someone -- in forms he / she
understands -- that Emacs is an optimization machine for ALL forms of text
editing.

But I've been successful with several non-programmers.



--
View this message in context: http://emacs.1067599.n5.nabble.com/Emacs-history-and-Is-Emacs-difficult-to-learn-tp293486p293759.html
Sent from the Emacs - Help mailing list archive at Nabble.com.

Re: Emacs history, and "Is Emacs difficult to learn?"

[Rustom Mody]

On Wednesday, July 31, 2013 11:41:21 PM UTC+5:30, Emanuel Berg wrote:
> Again, I don't understand the "data" viewpoint. Data structures
> and algorithms are the same, or very close, in my mind. Lots of
> algorithms don't even work - and how could they? - if not for a
> specific data structure. (Is this what you mean by "data"?)

> SQL is respected. There is nothing wrong with VB, or VBA, as
> *languages* (they are just BASIC offshots like all the others),
> the problem are those disgusting IDEs, and especially the MS
> Access database wizards. From a theory standpoint, they are the
> opposite of MVC. From an emotional standpoint, they make me want
> to puke. I don't know anything about Cobol. C is highly respect in
> theory and practice, perhaps because of Unix, perhaps because it
> is so cool. C++ is far from as stable/gentlemanly as C, but it
> works, and is fast, with development, and with execution. It is
> the language that the man on the street *still* is (by far) most
> likely to associate with programming.

Well we see differently then.

C programmers think that C has data-structures though they dont think of an int or a char as a data structure.
In fact the opposite is the case: The only data structures C has are int and char (and scalars).  The rest are just storage structures.
Haskell (and from a certain pov lisp) are languages that actually have data structures.

Of course we use the same words and in different ways so heres a map:
What I call a data structure you would probably call a discrete math structure
What you call a data structure I call a pattern of memory layout in a von Neumann machine.

The reason to make this distinction. Consider this C type:
struct S {
  T x; 
  struct S *a, *b; 
}

Does this type represent a doubly linked list of Ts or a binary tree of Ts?

The fact that it could be both (or something still different) implies that C does not have the tools for building genuine data structures, just for memory layouting.

In 1991 I had collected up many such issues about how students brains are getting pickled by being brought up on C. 
[Here with some uptodating http://blog.languager.org/2013/02/c-in-education-and-software-engineering.html ]
It used to be widely cited at one time including the C edition of Code Complete and also some C++ books.

R development environment

[Sebastien Vauban]

Phillip Lord wrote:
> Emanuel Berg <embe8573-oe7qfRrRQfc4M/bo5TPICw@public.gmane.org> writes:
>> phillip.lord-6agwQxOQk07RR8QwpCAWVg@public.gmane.org (Phillip Lord) writes:
>>
>>>> What is R?
>>>
>>> A programming language designed for doing stats. It's a really,
>>> really bizarre language which messes your head up, but is
>>> perfect for stats.
>>>
>>> And, yes, there is an emacs package for it. Very good too!
>>>
>>> http://ess.r-project.org/
>>
>> Cool! I like stats, like all boys, I was about to say. Probably
>> MATLAB draw some inspiration from R, in that case. And possibly
>> even from FORTRAN, the legacy "number crunching language" number
>> one. (Or so they say.)
>
> R was originally inspired by S which was a commercial equivalent. But
> there are now many. many libraries for R. including things like
> bioconductor which is great if you handling biological data.
>
> R by itself doesn't come with an integrated GUI like matlab, although
> you can use R studio which is nice (or Emacs which is my poison). It's
> main advantage over matlab is you don't have to spend time fighting with
> the license server which can be a tremendous pain.

Anybody having a configuration to share, in order to get an R environment such
as the one showed on page 9/50 of the slides
http://projects.iq.harvard.edu/rtc/event/introduction-r?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: R development environment

[Phillip Lord]

Sebastien Vauban <sva-news@mygooglest.com> writes:
> Anybody having a configuration to share, in order to get an R environment such
> as the one showed on page 9/50 of the slides
> http://projects.iq.harvard.edu/rtc/event/introduction-r?


Difficult to say because of the size, but I would imagine that's just
ESS. You can install it with pakage.el and it all works fine. R is easy
enough to install also.

Phil

Re: Emacs history, and "Is Emacs difficult to learn?"

[Emanuel Berg]

drain <aeuster@gmail.com> writes:

> The key is to tailor Emacs to the needs of the non-user. I was
> able to get a (female) art historian completely addicted to
> Emacs because I took her dissertation and broke it down into
> org-mode headlines. I sent her a video of this process -- how
> effortless it was -- and also explained how her thesis would
> have been much more coherently structured with regular headlines
> and subheadlines.
>
> Secondly, I showed her how effortlessly I could format
> paragraphs.

Isn't a thesis something LaTeX would be the natural choice for,
with its from-the-shelf support for a ToC, headers (of all sorts),
footnotes, references, etc.? Of which so much is automated to a
very high degree?

> Anyway, the point is, you can't just send someone a video of you
> editing a couple different .cpp buffers in multiple windows, or
> entering commands into the shell. You have to really convince
> someone -- in forms he / she understands -- that Emacs is an
> optimization machine for ALL forms of text editing.

Yes, I think videos are great for this! At least if the person who
makes the video has the real Emacs fingers, moving the cursor at
Jedi-master speed, killing, yanking, filling, other window,
reading mail, sending a Usenet post, evaluating some Elisp defun,
1-2-3, KO. Irresistible to any and all true techno-warriors.

I done well, I don't think there even need to be a speaker's voice
explaining what happens. Just the sound from the keyboard and some
techno-eurodisco-trance song to get the bloodlust going.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Emacs history, and "Is Emacs difficult to learn?"

[Emanuel Berg]

Rustom Mody <rustompmody@gmail.com> writes:

> The reason to make this distinction. Consider this C type:
> struct S { T x; struct S *a, *b; }
>
> Does this type represent a doubly linked list of Ts or a binary
> tree of Ts?
>
> The fact that it could be both (or something still different)
> implies that C does not have the tools for building genuine data
> structures, just for memory layouting.

Are you saying: C doesn't have hash tables, search trees, etc.,
you have to make them yourself with data types and pointers, and
put them into structs, and then have the algorithm traverse them,
and all this you do manually, with no support from the language?

It doesn't surprise me one bit that Haskell has all that fancy
stuff, because Haskell is much, much more recent, and with a
strong (the strongest?) tilt towards university people (of CS
*and* math), while C is something that were/is very robust in
practice, and is "engineering" in nature (as opposed to
scientific).

Even their *names* illustrate this. C is C because its predecessor
was B. Haskell is Haskell because of a math (?) guy who did
function theory.

Haskell people have neurotic hangups how thing "should" be,
especially with respect to side-effect: they even separate the
"pure" (yuk) part of their programs, so it shouldn't intermingle
with all those toxic side-effects. C people are more like, if it
works, that's the definition of a good program.

But what about *Lisp*? Lisp has lists, obviously, which can be
made into association lists, and just about anything else. Is
there anything more that didn't meet my eyes?

Yes, a struct is just a memory pattern. You are saying, a Lisp
list isn't - is it moving around in memory, is it fragmented, or
is allocation made dynamically based on the elements? Is that the
difference? With pointers, isn't that what you get in C?  Please
explain.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Emacs history, and "Is Emacs difficult to learn?"

[Luca Ferrari]

On Thu, Aug 1, 2013 at 4:17 PM, Emanuel Berg <embe8573@student.uu.se> wrote:

> Isn't a thesis something LaTeX would be the natural choice for,
> with its from-the-shelf support for a ToC, headers (of all sorts),
> footnotes, references, etc.? Of which so much is automated to a
> very high degree?
>



Yes, but maybe for something in the science field, while for other
types of thesis org mode can be a more gentle approach to editing very
large documents.

> Yes, I think videos are great for this! At least if the person who
> makes the video has the real Emacs fingers, moving the cursor at
> Jedi-master speed, killing, yanking, filling, other window,
> reading mail, sending a Usenet post, evaluating some Elisp defun,
> 1-2-3, KO. Irresistible to any and all true techno-warriors.
>

+1
For the average non-emacs users a video tutorial or demo is surely
something much more interesting than a wiki. Most of us buy what we
see, not what is under the hood.

Luca

Re: Emacs history, and "Is Emacs difficult to learn?"

[Rustom Mody]

On Thursday, August 1, 2013 8:09:08 PM UTC+5:30, Emanuel Berg wrote:
> 
> Yes, a struct is just a memory pattern. You are saying, a Lisp
> list isn't - is it moving around in memory, is it fragmented, or
> is allocation made dynamically based on the elements? Is that the
> difference? With pointers, isn't that what you get in C?  Please
> explain.

Well... I dont know if this is the best forum for these discussions :-)

In short: A language becomes more powerful when it has less...

Think of registers and interrupts disappearing from assembly to C, making C better than assembly in 95% use-cases.  Now if you were an assembly programmer, you would pooh-pooh a C (like) language: "How can having less make it a better language?"

It makes it better because one's thoughts have more clarity.

You may remember the quote from Bruce Lee: I am not afraid of the man who knows 10 thousand kicks. I am afraid of the man who has practiced one kick 10 thousand times.  Likewise in programming, doing few things well gets you further than doing many things sub-optimally.

And so assignment disappearing from C to haskell makes haskell programmers able to have better thoughts [Well they say 100% of the time; I say 80% of the time ;-)  ]

I could go on eg why lisp can be C-like or haskell-like depending on how you use it etc etc.  Or answering 

> Are you saying: C doesn't have hash tables, search trees, etc.,
> you have to make them yourself with data types and pointers, and
> put them into structs, and then have the algorithm traverse them,
> and all this you do manually, with no support from the language?

However as I said this is getting too too OT for this group.

If you want we can continue off-list.
Do read my blog though http://blog.languager.org/  in case you find may my ideas painful to your delicate digestion :-)

Re: Emacs history, and "Is Emacs difficult to learn?"

[Emanuel Berg]

Rustom Mody <rustompmody@gmail.com> writes:

>>  Yes, a struct is just a memory pattern. You are saying, a Lisp
>> list isn't - is it moving around in memory, is it fragmented, or
>> is allocation made dynamically based on the elements? Is that
>> the difference? With pointers, isn't that what you get in C?
>> Please explain.
>
> Well... I dont know if this is the best forum for these
> discussions :-)
>
> In short: A language becomes more powerful when it has less...
>
> Think of registers and interrupts disappearing from assembly to C,
> making C better than assembly in 95% use-cases.  Now if you were
> an assembly programmer, you would pooh-pooh a C (like) language:
> "How can having less make it a better language?"
>
> It makes it better because one's thoughts have more clarity.
>
> You may remember the quote from Bruce Lee: I am not afraid of the
> man who knows 10 thousand kicks. I am afraid of the man who has
> practiced one kick 10 thousand times.  Likewise in programming,
> doing few things well gets you further than doing many things
> sub-optimally.
>
> And so assignment disappearing from C to haskell makes haskell
> programmers able to have better thoughts [Well they say 100% of
> the time; I say 80% of the time ;-) ]
>
> I could go on eg why lisp can be C-like or haskell-like depending
> on how you use it etc etc.  Or answering
>
>> Are you saying: C doesn't have hash tables, search trees, etc.,
>> you have to make them yourself with data types and pointers, and
>> put them into structs, and then have the algorithm traverse
>> them, and all this you do manually, with no support from the
>> language?
>
> However as I said this is getting too too OT for this group.
>
> If you want we can continue off-list.  Do read my blog though
> http://blog.languager.org/ in case you find may my ideas painful
> to your delicate digestion :-)

OK, the international press is content with that answer.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Emacs history, and "Is Emacs difficult to learn?"

[Stefan Monnier]

> Think of registers and interrupts disappearing from assembly to C, making
> C better than assembly in 95% use-cases.  Now if you were an assembly
> programmer, you would pooh-pooh a C (like) language: "How can having less
> make it a better language?"

It goes even further back: assembly is better than raw machine code
because it doesn't let you see the raw byte encoding of your
instructions (which prevents you from jumping in the middle of an
instruction, even though that can be useful when trying to shave off
a few bytes).


        Stefan

Re: Emacs history, and "Is Emacs difficult to learn?"

[Rustom Mody]

On Thursday, August 1, 2013 9:12:45 PM UTC+5:30, Stefan Monnier wrote:
> It goes even further back: assembly is better than raw machine code
> because it doesn't let you see the raw byte encoding of your
> instructions (which prevents you from jumping in the middle of an
> instruction, even though that can be useful when trying to shave off
> a few bytes).

Not sure how to parse that:

a. If you are saying having access to the encoding of instructions can sometimes help one to choose more intelligently than a software like an assembler, yeah along with clock-counting, Ive enjoyed that passtime.

b. If you are saying jumping into the middle of an instruction can be useful, well I confess this is beyond my ken.  For one I believe that in assembly alone with arithmetic on the location-counter that should be possible.  On the other hand I dont know how to do that without getting into undefined instruction issues.

RE: Emacs history, and "Is Emacs difficult to learn?"

[Drew Adams]

> And so assignment disappearing from C to haskell makes haskell programmers
> able to have better thoughts [Well they say 100% of the time; I say 80% of
> the time ;-)  ]

See John Hughes's classic paper, "Why Functional Programming Matters", 1984:
http://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf

From the Introduction:

 "The special characteristics and advantages of functional programming are often
  summed up more or less as follows. Functional programs contain no assignment
  statements, so variables, once given a value, never change. More generally,
  functional programs contain no side-effects at all....

  Such a catalogue of "advantages" is all very well, but one must not be surprised
  if outsiders don't take it too seriously. It says a lot about what functional
  programming is not (it has no assignment, no side effects, no flow of control)
  but not much about what it is. The functional programmer sounds rather like a
  medieval monk, denying himself the pleasures of life in the hope that it will
  make him virtuous. To those more interested in material benefits, these
  "advantages" are not very convincing....

  It is a logical impossibility to make a language more powerful by omitting
  features, no matter how bad they may be....

  Even a functional programmer should be dissatisfied with these so-called
  advantages, because they give him no help in exploiting the power of
  functional languages. One cannot write a program which is particularly lacking
  in assignment statements, or particularly referentially transparent. There is
  no yardstick of program quality here, and therefore no ideal to aim at."

That motivates the paper, but the paper itself is about why functional
programming really *does* matter: what it offers that is additional and different,
and not just what it omits or avoids.  I heartily recommend it.

(http://www.emacswiki.org/emacs/DrewAdams#WhyFunctionalProgrammingMatters)

Re: Emacs history, and "Is Emacs difficult to learn?"

[Emanuel Berg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> It goes even further back: assembly is better than raw machine
> code because it doesn't let you see the raw byte encoding of
> your instructions ...

Are you saying, assembly has encodings (words) for instructions,
registers, etc., instead of the bitsrings (that they represent),
so you can at least separate them from the bitstring data, instead
of just having an (seemingly) endless bitstring?

> (which prevents you from jumping in the middle of an
> instruction, even though that can be useful when trying to shave
> off a few bytes).

?

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Emacs history, and "Is Emacs difficult to learn?"

[Barry Margolin]

In article <mailman.2321.1375374479.12400.help-gnu-emacs@gnu.org>,
 Drew Adams <drew.adams@oracle.com> wrote:

>   It is a logical impossibility to make a language more powerful by omitting
>   features, no matter how bad they may be....

While it may not make it "more powerful", it may make it more likely to 
produce correct programs.

For instance, by removing features related to pointers, you can get a 
language that makes buffer overflows very unlikely.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: Emacs history, and "Is Emacs difficult to learn?"

[Emanuel Berg]

Drew Adams <drew.adams@oracle.com> writes:

> it has no ... no side effects

Perhaps not the functions, but the program must at least produce
some persistent result, otherwise why use it?

> no flow of control

Yeah?

> The functional programmer sounds rather like a medieval monk,
> denying himself the pleasures of life in the hope that it will
> make him virtuous.

Normally I like that sort of stuff, but in programming, it doesn't
fit because there are one million ways to do everything. There
isn't a true path. You can use iteration in SML and recursion in
C - just go nuts, as long as it works, and you enjoyed doing it. I
just can't see the paradigm be that decisive.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Emacs history, and "Is Emacs difficult to learn?"

[Óscar Fuentes]

Rustom Mody <rustompmody@gmail.com> writes:

> b. If you are saying jumping into the middle of an instruction can be
> useful, well I confess this is beyond my ken. For one I believe that
> in assembly alone with arithmetic on the location-counter that should
> be possible. On the other hand I dont know how to do that without
> getting into undefined instruction issues.

When I was a kid with a Sinclair ZX Spectrum, I found that cracking
videogames was more fun than playing them. One common obfuscation
technique consisted on prefixing chunks of instructions with bytes that
confused the disassembler.

But one day confronted a self-decryption method that processed the
game's binary, then jumped into itself but at a "wrong" instruction
offset, which had the effect of executing a very different sequence of
instructions that performed another decrypting round with a different
method.

The show of byte-mingling capability and the displayed mastery on Z80
machine code was truly impressive, but in the end it was fairly easy to
crack, albeit quite a bit boring after the first impression waned.

Re: Emacs history, and "Is Emacs difficult to learn?"

[Stefan Monnier]

> b. If you are saying jumping into the middle of an instruction can be
> useful, well I confess this is beyond my ken.  For one I believe that in
> assembly alone with arithmetic on the location-counter that should be
> possible.  On the other hand I dont know how to do that without getting into
> undefined instruction issues.

You can do it in assembly, just like you an do it in C: by making
assumptions about how the compiler/assembler works.

But yes, jumping in the middle of an instruction can be useful, if the
"tail" of the byte-sequence encoding that instruction "happens" to be
a valid instruction.  E.g. back in the 68000, to skip a 4B instruction
you could either use a jump, or (more efficient) place that 4B
instruction in the "immediate constant" part of a CMP (compare)
instruction whose result you just don't use (i.e. this CMP instruction
was just used as a 6B no-op whose last 4B was free for you to choose as
you please).

Other things you can't do in assembly (without again making assumptions
about the way the assembler works, i.e. going down to machine code) is
to self-modify the code.  Or to use some of the instruction bytes as
data-constants (in case they happen to contain the same bit-pattern).


        Stefan

Re: Emacs history, and "Is Emacs difficult to learn?"

[Rustom Mody]

On Thursday, August 1, 2013 10:03:28 PM UTC+5:30, Barry Margolin wrote:
> For instance, by removing features related to pointers, you can get a 
> language that makes buffer overflows very unlikely.

Nice example!

I maintain two FP-related lists:

a. A 'lost booty' of features list http://blog.languager.org/2012/10/functional-programming-lost-booty.html

b. FP invades the mainstream list http://blog.languager.org/2013/06/functional-programming-invades.html

If there are more examples to be added (as you will see majority come from lisp) please let me know!


> While it may not make it "more powerful", it may make it more likely to 
> produce correct programs.


Well...
Its true as a fact but not so good as an attitude.
In my experience people get driven away by even a faint whiff of (what Hughes calls) monkishness.

How to kid the kids into liking spinach is always a challenge for Momma!

Re: Emacs history, and "Is Emacs difficult to learn?"

[Pascal J. Bourguignon]

Emanuel Berg <embe8573@student.uu.se> writes:

> Note that there is no "C/C++". Those are two different languages,
> with different tools, and with different libraries.

In the same way there's no scheme/emacslisp or emacslisp/common-lisp
languages, but you can still write programs that run on both scheme,
emacs lisp and common lisp!

http://www.informatimago.com/develop/lisp/com/informatimago/small-cl-pgms/intersection-r5rs-common-lisp-emacs-lisp/


Oh, and there's no csh/fortran or fortran/c, but you can still run this
program on both sh, csh, fortran and C:

https://groups.google.com/forum/#!msg/comp.lang.lisp/i7CpbNGueXw/jZ5Hhk1iUO4J


But honestly, it's with C and C++ that you can write functions that are
identical and that will compile in both languages into the same
semantics, without adding any compatibility layer.  Even for emacs lisp
vs. common lisp you need at least (require 'cl), and I don't say the
macrology required to run scheme in CL or CL in scheme, just check the
first url above.


[pjb@kuiper :0.0 ~]$ g++ -Werror -Wall -c -o f_c++.o f.c
[pjb@kuiper :0.0 ~]$ gcc -Werror -Wall -c -o f_c.o   f.c
[pjb@kuiper :0.0 ~]$ cat f.c
int f(int x){
    return((0==x)    
           ?1
           :(x*f(x-1)));}
[pjb@kuiper :0.0 ~]$ 

With lisp, you'd have at least to define a macro:

(defmacro define ((fname &rest lambda-list) &body body) 
  `(defun ,fname ,lambda-list ,@body))

to be able to read and run:

(define (f x) (if (= 0 x) 1 (* x (f (- x 1)))))

in both emacs lisp, common lisp and scheme.  Therefore here you could
rightly argue that there's no scheme/common lisp, but two languages.



But not for C/C++, I don't think so.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.  
You know you've been lisping too long when you see a recent picture of George 
Lucas and think "Wait, I thought John McCarthy was dead!" -- Dalek_Baldwin

Re: Emacs history, and "Is Emacs difficult to learn?"

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

> With lisp, you'd have at least to define a macro:
>
> (defmacro define ((fname &rest lambda-list) &body body) `(defun
> ,fname ,lambda-list ,@body))
>
> to be able to read and run:
>
> (define (f x) (if (= 0 x) 1 (* x (f (- x 1)))))
>
> in both emacs lisp, common lisp and scheme.  Therefore here you
> could rightly argue that there's no scheme/common lisp, but two
> languages.
>
> But not for C/C++, I don't think so.

OK, if I made an effort to be as correct as possible, but still
ignoring details that shouldn't be allowed to mess up general
reasoning if they don't matter, I'd say:

- there is C (without classes etc.; i.e., without C++)
- there is C++ (*with* C, almost always).

So there *is* a C/C++, and that is C++!

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Emacs history, and "Is Emacs difficult to learn?"

[Emanuel Berg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> But yes, jumping in the middle of an instruction can be useful,
> if the "tail" of the byte-sequence encoding that instruction
> "happens" to be a valid instruction.  E.g. back in the 68000, to
> skip a 4B instruction you could either use a jump, or (more
> efficient) place that 4B instruction in the "immediate constant"
> part of a CMP (compare) instruction whose result you just don't
> use (i.e. this CMP instruction was just used as a 6B no-op whose
> last 4B was free for you to choose as you please).

So, jump = compare(... jump ...), in that case?

Interesting. For sure, that is *far* from FP! What would you gain
with the compare method, um, "compared" to just jumping?

By the way, I think *this* (and the C pointers) is the monk
stuff. And a bit of the point with C is that you have memory
addressing, the binary arithmetic, etc., *if* you need it. You can
get as close as you wish. Not the least for programming for a
specific, peculiar platform... (embedded systems, etc.) Yes, Lisp
(and FP in general) is much more gentle. But let's not get carried
away: if a decent programmer (to begin with) does C for say, one
year, just because it is not FP does not mean the code is without
discipline, not modular, etc. And there are no overflows due to
pointers! That guy will be a very self-confident juggler.

> self-modify the code

?

> Or to use some of the instruction bytes as data-constants (in
> case they happen to contain the same bit-pattern).

This is what I said (almost)! I guess there were no assigned
bitstring to append as a prefix to "quote" such constants? (Not
enough room?)

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Emacs history, and "Is Emacs difficult to learn?"

[drain]

> Isn't a thesis something LaTeX would be the natural choice for,
> with its from-the-shelf support for a ToC, headers (of all sorts),
> footnotes, references, etc.? Of which so much is automated to a
> very high degree? 

I prefer the minimalism of org-mode. LaTex clutters the buffer with code.
Secondly, I don't even like the output. I wish all books would be printed
org-mode documents. Clean and pure. Org-mode should be the standard visual
grammar.

> Yes, I think videos are great for this! At least if the person who
> makes the video has the real Emacs fingers, moving the cursor at
> Jedi-master speed, killing, yanking, filling, other window,
> reading mail, sending a Usenet post, evaluating some Elisp defun,
> 1-2-3, KO. Irresistible to any and all true techno-warriors.

Yes, I often treat my videos as performances: like speed runs of Quake.
Although not quite, since Emacs has better gameplay.

> I[f] done well, I don't think there even need to be a speaker's voice
> explaining what happens. Just the sound from the keyboard and some
> techno-eurodisco-trance song to get the bloodlust going.

I have a scratch.org buffer I continuously switch to: I use this to explain
what I am doing (and also to showoff rapid buffer switching). I /hate/
videos
with any music though. 

The point is, Emacs should speak for itself.



--
View this message in context: http://emacs.1067599.n5.nabble.com/Emacs-history-and-Is-Emacs-difficult-to-learn-tp293486p293981.html
Sent from the Emacs - Help mailing list archive at Nabble.com.

Re: Emacs history, and "Is Emacs difficult to learn?"

[Emanuel Berg]

drain <aeuster@gmail.com> writes:

> I prefer the minimalism of org-mode. LaTex clutters the buffer
> with code.  Secondly, I don't even like the output. I wish all
> books would be printed org-mode documents. Clean and
> pure. Org-mode should be the standard visual grammar.

Oh yeah? Do you have a PDF example of the result? (Or whatever
output file you get.) And the corresponding "source", although you
said there weren't any? That way, I could compare to my LaTeX
stuff, both source and result (.tex and .pdf). Perhaps you are
right. But from my experience with LaTeX, you can get just about
any result that you can find in a book shop or public library, at
the very least. So there isn't any "I don't even like the output"
- you can get whatever you like.

> The point is, Emacs should speak for itself.

Yes, and not just Emacs. I don't know how many times I've seen
people get stuck on the deliverer of a message, or the message's
form. I show them something, and they instantly scream "after the
title, there shouldn't be a dot!" (or period, full stop) - and
that guy thinks he is on top, because he is right, but I know that
he is also incapable of assessing information, and making a
distention of what matters and what doesn't.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Emacs history, and "Is Emacs difficult to learn?"

[drain]

> But from my experience with LaTeX, you can get just about
> any result that you can find in a book shop or public library, at
> the very least. So there isn't any "I don't even like the output"
> - you can get whatever you like. 

I make my case based on its powerful minimalism. As soon as the general
population see any code, they run away scared.

However, it is still possible to boil the frog by gradually raising the
heat: now that I've gotten these people addicted to this text editing
environment, perhaps I can get them to start writing more code. Generally
the beginning involves a lot of hand-holding and blind copy / paste of
Elisp code blocks into the .emacs. It does take up a lot of my time, but in
the end, a dutiful member of the church is dedicated to proselytization.

LaTex may have infinite output possibilities, but doesn't it still require
writing a lot of code in the actual buffer? What's nice about org-mode is
that the printed output is the same as the printed input.




--
View this message in context: http://emacs.1067599.n5.nabble.com/Emacs-history-and-Is-Emacs-difficult-to-learn-tp293486p294069.html
Sent from the Emacs - Help mailing list archive at Nabble.com.

LaTeX (was: Re: Emacs history, and "Is Emacs difficult to learn?")

[Emanuel Berg]

drain <aeuster@gmail.com> writes:

>> But from my experience with LaTeX, you can get just about any
>> result that you can find in a book shop or public library, at
>> the very least. So there isn't any "I don't even like the
>> output" - you can get whatever you like.
>
> I make my case based on its powerful minimalism. As soon as the
> general population see any code, they run away scared.

Aha, I thought we were comparing LaTeX and org-mode (and I don't
know anything about org-mode) as technologies, not with respect to
the general population.

Yes, LaTeX isn't the easiest thing to use. Just the fact that you
need to compile it (and especially if you have several files, for
example references with BibTeX), and that the whole process
produces a pack of intermediate representation and/or (?) metadata
files in the bargain, could be a regular horror show to some
people. Or even more common: something they just wouldn't do.

I even used an old-school *makefile* to do the job. But I don't
know how common that is (but it wasn't my idea, either).

I did lots of LaTeX when I did my bachelor paper (that was some 50
pages). Actually, I learned more from that (the LaTeX), than from
what was the academic subject. I thought like this: if I get *one*
paper to look *exactly* the way I want it to - with ToC, headers,
subheaders, figures, page numbering, and references - I would
*never* have to do it again, because then I would just re-use all
those settings in the preamble (use the document as a skeleton),
and they'd work, and I'd just have to worry about *writing*.

So instead of going to the library, and read the whole history, as
I would with a GPPL, I used Google, and the SX LaTeX site. The
LaTeX people are very helpful, and they understand
perfectionism. If you want something lowercased, some paragraph
aligned some other way, whatever, just ask, and they will not be
dismissive. The SX Unix & Linux site or actually just about any
programmers' forum I've ever visited, can't compare with the
"good karma" of the LaTeX people.

> LaTex may have infinite output possibilities, but doesn't it
> still require writing a lot of code in the actual buffer?

Yes *and* no - LaTeX requires lots of code to get the paper
exactly the way you want it, and especially for advanced documents
- but once done, you have it.

The coolest thing I did (again, with help from the LaTeX
community), is this interactive "Public Library Ad". That's
original, don't you think? :)

.tex & PDF:
http://user.it.uu.se/~embe8573/latex/matte.tex
http://user.it.uu.se/~embe8573/about/matte.pdf

> What's nice about org-mode is that the printed output is the
> same as the printed input.

That sounds like - text mode :) Like I said, if you provide me
with an example, that would be very interesting to see!

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573